Found during a 2026-07-08 miner-roadmap audit: #3014 ("wire historical replay into Phase 7 calibration loop") is closed, but the two sides it claims to connect were never actually connected.
packages/gittensory-engine/src/phase7-calibration-loop.ts (landed via #3014/PR #3225) is a well-built, well-tested pure contract for combining a historical_replay score with the passive pr_outcome signal into one tracked calibration metric. By design it can't call into packages/gittensory-miner itself (wrong dependency direction — miner depends on engine, not vice versa; its own header comment says "the miner runtime owns scheduling replay runs and persisting ledger rows; this module owns [the combining logic]"), so it correctly expects an external caller to feed it real replay results.
packages/gittensory-miner/lib/replay-objective-anchor.js (#3012) and lib/replay-task-generation.js (#3011) are also real, well-built, and well-tested — a sophisticated pure structural scorer and a leakage-safe synthetic-task generator, respectively.
Confirmed directly: neither grep -rn "phase7-calibration-loop" in packages/gittensory-miner/ nor a search for callers of the two replay modules (outside their own tests) turns up anything. PR #3225 only touched files inside packages/gittensory-engine/ — it never touched the miner side. Two finished pieces, never connected, behind an issue that claims "wired." This is exactly the kind of gap a closed-issue count won't surface.
Deliverables
References
Found during a 2026-07-08 miner-roadmap audit: #3014 ("wire historical replay into Phase 7 calibration loop") is closed, but the two sides it claims to connect were never actually connected.
packages/gittensory-engine/src/phase7-calibration-loop.ts(landed via #3014/PR #3225) is a well-built, well-tested pure contract for combining ahistorical_replayscore with the passivepr_outcomesignal into one tracked calibration metric. By design it can't call intopackages/gittensory-mineritself (wrong dependency direction — miner depends on engine, not vice versa; its own header comment says "the miner runtime owns scheduling replay runs and persisting ledger rows; this module owns [the combining logic]"), so it correctly expects an external caller to feed it real replay results.packages/gittensory-miner/lib/replay-objective-anchor.js(#3012) andlib/replay-task-generation.js(#3011) are also real, well-built, and well-tested — a sophisticated pure structural scorer and a leakage-safe synthetic-task generator, respectively.Confirmed directly: neither
grep -rn "phase7-calibration-loop"inpackages/gittensory-miner/nor a search for callers of the two replay modules (outside their own tests) turns up anything. PR #3225 only touched files insidepackages/gittensory-engine/— it never touched the miner side. Two finished pieces, never connected, behind an issue that claims "wired." This is exactly the kind of gap a closed-issue count won't surface.Deliverables
packages/gittensory-miner(CLI command or background job) that invokes the replay scorers, produces ahistorical_replayscore in the shapephase7-calibration-loop.tsexpectspr_outcomesignalpackages/gittensory-miner/lib/)References
packages/gittensory-engine/src/phase7-calibration-loop.ts(feat(miner): wire the historical-replay harness into the live Phase 7 calibration loop #3014, PR feat(engine): wire historical replay into Phase 7 calibration loop #3225)packages/gittensory-miner/lib/replay-objective-anchor.js(feat(miner): objective-anchor scoring for replayed plans against revealed history #3012)packages/gittensory-miner/lib/replay-task-generation.js(feat(miner): leakage-safe task generation from real historical outcomes #3011)test/unit/miner-replay-task-generation.test.ts,test/unit/miner-replay-objective-anchor.test.ts(only current callers)