Curate

/curate [--init] [--deeper] [--verify]

Correlation engine that combines vallorcine's structured history with git data to find things that individual features, decisions, and research sessions couldn't see because they each had a narrower scope.

What it finds:

1. ADR pressure — decisions under concentrated change (scope being actively modified)
2. ADR gravity — files implicitly related to decisions but not in their scope
3. Hub files — shared dependencies across 3+ decisions (fragility/test concerns)
4. ADR drift — code diverging from architectural decisions
5. Stale KB — research that may have better approaches now given what's been built
6. Implicit dependencies — gaps between independently-designed features
7. Orphaned areas — high-churn files with no structured knowledge behind them
8. Unspecified shared types — foundational types referenced by 3+ specs with no spec
9. Spec obligations — DRAFT specs with unresolved conflicts blocking approval
10. Spec-code drift — specs whose domain code changed after the spec was written
11. Cross-reference gaps — KB entries and ADRs with missing related/source links
12. Missing @spec annotations — APPROVED specs with reqs that lack impl-side or test-side annotations
13. Aging open obligations — obligations on specs that haven't been committed in 30+ days
14. Link rot — KB-cited URLs that no longer resolve (4xx or connection failures)
15. Falsification-lens staleness — APPROVED specs authored before a falsification lens shipped that match the lens's keywords (candidates for re-falsification under the newer lens)
16. KB filename collisions — entries sharing a filename across folders (silently fragments search and pattern-recurrence evidence)
17. KB schema drift — frontmatter that does not match .kb/_refs/frontmatter.md (missing/bad-enum fields, confidence overclaim, path/frontmatter mismatch)
18. KB type/location mismatch — adversarial findings outside patterns/<concern>/ or feature-footprints outside architecture/feature-footprints/
19. KB citation drift in source — // KB: / # KB: citations in changed source files that point at missing entries or whose entry's applies_to doesn't include the source file (closes the loop with the check-kb-ref.sh PostToolUse hook)
20. Spec graduation candidates — specs marked status: DEPRECATED that are still state: APPROVED (still entering /spec-resolve bundles despite the author's intent to retire them — finalize displacement or retract the status)
21. Spec corpus xref drift — corpus rollup of unresolvable decision_refs / kb_refs across all specs (per-spec spec-validate.sh warnings are easy to miss at scale)
22. Spec annotation coverage rollup — corpus-level summary across the four buckets (fully covered / drift / bare-only / unannotated). Frames /spec-backfill --all vs row-by-row routing decision.
23. ADRs without spec coverage — accepted/proposed ADRs that no spec references via decision_refs. Architectural intent without an operational contract.

Flags:

• --init — first-time scan (ignores last-scanned SHA, good for new installs)
• --deeper — scan 6 months instead of default 3
• --obligation-age-days <n> — override aging threshold for open obligations (default: 30)
• --max-specs-traced <n> — cap @spec annotation traces per run (default: 50)
• --verify — focused pass over verification-shaped candidates only (link-rot, falsification-staleness). Skips the broader correlation flow. Dismissals persist to .curate/verify-dismissed.txt so future scans don't re-prompt the same items.
• --analysis <name> — when used with --verify, restrict to a single analysis: link-rot, falsification-stale, or all (default: all).

This command feels like a colleague who noticed something and is offering to help, not a task manager assigning work.

Verify mode

When invoked with --verify, this skill runs the same scan but presents ONLY the verification-shaped candidates from Analyses 21 (link rot) and 22 (falsification staleness). The broader correlation flow (ADR pressure, hub files, spec-code drift, cross-ref repair, etc.) is skipped — those signals belong to the regular /curate cadence.

Verify mode is a separate cadence: run it before major work (release prep, audit kickoff) or monthly, when the heavier verification pass is justified. Regular /curate stays drift-shaped; verify mode is verification-shaped.

Per-candidate flow:

• Each link-rot row → AskUserQuestion with options: refresh via /research, mark accepted, dismiss, skip.
• Each falsification-stale row → AskUserQuestion with options: run depth pass via /spec-author <id> --depth-pass-only --lens <name>, decline (lens does not apply), dismiss, skip.

Dismissal persistence. When the user picks "dismiss" in verify mode, append a row to .curate/verify-dismissed.txt:

<analysis>|<candidate-key>|<dismiss-date>|<reason>

Where <candidate-key> is the URL for link-rot or <spec-id>:<lens> for falsification-staleness. Future verify-mode runs read this file and skip any candidate whose key is dismissed (the underlying scan-summary.md still surfaces them for non-verify /curate runs; the dismissal only applies to the verify-mode prompt loop).

When the user picks "skip" instead of "dismiss", nothing is recorded — the candidate resurfaces next verify-mode run.

Subagent contract — MANDATORY for every dispatch

Every Agent dispatch this skill issues (invoke-architect, invoke-research, invoke-spec-author, or any future side-effect that uses the Agent tool) MUST be given this preamble at the top of the dispatched skill's prompt:

Subagent contract: Honor rules/completeness-contract.md (load-bearing — no silent deferrals; trigger phrases = escalation signals, not completion modes). If you cannot complete assigned scope, escalate via AskUserQuestion with user-validatable proof. A return claiming COMPLETE alongside deferred items is a contract violation.

When dispatched skills return, the curator MUST run the validation script BEFORE marking the finding resolved:

mkdir -p /tmp/vallorcine
return_file=/tmp/vallorcine/curate-return-"<finding-key>".txt
printf '%s\n' "$FULL_RETURN_TEXT" > "$return_file"
bash .claude/scripts/validate-subagent-return.sh "$return_file" 2>/tmp/vallorcine/validator-stderr.txt
rc=$?

• rc=0 → mark finding resolved and continue.
• rc=1 → trigger phrase detected. Surface to user via AskUserQuestion with validator stderr. Block resolved until user clears.
• rc=2 → tooling error. Log and treat as rc=0.

Step 0 — Pre-flight

Check that .curate/ directory exists. If not, create it.

Read .curate/curation-state.md if it exists — extract the last-scanned SHA from the Scan State section. (Older installs may still carry a Review Log section in this file. Migrate it to the append-only review log on first run:)

if [[ -f .curate/curation-state.md ]]; then
  bash .claude/scripts/curate-review-log.sh migrate \
    .curate/curation-state.md .curate/review-log.md
fi

Migration is idempotent — re-running on a migrated state file is a no-op. After this point, the review log lives at .curate/review-log.md and is append-only. Never edit it by hand.

Read the unresolved items the user previously deferred or noted-for-later. These will be re-surfaced in Step 2.5 alongside any new findings:

PRIOR_UNRESOLVED=$(bash .claude/scripts/curate-review-log.sh unresolved \
  .curate/review-log.md 2>/dev/null || true)

PRIOR_UNRESOLVED is a list of <key>|<status>|<description>|<date> records. Empty when this is the first run or every prior finding was resolved/dismissed.

Stuck-marker recovery. Scan .curate/_dispatches/ for any unacknowledged finding-resolution markers from a previous /curate run that crashed mid-dispatch:

STUCK_MARKERS=$(bash .claude/scripts/dispatch-marker.sh stuck \
  .curate/_dispatches 2>/dev/null || true)

Each row is <finding-key>|<dispatched-at>|<has-result>|<failure-reason>.

If non-empty, surface BEFORE Step 1 (the scan run). Batch the prompt when N > 2 markers exist (2026-05-11 adversarial MED #3) — per the kit-development "Interactive prompt standard," dynamic lists with >4 items should use summary options rather than firing N consecutive AskUserQuestions in a row.

• N == 1: single AskUserQuestion with three options — "Re-dispatch" (clear marker, include in this run), "Skip for now" (leave marker; next run will resurface it), "Investigate manually" (print marker JSON via dispatch-marker.sh status .curate/_dispatches <finding-key> and stop the /curate run).

• N == 2: two sequential AskUserQuestions, same option set. Acceptable user friction.

• N > 2 (the batching path): one AskUserQuestion with summary options that apply to all stuck markers:

  • "Re-dispatch all" — clears all markers and includes each finding in this run
  • "Skip all" — leaves every marker; next run resurfaces them
  • "Walk one at a time" — falls back to the per-marker prompt (N consecutive AskUserQuestions, one per marker, same option set as the N==1 case)
  • "Investigate manually" — print all marker JSONs and stop This caps user interruption at one prompt regardless of N — the pre-fix flow with N=5 markers fired 5 sequential prompts before the scan even started.

This mirrors /work-resume rule 0 (PR #79) and /spec-backfill C0 — any unacknowledged marker pre-empts the normal flow because it represents a previous dispatch whose result was never reconciled.

Display opening header:

───────────────────────────────────────────────
🔍 CURATION · scanning for quality signals
───────────────────────────────────────────────

Step 0.5 — Index verification (self-healing)

Before scanning, run the index verification script to catch and repair any index inconsistencies from previous crashes:

bash .claude/scripts/index-verify.sh --both 2>&1

If repairs are made, the script outputs what was fixed. Note these for the findings presentation — they're bookkeeping fixes the user should know about but don't need to act on.

If the script doesn't exist (older install), skip silently.

Step 1 — Run the scan script

Build the scan command:

bash .claude/scripts/curate-scan.sh [--init] [--window <months>] \
  [--obligation-age-days <n>] [--max-specs-traced <n>]

• Default: --window 3 (3 months, capped at 500 commits)
• If --init flag: pass --init
• If --deeper flag: pass --window 6
• If the user passes --obligation-age-days or --max-specs-traced, forward them
• The --verify flag does NOT change the scan invocation — the script still runs every analysis. Verify mode only narrows which candidates the pick-list presents in Step 3.

Run the script. If it exits with "No new commits since last scan," report that and ask if the user wants to force a rescan with --init.

Step 1.1 — Verify scan completeness via sentinel (REQUIRED)

After the scan script exits, before reading the summary in Step 2, check that .curate/scan-summary.md ends with the scan-complete sentinel. The sentinel is the last line and looks like:

✓ Scan complete: <iso-date> · max_specs_traced=<N> · specs_traced=<M> · scan_mode=<full|incremental> · window_months=<W>

A missing sentinel means the script exited before its final block — the summary was partially written and must NOT be read as authoritative. Common causes: Claude Code's default Bash timeout (jlsm-sized repos can run 10–15 min if Analysis 18 traces all APPROVED specs), manual Ctrl-C, context compaction mid-run.

Check:

tail -1 .curate/scan-summary.md | grep -q "^✓ Scan complete:"

If absent → the scan was interrupted. Surface to the user via AskUserQuestion:

• "Re-run with --init --max-specs-traced 0" — recommended for large repos. Skips the per-spec annotation trace (Analysis 18), which is the only analysis that typically pushes runtime past 60s. Annotation-coverage rollup data will be absent; if needed, run a follow-up trace pass with --max-specs-traced 50 (or higher) once the fast scan confirms the rest of the corpus is clean.
• "Re-run with --init" — fresh full scan; same timeout risk.
• "Read partial summary anyway" — only safe when the missing analyses are known to not apply (small repos, first-time setup). The user takes responsibility.

If the sentinel IS present, surface its contents to the user in one line so they see the scope of what ran:

Scan complete: <date> · traced <M>/<approved-count> specs · window <W>m

No-op scan detection (CRIT 5, 2026-05-11 adversarial). When the scan script exits "No new commits since last scan" or "No commits found in scan range," it overwrites scan-summary.md with a no-op marker — the sentinel includes the literal substring · no-op ·. Detect this:

if tail -1 .curate/scan-summary.md | grep -q "· no-op ·"; then
    # No-op scan — prior findings already addressed or no qualifying
    # activity in window. Do NOT proceed into Step 2 with the prior
    # summary as if it were fresh.
fi

If detected, surface to the user via AskUserQuestion:

• "Force a fresh scan (--init)" — re-runs against the full window regardless of LAST_SHA.
• "Expand the window (--window-months N)" — useful when commit activity falls outside the default window.
• "Stop — nothing to curate right now" — exit cleanly.

Without this check, prior findings (potentially days/weeks old) get re-presented as if they were just discovered — confusing the user and re-surfacing already-resolved drift.

If specs_traced=0 in the sentinel AND APPROVED specs exist in the manifest, note that the annotation-coverage rollup (Analysis 18b) and the per-spec annotation gap analyses (Analysis 18) did not run for this scan. Offer to schedule a follow-up trace pass before closing.

Step 1.5 — Verify-mode branch

If the user invoked /curate --verify:

1. Filter Step 2 to subsections 2p (link rot) and 2q (falsification staleness) only. Skip 2a-2o and 2r entirely. The other signals belong to the regular /curate cadence.
2. Apply the analysis filter. If the user passed --analysis link-rot, only run 2p. If --analysis falsification-stale, only run 2q. Default (or --analysis all) runs both.
3. Read the dismissed-state file at .curate/verify-dismissed.txt (touch it if missing). The format is one row per dismissal: <analysis>|<candidate-key>|<date>|<reason>. Build a transient set of dismissed keys.
4. Filter candidates by dismissed-state. When walking the candidate list from the scan summary, skip any candidate whose key matches a dismissed entry. The user already declined to act on it; don't re-prompt until the dismissed entry is manually removed.
5. Step 3 pick list shows ONLY verify-mode items. No other findings surface. The cold-start framing is also skipped — verify mode assumes structured artifacts already exist.
6. Step 4 routing in verify mode. When the user picks "dismiss" on a candidate, append a new row to .curate/verify-dismissed.txt:
   • For link-rot: link-rot|<url>|<YYYY-MM-DD>|<one-line reason>
   • For falsification-stale: falsification-stale|<spec-id>:<lens>|<YYYY-MM-DD>|<one-line reason> When the user picks "skip", do NOT write to the dismissed file — "skip" defers; "dismiss" persists.

If the user did NOT pass --verify, skip this entire section and run Step 2 normally with all subsections.

Step 2 — Read and correlate

Read .curate/scan-summary.md (the script's output).

Also read (if they exist):

• .decisions/CLAUDE.md — active decisions index
• .kb/CLAUDE.md — KB root index
• .feature/CLAUDE.md — active and archived features

2a — ADR drift detection

ADR Pressure (from "ADR Pressure" in scan summary):

1. ADRs with 2+ constrained files changed in the scan window
2. Higher pressure % = more of the decision's scope is actively changing
3. Read the ADR and assess: is the code evolving within the decision, or away from it?
4. High pressure (>60%) → strong signal for re-evaluation

ADR Gravity (from "ADR Gravity" in scan summary):

1. Files that co-change with ADR-constrained files but aren't in the ADR's scope
2. These are implicit relationships — the decision's influence is wider than documented
3. Assess: should these files be added to the ADR's files: field, or is the co-change coincidental?
4. High gravity (5+ unconstrained files for one ADR) → potential isolation problem. The decision may have drawn the boundary in the wrong place. Flag for /architect review with framing: "This decision's actual dependency footprint is larger than its documented scope — worth re-evaluating the boundary."

Hub Files (from "Hub Files" in scan summary):

1. Files co-changing with 3+ ADRs' constrained areas
2. These are fragility points — changes here ripple across multiple decisions
3. Flag as test coverage concerns: "This file is a shared dependency across architectural decisions. Worth ensuring test coverage is solid."

Flat artifact correlations (from "Artifact Correlations" where Type is ADR):

1. Individual ADR file references not captured by pressure (single-file changes)
2. Read the referenced ADR, compare stated approach against changed files
3. Check if "Conditions for Revision" have been met by recent changes

2b — KB + hindsight review

For each entry in "Stale KB Entries":

1. Note the KB file and how long since last research
2. Cross-reference with "Churn Hotspots" — is the area the KB covers actively changing?
3. Check if any ADRs were made since the KB entry was written that might change which options are viable

For each entry in "Artifact Correlations" where Type is KB:

1. Note that implementation has changed since research was done
2. Flag if the changes suggest the research conclusions may need updating

2c — Implicit dependency detection

Using "Co-change Clusters" and "Artifact Correlations" where Type is FEATURE:

1. Identify file pairs that co-change but were designed in separate features
2. Check if cross-feature test coverage exists for the shared files
3. Flag gaps where independently-designed features share files without cross-coverage

2d — Orphaned areas

From "Orphaned Areas" in the scan summary:

1. Identify high-churn files with no KB, ADR, or feature coverage
2. These are backfill candidates — areas the codebase is actively changing but that have no structured knowledge behind them

2e — Test-source drift

From "Test-Source Drift" in the scan summary:

1. Source files that changed but their corresponding tests didn't
2. Cross-reference with feature archives — were these files part of features that should have had test updates?
3. Flag files where the drift is significant (3+ source commits with no test change)
4. This catches within-feature drift where implementation evolved but tests didn't keep pace

2f — Backfill candidates (implicit decisions)

From "Backfill Candidates" in the scan summary:

1. Archived feature domains that made implicit decisions (no governing ADR)
2. For each candidate, assess whether the decision is significant enough to warrant formal documentation
3. Present as items the user can decide, draft as ADR, defer, or dismiss
4. This subsumes the standalone /decisions backfill command — curate is the single entry point for finding undocumented decisions

2g — Out-of-scope items (deferred work in accepted ADRs)

From "Out-of-Scope Items" in the scan summary:

1. Items from "What This Decision Does NOT Solve" sections of confirmed ADRs that have no corresponding deferred decision stub
2. These are architectural concerns the team explicitly scoped out when making a decision — they are effectively deferred work invisible to /decisions triage
3. Group items by parent ADR for presentation
4. For each item, the user can: create a deferred stub, skip, or create all stubs from that parent ADR at once

2h — Spec coverage analysis

Guard: Only run this step if .spec/ exists. If no spec directory, skip entirely — don't mention specs or suggest setting up specs.

From "Spec Coverage Gaps" in the scan summary (if present):

Unspecified shared types:

1. Types referenced by 3+ specs that have no spec of their own
2. These are foundational types with implicit contracts — multiple specs depend on their behavior but nobody has defined what that behavior is
3. Rank by reference count — higher count = more dependent specs = bigger risk

Specs with open obligations:

1. Specs with [UNRESOLVED] or [CONFLICT] markers or open_obligations in frontmatter
2. These are blocking downstream work — DRAFT specs can't be relied on until obligations are resolved
3. Higher obligation count = more blocking

Obligation registry (from _obligations.json):

1. Open obligations from the centralized registry — spec requirements where the code does not match the spec. These are the gap between what was specified and what was built.
2. Group by spec for display. Show affected requirement count and blocked_by.
3. Route to /work-decompose "<group>" --from-obligations to convert obligations into a work group with proper WD ordering. This is the primary action — obligations without a work group have no implementation path.
4. Higher affected-requirement count = larger implementation gap.

Spec-code drift:

1. Specs whose domain files have been committed since the spec was created
2. Higher commit count = more likely the spec no longer matches reality
3. Cross-reference with ADR pressure — if the same area has both ADR pressure and spec drift, it's a stronger signal

Undecided absent behaviors:

1. Specs with [ABSENT] requirements — behaviors that downstream specs assume but the implementation doesn't provide
2. These are unresolved design decisions: each [ABSENT] requirement needs an explicit promote/preserve/defer choice
3. Higher count = more implicit assumptions without backing decisions

Orphaned specs (no matching source code):

1. APPROVED specs whose subject tokens were not found in any source file
2. These may describe behavior that was removed without updating the spec
3. For each orphaned spec, use AskUserQuestion with options:
   • "Verify with /spec-verify" — run spec-verify to check if the behavior still exists (subject token search may have missed it)
   • "Mark as INVALIDATED" — the behavior was removed; mark the spec as INVALIDATED with displacement_reason: "behavior removed — detected by curate scan"
   • "Skip for now" — defer to a later curation pass

2i — Cross-reference repair candidates

Guard: Only run this step if "Cross-Reference Candidates" section exists in the scan summary. If absent, skip entirely.

From "Cross-Reference Candidates" in the scan summary:

KB entries with missing related links (tag overlap):

1. Entry pairs that share 2+ tags but have no related link between them
2. Higher tag overlap = stronger signal that these entries should reference each other
3. Entries in different categories are more valuable links — same-category entries are already navigable via category indexes
4. Assess whether the overlap is meaningful: shared tags like "performance" + "caching" between a caching strategy and a benchmarking entry → likely related. Shared tags like "java" + "testing" between unrelated entries → coincidental.

KB entries with overlapping applies_to:

1. Entries that target the same source files/patterns but don't reference each other
2. These likely describe different aspects of the same code — a related link helps the Research Agent find all relevant context when loading one entry
3. Stronger signal than tag overlap because file paths are specific

ADR evaluation references not in KB Sources:

1. KB entries cited in evaluation.md scoring that don't appear in the ADR's KB Sources Used table
2. These are missing traceability links — the ADR used this research during evaluation but doesn't formally reference it
3. Fix is straightforward: add the missing row to the KB Sources table

2j — Deferred audit feedback

Guard: Only run this step if "Deferred Audit Feedback" section exists in the scan summary. If absent, skip entirely.

From "Deferred Audit Feedback" in the scan summary:

1. Each row is a spec-updates.md or kb-suggestions.md file from a completed audit where the user skipped or deferred the feedback loop
2. These contain ready-made spec requirements and KB pattern suggestions that a prior audit produced — they don't need re-analysis, just review and application
3. Present as high-priority pick list items — the work is already done, applying it is cheap

When the user picks one of these items:

• Read the file at the path shown in the scan summary
• Present the contents using the same apply/review/skip (for specs) or create/select/skip (for KB) menus from the audit feedback loop (see audit SKILL.md Job 5a/5b for the exact flow)
• After applying: rename the file from <name>.md to <name>.applied.md so it won't be picked up by future curate scans or audit feedback loops

2k — Decisions roadmap needed

Guard: Only run this step if "Decisions Roadmap Needed" section exists in the scan summary. If absent, skip entirely.

From "Decisions Roadmap Needed" in the scan summary:

1. There are 10+ deferred decisions with no current roadmap
2. Present as a high-priority pick list item: "N deferred decisions need planning — run /decisions roadmap to cluster and prioritize"
3. When the user picks this item: suggest running /decisions roadmap in a separate session (roadmap is a planning skill, not a curate action)

2l — Work group health

Guard: Only run this step if any "Work Group:" section exists in the scan summary. If absent, skip entirely.

Displaced dependencies:

1. Work definitions that depend on specs now INVALIDATED
2. These WDs are effectively BLOCKED by a spec that no longer exists
3. For each, use AskUserQuestion with options:
   • "Author replacement spec" → suggest /spec-author for the missing spec
   • "Update WD to remove dependency" → the WD no longer needs this artifact
   • "Skip for now" — defer

Stalled work groups:

1. Work groups with no WD activity in 14+ days
2. Present the group name, total WDs, completed WDs, and days since last activity
3. For each, use AskUserQuestion with options:
   • "Check status" → run /work-status "<group>"
   • "Skip" — acknowledged, no action needed

Artifact drift:

1. WDs whose artifact dependencies were modified after the WD was written
2. The artifact still exists but its content changed — the WD's assumptions may be stale
3. For each, use AskUserQuestion with options:
   • "Review WD" → read the WD and the changed artifact, assess impact
   • "Skip" — the change was minor and doesn't affect the WD

2m — Spec annotation coverage gaps

Guard: Only run this step if "Spec Annotation Coverage Gaps" section exists in the scan summary. If absent, skip entirely.

From "Spec Annotation Coverage Gaps" in the scan summary:

Requirements missing impl- or test-side annotations:

1. Rows with gap "test-only → missing impl annotation" mean a test is tagged with @spec <sid>.Rn but no implementation file carries the same tag. The requirement may be unimplemented, or the impl exists but was never annotated.
2. Rows with gap "impl-only → missing test annotation" mean implementation is tagged but no test is. The requirement may be untested, or a test exists but was never annotated.
3. Higher req count per spec = bigger coverage hole.

APPROVED specs with no annotations at all:

1. The spec is APPROVED but spec-trace found zero @spec references in source or test. Either the code was never annotated, or the spec no longer describes any implemented behavior (overlap with orphaned-spec detection).
2. These are higher-priority than single-requirement gaps because the whole spec's traceability is missing.

For each finding, use AskUserQuestion with options:

• "Backfill via /spec-backfill" → routes to /spec-backfill <spec-id> to walk uncovered requirements and apply annotations to existing code. This is the right tool for the "no annotations at all" case and for single-requirement gaps where the implementation already exists.
• "Verify via /spec-verify" → use when the gap may indicate spec→code drift (the spec describes behavior that may no longer be in the code, or vice versa). /spec-verify classifies and repairs spec violations; it is heavier than /spec-backfill and not the default for pure annotation backfill.
• "Accept gap with justification" → the gap is intentional (e.g. the requirement is pure documentation; no runtime behavior to annotate). Record in the curation state review log with a short justification.
• "Skip for now" — defer to next /curate pass

2m-drift — Annotation drift (partial coverage below 50%)

Guard: Only run this step if the "Annotation drift — APPROVED specs below 50% coverage" subsection exists under "Spec Annotation Coverage Gaps" in the scan summary. If absent, skip entirely.

This subsection lists APPROVED specs whose annotation coverage has slipped below 50% — they have some annotations (so they are not in the unannotated bucket above) but are drifting. Rows are ordered by uncovered- percentage descending, then by spec-file age descending.

If there are 4+ drifted specs, ask the user once whether to handle them individually or run a corpus walk. Use AskUserQuestion with options:

• "Run /spec-backfill --all" → the corpus walk catches drift across every spec in one pass; progress persists in .spec/backfill-log.md so the user can break out and resume.
• "Walk specs one at a time" → fall through to per-spec routing below.

For each drifted spec (or each one when walking individually), use AskUserQuestion with options:

• "Backfill via /spec-backfill " → routes to per-spec walk.
• "Skip for now" — defer to next /curate pass.
• "Dismiss as intentional" — record in the review log so this spec no longer appears in drift findings (e.g. an aspirational spec where partial coverage is by design).

2n — Aging open obligations

Guard: Only run this step if "Aging Open Obligations" section exists in the scan summary. If absent, skip entirely.

From "Aging Open Obligations" in the scan summary:

1. Each row shows a spec ID, age in days since the spec file was last committed, and the obligation text.
2. The age is a proxy — the obligation has survived that long without the spec being touched, suggesting it's drifted out of active attention.
3. Higher age = more drift. 60+ days is a strong signal; 30-60 is a reminder.

For each aging obligation, use AskUserQuestion with options:

• "Resolve via /spec-author" → run /spec-author on the spec to either author the missing behavior as new requirements or close the obligation as intentional
• "Resolve via /spec-resolve" → use /spec-resolve to work through [UNRESOLVED] / [CONFLICT] markers if the obligation is a conflict
• "Close as stale" → the obligation is no longer relevant; remove it from the spec's open_obligations frontmatter with a short note in the spec's design narrative explaining the closure
• "Skip for now" — defer to next /curate pass

2p — Link rot in KB entries

Guard: Only run this step if "Link Rot in KB Entries" section exists in the scan summary. If absent, skip entirely.

From "Link Rot in KB Entries" in the scan summary:

1. Each row shows a status code, the KB entry path, the URL, and when it was last checked. Status 000 indicates a connection failure (DNS, timeout, refused). Status 4xx indicates the server responded but the resource is gone.
2. Dead URLs in KB entries silently rot the knowledge: the stored fact looks authoritative but the source it claims to ground no longer exists. Higher-impact when the KB entry is heavily cross-referenced.
3. The script caches per-URL results (7-day TTL) so the same dead URLs don't trigger fresh curl requests on every scan.

For each candidate, use AskUserQuestion with options:

• "Refresh via /research" (description: "Run /research to re-investigate the topic and replace the dead citation with a current source")
• "Verify via /curate --verify" (description: "Confirm via WebFetch that the URL is genuinely gone before refreshing — useful when transient connection failures may have produced false positives")
• "Mark as accepted" (description: "The URL is gone but the cited fact is still valid in the KB; record acceptance in the curation review log so the same URL doesn't resurface")
• "Skip" — defer to next /curate pass

If "Refresh": invoke /research "<subject inferred from KB entry>" context: "curate: dead citation at <kb-path>, URL <url> returned <status>". If "Mark as accepted": append the URL to a link-rot-accepted block in .curate/curation-state.md. The cache continues to track it; future scans surface it but the review log shows the user's prior acceptance.

2q — Falsification-lens staleness

Guard: Only run this step if "Falsification Lens Staleness" section exists in the scan summary. If absent, skip entirely.

From "Falsification Lens Staleness" in the scan summary:

1. Each row shows an APPROVED spec, its git first-commit-touched date, the lens whose introduction date post-dates the spec, and the keyword from the spec body that matched the lens's pattern.
2. The signal: the spec's original Pass 2 falsification predates this lens shipping, so attack categories the lens covers (e.g., adversary- model patterns from the security lens shipped in v0.14.2) may not have been considered.
3. The match is heuristic. A spec mentioning "auth" doesn't necessarily need a security depth pass; the user judges whether the lens applies.

For each candidate, use AskUserQuestion with options:

• "Run depth pass via /spec-author" (description: "Run /spec-author <spec-id> --depth-pass-only --lens <lens> to re-falsify the spec under the named lens; findings flow through the standard arbitration UI")
• "Decline — lens does not apply" (description: "The keyword match is incidental; the spec's scope does not actually need the lens's attack categories. Records a decline so future scans don't resurface this lens for this spec")
• "Skip" — defer to next /curate pass

If "Run depth pass": invoke /spec-author <spec-id> --depth-pass-only --lens <lens> directly. If "Decline": append a falsification-decline row to .curate/curation-state.md keyed by <spec-id>:<lens>. The script continues to surface this candidate, but the review log shows the user's prior decline.

2o — Subdivision candidates (mature specs that may want to subdivide)

Guard: Only run this step if "Subdivision Candidates" section exists in the scan summary. If absent, skip entirely.

From "Subdivision Candidates" in the scan summary:

1. Each row shows a spec that has grown past one file's worth of behavior (≥50 reqs OR ≥15K tokens) AND shows multiple distinct concerns (≥2 section headers, no single section dominating).
2. Subdivision is a natural progression for these specs — the parent stays a full spec retaining cross-cutting requirements, while concern- specific reqs move to child specs. The detection is heuristic; a spec that looks subdividable on paper may turn out to be a single tightly- coupled concern that just happens to have multiple section headers.
3. The script already filters out specs where one section holds ≥90% of the requirements (those are mature-but-singular and not real candidates).

For each candidate, use AskUserQuestion with options:

• "Subdivide via /spec-split" → run /spec-split <spec-id>. The skill will propose concern boundaries from the spec's existing section structure, confirm with you (with edit option), and execute the split with @spec annotation rewrites + automatic rollback on validation failure.
• "Decline — concerns are interlocked" → mark this spec as a recent decline so a future /curate pass doesn't surface it again immediately. Add a one-line note to the spec's design narrative explaining why it shouldn't subdivide (e.g. "single algorithm, requirement clusters reflect implementation phases, not separable concerns").
• "Defer" → the spec is a candidate but you're not ready to subdivide this session. It will resurface at the next /curate run.

The "Decline — concerns are interlocked" option is important. Subdivision fragments a coherent contract when forced; it should never be automatic. Honest declines are a feature, not a failure.

2r — KB structural drift

Guard: Only run this step if any of the following sections exist in the scan summary: "KB Filename Collisions", "KB Schema Drift", "KB Type/Location Mismatch". If none exist, skip entirely.

These three analyses share a goal — keep the KB's structure aligned with .kb/_refs/frontmatter.md so search, cross-reference repair, and type-aware loaders work. They are presented together because the user's typical action is the same: review one entry's drift and apply the patch.

KB filename collisions (from "KB Filename Collisions" in scan summary):

1. Each row shows a filename that exists at 2+ paths under different folders. Cross-folder collisions silently fragment grep, pattern- recurrence evidence, and kb-search.sh ranking. A reader running grep partial-init-no-rollback.md .kb gets N hits and cannot tell which is canonical.
2. Resolve by renaming the lesser-used variant(s) to disambiguate (e.g., builder-pre-validation-mutation.md and multi-step-init-no-rollback.md).
3. Alternatively, if the collision is intentional and benign, dismiss with a one-line reason — but the default assumption is that a collision is drift.

For each collision, use AskUserQuestion with options:

• "Rename one variant" (description: "Choose which path keeps the name; the other gets a more specific filename. /curate updates references that point at the renamed file.")
• "Merge into one entry" (description: "If the entries cover the same pattern, merge into the canonical location and delete the duplicate. Append the deleted entry's ## Audit Findings history to the kept entry.")
• "Dismiss as intentional" (description: "Record in review log; won't resurface")
• "Skip" (description: "Defer to next /curate pass")

KB schema drift (from "KB Schema Drift" in scan summary):

1. Each row is one issue per entry. Issue codes:
   • missing-frontmatter — no YAML block at top.
   • missing-<field> — required core or type-specific field absent.
   • bad-<field> — value outside the allowed enum (e.g. research_status: foo).
   • legacy-<field> — deprecated value in use (e.g. research_status: archived should be deprecated).
   • confidence-overclaim — confidence: high without ≥2 corroborating sources or ## Found in entries.
   • topic-mismatch / category-mismatch — frontmatter field disagrees with the file's path (path is canonical).
2. An entry with multiple issues appears multiple times. Resolve them together when picking that entry.
3. Drift breaks tag-based search, cross-reference repair, and the type-aware loaders in /research, audit, and feature-retro.

For each entry (group rows by path), use AskUserQuestion with options:

• "Apply patches" (descri

…(truncated)