Tech Program

This is the approach, not the live tracker — current build status is in "Where it actually stands" above. Step 0 is done; "Harvest Brian" stays urgent (he leaves Jun 12).

• 0
  Safe workspace — the precondition

  Before touching code: a frozen prod snapshot plus the ability to run dev against a copy of the data. Tests run against snapshots and fixtures, never the live instance — the "don't flood the real bathroom" rule. This is also where you confirm data changes are reversible, because rolling back code doesn't roll back migrated data. In old-school terms: branch isolation plus a restorable data fixture.
  Done
• 1
  Harvest Brian — do this this week

  Out of logical order on purpose. The oracle and the test both depend on knowing why the bugs happen, and 136 tickets of that knowledge walk out on the 12th. Sit Brian down against the ticket ledger and extract the failure patterns and the gnarly real BOMs. The single most time-sensitive step — it can't be redone later.
  This week
• 2
  Define the bullseye precisely

  Name the one transform in plain words: BOM → finished goods, decrement raw materials, with yields and sequencing. Write what "correct" means before writing any test. Critically, include the temporal/state dimension — order and timing of MOs, concurrency — because the late-MO pain lives there, not in the snapshot math.
  Next
• 3
  Build the oracle from the hardest real cases

  Hand-compute expected outputs for multi-level, partial-yield, sequenced BOMs sourced from step 1 — not clean toy examples. This is your user-validated truth, and its coverage is what the whole strategy rides on. The easy cases are exactly the ones that don't matter.
  Next
• 4
  Anchor the test to the bug ledger

  Resolved tickets become regression cases; open tickets become target cases. This makes "the test defines the core" measurable instead of circular — the ledger is your external completeness check. Segment the suite (fundamentals vs nice-to-haves) and weight by severity, so a high average can't hide a critical regression.
  Planned
• 5
  Make it deterministic

  Exact-decimal arithmetic for units of measure, frozen inputs, canonical units defined once. If the same test scores differently twice, the merge gate is noise. UoM normalization is both a correctness fix and the thing that makes the gate trustworthy.
  Planned
• 6
  Run the parallel harness, then refactor green-to-green

  Score the prod snapshot and dev on the weighted suite; classify every divergence as fix / regression / neutral. Then change code — smallest pieces first, starting at the center of the bullseye (UoM is the likely first real refactor), always with the test as guardrail: characterize, then refactor under its protection.
  Planned
• 7
  Merge on dominance

  Promote dev → prod only when there are zero regressions on the weighted segments, strict improvement, and a reversible / cutover-safe data migration. Communicate the breaking changes when UoM behavior flips — the cutover-window reliability dip is the one real residue.
  Planned
• 8
  Loop or advance

  A precision threshold — depth × breadth against the test — decides the next move: close enough, advance one ring out on the bullseye; not close enough, improve the test or the code and re-run. The test defines done.
  Planned

Live from MRP feedback_submissions (user-reported bugs) — distinct from the engineering findings register (F-001–F-014) above, and from Brian's own ticket count. Confirm which is the canonical bug ledger before using it as the test's completeness check.