a38e4d080d
* fix(#2788): recover Gaps Found rows; mark-complete no longer false-succeeds on a rejected row
Two coupled defects in the requirement traceability state machine:
Defect 1 (terminal state): requirements revert-phase (the gaps_found response)
left a row at 'Gaps Found' with no inverse — neither mark-complete's /^pending$/i
guard nor the phase-complete reconcile's /^(?:pending|in progress)$/i accepted it,
so a single failed verification stranded every requirement permanently and blocked
the milestone. Widen both guards to accept 'gaps found' so a genuinely-satisfied
stranded row reaches Complete again.
Defect 2 (false success): mark-complete ORed checkboxHit || tableHit for 'updated',
so on a Gaps Found row it flipped the checkbox but could not move the row, yet
reported updated:true. When a traceability table has a row for an ID, gate 'updated'
on the row moving (tableHit) — a checkbox-only flip on a table-bearing file no
longer lies. The #2140 table_unmatched path (no row for the ID) is preserved.
* chore(#2788): backfill changeset PR 2902
---------
Co-authored-by: Test <test@example.com>
(cherry picked from commit 9f567a1627)
515 B
515 B
type, pr
| type | pr |
|---|---|
| Fixed | 2902 |
A requirement row stranded at Gaps Found can now be completed again, and requirements mark-complete no longer reports false success on a row it could not move — the completion guards now accept Gaps Found (so revert-phase's stranded rows are recoverable instead of permanently blocking the milestone), and when a traceability table has a row for an ID, mark-complete counts it as updated only if the row actually moved (not merely because the checkbox flipped). (#2788)