Log rupture and repair on rework, not only “reopened”
Rework rows carry rupture clocks, rupture type, and repair path so delays and repairs are logged as data.
Pain. Rework columns often show a card moved backward without recording why the alliance with the last run broke—latency to repair, type of rupture, or path taken to fix. Aggregate metrics then confuse queue delay with conceptual repair.
What changed. Rework rows gain rupture clocks, a rupture_type taxonomy, and a repair_path enum. Existing rework lanes can split by repair path so pass-next and dwell behave as comparable series.
Why it matters. Working-alliance measurement in this program treats repair as observable. These columns are the minimum schema for contrasting quick reopen versus sustained repair work on the same assignment lineage.
How to try it
- Drive a card into rework after a merged fault and inspect rupture and repair fields populated by the migration-backed schema.
- Compare board rollups that segment by repair path when available in your build.
Shipped in 516ba34 — DP-79: Rupture-repair instrumentation (clocks, rupture_type, repair_path) (#49)