Script used calendar-day duration (end_date - init_date), which
inflated tracks that sat dormant between work and archive-move.
Example: external_editor_integration_20260308 reported 60 days
(init 2026-03-08, last archive-move 2026-05-07) when actual work
was 2 active days.
Corrected metric: active days = distinct calendar days with at
least one commit touching the track folder. All 30 top tracks
now show 2-7 active days, matching the user's expectation that
no track lasts more than a week.
Also fixed commit_count + files_touched for all 30 tracks (the
script's work-prefix-only count was always 0-1 for these).
Top 3 examples:
- external_editor_integration_20260308: 60d/1c/4f -> 2d/4c/8f
- code_path_audit_20260607: 18d/1c/7f -> 7d/23c/14f
- nagent_review_20260608: 12d/0c/20f -> 3d/53c/20f
Still stale (need recompute, not hand-fix):
- 3.1 per-era aggregates
- 8 use-case predictions
- 218 other tracks not in top-30
The script's commit_count and files_touched columns only counted
work-prefix commits (feat|fix|refactor|perf|test) with pathspecs
matching the track folder. Track folders contain only metadata
commits (conductor(*), chore(conductor), docs(track)), so the
script reported 0 commits for any track that did real work.
Corrected rows (now using total commits + total unique files
touching the track folder, any prefix):
- code_path_audit_20260607: 1->23 commits, 7->14 files
- qwen_llama_grok_integration_20260606: 0->25 commits, 4->8 files
- nagent_review_20260608: 0->53 commits, 4->20 files
- data_oriented_error_handling_20260606: 0->21 commits, 4->8 files
- superpowers_review_20260619: 0->63 commits, 8->16 files
Added 9.1 caveat explaining the manual corrections and the
methodology error that caused them.