gru-ai 0.1.0

package/.claude/skills/directive/docs/reference/schemas/directive-json.md

@@ -0,0 +1,143 @@
+<!-- Reference: directive-json.md | Source: SKILL.md restructure -->
+
+# directive.json — THE Single Source of Truth
+
+directive.json is the ONLY state file for a directive. It stores metadata, pipeline progress, per-step outputs, and project references. There is NO separate checkpoint file — directive.json IS the checkpoint.
+
+**File:** `.context/directives/{directive-name}/directive.json`
+
+```json
+{
+  "id": "$ARGUMENTS",
+  "title": "{extracted from first heading of the .md}",
+  "status": "in_progress",
+  "created": "{today's date YYYY-MM-DD}",
+  "completed": null,
+  "weight": "{classification from triage step}",
+  "category": "framework | pipeline | dashboard | game",
+  "produced_features": [],
+  "report": null,
+  "backlog_sources": [],
+
+  "started_at": "ISO datetime",
+  "updated_at": "ISO datetime",
+  "current_step": "triage | read | context | challenge | brainstorm | plan | audit | approve | project-brainstorm | setup | execute | review-gate | wrapup | completion",
+
+  "pipeline": {
+    "triage": {
+      "status": "completed",
+      "agent": "CEO",
+      "output": { "weight": "medium", "rationale": "..." }
+    },
+    "read": {
+      "status": "completed",
+      "agent": "CEO",
+      "output": { "summary": "..." }
+    },
+    "context": {
+      "status": "completed",
+      "agent": "CEO",
+      "output": { "summary": "Read vision.md, goals, lessons..." }
+    },
+    "challenge": {
+      "status": "skipped",
+      "agent": "C-suite",
+      "output": { "summary": "Skipped for medium weight" }
+    },
+    "brainstorm": {
+      "status": "completed",
+      "agent": "C-suite",
+      "output": { "summary": "..." },
+      "artifacts": [".context/directives/{id}/brainstorm.md"]
+    },
+    "plan": {
+      "status": "completed",
+      "agent": "COO",
+      "output": { "goal": "...", "projects": "..." },
+      "artifacts": [".context/directives/{id}/plan.json"]
+    },
+    "audit": {
+      "status": "completed",
+      "agent": "CTO",
+      "output": { "summary": "...", "findings": 3 },
+      "artifacts": [".context/directives/{id}/audit.md"]
+    },
+    "approve": {
+      "status": "completed",
+      "agent": "CEO",
+      "output": { "decision": "approved", "modifications": [] }
+    },
+    "project-brainstorm": {
+      "status": "completed",
+      "agent": "CTO + builder",
+      "output": { "summary": "Task breakdown and DOD produced per project" },
+      "artifacts": [".context/directives/{id}/projects/{project-id}/project.json"]
+    },
+    "setup": {
+      "status": "completed",
+      "agent": "CEO",
+      "output": { "mode": "branch", "branch": "directive/{id}" }
+    },
+    "execute": {
+      "status": "active",
+      "agent": "frontend-engineer",
+      "reviewers": ["CTO"],
+      "output": { "progress": "1/3 complete", "current": "project-name" }
+    },
+    "review-gate": { "status": "pending" },
+    "wrapup": { "status": "pending", "agent": "CEO" },
+    "completion": { "status": "pending", "agent": "CEO" }
+  },
+
+  "projects": [
+    {
+      "id": "project-slug",
+      "status": "pending | in_progress | completed | failed"
+    }
+  ],
+
+  "planning": {
+    "coo_plan": {},
+    "ceo_approval": { "status": "approved|rejected|auto-approved", "modifications": [] },
+    "worktree_path": "string | null"
+  },
+
+  "wrapup": {
+    "okrs_persisted": false,
+    "follow_ups_processed": false,
+    "digest_path": null,
+    "lessons_updated": false
+  }
+}
+```
+
+### Status enum
+Valid values for `status`: `pending`, `triaged`, `in_progress`, `awaiting_completion`, `completed`, `failed`, `reopened`.
+
+- `awaiting_completion` — all work done, wrapup produced, waiting for CEO to approve completion
+- `reopened` — CEO reopened after completion; new projects being planned
+
+### Pipeline step statuses
+Each step in `pipeline` has: `status` (pending|active|completed|skipped|failed), `agent` (who runs it), `output` (key-value summary of what happened), and optional `artifacts` (file paths to detailed outputs).
+
+### Projects
+The `projects[]` array contains lightweight references. Each entry has `id` (matching the project directory name under this directive) and `status`. The full project detail (tasks, DOD, agents) lives in `projects/{id}/project.json` — directive.json does NOT duplicate task-level data.
+
+### Write protocol
+Use the Write tool to overwrite the entire directive.json. Always update `updated_at` to the current ISO timestamp. Update `pipeline.{step}.status` and `pipeline.{step}.output` after each step completes.
+
+### Extracting `category`
+- Look for `**Category**: {category}` in the directive text
+- Valid categories: `framework`, `pipeline`, `ui`, `game`
+- If not found, infer from the directive name/scope
+- If uncertain, set to the best-fit category — every directive MUST have a category
+
+### On completion (wrapup + completion gate)
+- Set `status` to `"awaiting_completion"` (CEO must approve)
+- CEO reviews digest and either:
+  - **Approves** -> status = `"completed"`, set `completed` to today's date
+  - **Reopens** -> status = `"reopened"`, CEO states what's missing, the COO plans new projects
+- Set `report` to the digest filename
+- `pipeline` data stays — it's the permanent execution record
+
+Directives live in `directives/{id}/` — a directory per directive containing directive.json, directive.md, and all artifacts.

package/.claude/skills/directive/docs/reference/schemas/investigation-output.md

@@ -0,0 +1,37 @@
+<!-- Reference: investigation-output.md | Source: redesign-pipeline-steps -->
+
+# Investigation Output JSON Schema
+
+Output from the Investigator agent (first phase of the two-agent audit flow). Contains pure data -- no recommendations, no risk classifications, no follow-ups.
+
+The Architect agent receives this output as input when producing design recommendations.
+
+```json
+{
+  "projects": [
+    {
+      "id": "slug matching the COO's project id",
+      "baseline": "Real measured baseline (e.g., '4 endpoints use string interpolation for SQL')",
+      "active_files": ["files that are in use and need work"],
+      "dead_code": ["files that exist but aren't actively used"],
+      "findings": "What was found in the codebase — specific, factual, no recommendations",
+      "constraints": ["Codebase patterns, conventions, or technical debt that affect this scope"]
+    }
+  ]
+}
+```
+
+## Field Definitions
+
+- **id**: Matches the project slug from the COO's plan.
+- **baseline**: Exact measurements. Numbers, not vague qualifiers. "4 endpoints" not "several endpoints."
+- **active_files**: Files that exist, are actively imported/used, and need modification for this project.
+- **dead_code**: Files that exist but have no active imports, route references, or usage. Candidates for cleanup.
+- **findings**: Factual observations about the codebase state. What patterns exist, what conventions are used, what state things are in. No recommendations.
+- **constraints**: Technical debt, naming conventions, architectural patterns, or existing abstractions that would affect how this project is implemented. The Architect uses these to make informed design decisions.
+
+## What This Schema Does NOT Include
+
+- `recommended_approach` — that's the Architect's job (see audit-output.md)
+- `follow_ups` — the Architect produces these
+- `risk` classifications — the Architect classifies risk informed by these findings

package/.claude/skills/directive/docs/reference/schemas/plan-schema.md

@@ -0,0 +1,103 @@
+<!-- Reference: plan-schema.md | Source: SKILL.md restructure -->
+
+# COO Plan JSON Schema
+
+The COO's output must follow this schema EXACTLY. The COO plans at the **project level** -- task breakdown and DOD are produced later in the project-brainstorm step by the CTO + the assigned builder.
+
+## Schema
+
+```json
+{
+  "goal": "CEO's goal title",
+  "category": "framework | pipeline | dashboard | game",
+  "challenges": {
+    "risks": ["Top 3 risks with this directive — be specific, not generic"],
+    "over_engineering_flags": ["Anything in the directive that's scoped too broadly or could be simpler"],
+    "recommendation": "Proceed as-is | Simplify (explain how — but still deliver everything)"
+  },
+  "projects": [
+    {
+      "id": "project-slug",
+      "title": "Human-readable title",
+      "priority": "P0 | P1 | P2",
+      "complexity": "simple | moderate | complex",
+      "agent": ["builder-name"],
+      "reviewers": ["reviewer-name"],
+      "auditor": "agent-id -- who investigates the codebase (resolve from registry by role)",
+      "scope_summary": "2-4 sentences: what this project delivers, the outcome, and the approach",
+      "depends_on": [],
+      "touches_files_hint": ["path/to/likely-modified-file.ts"]
+    }
+  ]
+}
+```
+
+## Field reference
+
+### `depends_on` (array of project IDs, optional, default `[]`)
+
+Explicit cross-project dependencies. If `depends_on: ["project-a"]`, this project cannot start until `project-a` completes. This is the **project-level** `depends_on` — The COO outputs it to control cross-project execution order.
+
+**Task-level `depends_on`** is a separate concept: produced during the project-brainstorm step when the CTO + the builder decompose a project into tasks. Task-level `depends_on` controls within-project wave analysis (which tasks in the same project can run in parallel). Both levels feed into the wave algorithm in the execute step.
+
+- Empty array (or omitted) = no dependencies = eligible for parallel execution (subject to file-overlap checks).
+- Supplements array ordering. Array order is still respected -- `depends_on` makes implicit dependencies explicit and enables cross-priority-tier dependencies.
+- The COO identifies these from scope analysis: "this project reads output produced by that project" = dependency.
+
+### `touches_files_hint` (array of file paths, optional)
+
+The COO's prediction of which files this project will modify.
+
+- Used as a hint for the auditor -- NOT the source of truth for wave analysis. The audit's `active_files` determines real file overlap.
+- If The COO is unsure, omit it. Better no hint than a wrong hint. The auditor will discover the real files.
+- Why a hint: The COO does not scan the codebase. She guesses from scope descriptions. The auditor actually reads the code.
+
+## Example: parallel vs sequential projects
+
+```json
+{
+  "projects": [
+    {
+      "id": "update-schemas",
+      "title": "Update shared type definitions",
+      "priority": "P0",
+      "depends_on": [],
+      "touches_files_hint": ["src/types.ts", "src/schemas.ts"]
+    },
+    {
+      "id": "build-dashboard-widget",
+      "title": "Build dashboard analytics widget",
+      "priority": "P0",
+      "depends_on": ["update-schemas"],
+      "touches_files_hint": ["src/components/AnalyticsWidget.tsx"]
+    },
+    {
+      "id": "build-settings-page",
+      "title": "Build user settings page",
+      "priority": "P0",
+      "depends_on": ["update-schemas"],
+      "touches_files_hint": ["src/components/SettingsPage.tsx"]
+    },
+    {
+      "id": "integration-tests",
+      "title": "End-to-end tests for new features",
+      "priority": "P1",
+      "depends_on": ["build-dashboard-widget", "build-settings-page"]
+    }
+  ]
+}
+```
+
+Wave analysis computes from this:
+- **Wave 1**: `update-schemas` (no dependencies)
+- **Wave 2**: `build-dashboard-widget` + `build-settings-page` (both depend only on wave 1, no file overlap -- run in parallel)
+- **Wave 3**: `integration-tests` (depends on both wave 2 projects)
+
+Without `depends_on`, all four projects would run sequentially by array order.
+
+## Key rules
+
+- **Projects are ordered by priority + dependency.** Array order is respected. `depends_on` adds explicit dependency edges that the wave analyzer uses to compute parallel execution groups.
+- **Dependent work belongs in ONE project.** If work items share code dependencies, they MUST be in the same project. Use `depends_on` only for genuinely separate projects where one must complete before another starts.
+- **No tasks or DOD in the COO's output.** The COO identifies WHAT projects are needed and WHO builds them. Task decomposition and definition of done are produced in the project-brainstorm step by the CTO + the assigned builder.
+- **Every project gets a brainstorm.** Complex projects get a full brainstorm (CTO + builder + specialist). Simple projects get a lightweight brainstorm (CTO solo).

package/.claude/skills/directive/docs/reference/templates/architect-prompt.md

@@ -0,0 +1,66 @@
+<!-- Reference: architect-prompt.md | Source: redesign-pipeline-steps -->
+
+# Architect Prompt Template
+
+Used in the second phase of the two-agent audit flow (audit step). The Architect reads the QA engineer's investigation data + the COO's plan and produces design recommendations and risk-classified follow-ups.
+
+The Architect role is filled by the named auditor from the COO's cast -- not a separate agent definition. If no auditor is assigned, defaults to the CTO.
+
+```
+You are providing technical design recommendations based on a codebase investigation. The QA engineer already scanned the codebase in investigation mode and reported raw findings. Your job is to use those findings + the COO's plan to recommend HOW to implement each task.
+
+COO'S PLAN:
+{The COO's projects -- id, title, scope_summary for each}
+
+INVESTIGATION DATA (from the QA engineer's investigation):
+{The QA engineer's JSON output -- baselines, active_files, dead_code, findings, constraints per task}
+
+GUARDRAILS:
+{.context/vision.md guardrails section}
+
+CEO STANDING ORDERS:
+{.context/preferences.md}
+
+LESSONS:
+{.context/lessons/review-quality.md — for the CTO}
+{.context/lessons/agent-behavior.md}
+
+For each task:
+1. Read the QA engineer's investigation findings carefully -- these are ground truth about the codebase
+2. Consider the constraints the QA engineer flagged -- your approach must work within them
+3. Recommend a specific technical approach referencing real files and patterns from the investigation. **Your `recommended_approach` is the implementation spec that builders receive as their starting context.** Be concrete — name specific files to modify, patterns to follow, and functions to call. Vague approaches ("refactor the module") get ignored; specific ones ("add a Zod schema to server/api/products.ts validateInput(), following the pattern in server/api/users.ts") get followed.
+4. Identify follow-up actions with risk classification
+5. Flag if the QA engineer's findings suggest the task scope should change
+
+RISK CLASSIFICATION for follow-ups:
+- "low": Safe to auto-execute without CEO approval. Examples: delete dead code, remove unused imports, create backlog tickets, update OKR status, fix typos in comments.
+- "medium": Auto-executed without CEO approval, but revert commands are included in the digest so the CEO can undo if needed. Examples: fix auth gaps, add input validation, add middleware, refactor modules, change API behavior.
+- "high": CEO must decide. Examples: schema changes, new API endpoints, infrastructure changes, auth flow changes, anything user-facing, anything that could affect revenue.
+
+When in doubt, classify UP (low → medium, medium → high). Read the guardrails — anything that would violate a guardrail is automatically high risk.
+
+CRITICAL OUTPUT FORMAT: Your response must contain ONLY valid JSON. No prose, no analysis summary, no markdown fences, no text before or after the JSON. The very first character of your response must be `{` and the very last must be `}`.
+
+Your output must follow this schema:
+
+{
+  "tasks": [
+    {
+      "id": "slug matching the COO's task id",
+      "baseline": "Carried forward from investigation (for downstream reference)",
+      "active_files": ["Carried forward from investigation"],
+      "dead_code": ["Carried forward from investigation"],
+      "findings": "Carried forward from investigation + any additional design-relevant observations",
+      "recommended_approach": "How to implement this, referencing real patterns and files from the investigation data",
+      "follow_ups": [
+        {
+          "action": "Short description of what to do",
+          "risk": "low | medium | high",
+          "rationale": "Why this risk level — what could go wrong?",
+          "files": ["affected files, if known"]
+        }
+      ]
+    }
+  ]
+}
+```

package/.claude/skills/directive/docs/reference/templates/auditor-prompt.md

@@ -0,0 +1,53 @@
+<!-- Reference: auditor-prompt.md | Source: SKILL.md restructure -->
+
+# Auditor Prompt Template (CTO, or named auditor)
+
+Used for simple tasks (1-2 phases) where the single-agent audit path is used instead of the two-agent flow. The named auditor (defaulting to the CTO) does both investigation and architecture in one pass.
+
+```
+You are auditing the codebase to provide real technical context for the COO's strategic plan.
+
+For each project you've been assigned, your job is:
+1. Scan the codebase for the scope described — use Glob, Grep, Read tools
+2. Verify target files/endpoints are still active (grep for imports, fetch calls, route usage)
+3. Flag dead code — files or endpoints that exist but aren't actively used anywhere
+4. Measure real baselines (exact counts, specific file lists)
+5. Recommend a technical approach based on what you find
+6. Identify follow-up actions discovered during the audit, with risk classification
+
+Be THOROUGH: grep broadly to find ALL instances of a problem, not just the obvious ones. Check existing patterns, env var names, and function signatures before recommending changes.
+
+If a project's scope turns out to have nothing to fix (e.g., the problem described doesn't exist in the codebase, or it was already fixed), say so clearly in your findings.
+
+RISK CLASSIFICATION for follow-ups:
+- "low": Safe to auto-execute without CEO approval. Examples: delete dead code, remove unused imports, create backlog tickets, update OKR status, fix typos in comments.
+- "medium": Auto-executed without CEO approval, but revert commands are included in the digest so the CEO can undo if needed. Examples: fix auth gaps, add input validation, add middleware, refactor modules, change API behavior.
+- "high": CEO must decide. Examples: schema changes, new API endpoints, infrastructure changes, auth flow changes, anything user-facing, anything that could affect revenue.
+
+When in doubt, classify UP (low → medium, medium → high). Read `.context/vision.md` guardrails — anything that would violate a guardrail is automatically high risk.
+
+CRITICAL OUTPUT FORMAT: Your response must contain ONLY valid JSON. No prose, no analysis summary, no markdown fences, no text before or after the JSON. The very first character of your response must be `{` and the very last must be `}`.
+
+Your output must follow this schema:
+
+{
+  "projects": [
+    {
+      "id": "slug matching the COO's project id",
+      "baseline": "Real measured baseline (e.g., '4 endpoints use string interpolation for SQL')",
+      "active_files": ["files that are in use and need work"],
+      "dead_code": ["files that exist but aren't actively used — list them for auto-cleanup in follow_ups"],
+      "findings": "What you found in the codebase — be specific",
+      "recommended_approach": "How to implement this, referencing real patterns and files",
+      "follow_ups": [
+        {
+          "action": "Short description of what to do",
+          "risk": "low | medium | high",
+          "rationale": "Why this risk level — what could go wrong?",
+          "files": ["affected files, if known"]
+        }
+      ]
+    }
+  ]
+}
+```

package/.claude/skills/directive/docs/reference/templates/brainstorm-prompt.md

@@ -0,0 +1,68 @@
+<!-- Reference: brainstorm-prompt.md | Source: SKILL.md restructure -->
+
+# Brainstorm Agent Prompt Template
+
+## Phase 1: Initial Proposal
+
+Used for all brainstorm participants (C-suite + auditor) in both heavyweight and strategic directives.
+
+```
+You are {Name}, {Title}. The CEO issued a directive that needs approach exploration before execution planning.
+
+DIRECTIVE:
+{directive text}
+
+CONTEXT:
+- Vision: {vision.md relevant sections}
+- Preferences: {preferences.md}
+
+Your job: Propose a concrete approach for this directive. Not "endorse or challenge" — actually design HOW to solve this.
+
+{auditor_instruction — include ONLY for the auditor agent}
+As the auditor, ground your proposal in codebase reality. Reference specific files, patterns, and baselines you know exist. Flag any approaches that sound good in theory but would conflict with the actual codebase structure.
+{/auditor_instruction}
+
+{
+  "agent": "{name}",
+  "approach": "Your recommended approach in 3-5 sentences — be specific about what to build/change and in what order",
+  "tradeoffs": ["Key trade-off 1", "Key trade-off 2"],
+  "avoid": "What approach you'd explicitly NOT take and why",
+  "confidence": "high | medium | low — how certain are you this is the right approach?",
+  "feasibility_flags": ["Any codebase constraints or existing patterns that affect this approach — auditor fills this, others may leave empty"]
+}
+
+CRITICAL: First character `{`, last `}`. JSON only.
+```
+
+## Phase 2: Deliberation Round (Strategic Directives ONLY)
+
+**This phase fires ONLY for strategic directives. Skip entirely for heavyweight.**
+
+After collecting all initial proposals, share them with each agent and ask for one rebuttal. Each agent sees all proposals and writes one targeted critique.
+
+```
+You are {Name}, {Title}. You proposed an approach for this directive. Now review all proposals and write ONE rebuttal.
+
+YOUR PROPOSAL:
+{this agent's Phase 1 output}
+
+ALL PROPOSALS:
+{all Phase 1 outputs from all agents, including yours}
+
+Write ONE rebuttal targeting the proposal you most disagree with. Be specific: what's wrong with it, what they missed, and what would happen if we followed their approach.
+
+{
+  "agent": "{name}",
+  "target_agent": "name of the agent whose proposal you're rebutting",
+  "critique": "What's wrong with their approach — be specific about what they missed or got wrong",
+  "alternative": "What should be done instead, referencing your original proposal or a new variation"
+}
+
+CRITICAL: First character `{`, last `}`. JSON only.
+```
+
+## Synthesis
+
+After collecting proposals (and rebuttals for strategic), the orchestrator synthesizes:
+- **Heavyweight**: Synthesize proposals only. Identify convergence points and key disagreements. Write synthesis to brainstorm.md.
+- **Strategic**: Synthesize proposals AND rebuttals. Identify which critiques landed, which proposals survived challenge. Extract 2-3 CEO clarification questions from unresolved disagreements. Write synthesis to brainstorm.md.

package/.claude/skills/directive/docs/reference/templates/challenger-prompt.md

@@ -0,0 +1,35 @@
+<!-- Reference: challenger-prompt.md | Source: SKILL.md restructure -->
+
+# Challenger Prompt Template
+
+Customize per agent:
+
+```
+You are {Name}, {Title}. The CEO has issued a directive. Before we plan execution, your job is to independently evaluate this directive from your domain expertise.
+
+DIRECTIVE:
+{directive text}
+
+CONTEXT:
+- Vision + Guardrails: {vision.md content}
+- CEO Preferences: {preferences.md content}
+- Current Goals: {goals index summary}
+
+Evaluate the directive and produce ONE of these responses:
+
+1. ENDORSE — You agree this is the right thing to do. Briefly explain why from your domain perspective.
+2. CHALLENGE — You see problems with this directive. Explain what concerns you and propose an alternative or modification.
+3. FLAG — The directive is fine directionally, but there are risks or considerations the CEO should be aware of before committing.
+
+Keep it SHORT — 3-5 sentences max. This is a gut check, not a detailed analysis.
+
+CRITICAL OUTPUT FORMAT: Your response must contain ONLY valid JSON. The very first character must be `{` and the very last must be `}`.
+
+{
+  "agent": "{name}",
+  "verdict": "endorse | challenge | flag",
+  "reasoning": "Your 3-5 sentence evaluation from your domain perspective",
+  "alternative": "If challenging: what would you do instead? If endorsing/flagging: null",
+  "risk_flags": ["Short risk statements, if any. Empty array if none."]
+}
+```

package/.claude/skills/directive/docs/reference/templates/digest.md

@@ -0,0 +1,134 @@
+<!-- Reference: digest.md | Source: SKILL.md restructure -->
+
+# Digest Report Template
+
+Report file format:
+
+```markdown
+# Directive Report: {goal title}
+
+**Date**: {today}
+**Directive**: {directive filename}
+**Planned by**: COO
+
+## Summary
+
+{1-2 sentence overview of what was accomplished}
+
+## Definition of Done Assessment
+
+### {Task Title}
+- [x] {criterion 1} — MET
+- [x] {criterion 2} — MET
+- [ ] {criterion 3} — NOT MET ({reason})
+
+(repeat for each task)
+
+## Tasks
+
+### {Task Title} — {status: completed/partial/skipped/failed}
+- **Phases**: {phases list}
+- **Team**: {who was involved}
+- **Scope**: {what was accomplished}
+- **Files changed**: {list}
+- **Audit baseline**: {what the audit found before work started}
+- **Review findings**: {summary of reviewer feedback, if any}
+- **Notes**: {any blockers, partial work, or follow-ups}
+
+(repeat for each task)
+
+## Follow-Up Actions
+
+### Auto-Executed (low risk — done, just FYI)
+- {action} — {result}
+
+### Auto-Executed (medium risk — done, revert commands below)
+- {action} — {result}
+
+### Backlogged (high risk — written to goal backlog)
+- {action} — Added to {goal}/backlog.json
+
+## Revert Commands
+
+{Copy-pasteable commands to undo each auto-executed medium-risk follow-up action. The CEO can run any of these to revert a specific action without affecting other changes.}
+
+| # | Action | Revert Command |
+|---|--------|----------------|
+| 1 | {medium-risk action description} | `git checkout {hash} -- {file}` |
+| 2 | {medium-risk action description} | `rm {file}` |
+
+{If no medium-risk follow-ups were auto-executed: "No medium-risk actions — no revert commands needed."}
+
+{IMPORTANT: Every revert command must be tested before inclusion. The engineer generating these commands must verify they actually work — untested revert commands are worse than no revert commands.}
+
+## Agent-Proposed Improvements
+
+{Collect all `proposed_improvements` from engineer build reports. These are gaps, missing features, and edge cases identified by agents during the build — not assigned work, but task from the builders.}
+
+- {improvement description} — proposed by {agent/task}
+- {improvement description} — proposed by {agent/task}
+
+{If no improvements were proposed, note: "No improvements proposed — agents completed assigned work only." This is a signal that the task instruction isn't working.}
+
+## Corrections Caught
+
+{Aggregate corrections_check data from all task reviews. For each violation found and fixed during the build cycle:}
+
+| Correction | Task | Reviewer | Resolution |
+|------------|-----------|----------|------------|
+| {Standing Correction #N: description} | {task title} | {who caught it} | {Fixed in retry / Noted for follow-up} |
+
+- **Corrections reviewed**: {total across all tasks} (out of {N} standing corrections × {M} tasks)
+- **Violations found**: {count}
+- **Violations fixed**: {count fixed during retry vs noted}
+
+{If no violations: "All standing corrections verified across all tasks. No violations found — the guardrails held."}
+
+## UX Verification Results
+
+{Results from browser testing after UI tasks:}
+- {page/flow tested}: {pass/fail} — {what was found}
+- Screenshots: {list of screenshots taken}
+
+{If no UI work: "No UI tasks — UX verification skipped."}
+
+## Potentially Stale Docs
+
+{Output from `.claude/hooks/detect-stale-docs.sh` — lists docs that reference files modified in this directive but were not themselves updated. These docs may contain outdated information.}
+
+- {doc path} -> references modified: {list of modified files it references}
+- {doc path} -> references modified: {list of modified files it references}
+
+{If no stale docs detected: "No potentially stale docs detected."}
+
+## Self-Assessment
+
+### Audit Accuracy
+- Findings confirmed by build: {count}/{total}
+- Findings that were wrong or irrelevant: {list}
+- Issues found during build that audit missed: {list}
+
+### Build Success
+- Type-check passed: {yes/no}
+- Tasks completed: {count}/{total}
+- Build failures: {list if any}
+
+### UX Verification
+- UI tasks verified in browser: {count}/{total UI tasks}
+- Dead-end UI found: {count} (elements that look clickable but do nothing)
+- Data mismatches found: {count} (numbers/counts that don't match backend)
+- Issues fixed during verification: {list or "none"}
+
+### Agent Task
+- Improvements proposed by agents: {count}
+- Improvements worth pursuing: {list or "none yet — need more data"}
+- Agents that proposed nothing: {list — these agents need better prompting}
+
+### Risk Classification
+- Low-risk auto-executes that caused problems: {list or "none"}
+- Items that should have been classified differently: {list or "none"}
+
+### Challenge Accuracy
+- C-suite challenges: {count endorsed, count challenged, count flagged}
+- Challenges that proved correct in hindsight: {list or "N/A — first run"}
+```