feat(calibration): config-drift section in the maintainer recap (#8214)

[jeffrey701]

Summary

Adds the calibration config-drift section to the maintainer recap (epic #8211 track A): drift alerts are point-in-time, but the weekly recap is where a STANDING drift should be impossible to miss.

• src/services/maintainer-recap-drift.ts — a pure section builder mirroring buildCalibrationRecapSection exactly (a plain source struct in, a titled { title, counts, note, lines } section out, the same public-safe boundary): each drifting knob renders its direction, live vs dominating value, visible/held-out corpus sizes, and how long the episode has stood (whole days from the sentinel's fingerprint timestamp against the recap's own generatedAt — no wall-clock read, clock-skew/garbled timestamps clamp to 0). A mixed window lists longest-standing episodes first and appends the clean-knob summary; an all-clean window is one summary line; the sentinel-flag-off arm renders the explicit drift sentinel disabled line so absence of data is never mistaken for absence of drift.
• formatMaintainerRecap gains an optional configDrift section hook behind the existing recap plumbing (no new scheduling): when the caller supplies a sentinel projection the digest appends a ## Config drift bullet section through the same redactRecapLine/recapSectionLines guards as every other section; when absent, every existing digest stays byte-identical.
• Ships independently of the sentinel runtime the same way the calibration section shipped ahead of the full RecapReport (that file's own header documents the pattern): the builder consumes the KnobDriftReport shape evaluateKnobDrift (loosening-knobs.ts) already computes, via a minimal projection the sentinel wires in the moment it persists episodes.

Public-safe boundary

Aggregate numbers + knob/rule ids only — never corpus content. The KnobDriftReport's comparison objects never surface in any emitted line, knob ids run through the shared local-path scrub, and the formatter re-guards every appended line with the digest's existing redaction (pinned by an invariant test).

Validation

• npm run typecheck green; the full changed-graph suite (npm run test:changed, Node 22) green.
• New test/unit/maintainer-recap-drift.test.ts drives 100% line + branch coverage on the builder: drifting / clean / disabled / mixed arms, longest-standing-first ordering, standing-days clamping for future or unparseable timestamps, and the no-corpus-content + path-scrub invariant.
• test/unit/maintainer-recap-format.test.ts extended for both wiring arms: the drift section renders as bullets when supplied, and the empty-window digest provably does NOT contain ## Config drift (byte-identical pre-drift shape). All existing recap suites pass unchanged (61 tests across the five recap files).

Closes #8214

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-23 15:28:47 UTC}

4 files · 1 AI reviewer · no blockers · readiness 88/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
Adds a pure, well-tested config-drift section builder (maintainer-recap-drift.ts) and wires it into formatMaintainerRecap as an optional, additive section that leaves every existing digest byte-identical when omitted. The logic (disabled/clean/drifting arms, standing-day computation with future/garbled-timestamp clamping to 0, sort order, redaction) is correctly traced and covered by tests that exercise the real code path, not fabricated states. Note this PR ships the section builder only — runMaintainerRecap/runMaintainerRecapJob still never pass a configDrift option, so the sentinel wiring is deliberately deferred per the description, consistent with the stated 'ships independently' pattern used for the calibration section.

Nits — 5 non-blocking

• src/services/maintainer-recap-drift.ts:52,59 — the 240-char cap and 86_400_000 ms-per-day literals could be named constants (e.g. MAX_LINE_LENGTH, MS_PER_DAY) for clarity, though both mirror existing conventions in maintainer-recap.ts/-calibration.ts.
• The PR description references issue calibration: config-drift section in the maintainer recap #8214/epic Epic: calibration expansion — self-correcting configuration and measured judgment #8211 but the diff doesn't show an issue link check — confirm calibration: config-drift section in the maintainer recap #8214 is an eligible open issue this PR closes per repo convention.
• test/unit/maintainer-recap-drift.test.ts's driftReport() casts a partial object to KnobDriftReport via `as unknown as` for the visible/heldOut fields — reasonable given real comparison objects are opaque to this layer, but worth a one-line comment noting why the cast is safe here.
• Consider a follow-up PR wiring maintainer-recap-wire.ts's runMaintainerRecapJob to eventually supply the configDrift option once the sentinel persists episodes, as the description promises.
• The clean/disabled arms both duplicate the `{ title, drifting, clean, note, lines }` return shape three times in buildDriftRecapSection; a small local helper could reduce repetition without hurting readability.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#8214
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 68 registered-repo PR(s), 39 merged, 16 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jeffrey701; Gittensor profile; 68 PR(s), 16 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds a pure buildDriftRecapSection mirroring the calibration builder's shape, handling clean/drifting/disabled/mixed states with knob direction, values, corpus sizes, and standing days, plus a public-safe scrub and an invariant test that corpus content never leaks; it also wires an optional configDrift section into formatMaintainerRecap without new scheduling and adds a snapshot-style test

Review context

• Author: jeffrey701
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Rust, TypeScript, Clojure, JavaScript
• Official Gittensor activity: 68 PR(s), 16 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 1 step in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[andriypolanski]

Hi, @JSONbored
This is blocked by other issue, how did you approve? I 'm not clear.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.61%. Comparing base (3494297) to head (d39e4cf).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8256      +/-   ##
==========================================
- Coverage   92.14%   89.61%   -2.53%     
==========================================
  Files         784       99     -685     
  Lines       78694    22789   -55905     
  Branches    23752     3893   -19859     
==========================================
- Hits        72510    20422   -52088     
+ Misses       5062     2187    -2875     
+ Partials     1122      180     -942     

Flag	Coverage Δ
shard-1	62.65% <33.33%> (+3.78%)	⬆️
shard-2	96.38% <95.23%> (+43.16%)	⬆️
shard-3	3.61% <0.00%> (-44.49%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/services/maintainer-recap-drift.ts	100.00% <100.00%> (ø)
src/services/maintainer-recap.ts	96.87% <100.00%> (+0.10%)	⬆️

... and 686 files with indirect coverage changes