fix(governance): make the checkpoint regressions state-independent (WO-024-P-G1-C2) - #99
Merged
KayzenRoot merged 1 commit intoSep 17, 2026
Conversation
…O-024-P-G1-C2)
The two checkpoint regressions added by WO-024-P-G1-C1 read the working-tree
checkpoint as the promotion base, so they could not pass once the tree holds the
promoted checkpoint that WO-024-P produces. That made Validate unreachable for
the final promotion (hosted run 35234129663: 2 failed, 703 passed).
Both regressions now synthesize a pre-promotion checkpoint and its promoted
successor from the contract's own expectations, deterministically and separately
from the live checkpoint:
- the promotion base is never the live (possibly promoted) checkpoint, and the
promoted checkpoint is never presented to the contract as that base;
- the no-op negative fixture is rejected: the "active status without pending
items" case must actually remove a pending item, and the matrix asserts it did;
- negatives preserved: unknown status, residual pending in the promoted state,
missing canonical section, stale next step, empty checkpoint and an incomplete
active state all stay FAIL/UNKNOWN;
- a new regression runs the whole matrix with document_text returning the
promoted state, proving the tests hold in either legitimate tree state.
No guard was loosened: require_wo024p_checkpoint_semantics and
checkpoint_current() are untouched, and the patch changes no production path.
WO-024-P-G1-C2 is self-hosted as a separate bounded corrective work order: exact
base, closed allowlist, single authorized-base marker, no canonical/migration/
workflow/dependency/release delta, auto-merge unarmed, and explicitly outside the
active promotion pair {WO-024-G1, WO-024-P}.
HIVE Review Evidence — WO-024-P-G1-C2
Sol Review State: AWAITING_SOL Workflow run: https://github.com/KayzenRoot/hive/actions/runs/35237840264 |
KayzenRoot
commented
Sep 17, 2026
KayzenRoot
left a comment
Owner
Author
There was a problem hiding this comment.
SOL FINAL AUDIT
VERDICT: APPROVED
Audited exact HEAD: fa43b33
Authorized base: a5cc341
Work order: WO-024-P-G1-C2
Scope is bounded to exactly 3 authorized governance/test paths. No canonical Project Brain, product, migration, dependency, workflow, ruleset or release path changed. The stateful checkpoint regressions are now independent of the physical working-tree checkpoint, no-op negative mutation is rejected, and strict promotion/checkpoint guards remain unchanged.
Hosted exact-head evidence, run 35237840264:
- Validate: PASS
- Integration health: PASS
- Review Evidence: PASS
- backend: 709 passed, 0 failed
- dashboard: 34 passed
- canonical verifier: 17 PASS
- secret scan: 211 PASS
- ruff/mypy/dashboard lint/typecheck/build/docker compose: PASS
Pre-merge governance rechecked: Ready, mergeable clean, main unchanged at authorized base, ruleset 21934284 active/strict/squash-only/zero bypass, zero unresolved threads, auto-merge UNARMED.
Secondary documentation-currentness evidence-field inconsistency is acknowledged as IMPORTANT follow-up but is nonblocking for this corrective increment because canonical DoD rows and closure_candidate use their own deterministic documentation/deployment verifiers. It must not expand this PR.
APPROVED FOR EXACT-HEAD SQUASH under HIVE-ADR-019.
KayzenRoot
deleted the
governance/wo024-p-g1-c2-stateful-test-correction
branch
September 17, 2026 15:58
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Revisão do executor - WO-024-P-G1-C2 (correção dos testes stateful)
1. Resumo
Correção mínima, test-only e auto-hospedada, que remove o último bloqueio objetivo do
WO-024-P: as duas regressões de checkpoint passam a ser independentes do estado físico daárvore de trabalho e funcionam tanto no estado pré-promoção quanto no estado final promovido.
Nenhum guard foi afrouxado, nenhum caminho canônico foi tocado e o par de promoção ativo
permanece exatamente
{WO-024-G1, WO-024-P}. O PR #98 e os arquivos canônicos não foramalterados.
2. As duas falhas e a correção
O incremento anterior (WO-024-P-G1-C1) acrescentou regressões que liam o checkpoint da árvore
de trabalho como base da promoção:
test_checkpoint_current_accepts_both_legitimate_statesentregava a árvore viva arequire_wo024p_checkpoint_semantics; na árvore promovida a mesma árvore já é o checkpointfinal, e o contrato corretamente rejeita
(
WO-024-P promotion base must contain exactly the remaining closure pending items).test_checkpoint_current_fails_closed_on_malformed_or_stale_statesconstruía o caso negativoremovendo
- stabilization.da árvore viva; após a promoção a remoção era inócua e a variantecoincidia com o checkpoint promovido válido (
('active status without pending items', 'PASS')).Correção aplicada (somente testes):
synthesized_checkpoint_pair()constrói, de forma determinística e a partir das expectativasdo próprio contrato, um checkpoint pré-promoção e o seu sucessor promovido,
independentemente do estado da árvore. O checkpoint vivo nunca é usado como base de promoção,
e o checkpoint promovido nunca é apresentado ao contrato como base.
realmente remove um item pendente: a matriz verifica isso explicitamente
(
assert without_one_pending != base_texte o item não permanece no texto), rejeitandoqualquer substituição no-op.
promovido, seção canônica ausente, next step obsoleto, checkpoint vazio e estado ativo
incompleto — todos continuam
FAIL/UNKNOWN, e nenhum pode virarPASS.test_checkpoint_regressions_hold_with_a_promoted_working_treeexecuta aasserção de contrato, o verificador nos dois estados e toda a matriz negativa com
document_textretornando o estado promovido, provando que os testes valem nos doisestados legítimos.
require_wo024p_checkpoint_semantics,checkpoint_current()e todos os guards fail-closed deprodução/governança permanecem intactos (nenhuma linha de
scripts/v01_closure_sprint.pyfoitocada).
3. Prova de independência de estado
pytest backend/tests/test_v01_closure_sprint.pycom a árvore pré-promoção (estado atual da main)f7b5ab74…, restaurado depois)pytest backend/tests/test_review_evidence.pyna árvore promovidacheckpoint_current()na base sintetizada, no promovido sintetizado e na árvore viva4. Governança auto-hospedada
WO-024-P-G1-C2foi registrado emscripts/review_evidence.pycom base exataa5cc341375a0cc067edc52db4ff2dc36b66a8c00e allowlist fechada (backend/tests/test_review_evidence.py,backend/tests/test_v01_closure_sprint.py,scripts/review_evidence.py). O contrato do corretivoexige: branch base
main, exatamente um marcadorHIVE-AUTHORIZED-BASEigual à base, delta nãovazio, nenhum caminho fora do allowlist, nenhum arquivo de promoção canônica, nenhum
Project Brain/canônico, nenhuma migration/workflow/dependency/release, par de promoção ativo
inalterado e auto-merge UNARMED. A evidência textual emitida registra explicitamente:
checkpoint_regressions_state_independent=True,live_checkpoint_never_a_promotion_base=True,no_op_negative_fixture_rejected=True,guards_unchanged=require_wo024p_checkpoint_semantics,checkpoint_current,active_promotion_pair_unchanged=True,corrective_outside_active_pair=True,v0.1_promotion_performed=False,v0.1_completion_claim=False.Regressões adicionadas em
backend/tests/test_review_evidence.py: work order suportado no baseexato; base errada rejeitada; delta vazio e caminho extra rejeitados; tentativa de incluir o par
canônico de promoção rejeitada; marcador ausente/duplicado/malformado rejeitado; work order
desconhecido continua fail-closed; texto de evidência de governance emitido com os fatos de
não-promoção.
5. Arquivos alterados
backend/tests/test_v01_closure_sprint.pybackend/tests/test_review_evidence.pyscripts/review_evidence.pyExatamente os três caminhos do allowlist; nenhum quarto arquivo foi necessário (
generate_maps.py --checkpassou sem regeneração). Nenhum arquivo canônico, de produto, workflow, dependência, migration ou release foi tocado.6. Testes e resultados
python -m pytest backend/tests/test_v01_closure_sprint.py -qpython -m pytest backend/tests/test_review_evidence.py -qpython scripts/verify_canonical_sources.pypython scripts/generate_maps.py --checkpython scripts/check_secrets.pypython -m ruff format --check/ruff check .python -m mypypython scripts/validate.py7. Identidade e estado
governance/wo024-p-g1-c2-stateful-test-correction(criada da main exata, não da branch do PR docs(project-brain): promote the final V0.1 closure checkpoint (WO-024-P) #98).a5cc341375a0cc067edc52db4ff2dc36b66a8c00.fa43b33a5cfb6b5b25b85a5da9f0c129d0e2ea3e.HIVE-WORK-ORDER: WO-024-P-G1-C2e umHIVE-AUTHORIZED-BASEexato.103d1fe46c3ff589fb69854fd4626153c8487835, mesma branch, mesmo diff canônico de dois arquivos.13-CHECKPOINT.md,CANONICAL-SHA256SUMS.txt): não alterados neste incremento.21934284: ativo e inalterado (squash-only, zero bypass); auto-merge UNARMED; sem merge, tag ou release; nenhum trabalho pós-V0.1 iniciado.8. Riscos pendentes
documentation_currentness_entry()não é usado para produzirdocumentation_entriesda evidência de closure, que hoje se auto-afirmamPASSguardadas apenas por existência de arquivo; a entradadeploymentfalharia com o verificador real (12-LOCAL-DEPLOYMENT.mdnão contémHIVE_DATA_ROOT).Update de checkpoint proposto: NONE — este incremento não promove V0.1 e não altera o checkpoint.