Problem
Recovered/in-flight issues with valid legacy FORGE:INVESTIGATOR reports are being mislabeled needs-human after implementation and validation pass, solely because those historical comments predate ACCEPTANCE_CHECK: emission. The same false-human escalation class also covers mechanically resolvable migration-number collisions and builder-contract scope drift.
Observed in a live AlterLab orchestration on 2026-08-05:
- RapierCraftStudios/AlterLab#32344, #32423, and #32525: valid local commits and quality gates passed, then blocked only for missing legacy
ACCEPTANCE_CHECK: lines.
- RapierCraftStudios/AlterLab#32408: blocked on a migration prefix already used by current
staging, although choosing the next valid number is mechanical.
- RapierCraftStudios/AlterLab#32534: blocked on repairable contract/file-scope drift plus legacy acceptance metadata.
Root Cause
commands/work-on/build.md Phase B6.5 treats an empty acceptance spec as an unrecoverable block and directly adds needs-human.
commands/work-on/investigate.md Phase 1A exits immediately for any completed investigator comment, so the build instruction to “re-run investigate” cannot regenerate or backfill the missing checks.
commands/work-on/build/implement.md Phase I4 maps every migration collision directly to needs-human, without distinguishing a safe filename/version collision from a semantic migration conflict.
commands/work-on/build/implement.md treats a stale/wrong builder contract as human-only instead of returning to contract/architecture repair.
This violates the pipeline rule that needs-human is reserved for genuine human judgment, external authority, procurement, or evidence-based review escalation.
Acceptance Criteria
Affected Files
commands/work-on/investigate.md
commands/work-on/build.md
commands/work-on/build/implement.md
- relevant spec/conformance tests
Problem
Recovered/in-flight issues with valid legacy
FORGE:INVESTIGATORreports are being mislabeledneeds-humanafter implementation and validation pass, solely because those historical comments predateACCEPTANCE_CHECK:emission. The same false-human escalation class also covers mechanically resolvable migration-number collisions and builder-contract scope drift.Observed in a live AlterLab orchestration on 2026-08-05:
ACCEPTANCE_CHECK:lines.staging, although choosing the next valid number is mechanical.Root Cause
commands/work-on/build.mdPhase B6.5 treats an empty acceptance spec as an unrecoverable block and directly addsneeds-human.commands/work-on/investigate.mdPhase 1A exits immediately for any completed investigator comment, so the build instruction to “re-run investigate” cannot regenerate or backfill the missing checks.commands/work-on/build/implement.mdPhase I4 maps every migration collision directly toneeds-human, without distinguishing a safe filename/version collision from a semantic migration conflict.commands/work-on/build/implement.mdtreats a stale/wrong builder contract as human-only instead of returning to contract/architecture repair.This violates the pipeline rule that
needs-humanis reserved for genuine human judgment, external authority, procurement, or evidence-based review escalation.Acceptance Criteria
ACCEPTANCE_CHECK:lines is automatically given an append-only acceptance-spec backfill derived from the issue criteria/recommendation; the existing investigation verdict and history remain intact. [type:unit]needs-human; if no machine-checkable criterion exists, the documentedtype=skippedsentinel is emitted and review remains the human quality gate. [type:unit]needs-human, while genuine review/merge/human-authority blockers still do. [type:regression]Affected Files
commands/work-on/investigate.mdcommands/work-on/build.mdcommands/work-on/build/implement.md