@chrisai/base 2.3.0

package/src/framework/tasks/carl-hygiene.md

@@ -0,0 +1,160 @@
+<purpose>
+Structured CARL domain maintenance. Review staged proposals, flag stale rules, audit domain health, and keep CARL lean and accurate.
+</purpose>
+
+<user-story>
+As an AI builder, I want a guided CARL maintenance session, so that my domain rules stay relevant, staged proposals get decided on, and CARL doesn't become a dumping ground of stale rules.
+</user-story>
+
+<when-to-use>
+- Monthly (on configured cadence)
+- When pulse reports overdue CARL hygiene
+- When user says "carl hygiene", "review carl rules", "clean up carl"
+- Entry point routes here via /base:carl-hygiene
+</when-to-use>
+
+<steps>
+
+<step name="assess" priority="first">
+Gather CARL health data and present summary.
+
+1. Read `.base/workspace.json` for `carl_hygiene` config (threshold, max rules, last run)
+2. Read `.base/staging.json` for pending proposals (via `carl_get_staged`)
+3. For each domain file in `.carl/`:
+   - Count rules
+   - Parse metadata comments (`# Last reviewed:` lines)
+   - Flag rules where last_reviewed is older than `staleness_threshold_days`
+   - Flag domains exceeding `max_rules_per_domain`
+4. Present summary:
+   ```
+   CARL Hygiene Assessment
+   ━━━━━━━━━━━━━━━━━━━━━━
+   Staged proposals: {N} pending
+   Domains: {N} total, {N} with stale rules, {N} over max
+   Total rules: {N} across all domains
+   Last hygiene: {date or "never"}
+   ```
+
+**Wait for operator confirmation before proceeding.**
+</step>
+
+<step name="review_proposals">
+Process each pending staged proposal.
+
+For each pending proposal from `carl_get_staged`:
+1. Present:
+   ```
+   Proposal {id} — {domain}
+   Proposed: {date} | Source: {source}
+   Rule: "{rule_text}"
+   Rationale: {rationale}
+   ```
+2. Ask: "**Approve**, **Kill**, **Archive**, or **Defer**?"
+3. Execute:
+   - Approve → `carl_approve_proposal(id)` (writes rule to domain file with metadata)
+   - Kill → `carl_kill_proposal(id)`
+   - Archive → `carl_archive_proposal(id)`
+   - Defer → skip (stays pending for next hygiene)
+
+**After approval:** Add metadata comments above the new rule in the domain file:
+```
+# Rule added: {today}
+# Last reviewed: {today}
+# Source: {proposal.source}
+{DOMAIN}_RULE_{N}={rule_text}
+```
+
+Process one proposal at a time. Wait for response between each.
+</step>
+
+<step name="review_stale_rules">
+Review rules flagged as stale (last_reviewed > threshold).
+
+For each domain with stale rules:
+1. Present domain name and total rule count
+2. For each stale rule:
+   ```
+   [{DOMAIN}] Rule {N} — last reviewed {date} ({days} days ago)
+   "{rule_text}"
+   ```
+3. Ask: "**Keep** (update reviewed date), **Archive**, or **Kill**?"
+4. Execute:
+   - Keep → Update `# Last reviewed:` comment to today
+   - Archive → Remove rule from domain file, add to `.carl/archive/archived-rules.json` with context
+   - Kill → Remove rule from domain file (with "Are you sure?" confirmation)
+
+**When archiving:** Read `.carl/archive/archived-rules.json`, append:
+```json
+{
+  "domain": "DOMAIN",
+  "rule_number": N,
+  "rule_text": "the rule",
+  "added": "original-added-date",
+  "archived": "today",
+  "reason": "operator's reason"
+}
+```
+
+Then renumber remaining rules in the domain file to close gaps.
+
+Process one domain at a time.
+</step>
+
+<step name="review_domains">
+Quick domain health check — guided Q&A.
+
+1. List all active domains with rule counts
+2. Cross-reference with `.base/ACTIVE.md` current projects:
+   - Any active projects missing a domain?
+   - Any domains for inactive/completed projects?
+3. Check recall phrases:
+   - "Do the recall phrases for {domain} still match how you talk about this work?"
+4. Check for domains over `max_rules_per_domain`:
+   - "Domain {X} has {N} rules (max: {max}). Any candidates to archive or consolidate?"
+5. Ask: "Any new domains to create? Any to deactivate?"
+
+**Guided Q&A — don't force changes, just surface questions.**
+</step>
+
+<step name="review_decisions">
+Quick check on per-domain decision health.
+
+1. List `.carl/decisions/*.json` files with counts
+2. Flag domains with 0 decisions (might be missing logging)
+3. Flag decisions older than 90 days (might be outdated)
+4. Ask: "Any decisions to review or archive?"
+
+**Brief pass — decisions are mostly self-maintaining.**
+</step>
+
+<step name="log">
+Record the hygiene session.
+
+1. Update `.base/workspace.json` → `carl_hygiene.last_run` to today's date
+2. Update `.base/STATE.md` → note CARL hygiene completed
+3. Report:
+   ```
+   CARL Hygiene Complete
+   ━━━━━━━━━━━━━━━━━━━━━
+   Proposals: {N} processed ({N} approved, {N} killed, {N} archived, {N} deferred)
+   Rules reviewed: {N} ({N} kept, {N} archived, {N} killed)
+   Domains: {N} active
+   Next hygiene due: {date based on cadence}
+   ```
+</step>
+
+</steps>
+
+<output>
+CARL domains reviewed and maintained. Staged proposals decided. Stale rules addressed. Domain health verified. Hygiene session logged to workspace.json.
+</output>
+
+<acceptance-criteria>
+- [ ] All pending proposals presented and decided (approve/kill/archive/defer)
+- [ ] Stale rules flagged and reviewed with operator
+- [ ] Domain health check completed (rule counts, recall phrases)
+- [ ] Archived rules moved to .carl/archive/archived-rules.json
+- [ ] workspace.json carl_hygiene.last_run updated
+- [ ] STATE.md updated with hygiene completion
+- [ ] Operator confirmed completion of each step
+</acceptance-criteria>

package/src/framework/tasks/groom.md

@@ -0,0 +1,164 @@
+<purpose>
+Structured weekly maintenance cycle. Walk through each workspace area, review with operator, enforce backlog time-based rules, graduate ready items, and log the groom.
+</purpose>
+
+<user-story>
+As an AI builder, I want a guided workspace maintenance session, so that my context documents stay current, my backlog items graduate when ready, and my workspace doesn't drift.
+</user-story>
+
+<when-to-use>
+- Weekly (on configured groom day)
+- When pulse reports overdue grooming
+- When user says "base groom", "let's groom", "workspace maintenance"
+- Entry point routes here via /base:groom
+</when-to-use>
+
+<steps>
+
+<step name="assess_scope" priority="first">
+Determine what needs grooming.
+
+1. Read `.base/workspace.json` manifest
+2. Read `.base/STATE.md` for last groom dates per area
+3. Identify which areas are due for grooming (past their cadence)
+4. Sort by staleness (most overdue first)
+5. Present: "Groom session starting. {N} areas due for review: {list}. Estimated time: {N*5} minutes."
+
+**Wait for operator confirmation before proceeding.**
+</step>
+
+<step name="groom_active">
+Review ACTIVE.md — the working memory for projects and tasks.
+
+1. Read `.base/ACTIVE.md`
+2. Present summary: "{N} projects, {N} tasks, last updated {date}"
+3. For each project: "Still active? Status changed? Next action current?"
+4. For each task in TASKS section: "Done? Still in progress? Blocked?"
+5. Close completed tasks (move to DONE/CLOSED with outcome + date)
+6. Ask: "Anything new to add?"
+7. Update timestamp
+
+Voice-friendly: walk through one entry at a time, wait for response.
+</step>
+
+<step name="groom_backlog">
+Review BACKLOG.md — enforce time-based rules AND handle graduation.
+
+**Time-based enforcement:**
+1. For each item, check Added date against review-by threshold:
+   - High priority: 7 days
+   - Medium priority: 14 days
+   - Low priority: 30 days
+2. Items past review-by → surface: "These items need a decision: {list}"
+3. Items past staleness (2x review-by) → "Auto-archiving: {list} (past {N} days without action)"
+4. Process operator decisions on each flagged item
+
+**Graduation check:**
+5. For each remaining item, ask: "Ready to work on any of these?"
+6. If yes — determine destination:
+   - **As a TASK:** Item is bounded, standalone work. Move to ACTIVE.md → TASKS section.
+     Format: `### {Task Name}` with Status, Next, Blocked, Notes fields.
+   - **As a PROJECT:** Item is complex enough to warrant its own project entry.
+     Move to ACTIVE.md under appropriate priority section with full project format.
+   - **Stay in backlog:** Not ready yet. Keep with updated review-by date.
+7. For graduated items: remove from BACKLOG.md, add to ACTIVE.md in correct section
+8. Update BACKLOG.md timestamp
+
+**The graduation question is explicit every groom.** Items don't graduate silently — the operator decides.
+</step>
+
+<step name="groom_directories">
+Review directory-type areas (projects/, clients/, tools/).
+
+For each directory area due for grooming:
+1. List contents
+2. Flag anything that looks orphaned or new since last groom
+3. Ask: "Anything to archive, delete, or reclassify?"
+4. Execute approved changes
+</step>
+
+<step name="groom_satellites">
+Review PAUL satellite project health.
+
+1. Read `.base/workspace.json` — collect all satellite entries where `groom_check: true`
+2. If no satellites have `groom_check: true` → skip this step silently
+3. For each eligible satellite:
+   a. Read its STATE.md at the path in `satellite.state` (relative to workspace root)
+   b. If STATE.md is missing or unreadable → note as "⚠️ {name}: STATE.md not found"
+   c. Get last activity timestamp:
+      - PRIMARY: read `satellite.last_activity` from workspace.json entry (ISO timestamp written by session-start hook from paul.json)
+      - FALLBACK: if `last_activity` not present in workspace.json, parse "Last activity" line from the satellite's STATE.md
+      - If neither available → note as "⚠️ {name}: cannot determine last activity"
+   d. Parse "Loop Position" section from STATE.md → extract PLAN/APPLY/UNIFY markers (✓ = done, ○ = pending)
+   e. Evaluate health criteria:
+      - **STUCK LOOP**: Loop shows PLAN ✓ APPLY ○ or PLAN ✓ APPLY ✓ UNIFY ○, AND last activity > 7 days ago
+      - **ABANDONED PHASE**: Last activity > 14 days ago AND milestone status is not COMPLETE
+      - **MILESTONE DRIFT**: Milestone marked COMPLETE, loop shows ○ ○ ○ (no new milestone started), AND last activity > 14 days ago
+4. Collect all issues across satellites
+5. If issues found: surface as:
+   ```
+   ⚠️ Satellite health issues:
+     - {satellite-name}: {issue type} (last active: {date})
+   ```
+6. If no issues: output single line "Satellites: all healthy ({N} checked)"
+
+**Report only — do NOT auto-fix.** Operator decides what to do with flagged satellites.
+</step>
+
+<step name="groom_system">
+Review system layer areas (hooks, commands, skills, CARL).
+
+1. Quick scan for obvious dead items
+2. Only flag if something clearly wrong
+3. Ask: "Any system changes to note?"
+4. If CARL hygiene is enabled (workspace.json `carl_hygiene.proactive: true`):
+   - Check `.carl/staging/` for pending proposals
+   - Check rule timestamps for staleness
+   - Surface: "{N} staged proposals, {N} stale rules — run /base:carl-hygiene?"
+</step>
+
+<step name="log_groom">
+Record the groom session.
+
+1. Update `.base/STATE.md` with new timestamps for all groomed areas
+2. Reset drift score
+3. Write groom summary to `.base/grooming/{YYYY}-W{NN}.md`:
+   ```markdown
+   # Groom Summary — Week {NN}, {YYYY}
+
+   **Date:** {YYYY-MM-DD}
+   **Areas Reviewed:** {list}
+   **Drift Score:** {before} → 0
+
+   ## Changes
+   - {what changed}
+
+   ## Graduated from Backlog
+   - {item} → ACTIVE.md TASKS / PROJECT
+
+   ## Archived / Killed
+   - {item} (reason)
+
+   ## Next Groom Due
+   {YYYY-MM-DD}
+   ```
+4. Report: "Groom complete. Drift score: 0. Next groom due: {date}."
+</step>
+
+</steps>
+
+<output>
+Updated workspace state. All due areas reviewed and current. Backlog time-based rules enforced. Ready items graduated. Groom summary logged.
+</output>
+
+<acceptance-criteria>
+- [ ] All overdue areas reviewed with operator
+- [ ] ACTIVE.md and BACKLOG.md timestamps updated
+- [ ] Backlog time-based rules enforced (review-by, staleness)
+- [ ] Graduation question asked explicitly for backlog items
+- [ ] Graduated items properly moved to ACTIVE.md (TASKS or PROJECT)
+- [ ] STATE.md updated with new groom date
+- [ ] Groom summary written to grooming/ directory
+- [ ] Drift score reset to 0
+- [ ] Operator confirmed completion of each area
+</acceptance-criteria>

package/src/framework/tasks/history.md

@@ -0,0 +1,34 @@
+<purpose>
+Show workspace evolution over time. Read ROADMAP.md and present the chronological record of major workspace changes.
+</purpose>
+
+<user-story>
+As an AI builder, I want to see how my workspace has evolved, so that I can understand the trajectory and make informed decisions about future changes.
+</user-story>
+
+<when-to-use>
+- When user wants to review workspace history
+- Entry point routes here via /base:history
+</when-to-use>
+
+<steps>
+
+<step name="read_history" priority="first">
+Read and present workspace evolution.
+
+1. Read `.base/ROADMAP.md`
+2. Present chronologically: dates, what changed, why
+3. Include audit summaries and major groom outcomes
+4. If ROADMAP.md is empty or missing: "No history yet. Run /base:audit or /base:groom to start building your workspace timeline."
+</step>
+
+</steps>
+
+<output>
+Chronological workspace evolution timeline from ROADMAP.md.
+</output>
+
+<acceptance-criteria>
+- [ ] History presented in clear chronological format
+- [ ] Includes both audits and significant groom outcomes
+</acceptance-criteria>

package/src/framework/tasks/pulse.md

@@ -0,0 +1,83 @@
+<purpose>
+Daily workspace activation. Read workspace state, calculate drift, present health dashboard, prime the operator for their session.
+</purpose>
+
+<user-story>
+As an AI builder, I want a quick workspace health briefing at session start, so that I know what needs attention before I start working.
+</user-story>
+
+<when-to-use>
+- Start of every work session
+- When user says "base pulse", "what's the state of things", "workspace status"
+- When the pulse hook detects overdue grooming and injects a prompt
+- Entry point routes here via /base:pulse
+</when-to-use>
+
+<steps>
+
+<step name="read_state" priority="first">
+Read workspace state from `.base/workspace.json` and `.base/STATE.md`.
+
+1. Read `.base/workspace.json` — the manifest
+2. Read `.base/STATE.md` — the last known state
+3. If either file is missing, suggest running `/base:scaffold` first
+4. Extract: last groom date, groom cadence, area list, satellite list
+</step>
+
+<step name="calculate_drift">
+Check each tracked area against filesystem reality.
+
+For each area in the manifest:
+1. Check filesystem timestamps on tracked paths (stat modification dates)
+2. Compare against last groom date and area-specific cadence
+3. Calculate days overdue (0 if within cadence)
+4. Classify: Current (within cadence), Stale (1-2x overdue), Critical (2x+ overdue)
+
+For each registered satellite:
+1. Check if state file exists and is readable
+2. Extract last modification date
+3. Report current phase if parseable
+
+Calculate total drift score: sum of days-overdue across all areas, with Critical areas weighted 2x.
+</step>
+
+<step name="present_dashboard">
+Present the health dashboard to the operator.
+
+Format:
+```
+BASE Pulse — {workspace-name}
+Last Groom: {date} ({N} days ago)
+Drift Score: {score}
+
+| Area | Status | Age | Due |
+|------|--------|-----|-----|
+...
+
+Satellites:
+| Project | Phase | Last Active |
+...
+
+{Recommendation based on drift score}
+```
+
+Recommendations:
+- Drift 0: "Workspace is clean. Proceed normally."
+- Drift 1-7: "Minor drift in {areas}. Consider grooming this week."
+- Drift 8-14: "Moderate drift. Run /base:groom soon."
+- Drift 15+: "Critical drift. Workspace context is stale. Run /base:groom now."
+</step>
+
+</steps>
+
+<output>
+Health dashboard with drift score, area statuses, satellite health, and recommended next action.
+</output>
+
+<acceptance-criteria>
+- [ ] All manifest areas checked against filesystem reality
+- [ ] Drift score calculated correctly
+- [ ] Satellites checked for health
+- [ ] Clear recommendation provided based on drift level
+- [ ] Dashboard is concise and scannable (not a wall of text)
+</acceptance-criteria>

package/src/framework/tasks/scaffold.md

@@ -0,0 +1,167 @@
+<purpose>
+Set up BASE in a new or existing workspace. Scan the workspace, ask guided questions, generate the manifest, install hooks, and establish baseline state. Optional --full mode adds operational templates (ACTIVE.md, BACKLOG.md, CLAUDE.md audit).
+</purpose>
+
+<user-story>
+As an AI builder setting up my workspace, I want a guided scaffolding process that configures workspace management for my specific setup, so that I get maintenance automation without manual configuration.
+</user-story>
+
+<when-to-use>
+- First-time BASE installation in any workspace
+- When user says "base scaffold", "set up base", "initialize workspace management"
+- Entry point routes here via /base:scaffold
+- Use --full flag for batteries-included mode with operational templates
+</when-to-use>
+
+<context>
+@templates/workspace-json.md
+@templates/state-md.md
+@templates/active-md.md
+@templates/backlog-md.md
+</context>
+
+<steps>
+
+<step name="detect_mode" priority="first">
+Determine scaffold mode.
+
+1. Check if user specified `--full` or mentioned wanting templates/full setup
+2. If `--full`: operational templates will be offered after data layer setup
+3. If standard: data layer only (workspace.json, STATE.md, ROADMAP.md)
+4. Announce mode: "Running BASE scaffold ({standard|full} mode)."
+</step>
+
+<step name="scan_workspace">
+Scan the workspace and detect what exists.
+
+1. List top-level directories and files
+2. Detect common patterns:
+   - ACTIVE.md, BACKLOG.md → working memory (note if already in .base/)
+   - projects/ → project tracking
+   - apps/ → satellite projects
+   - tools/ → tool management
+   - .claude/ → system layer
+   - .mcp.json → MCP configuration
+   - content/ → content pipeline
+   - clients/ → client work
+   - obsidian/ → knowledge graph
+   - .carl/ → CARL dynamic rules
+3. Detect satellite projects (directories with .paul/ inside apps/)
+4. Present findings: "I found: {list of detected areas}"
+
+**Wait for confirmation before proceeding.**
+</step>
+
+<step name="guided_configuration">
+Walk through each detected area and configure tracking.
+
+For each detected area:
+1. "I found {area}. Want BASE to track this?"
+2. If yes: "What grooming cadence? (weekly/bi-weekly/monthly)"
+3. Auto-select audit strategy based on area type
+4. Allow override of defaults
+
+Also ask:
+- "What day do you prefer for weekly grooming?" (default: Friday)
+- "Any directories I should scan for satellite projects?" (default: apps/)
+- "Anything else you want tracked that I didn't detect?"
+
+Build workspace.json from responses using `@templates/workspace-json.md` schema.
+</step>
+
+<step name="install_data_layer">
+Create .base/ directory and generate all state files.
+
+1. Create `.base/` directory structure:
+   ```
+   .base/
+   ├── workspace.json
+   ├── STATE.md
+   ├── ROADMAP.md
+   ├── grooming/
+   └── audits/
+   ```
+2. Write workspace.json from guided configuration
+3. Generate initial STATE.md using `@templates/state-md.md` by checking current filesystem timestamps
+4. Initialize ROADMAP.md with scaffold entry
+5. Register any detected satellite projects in workspace.json
+6. Report: "BASE data layer installed. {N} areas tracked, {N} satellites registered."
+</step>
+
+<step name="install_operational_templates">
+**Full mode only.** Offer operational templates for working memory files.
+
+**ACTIVE.md:**
+1. Check if ACTIVE.md exists at workspace root
+2. If exists at root (not in .base/):
+   - "You have an existing ACTIVE.md. Want me to move it into .base/ and adopt BASE conventions?"
+   - If yes: move to `.base/ACTIVE.md`, audit against `@templates/active-md.md`
+   - Check for existing references (CLAUDE.md @mentions, hooks, etc.) — if found, offer symlink at root for backward compatibility
+   - If no: skip, user keeps their current setup
+3. If doesn't exist anywhere:
+   - "Want me to create ACTIVE.md from the BASE template?"
+   - If yes: generate from `@templates/active-md.md` directly in `.base/ACTIVE.md`
+4. Explain the TASKS section and graduation flow
+
+**BACKLOG.md:**
+1. Same pattern — check if exists at root
+2. If exists: offer to move into .base/ with optional symlink for existing references
+3. If creating fresh: generate from `@templates/backlog-md.md` in `.base/BACKLOG.md`
+4. Explain time-based rules (review-by, staleness, graduation)
+
+**CLAUDE.md:**
+1. Check if CLAUDE.md exists
+2. If exists: "Want me to audit your CLAUDE.md against BASE conventions?"
+   - If yes: route to `/base:audit-claude-md` task
+3. If doesn't exist: "Want me to generate a CLAUDE.md template for your workspace?"
+   - If yes: generate based on detected workspace structure
+
+**Symlinks (migration only — not default):**
+Symlinks are ONLY offered when scaffold detects existing files at workspace root that have references pointing to them (CLAUDE.md @mentions, hooks reading from root paths, etc.). BASE operates strictly out of `.base/`. Symlinks exist solely to prevent breaking existing references during migration.
+- If existing references detected: "I found references to ACTIVE.md at root in your CLAUDE.md. Want a symlink for backward compatibility?"
+- If no existing references: no symlinks offered. Files live in `.base/` only.
+</step>
+
+<step name="install_hooks">
+Install and register BASE session hooks.
+
+Session hooks: base-pulse-check.py, psmm-injector.py, satellite-detection.py
+
+For each session hook:
+1. Check if `.claude/hooks/{hook}` exists in workspace
+2. If not: copy from `~/.claude/base-framework/hooks/{hook}` (global install source)
+   - If `~/.claude/base-framework/hooks/{hook}` doesn't exist either, warn:
+     "BASE framework not globally installed. Run `npx base-framework --global` first, then re-run scaffold."
+3. Check project `.claude/settings.json` for hook registration in UserPromptSubmit array
+4. If not registered: add the hook path to settings.json UserPromptSubmit array
+
+Report: "Session hooks installed (pulse, PSMM injector, satellite detection). Workspace health will be monitored every session."
+</step>
+
+<step name="first_groom">
+Offer to establish baseline.
+
+1. "Want to run an initial groom to establish baseline? This reviews each area once."
+2. If yes: run /base:groom flow
+3. If no: "Baseline set from filesystem timestamps. First groom due: {date}."
+</step>
+
+</steps>
+
+<output>
+Fully configured BASE installation. Standard mode: data layer with workspace.json, STATE.md, hooks. Full mode: adds operational templates (ACTIVE.md, BACKLOG.md with graduation flow, CLAUDE.md audit), symlinks, and guided first groom.
+</output>
+
+<acceptance-criteria>
+- [ ] Workspace scanned and areas detected
+- [ ] Operator confirmed tracked areas and cadences
+- [ ] .base/ directory created with all required files
+- [ ] workspace.json generated from guided configuration
+- [ ] STATE.md reflects current filesystem state
+- [ ] Satellite projects detected and registered
+- [ ] Pulse hook installed and registered
+- [ ] (Full mode) Operational templates offered and created if accepted
+- [ ] (Full mode) Symlinks created for .base/ files
+- [ ] (Full mode) Graduation flow and time-based rules explained
+- [ ] Operator informed of next groom date
+</acceptance-criteria>

package/src/framework/tasks/status.md

@@ -0,0 +1,35 @@
+<purpose>
+Quick one-liner workspace health check. No conversation, just the numbers.
+</purpose>
+
+<user-story>
+As an AI builder, I want a fast health check I can glance at, so that I know if anything needs attention without a full briefing.
+</user-story>
+
+<when-to-use>
+- When user wants a quick check without full pulse
+- Entry point routes here via /base:status
+</when-to-use>
+
+<steps>
+
+<step name="quick_check" priority="first">
+Read state and output one-liner.
+
+1. Read `.base/STATE.md`
+2. Calculate current drift score from timestamps
+3. Count overdue areas and past-due backlog items
+4. Output single line: "BASE: Drift {score} | {N} areas overdue | {N} backlog items past review-by | Last groom: {date}"
+</step>
+
+</steps>
+
+<output>
+Single-line health summary. No conversation.
+</output>
+
+<acceptance-criteria>
+- [ ] Output is one line
+- [ ] Drift score is current (not cached)
+- [ ] Overdue counts are accurate
+</acceptance-criteria>