feat(directives): scavenge sweep 4/5 (tracks + commands + styleguides + todos): 18 batch-4 directives + concurrent worker batches

2026-07-04 02:00:42 -04:00
parent e8d3578f2e
commit 79124774ec
82 changed files with 2430 additions and 0 deletions
@@ -0,0 +1,10 @@
+# per_phase_metric_regression_fix
+
+## v1
+
+**Why this iteration:** Lifted from `conductor/tier2/agents/tier2-autonomous.md:152` — the TDD Red-Green rule (added 2026-06-27 per the cruft_elimination track's lessons learned): if a phase's count delta doesn't match the planned count, FIX the migration (add more sites, amend the commit). Do NOT classify the phase as no-op. Do NOT use `git revert` to throw the work away. The hard metric (per `conductor/workflow.md` §0) is `compute_effective_codepaths < 1e+20` for type-promotion tracks.
+**Source:** `conductor/tier2/agents/tier2-autonomous.md:152` + `conductor/workflow.md` §0
+
+---
+
+**Lifted:** 2026-07-03 scavenge sweep batch 4/5: tracks + commands + styleguides + todos
@@ -0,0 +1,37 @@
+# If a phase's metric delta does not match the planned delta, FIX the migration — do NOT classify the phase as no-op or use `git revert` to throw the work away
+
+## What it says
+
+When a track's phase has a measurable target metric (e.g., "this phase reduces the weak-type count by N" or "this phase adds N new file-level fixes"), and the post-phase metric delta does not match the planned delta, the implementation is wrong. FIX the migration in the next commit by adding more sites, amending the work, or correcting the consumer. Do NOT:
+
+- classify the phase as no-op (the work did happen; the metric just doesn't reflect it)
+- use `git revert` to throw the work away (banned per AGENTS.md)
+- rationalize that "close enough" counts
+- skip the verification and commit anyway
+
+## Why
+
+The hard metric (per `conductor/workflow.md` §0) is the success criterion for type-promotion tracks. If `compute_effective_codepaths < 1e+20` is the target and the post-phase delta doesn't drop, the migration missed sites. The right action is:
+
+1. Re-read the planned count vs. the measured count.
+2. Identify which sites the plan called out but the implementation missed.
+3. Fix those sites in the next commit (or amend the prior commit per the atomic-per-task discipline).
+4. Re-run the metric and confirm the delta.
+
+## The TDD red-green framing
+
+Same as the Red-Green rule: a phase that doesn't reduce the metric is "still in Red." The phase is not complete until the metric shifts by the planned amount.
+
+## Concrete pattern from the cruft_elimination_20260627 track
+
+The track had multiple phases with planned count deltas (e.g., "Phase 2 reduces `dict[str, Any]` sites by 200"). When a phase's measured delta was smaller than planned, the Tier 2 agent added more sites in the next commit (or amended the prior commit) until the delta matched. The alternative — "the phase is close enough, move on" — was explicitly forbidden by the user directive.
+
+## Failure modes to avoid
+
+- **"This was a one-time exception"** — no, the rule applies always. Every phase with a metric has a target.
+- **"The work is in the commit, the metric will catch up next phase"** — no, the metric is per-phase. A 0-delta phase is a failure, not a deferral.
+- **"The audit script is wrong"** — possible, but verify by reading the script before declaring it wrong. The audit script is the source of truth.
+
+## The escape hatch
+
+If the metric genuinely is wrong (the audit script has a bug, the planned count was off by 2x), raise the issue with the Tier 2 Tech Lead. The lead will either update the metric or rewrite the phase. Do NOT silently reclassify.