Repair qualification process contracts, recovery isolation and completion gates - #31
Merged
Merged
Conversation
Keep C09/C10/C13 expected assertions and full release requirements unchanged. Align materialized configuration docs with the pinned loader and v7 project-scoped transport; run the same live runtimes in recovery mode without claiming a full release pass.
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.
Repairs
SubagentStart subagent-start-fixture.pyto the generic proxy selected by the active compatibility context. Project role/hook scope and the recognized-error-only ephemeral fallback are unchanged.recoveryto the existing runner-allowed workflow. It selects exactly C09/C10/C13 through the same v7 runtimes as full. Targeted success always hasrelease_gate_passed=false; full release qualification remains C01–C16.Executable verification
The test-only commit
f25fb15e4664a7afab371f696eae71dedd8876fepreceded fixes. CI #102 ran 134 distribution/harness tests and exposed exactly four failures: C13 argv, C10 root-checkout isolation, C09 timeout and C09 missing output.Final PR head
ef76142edb4d435e87c5a3010f223c7cf05b22da: CI #106 passed all 7 jobs. Distribution/harness suite: 140 tests, OK. Qualification execution-boundary tests also ran successfully in all six core combinations: Ubuntu/macOS/Windows with Python 3.11/3.14, in addition to the existing product suite. Evidence template validation, candidate metadata, deterministic archive build and whitespace checks passed.Tests execute the generated C13 command and real installer/Git/start/checkpoint/recovery processes for C10. Only the live Codex call is substituted in the offline C10 lifecycle driver. A separate regression checks runner config restoration after an exception without reverting refreshed authentication. Offline tests do not create live capability evidence.
Scope and remaining live confirmation
No product .agents/.codex payload, implementation specification, baseline, sandbox/approval permissions or full release requirements were changed. The audit records official documentation and pinned upstream source paths in
docs/CODEX_QUALIFICATION_EXECUTION_AUDIT_2026-09-05.md.No self-hosted workflow was dispatched. Next manual run: existing qualification workflow, main, mode=recovery. This patch does not claim to fix the upstream ephemeral parent-thread error or prove that C09's deliberately low threshold will finish live. Those results remain subject to the targeted run; incomplete evidence now fails closed.