Found during the devel integration review (PR #15/#25).
Two related gaps when a baselined requirement is revised and the new revision baselines:
- Children keep
parent_id pointing at the superseded row. The tree excludes superseded rows, so all children get promoted to roots / flagged orphan until someone manually re-parents each one — and that re-parent PATCH clears stale, destroying the very re-derivation signal UX-4 set on them.
PartRequirement.requirement_ref_id is never migrated forward. After revise+baseline, the effective revision shows zero allocated parts; the superseded row silently keeps the traceability.
Needs a design decision rather than a mechanical fix: likely re-parent children and carry allocations forward atomically inside the supersede (same transaction, audit-logged), with stale preserved on the moved children.
🤖 Generated with Claude Code
Found during the devel integration review (PR #15/#25).
Two related gaps when a baselined requirement is revised and the new revision baselines:
parent_idpointing at the superseded row. The tree excludes superseded rows, so all children get promoted to roots / flagged orphan until someone manually re-parents each one — and that re-parent PATCH clearsstale, destroying the very re-derivation signal UX-4 set on them.PartRequirement.requirement_ref_idis never migrated forward. After revise+baseline, the effective revision shows zero allocated parts; the superseded row silently keeps the traceability.Needs a design decision rather than a mechanical fix: likely re-parent children and carry allocations forward atomically inside the supersede (same transaction, audit-logged), with
stalepreserved on the moved children.🤖 Generated with Claude Code