D2 Regeneration — The Update Drill: What Re-Verifies When Claude Code Ships · Maya R.

Learning objective

(Bloom's: Evaluate) Evaluate, when Claude Code ships an update, exactly which of your pipeline's artifacts the change actually invalidates — by maintaining a dependency-tagged inventory, reading release deltas against it, re-running each touched artifact's own check, and running the whole judgment as a standing freshness beat — so that regeneration is a scoped drill you execute, not a rebuild you dread — AIHC.2.D2 (Regeneration).

Work at hand: eleven lessons built you a working system: contracts, a reviewer, lanes, hooks, a convention, metrics, an orchestration plan. Every piece of it depends on documented product behavior — and the product ships frequently (the doc-set's own front-matter says so, and gates several facts on CLI versions). The JD-shaped truth your whole arc ends on: durability isn't artifacts that never age; it's fast regeneration when they do. Today you build the aging machinery — then prove it in the capstone drill, alone.

SSD cycle 1 — the inventory: every artifact declares what it stands on

SAY: You can't scope a re-verification you can't look up. The regeneration unit is a dependency row: artifact → the frozen behavior it assumes (doc-set §) → the check that re-verifies it (which you already built — that was the arc's quiet gift: L5's legs, L7's probes, L10's drills are your regeneration checks) → last-verified date. The doc-set models this discipline on itself: every source carries last_validated, and its front-matter names an audit priority — "settings.json schema → hooks events → MCP scopes/precedence" — highest-churn surfaces first. Your inventory inherits that ordering logic: sort by blast-radius × churn, not alphabetically (X7 — the beat spends your minutes).
SEE: The inventory's first rows, from your real artifacts: ARTIFACT DEPENDS ON (§) RE-VERIFY BY LAST-V L7 permission lanes §9 rule syntax/merge/deny /doctor + deny-lane probe 07-19 L6+L9 hooks (Post/PreToolUse) §6 events, exit/JSON contract observe firing + blocked 07-19 probe w/ reason string reviewer subagent file §8 format, tools allowlist, drill seed S1/S2/S3 — 07-19 parent-mode precedence L10 catch-rate run L8 session-to-PR convention §3 gh pr create auto-link --from-pr resolves on 07-19 newest PR L2 CLAUDE.md rules §4 load order, 200-line bar /context shows loaded 07-19 L11 worktree layout §3 worktree + ≥1-commit two-terminal collision- 07-19 free session One column is doing the D2 work: RE-VERIFY BY names a check you run, never "re-read the docs and feel okay." Re-reading tells you what should hold; the probe tells you what does.
DO: Build the full real inventory in docs/regeneration-inventory.md — every artifact lessons 2–11 left in the repo, its §-dependency, its existing check (if an artifact has no check, that's a finding: give it one or demote it to "unverified convenience"), and its date. Sort by the blast-radius × churn logic and write one line defending your top three positions.

SSD cycle 2 — reading a delta: a release note is a diff against your inventory

SAY: When an update lands, the note describing it is a set of claims about changed behavior. Your move is a join: for each entry, which inventory rows name the touched surface? Rows hit → re-verify by their own column. Rows not hit → left alone — X7 discipline; re-verifying everything every time is how beats die. Two frozen tools make the join honest: the version-check habit (the doc-set gates several facts on CLI versions — its own model_version note flags them "CLI-version-gated (v2.1.xxx)"), and §3's self-reference channel: Claude Code "always answers from the current docs regardless of installed version" — meaning you can interrogate current-doc behavior in-session, and ALSO meaning its answers track the docs, not your installed binary: the probe, not the answer, settles what YOUR version does [the italicized inference is instructor synthesis from the quoted §3 claim].
SEE: A worked join on a two-line hypothetical delta (SIMULATED-FOR-DRILL — not a real release): SIMULATED ENTRY JOIN AGAINST INVENTORY "settings: permission rule patterns now hits row 1 (lanes) — §9 syntax dependency support brace expansion" → run /doctor + probe BOTH lane syntaxes "UI: session picker redesigned" hits nothing — no row depends on picker UI → no action; log 'reviewed, no join' + date The second entry matters as much as the first: a written "reviewed, no join" is what makes next month's you trust that the beat actually looked. (Spring training exists because the roster moved, not because baseball changed — you re-check the signs with the players you have; you don't re-learn the game.)
DO: Write the join procedure as a ≤10-line runbook section in the inventory file: where you'll find deltas when they ship, the join question per entry, the two dispositions (re-verify by row's check / reviewed-no-join with date), and the escalation line for an entry you can't classify (which is cycle 3's subject).

SSD cycle 3 — the known-unknown zones get stricter triggers

SAY: Your doc-set freeze is honest about its edges: MCP ~80% read, Subagents ~75%, with the unread tails named (deeper OAuth/output-tuning; nested-subagent and context-management edge cases). For fully-read zones, delta-joining works because your inventory knows the surface. For partially-read zones the inventory is incomplete by disclosure — so the trigger rule inverts: any delta entry touching a partially-read zone's surface escalates past the join to "re-freeze that source before trusting any conclusion," because you can't join against rows you never froze. A regeneration system that treats its blind spots like its mapped ground is calibrated exactly backwards (B3's lesson, aimed at your own doc-set).
SEE: The trigger table, two lines: zone fully read at freeze → delta joins against inventory rows; scoped re-verify zone partially read (MCP §7, → any touching delta = re-freeze the source page first; Subagents §8 tails) inventory rows in that zone marked PROVISIONAL until then
DO: Mark your real inventory: which rows stand on §7/§8 territory (your reviewer's file format and parent-precedence rows do; your --from-pr row doesn't), tag them with the stricter trigger, and add the one-line rationale to each so a teammate reading the inventory understands why two trigger classes exist.

SSD cycle 4 — the beat: regeneration as a calendar fact, not a virtue

SAY: Krystal's governance doctrine, carried by the playbook (§10): a scheduled freshness beat — "Claude on a cadence auditing a rotating subset for currency" — and the doc-set sets its own cadence for this cell: "recheck a rotating subset every 1–2 weeks (Claude Code ships frequently)." Your version is the personal edition: a 15-minute weekly slot, rotating a third of the inventory, running RE-VERIFY BY checks and updating dates — plus the event-driven path from cycle 2 when a delta actually ships. Two entry points, one inventory, and the beat's output is dates changing, which is what makes staleness visible as a gap instead of a feeling.
SEE: The beat, as it lands in the inventory file's header: BEAT: weekly, 15 min, rotate thirds (rows 1-4 / 5-8 / 9-12); delta-join runs on any release, whichever week. A row >30 days stale = the beat's own failure → failure-log entry (L6 format), not a shrug. Beat minutes logged in docs/review-metrics.md (L10).
DO: Write your real beat header, run beat #1 on your top third right now (real checks, real date updates), and log its minutes in docs/review-metrics.md. If any check fails on a current install — a drift the freeze didn't know — that's simultaneously a failure-log entry (L6), possibly a lane/hook fix (L7/L9), and a doc-set staleness signal: note which, and act on the smallest one today.

Independent at-bat — THE CAPSTONE DRILL (fully unscaffolded)

The drill input, verbatim — SIMULATED-FOR-DRILL, fabricated update, not product truth:

Claude Code vNEXT — release delta (SIMULATED)
1. Permission rules: resource patterns gain a new negation syntax; existing patterns
   unchanged but merge tie-breaks re-documented.
2. Hooks: PreToolUse adds a new field to its stdin JSON; exit-code semantics unchanged.
3. Subagents: default model for custom subagents without a `model:` field has changed.
4. MCP: OAuth token refresh flow updated for remote servers.
5. Docs: memory page restructured; content unchanged.

Run your entire regeneration system alone, end to end, and write the drill log as you go (docs/regeneration-drill-01.md): (a) join all five entries against your inventory — which rows are hit, which entries are reviewed-no-join, and which entry trips the cycle-3 stricter trigger (at least one does; find it and say why your inventory can't fully join it); (b) defend every exclusion in one line each — an undefended exclusion is a skipped verification wearing a time-saving costume; (c) execute the re-verifications by each row's own check — the /doctor + both-syntax lane probe, the hook firing/blocking probe with its reason string, the reviewer drill seeds for the model-default change (does your reviewer even have a model: field? look — the answer decides whether entry 3 touches you at all); (d) update inventory dates and PROVISIONAL marks; (e) close with the verdict the objective demands: which artifacts survived untouched, which re-verified clean, which needed a fix, and the one sentence you'd send your team about it. No template beyond what you built in cycles 1–4 — the system is the scaffold now; that was the arc.

Exit ticket

(Q1–Q2 graded against the doc-set and your inventory; Q3–Q5 against your drill log — the drill input is simulated, so grading is against your procedure's own rules, never against the fabricated entries' "truth.")

(Remember) Name the doc-set's own three-item audit priority order, and your inventory's top-three order with your defense line.
(Understand) Why does an update entry touching the Subagents unread tail trigger a re-freeze rather than a join — and why is writing "reviewed, no join" for a non-matching entry still mandatory?
(Apply) Drill entry 3 (subagent model default). Walk your own (c)-step: what did you check on the reviewer's file, what determined whether the entry touched you, and which check re-verified the answer?
(Analyze) Entry 2 claims exit-code semantics are unchanged while the stdin JSON grows. Analyze what your hook probe can and cannot confirm about that claim from outside the unread tails — and which single observation would falsify "unchanged" fastest.
(Evaluate — objective level) Judge your own drill log: which exclusion decision (b) was riskiest, what evidence would flip it to a re-verification, and what does your answer say about where your inventory needs its next row?

ledger_write

ledger_write:
  learner_id: L1-DEV-MAYA
  lesson_id: L1-dev-maya-12-d2-regeneration
  anchors: [AIHC.2.D2]
  bloom_reached: Evaluate
  exit_ticket_score: ""
  auto_score: ""
  self_score: ""
  calibration_gap: " — computed once Maya's self_score exists"
  starting_mastery:
    AIHC.2.D2: "not previously evidenced — first measurement this lesson (arc capstone)"
  journal_prompt: >
    Twelve lessons ago your learning goal was "run one real PR through an agent-assisted
    review I actually trust." Today you re-verified that system against a platform shift,
    alone, from your own inventory. Write what "actually trust" means to you now, in one
    sentence that lesson-1 you would not have written — and name the artifact you'd defend
    hardest if a teammate proposed deleting one.
  structure_used: PBL
  referents_used: [baseball-mets-spring-training]
  next_lesson_seed: >
    Arc complete: all six Band-2 stewardship/evolution anchors evidenced (B3, C1, C2, C3,
    D1, D2) on one real pipeline. Ledger candidates next: band-3 A2/D1 (the team adopts her
    orchestration — delegation-and-tier governance), or the L10 fortnight report deciding
    the next hardening target. The beat runs weekly regardless — that's the point.

RUBRIC SELF-AUDIT

#	Indicator	Verdict	Evidence
R1	One objective, Bloom's-leveled, named anchor	PASS	States "Bloom's: Evaluate," names AIHC.2.D2 only
R2	Every tool claim traces to the doc-set	PASS	Front-matter freshness cadence + audit priority quoted; §3 (self-reference channel quoted, worktree, --from-pr), §6 (hook contract), §9 (/doctor, /status, rule syntax), §4 (/context, load order), version-gating note — all cited at point of use; the one inference beyond a quote is flagged [instructor synthesis]; the capstone's release note is triple-labeled SIMULATED-FOR-DRILL and grading explicitly refuses to treat it as product truth
R3	3–6 cycles, one point each	PASS	4 cycles: dependency inventory; delta-join reading; stricter triggers for known-unknown zones; the scheduled beat
R4	SEE verified against ground truth	PASS	Inventory rows restate only dependencies established in L2–L11 against quoted §-facts; the worked join uses a labeled simulated delta; the trigger table restates the doc-set's own disclosure; nothing fabricated is presented as product behavior
R5	Every DO on real work-at-hand	PASS	DOs build her real inventory from her real artifacts, write her real runbook, mark her real §7/§8-dependent rows, and run beat #1 with real checks and logged minutes; the capstone drill executes on her actual repo state
R6	Media doctrine honored	PASS	Static tables/text; regeneration is taught through documents and probes, not motion content
R7	Exit ticket 3–5 Qs, Bloom's-climbing	PASS	5 Qs, Remember→Understand→Apply→Analyze→Evaluate, with the grading note separating doc-set-graded from drill-log-graded items
R8	Ledger write complete	PASS	`auto_score`/`self_score` = `""`; journal prompt closes the arc against her lesson-1 baseline; next seeds recorded
R9	Scaffolding fades; at-bat genuinely independent	PASS	Cycles model one join and one trigger table only; the capstone provides raw drill input and zero procedure — the system built in cycles 1–4 is the only scaffold, which is the capstone's design; completes the arc's 7→12 fade
R10	Referents elected-only, flavor-only	PASS	One Mets spring-training referent (cycle 2), decorative; the join logic stands on the doc-set's freshness contract
R11	Info-at-point-of-use honored	PASS	The audit-priority order appears at inventory-sorting; the self-reference channel at delta-reading; cadence facts at the beat DO; no front-loaded reading
R12	No replication	PASS	No prior lesson or exemplar contains an inventory, delta-join, trigger classes, beat, or update drill; L5/L7/L10 checks are consumed as re-verification instruments, not re-taught; all DOs/exit Qs new; the capstone fulfills the lesson-12 spec (simulated update → re-derive → re-verify, alone)

Escalation: all load-bearing indicators PASS → auto-ships (Playbook §5, AIHC X2/B3).