Summary
The lifecycle governance validator enforces its current checks unconditionally against all iterations — there is no schema-version / baseline grandfathering. So every time the validator tightens, previously-closed iterations retroactively FAIL on checks that did not exist when they closed. This forces a bad choice: fabricate governance records for long-closed iterations (which violates the anti-fabrication principle, Proposals 141/196) or carry a red baseline.
Evidence
In extensions/specrew-speckit/scripts/validate-governance.ps1, the Task Verdicts table (~:3138), retro sections Estimation Accuracy/Drift Summary/Improvement Actions (~:3205), and Effort Model Time Limit/Defer Strategy (~:3741-3743) are applied with no version gate. "Baseline Ref" in the validator is only the git-diff scope, not a close-time schema marker.
Surfaced 2026-06-24 on Feature 197: iterations 003/004 (closed under an earlier validator) now fail these checks. Per the maintainer ruling (anti-fabrication outranks green-baseline), they were grandfathered + documented in specs/197-continuous-co-review/iterations/VALIDATOR-LAG.md rather than back-filled; the cleanup agent's speculative 002 status-guess demonstrated the fabrication hazard the ruling avoids.
Fix
Grandfather by the iteration's recorded baseline / schema-version-at-close: the validator enforces only the checks that existed when the iteration closed. New iterations get the full current schema; closed iterations are validated against their own close-time schema. Same Baseline-Ref territory as F-044; composes with the anti-fabrication principle (141/196). Removes the recurring "tighten → retroactively red → fabricate-or-carry-red" trap.
Disposition
Small validator slice; bug-bash backlog candidate (post-F197/F200).
🤖 Generated with Claude Code
Summary
The lifecycle governance validator enforces its current checks unconditionally against all iterations — there is no schema-version / baseline grandfathering. So every time the validator tightens, previously-closed iterations retroactively FAIL on checks that did not exist when they closed. This forces a bad choice: fabricate governance records for long-closed iterations (which violates the anti-fabrication principle, Proposals 141/196) or carry a red baseline.
Evidence
In
extensions/specrew-speckit/scripts/validate-governance.ps1, the Task Verdicts table (~:3138), retro sectionsEstimation Accuracy/Drift Summary/Improvement Actions(~:3205), and Effort ModelTime Limit/Defer Strategy(~:3741-3743) are applied with no version gate. "Baseline Ref" in the validator is only the git-diff scope, not a close-time schema marker.Surfaced 2026-06-24 on Feature 197: iterations 003/004 (closed under an earlier validator) now fail these checks. Per the maintainer ruling (anti-fabrication outranks green-baseline), they were grandfathered + documented in
specs/197-continuous-co-review/iterations/VALIDATOR-LAG.mdrather than back-filled; the cleanup agent's speculative 002 status-guess demonstrated the fabrication hazard the ruling avoids.Fix
Grandfather by the iteration's recorded baseline / schema-version-at-close: the validator enforces only the checks that existed when the iteration closed. New iterations get the full current schema; closed iterations are validated against their own close-time schema. Same Baseline-Ref territory as F-044; composes with the anti-fabrication principle (141/196). Removes the recurring "tighten → retroactively red → fabricate-or-carry-red" trap.
Disposition
Small validator slice; bug-bash backlog candidate (post-F197/F200).
🤖 Generated with Claude Code