Skip to content

Complete the bounded incremental-review pilot and final candidate gate #109

Open

Description

@BaseInfinity

Goal

Finish the measured bounded-correction pilot that underpins the 1.0 claim of bounded autonomous delivery.

Required invariant

Bounded incremental checkpoints may reduce repeated review scope, but the completion boundary must still prove the assembled candidate. A correction budget is cumulative for one root task and cannot be reset by renaming a prompt, creating another commit, or reopening the same plan.

Landed foundation

PR #120 added the cadence ledger, summary tooling, and initial pilot contract. #158 now rejects forbidden reviewer tool use, and #157 truthfully classifies partial outcomes. Their completion does not permit a review exception or automatic retry.

Frozen v4 result — 2026-08-23

  • Worktree: /Users/stefanayala/codex-sdlc-issue109-v4
  • Branch: fix/issue-109-bounded-incremental-v4
  • Base/HEAD: a07fc3d3fb77767de4c6e677e24bce628256668a
  • Staged candidate tree: 6f7c46cda02685feaf27eabe45e83c7fd1d604b2
  • Focused proof: benchmark 16/16 and roadmap 15/15.
  • Canonical proof: 11/11; fingerprint sha256:9250d3fec6f4bf36e0dfb46be85341df4ec01bcc92440377f6b636bf3ac10717.
  • Maintainer 1.0 decision: tune. Retain bounded completion-boundary dual review for high-risk/proof/security/release work, keep ordinary work risk-tiered, and continue measurement after 1.0.
  • The single bounded final gate was consumed without certification. Fable High attempted forbidden Bash use; the runner classified non-transient invalid_execution, recommended no retry, cancelled the incomplete Sol peer, and wrote an explicitly non-certifying partial receipt.
  • No commit, push, PR, or merge occurred. The candidate and recovery stash remain frozen. Do not resume obsolete v2/v3/v4 gates.

Current dependencies

  1. fix(review): prevent Fable built-in tools before required review #167 must provide a Fable lane that prevents forbidden built-in tools before required review. Detection alone is not a usable release gate.
  2. Enforce Sol High implementation and High-only planning/review #86 implements the current owner decision that Sol High is the only autonomous Sol effort and removes the former xhigh maintainer exception.
  3. After both integrate, create an explicitly authorized fresh Complete the bounded incremental-review pilot and final candidate gate #109 replan/checkpoint from then-current main. Carry the evidence delta recoverably; do not reset cumulative correction or proof accounting.

1.0 completion criteria

Stop rule

No review exception is available. Do not retry the v4 gate, deliver its partial receipt, reuse #158's exception, or continue under an autonomous xhigh policy.

Activity

  1. BaseInfinity commented on Aug 9, 2026

    @BaseInfinity
    OwnerAuthor

    Dogfooding clarification from m180-jumpseat:

    The desired workflow is not "commit the known-bad baseline after the first review." It is a review checkpoint over the current working tree.

    After an initial full codex review --uncommitted, Codex should be able to:

    • retain an immutable identifier/hash for the reviewed HEAD + index + worktree state;
    • retain the findings and their resolved/unresolved state;
    • run a follow-up review over only the corrective edits since that checkpoint, while still checking every unresolved finding;
    • invalidate or widen the checkpoint if unrelated edits, a rebase, or other baseline-changing work occurs;
    • avoid requiring a commit before the slice is green;
    • still run the final whole-branch/merge-base review before release.

    A possible native shape would be codex review --continue <review-id> or --since-review <review-id>, with output separating previously reviewed content, new corrective edits, and unresolved findings.

    Today, rerunning review --uncommitted rereads the entire HEAD-to-worktree diff. Committing only clean slices reduces that scope, but there is no equivalent incremental loop for fixing findings inside one not-yet-clean slice.

  2. changed the title [-]Evaluate incremental slice reviews with a final whole-branch gate[/-] [+]Implement incremental corrective commits with a final whole-PR review gate[/+] on Aug 9, 2026
  3. BaseInfinity commented on Aug 9, 2026

    @BaseInfinity
    OwnerAuthor

    Prioritized for 0.7.37 based on the #86 release-candidate loop.

    Measured failure mode on 2026-08-08:

    • one 28-file / ~3,400-line uncommitted patch
    • each independent finding invalidated the whole frozen candidate
    • the full proof suite took roughly 16 minutes per rerun
    • whole-patch Sol High review took roughly 3–5 minutes per rerun
    • real findings were valuable, but repeatedly re-certifying unrelated clean work dominated cycle time

    Required implementation shape:

    1. Keep each logical slice small: TDD RED/GREEN, affected tests, exact-diff author review, independent Sol High, then commit the clean slice.
    2. Treat a reviewer correction as its own bounded corrective commit. Bind it to the finding it resolves and verify the affected behavior before committing.
    3. Do not rerun Fable for every slice. Fable High remains the final cross-model gate.
    4. At PR/release completion, run the full suite on the assembled branch, review the complete merge-base-to-HEAD diff plus any remaining staged work, and verify that every earlier finding has a corresponding corrective commit/test.
    5. If the final whole-PR review finds a defect, add a small corrective commit, rerun affected proof plus the required release suite, rerun whole-PR Sol High, then Fable High.
    6. Never merge failing tests or CI; incremental certification reduces repeated scope but cannot replace final integration certification.

    The final gate should produce a concise ledger mapping: finding -> corrective commit -> regression test/proof -> final whole-PR certification.

  4. BaseInfinity commented on Aug 9, 2026

    @BaseInfinity
    OwnerAuthor

    Adopted workflow clarification: chained incremental certification

    The goal is not to rereview the whole branch after every correction.

    Local branch loop

    1. Implement one bounded change while it is uncommitted.
    2. Run the affected tests and exact-diff author review.
    3. Sol High and Fable High review that uncommitted delta through the local gate.
    4. Address findings while the delta remains uncommitted; reviewers inspect only the correction/new delta required by the gate.
    5. Commit once that delta is clean. The commit becomes an immutable reviewed checkpoint.
    6. Repeat for the next uncommitted slice. A PR is optional until collaboration or merge readiness requires one.

    Initial pull-request gate

    1. Push the accumulated reviewed commits to one branch and open/update one PR.
    2. Run integration tests/CI.
    3. Sol High and Fable High each review the whole PR once (merge base -> current PR head).
    4. Record that PR head as the certified baseline.

    PR correction loop

    1. Apply requested fixes as new uncommitted deltas on the same branch.
    2. Use the normal local delta review/test/commit loop.
    3. Push those commits to the same PR.
    4. Review only previously certified PR head -> new PR head; do not reread the unchanged whole PR.
    5. Advance the certified PR head only when both reviewers and required tests/CI are clean.
    6. Repeat until no findings remain.

    Final merge invariant

    Before merge, verify mechanically that:

    • the current PR head exactly equals the latest dual-certified head;
    • every commit/delta since the initial whole-PR review is covered by a later incremental Sol + Fable certification;
    • required tests and CI are green;
    • no uncommitted or unreviewed changes remain.

    This produces cumulative assurance: one whole-PR review establishes the baseline; dual-reviewed incremental deltas extend it. A new whole-PR review is required only when the certification chain is missing/broken, history is rewritten, the merge base changes materially, or an integration-risk rule explicitly requires it.

    CI/CD may run tests and enforce the certification ledger, but it is not itself a code reviewer unless an actual configured review agent produces a bound review result.

  5. BaseInfinity commented on Aug 9, 2026

    @BaseInfinity
    OwnerAuthor

    Fresh dogfood evidence from the #98/#91 Windows repair on 2026-08-09:

    • The exact staged one-file patch passed the focused npm suite 25/25 and the full 11/11 proof suite.
    • Exact-diff author review, Sol High, and Fable High were clean.
    • Because the full suite was invoked directly, the commit guard had no supported way to consume that completed exact-tree result. It required the same full suite again through git-guard.cjs prove --reviewed solely to write its stamp.
    • On Enforce Sol High implementation and High-only planning/review #86, a freshly written worktree-scoped proof was still rejected by the parent session because the PreToolUse hook resolved the main worktree; a fresh Codex session rooted in the linked worktree committed safely.

    Required KISS outcome for this issue: one canonical proof invocation per frozen tree, proof/review receipts bound to the exact tree hash rather than expiring while the tree is unchanged, and correct command-working-directory/worktree resolution. Do not make agents rerun an unchanged 8–18 minute suite merely to translate already-current evidence into another local stamp.

  6. BaseInfinity commented on Aug 9, 2026

    @BaseInfinity
    OwnerAuthor

    Audit evidence from the 2026-08-09 overnight run: between 01:00 and 15:00 PDT the repo produced five local commits, closed two tracking issues, merged zero PRs, and shipped zero releases. The current release slice completed repeated full-proof runs plus reviewer-triggered duplicate suites while the uncommitted parser patch kept growing. The gates found real P1 defects, but delivery cadence entered diminishing returns.

    Add these requirements to the prototype:

    • Full proof once per frozen candidate; reviewers consume tree-bound proof and may run only targeted probes tied to a concrete suspected defect.
    • Commit each bounded green/reviewed slice before starting the next so uncommitted scope shrinks.
    • After one corrective review round, triage new findings: P0/P1 in the changed contract block the slice; unrelated or speculative expansion becomes a linked follow-up.
    • Final merge gate reviews the complete merge-base-to-HEAD diff, then Fable High runs only after author self-review and Sol High are clean.
    • Record elapsed implementation, proof, Sol review, correction, Fable review, CI, and release time.
    • Define an explicit overnight stop condition: never loop indefinitely, never bypass gates, and stop before human-only release/Windows/auth/history operations.
  7. BaseInfinity commented on Aug 9, 2026

    @BaseInfinity
    OwnerAuthor

    Proposed cadence after an m180 negative pilot

    The m180 v0.3 candidate is a clean counterexample to “review more often” as a complete answer. Commit dff6867 combined three issues into 37 files (+4,692/-253). The full 1,659-test Pester suite stayed green, but two completed review rounds found eight legitimate defects and further review attempts timed out or returned no usable result. The pushed branch closed no issue.

    I think the efficient form of this issue is:

    1. Each bounded slice: red/green, affected proof, self-review exact diff, commit.
    2. Risk-based slice review: one independent reviewer for high-risk code/proof changes; ordinary low-risk commits do not need both models.
    3. Final delivery candidate: freeze the SHA; run the broad suite once; Sol and Fable review independently; reconcile once in a compact ledger.
    4. Corrections: commit bounded deltas and run targeted proof. Ask the reviewer responsible for the finding to recheck the delta. Do not rerun both models and the full suite unless the tree/config/runner surface that the receipt covers changed.
    5. Termination: two corrective rounds per frozen scope. A third same-plan round means split/redesign or explicit human approval.
    6. Invariant: default branch may advance only when its head equals the latest dual-cleared frozen candidate and its tree-bound proof is current.

    That preserves the real-life two-reviewer merge gate the maintainer wants without turning each development commit into a miniature merge ceremony. It also makes #73's tree-bound proof receipt load-bearing rather than an optimization.

    Suggested pilot metrics for 10 issue-sized changes: planned vs actual diff, tripwire count, unique findings per reviewer, correction rounds, broad-suite runs, review wall time, issues closed, PRs merged, and milestones closed. “Green candidate pushed” should be recorded separately from “delivered.”

  8. BaseInfinity commented on Aug 9, 2026

    @BaseInfinity
    OwnerAuthor

    VisualHUD comparison: incremental checkpoints delivered; an uncommitted final slice stalled\n\nProduct-repo dogfood from Sunday 2026-08-09 gives a useful A/B result for this issue:\n\n- Nine incremental commits closed five v1.2 issues; each bounded issue reached green CI and main ended synchronized.\n- The remaining uncommitted issue #15 grew to 684 new-file lines plus 70 tracked additions / 174 deletions, including a 333-line custom auditor and 279-line test.\n- Repeated whole-slice review found valid new defects but kept recertifying the broad candidate and expanding its mechanisms.\n- The unattended goal reached about 12.9 hours / 3.9 million tokens with the milestone still 5/8 and no release.\n- Two commits were pushed directly to main with red CI before follow-up repairs.\n\nInterpretation: immutable reviewed increments materially improved delivery and attribution, but the incremental sensor needs #110's breaker. The measured default should be:\n\n1. bounded TDD + affected proof + exact-delta review per increment;\n2. one tree-bound full proof and whole-issue Sol/Fable gate at completion;\n3. one compact reconciliation only on blocker/disagreement;\n4. bounded corrective delta review, not whole-issue rereview;\n5. stop/replan/split after two correction rounds, >2x estimated scope, or a new parser/enforcement mechanism outside the scope card;\n6. high-risk work uses an issue branch and required latest-SHA CI before main.\n\nTrack closed issues and milestone boundaries, not commit count alone. Also record proof duplication, review rounds, blocker locus, wall time, and tokens per completed issue.\n\nFull source receipt: claude-sdlc-harness#534.

  9. added this to the milestone on Aug 10, 2026
  10. BaseInfinity commented on Aug 10, 2026

    @BaseInfinity
    OwnerAuthor

    Refined implementation and ten-delivery pilot contract

    Independent evidence from codex-sdlc-wizard, m180-jumpseat, and VisualHUD plus the Sol/Fable reconciliation on #110 narrows this issue from open-ended research to a measurable pilot.

    Cadence

    • Incremental checkpoints: bounded TDD, affected proof, exact-delta author readback, and at most one risk-based native reviewer before committing.
    • Completion boundary: Sol + Fable independently review one frozen base-to-candidate issue diff before issue closure, PR merge, feature-branch integration, or direct default-branch completion.
    • Reconciliation: clean-clean records same-candidate attestation. A blocker or material disagreement gets one compact ledger exchange; no full rereview merely to debate.
    • Corrections: one bounded delta slice, targeted regression proof, exact-delta review, commit, then refreshed final approval focused on the delta plus prior blockers. Fresh unrelated nits are suppressed; genuinely new blockers remain allowed.
    • Breaker: structural scope growth or two corrective rounds forces stop/replan/split. A third same-plan correction requires explicit human approval.

    Cumulative accounting

    Incremental commits must not reset the review budget.

    Bind accounting to one root task identity:

    • owning issue/request;
    • stable base SHA;
    • declared scope card;
    • child slice/commit IDs;
    • cumulative proof runs, reviewer passes, wall time, and model/token/quota cost.

    A renamed prompt or new commit does not create a new root budget. New authorized scope is recorded as a child decision; it does not erase prior cost.

    Ten eligible delivery measurements

    For ten issue-completion candidates record:

    • issue/milestone/release outcome, not just green tests;
    • diff size per acceptance criterion;
    • proof count and duplicate broad-proof count per frozen tree;
    • Sol and Fable duration/quota;
    • blockers uniquely caught by reviewer two;
    • ledger exchanges and changed dispositions;
    • false blocks and pre-existing versus introduced locus;
    • corrective rounds and tripwire activations;
    • red-on-main count;
    • time from first green candidate to integration/distribution.

    After ten eligible deliveries, a human chooses keep, tune, or sunset reconciliation/risk tiers. No silent promotion to permanent policy.

    Dependencies and propagation

    Only after the pilot earns its complexity, propagate the validated lifecycle through the maintainer harness, canonical repo-local SDLC skill, and installer/plugin/update templates.

  11. added
    priority: P0Stop-the-line critical path; work before lower-priority roadmap items
    on Aug 10, 2026
  12. removed this from the milestone on Aug 10, 2026
  13. 10 remaining items

  14. BaseInfinity commented on Aug 12, 2026

    @BaseInfinity
    OwnerAuthor

    m180 v0.15 pilot: add an external-evidence eligibility gate before final review

    Reporting repo: BaseInfinity/m180-jumpseat; issue #49. Process evidence only—no source, credentials, tenant identifiers, or private proof.

    This auth/security card reached:

    • focused auth/session proof green;
    • full deterministic suite 1,794/1,794 green;
    • a frozen staged tree;
    • independent Codex + Fable final review, followed by one bounded corrective delta and CLEAN/CLEAN.

    The reviewers added real value: they caught a Windows junction escape, an unvalidated cached Graph context being called healthy, and a ServiceNow wrapper trusting child exit status instead of run-bound artifact readback.

    But the card was not actually BoundaryEligible when final review began. A provider-required ServiceNow MFA step still blocked the two required live unattended repeats. Completing that live proof will update canonical evidence and release-state docs, changing the candidate and invalidating the final approval identity. So CLEAN/CLEAN was technically premature even though the code was ready.

    Suggested refinement for #109:

    1. Add a pre-review eligibility check: every required live/external acceptance dependency is either complete, explicitly waived/out of scope, or classified as a terminal provider blocker permitted by the scope card.
    2. Allow early independent review as a preflight sensor, but do not count it as the final completion gate.
    3. Freeze the final candidate only after live proof and candidate-mutating docs/evidence are complete.
    4. Then run one canonical full proof and the risk-tiered final review against that exact tree.
    5. Corrective re-review stays delta + prior blockers; do not restart broad discovery.

    This preserves the security bar while avoiding clean reviews that must be repeated because a known external gate later changes the candidate. Instrument BoundaryEligibleAt, FinalReviewStartedAt, and KnownExternalGateCountAtReview; the desired invariant is zero known candidate-mutating external gates when final review starts.

  15. BaseInfinity commented on Aug 12, 2026

    @BaseInfinity
    OwnerAuthor

    Fresh measurement from BaseInfinity/m180-jumpseat (shared with the maintainer''s explicit permission; process metadata only).

    Pilot result

    From v0.15 publication to #65 closure, 8h02m53 elapsed. The revised cadence produced:

    The eight late one-issue cards had a median of about 8.5 files / +332 lines and a maximum of 16 files / +620 lines, versus the earlier failed three-issue review unit at 37 files / +4,692 lines. The completion boundary was not the bottleneck. One-issue scope cards materially improved throughput and reviewability.

    Did TDD and dual final review earn their cost?

    Yes, with risk-tiering.

    TDD caught real portability and security behavior. Most notably, #60''s linked-checkout green did not conceal a standalone-clone run with 11 ambient-dependency failures; those were repaired before a clean 1,875/1,875 result.

    The two review legs found complementary defects:

    That supports two independent final reviewers for security, CI, proof, release, and public-claim cards. It does not justify two broad reviewers on every ordinary commit.

    Avoidable churn

    #58 needed six Fable verdict passes across successive frozen trees. The findings were real, but two process defects made them arrive late:

    1. Focused tests mirrored the implementation instead of tracing every issue acceptance criterion, so three omitted obligations still produced green tests.
    2. Review legs were effectively serial. A second-leg finding arrived after an earlier CLEAN, forcing another candidate and another pass.

    #65 showed the healthier shape: both reviewers examined one bounded card, found different defects, one combined correction landed, bounded rechecks passed, and it shipped.

    Recommended harness behavior

    1. Generate an acceptance trace before RED: every issue criterion maps to an artifact, test, and evidence source. Focused green cannot certify an unmapped criterion.
    2. Freeze one exact candidate tree and fan out both final review legs concurrently.
    3. Join findings into one ledger, correct once, and refreeze once.
    4. Apply the two-corrective-round breaker to the root issue, regardless of new tree IDs or reviewer handoffs.
    5. Cache broad proof by exact tree. Reuse it only for the identical tree; allow targeted extension for a bounded docs/test correction, but require one final broad suite for each changed closure tree.
    6. Keep reviewer roles non-overlapping: acceptance/lifecycle/claims versus implementation/runtime/test semantics.
    7. Record time by phase: boundary eligibility, human/auth wait, review legs, correction, full suite, close, and release. This distinguishes real delivery delay from provider wait.

    This complements #111: approval identity should be exact-tree-bound, and any mutation while review or the full suite is running should mark that result stale candidate, not CLEAN or FAIL.

    Secondary observations worth measuring, but not enough evidence for new trackers yet: long-running suite calls can outlive a client timeout and overlap a retry; proof/commit command quoting and receipt expiry were difficult to diagnose. Structured receipts and explicit running-process/candidate IDs would make those failures safer.

    Conclusion: keep TDD and the quality gates. Improve orchestration, acceptance tracing, and reviewer concurrency; do not add another review layer.

  16. BaseInfinity commented on Aug 14, 2026

    @BaseInfinity
    OwnerAuthor

    Additional m180 pilot datapoint: dual review found distinct mutation-boundary defects

    Reporting repo: BaseInfinity/m180-jumpseat, issue #74. Process evidence only; no account, tenant, recipient, or private-binding data.

    A single frozen candidate for an exact test-owned draft/resume-send authorization route passed affected proof and the full 2,054/2,054 required suite. Two independent final reviewers still produced non-overlapping P1 findings:

    • one leg found write-before-authorization and preflight-to-mutation TOCTOU/reparse gaps, plus the absence of an executed root-route contract;
    • the other leg found that the broker was accepting caller-shaped evidence instead of deriving it from the retained readback proof, and that positive attachment matching proved only filename rather than bytes.

    The findings were reconciled into one bounded correction: authorization now precedes every write, the canonical wrapper revalidates exact paths/context/evidence at the mutation seam, the broker derives evidence identity from the retained draft proof, the root route is exercised end-to-end with deterministic children, and attachment bytes are bound. Both reviewers then returned CLEAN on the same tree.

    Interpretation: risk-tiered dual review earned its cost here. The two legs were not duplicate readers; each caught a different authority/proof class that green TDD had missed. The efficient shape was one frozen candidate, parallel independent findings, one combined ledger/correction, targeted recheck, and no third broad review round.

    A separate hosted PR gate then caught an unrelated clean-checkout portability defect: a release test treated git archive ZIP bytes as cross-version deterministic. Local Windows Git 2.53 and hosted Windows Git 2.55 do not produce the same asserted archive hash from the same staged tree. That reinforces two harness rules: empirical instructions/proofs need execution on the claimed environment, and clean-checkout CI failures should be classified by locus rather than attributed automatically to the PR diff.

  17. BaseInfinity commented on Aug 15, 2026

    @BaseInfinity
    OwnerAuthor

    #111 duplicate-proof measurement — 2026-08-14

    A fresh #111 corrective delta produced a direct measurement of the proof-translation cost this issue is meant to remove.

    The corrected frozen tree ran the canonical proof directly:

    • all 11/11 groups passed;
    • adapter 225.7s;
    • setup 247.9s;
    • update 570.6s.

    The direct run did not refresh the tree-bound .git/codex-sdlc/proof.json receipt. Before the final dual-review gate, the same unchanged frozen tree therefore had to run the same suite again through git-guard.cjs prove --reviewed solely to write the receipt:

    • all 11/11 groups passed again;
    • adapter 220.9s;
    • setup 243.1s;
    • update 564.7s.

    No source changed between those runs. The second run bought receipt translation, not new behavioral coverage.

    This strengthens the KISS acceptance criterion here: one canonical proof invocation per frozen tree must both execute the suite and atomically populate the candidate-bound receipt. A caller that already ran the suite without the stamping entrypoint should report that evidence as non-reusable rather than silently rerun; the normal documented path should frontload the stamping entrypoint so duplicate broad proof is avoided.

  18. BaseInfinity commented on Aug 16, 2026

    @BaseInfinity
    OwnerAuthor

    2026-08-16 high-risk planning pilot checkpoint

    • Worktree: /private/tmp/codex-sdlc-issue109-v2
    • Branch: fix/issue-109-bounded-incremental-v2
    • Frozen staged tree: f391740ca461bb48343ac7801e30e101682b2e10
    • Focused TDD: tests/test-skill.sh RED then 22/22 GREEN
    • Fresh canonical proof: 11/11 GREEN; fingerprint sha256:19f61dc706274e421d033efd52a4428850e8ae33f408b4a1e39be5549095341f
    • First final gate found two real P1 ambiguities (overbroad mutation trigger; no consented Fable plan-challenge path) plus two P2 contract gaps. One bounded corrective delta narrowed the trigger, documented the explicit tool-free Fable High command and unavailable/auth fallback, allowed failing observables, and strengthened the regression.
    • Corrected tree passed the fresh proof.
    • Final dual review did not produce a verdict because Fable subscription quota returned HTTP 429/out of credits; reset reported for 2026-08-16 23:00 PDT. The runner failed closed and removed the stale receipt.

    Resume rule: do not edit the staged tree. After Fable quota is available, rerun one current canonical proof if the prior receipt has expired, then run exactly one bounded Sol High + Fable High final gate. If certified, deliver through the immutable dual-review delivery command and open a PR with Refs #109; keep #109 open for the multi-issue pilot. If another P0/P1 appears, stop and replan rather than starting a third correction loop.

  19. BaseInfinity commented on Aug 17, 2026

    @BaseInfinity
    OwnerAuthor

    2026-08-16 bounded pilot stop: do not ship the current plan-review recipe

    Candidate worktree: /private/tmp/codex-sdlc-issue109-v2
    Candidate tree: 1fc2f71d58a6976561678e98c41572d4ac8d17ab

    Evidence:

    • focused TDD: 23/23 GREEN after a real RED;
    • canonical exact-tree proof: 11/11 GREEN;
    • exact-diff author review: clean;
    • final bounded Sol High + cross-model gate terminated normally, but joint verdict was NOT CERTIFIED;
    • no commit, push, PR, or merge occurred.

    The final gate retained two Sol P1s:

    1. The documented raw shell recipe is POSIX-specific and therefore not a reliable supported Windows path.
    2. It checks subscription auth but invokes raw claude with ambient routing variables, so the actual review can diverge from the consented subscription lane.

    The cross-model leg certified at 78 confidence and treated these as P2/P3, but the Sol leg remained NOT CERTIFIED at 97 confidence. Per the two-correction breaker, no third patch/review loop was started.

    Decision: do not merge this candidate. The high-risk pre-code challenge experiment expanded beyond #109's incremental corrective-review acceptance criteria into a cross-platform trusted reviewer-launcher problem. Resolve that as a separately planned runner or reuse an existing hardened runtime; do not keep extending prose commands. #109 remains open for its measured multi-delivery incremental-review pilot.

  20. BaseInfinity commented on Aug 17, 2026

    @BaseInfinity
    OwnerAuthor

    Bounded v3 candidate result (2026-08-16): NOT CERTIFIED; no commit, push, or PR.

    Evidence:

    • Focused benchmark verification: 15/15 GREEN.
    • Canonical broad proof: 11/11 GREEN.
    • One duplicate broad-proof execution occurred because the first invocation used the proof runner directly instead of the canonical receipt-minting command. This is recorded as workflow waste.
    • Final gate: Sol High plus the configured cross-model fallback, one reconciliation round, then stop.

    Remaining blocker:

    • P1: source-bound evidence verification fails open when the referenced Git objects are unavailable. A shallow/pruned checkout or source archive can skip strong provenance verification yet still pass the evidence row.

    Nonblocking correctness follow-up:

    • P2: count/token fields accept fractional values and the summarizer truncates them.

    The two allowed corrective rounds are exhausted. The v3 staged candidate remains frozen as evidence. Replan scope for v4 is deliberately narrow: define an explicit fail-closed or explicitly-skipped provenance contract for non-full-history contexts, add strict integer validation for count/token fields, then run focused tests, one canonical broad proof, and one bounded final gate.

  21. BaseInfinity commented on Aug 18, 2026

    @BaseInfinity
    OwnerAuthor

    Release-train checkpoint: the v4 pilot candidate remains frozen while P0 reviewer-infrastructure issue #158 is corrected. The live v4 gate exposed forbidden advisor use that the runner did not reject safely; this is infrastructure failure and not a finding against the unchanged #109 evidence candidate. Do not resume obsolete v2 or v3 work. After #158 integrates, rebase or refresh v4 deliberately against current main, preserve its measured evidence, and continue the bounded #109 completion gate without resetting the correction budget.

  22. changed the title [-]Implement incremental corrective commits with a final whole-PR review gate[/-] [+]Complete the bounded incremental-review pilot and final candidate gate[/+] on Aug 22, 2026
  23. BaseInfinity commented on Aug 22, 2026

    @BaseInfinity
    OwnerAuthor

    1.0 release audit (2026-08-22): replaced the stale 0.7.36/research framing with the current v4 checkpoint and finite completion criteria.

    The staged v4 candidate remains at /Users/stefanayala/codex-sdlc-issue109-v4, tree 915130665ff2877f89397eb00ea0ecde460008c3, blocked by #158 and the narrowed #157 classification contract. The longer measurement program may continue after 1.0; this issue closes for 1.0 when the current candidate is refreshed, proven, boundedly certified, delivered, and the keep/tune/sunset decision is recorded.

  24. BaseInfinity commented on Aug 22, 2026

    @BaseInfinity
    OwnerAuthor

    #158 is integrated via PR #165 at exact commit af037604a6f8d8ac2b9a3279b176aebed61aefb5; its one-time owner exception is consumed and normal fail-closed policy has resumed.

    The v4 worktree and staged tree were rechecked and remain unchanged. Do not rebase or mutate them yet: #157 is now the sole dependency and the active 1.0 engineering slice. After #157 lands, deliberately refresh v4 onto then-current main without resetting the cumulative correction budget.

  25. BaseInfinity commented on Aug 23, 2026

    @BaseInfinity
    OwnerAuthor

    Dependency cleared — v4 resume audit

    #157 integrated through PR #166 at exact commit a07fc3d3fb77767de4c6e677e24bce628256668a; pre-merge and post-merge Windows CI both passed. The 1.0.0 milestone now has 7 open blockers, and #109 is authoritative next.

    Frozen v4 audit before refresh:

    • worktree /Users/stefanayala/codex-sdlc-issue109-v4;
    • branch fix/issue-109-bounded-incremental-v4;
    • HEAD a5763fe197d012935a2cc2d443a4b5b84c458f10, four commits behind current main;
    • staged tree unchanged at 915130665ff2877f89397eb00ea0ecde460008c3;
    • exactly five intended staged files, no unstaged/untracked files, no PR.

    Cumulative history is preserved: v3 exhausted its two same-plan corrections; v4 remains the explicitly authorized narrow replan for fail-closed unavailable provenance plus strict integer fields. The earlier v4 live gate was blocked by reviewer infrastructure (#158/#157), not a candidate verdict, so it did not create a new corrective round.

    Next: recoverably carry the exact staged v4 delta onto current main, add only the now-required #109 ROADMAP activation sync, run focused proof/self-review, one guarded canonical proof, and one bounded normal joint gate. No obsolete v2/v3 candidate or review exception will be reused.

  26. BaseInfinity commented on Aug 23, 2026

    @BaseInfinity
    OwnerAuthor

    v4 refreshed candidate — focused proof and self-review complete

    • Base/HEAD: a07fc3d3fb77767de4c6e677e24bce628256668a (current origin/main; +0/-0)
    • Worktree: /Users/stefanayala/codex-sdlc-issue109-v4
    • Branch: fix/issue-109-bounded-incremental-v4
    • Exact staged tree: 6f7c46cda02685feaf27eabe45e83c7fd1d604b2
    • Scope: seven staged files; no unstaged or untracked source paths; no PR.
    • Recovery stash retained: 15ce3361b112dc1cb7afeb3d7bd0dc3195ffbaba. The four source/evidence paths remain byte-identical to that preserved v4 candidate; the benchmark test only adds an independent fractional-token probe.
    • Focused proof: benchmark 16/16 GREEN; roadmap 15/15 GREEN; diff check GREEN.
    • Provenance readback: PR feat(review): supervise reviewer lifecycle #156 parent/tree/five-path diff, patch SHA-256, issue feat(review): add heartbeat, timeout, cleanup, and structured verdict metadata #137 closure, owner review receipt, and successful Windows run all match the source-bound evidence.
    • 1.0 decision recorded in ROADMAP.md: tune — retain bounded completion-boundary dual review for high-risk/proof/security/release work, keep ordinary work risk-tiered, and continue measurement post-1.0 into 1.1.
    • Root checkout remains untouched.
    • Confidence: HIGH after exact-diff self-review.

    Next and only remaining candidate gates: one guarded canonical 11/11 proof, then one bounded normal Sol High + Fable High gate. A new P0/P1 stops for explicit direction; no exception or correction-budget reset is available.

  27. BaseInfinity commented on Aug 23, 2026

    @BaseInfinity
    OwnerAuthor

    Canonical exact-tree proof complete

    • Candidate tree: 6f7c46cda02685feaf27eabe45e83c7fd1d604b2
    • Base/HEAD: a07fc3d3fb77767de4c6e677e24bce628256668a
    • Guarded invocation: git-guard.cjs prove --reviewed with the canonical proof runner
    • Result: 11/11 GREEN
    • Receipt created: 2026-08-23T08:24:49.228Z
    • Receipt expires: 2026-08-23T12:24:49.228Z
    • Workspace fingerprint: sha256:9250d3fec6f4bf36e0dfb46be85341df4ec01bcc92440377f6b636bf3ac10717
    • Adapter: 301.6s; setup: 251.7s; update: 594.1s
    • Candidate remains frozen with exactly the same seven staged files and no unstaged/untracked source paths.

    Next: exactly one bounded normal Sol High + Fable High final gate. No review exception is available.

  28. BaseInfinity commented on Aug 23, 2026

    @BaseInfinity
    OwnerAuthor

    v4 completion gate stopped fail-closed — forbidden reviewer tool use

    The single bounded normal completion gate terminated without certification. This was not an auth, quota, or timeout failure.

    • Candidate tree: 6f7c46cda02685feaf27eabe45e83c7fd1d604b2
    • Base/HEAD: a07fc3d3fb77767de4c6e677e24bce628256668a
    • Proof: canonical 11/11 receipt remains current; fingerprint sha256:9250d3fec6f4bf36e0dfb46be85341df4ec01bcc92440377f6b636bf3ac10717
    • Gate terminal state: INVALID_VERDICT
    • Partial receipt: status=partial, certifying=false, joint_verdict=NOT CERTIFIED
    • Overall classification: invalid_execution; infrastructure_failure=false; transient=false; retry.recommended=false
    • Fable High: rejected for forbidden reviewer tool use: Bash; no verdict completed.
    • Sol High: still running when the peer violation occurred, then cancelled; no verdict completed.
    • Reconciliation: skipped because initial review was incomplete.
    • Candidate remains frozen and unchanged. No commit, push, PR, or delivery occurred. The root checkout remains untouched.

    Evidence:

    • Run receipt: worktree Git path codex-sdlc/review-run.json
    • Explicitly non-certifying partial receipt: worktree Git path codex-sdlc/dual-review.json
    • Logs: codex-sdlc/review-logs/1787473524277-6f7c46cda026/

    Per #157 and the #109 v4 checkpoint, forbidden reviewer execution is non-transient and must not be retried automatically. The one bounded v4 final gate is consumed. Resume only with explicit maintainer direction for a new bounded replan; do not deliver this candidate, reuse an exception, or treat the partial receipt as certification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestpriority: P0Stop-the-line critical path; work before lower-priority roadmap items

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions