workspace-maxxing 0.1.0

package/templates/.workspace-templates/skills/iteration/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: iteration
+description: "Runs autonomous improvement loops with benchmark scoring. Use when score plateaued, deeper fixes needed, or after testing identifies patterns."
+triggers: ["run improvement loop", "iterate on workspace", "deeper fixes", "score plateau"]
+---
+
+## Overview
+
+Execute improvement loops until quality thresholds are met. Iteration applies systematic fixes when first-pass prompt improvements are not enough.
+
+## When to Use
+
+- Score is plateaued across runs
+- Testing finds repeated failure patterns
+- Validation failures persist after prompt-engineering
+- The condition-driven improvement loop requires deeper fixes
+- Latest benchmark score is strictly between 80 and 85 (`80 < score < 85`)
+- Score is 80 or lower (`score <= 80`) after prompt-engineering stops improving
+
+## When Not to Use
+
+- For first-pass improvements (use prompt-engineering first)
+- When workspace is new and untested (use testing first)
+- When structural redesign is needed (use architecture)
+
+## The Iron Law
+
+NO CLAIMING IMPROVEMENT WITHOUT RE-RUNNING BENCHMARK
+NO SKIPPING FIX SUGGESTIONS
+NO INFINITE ITERATION LOOPS
+NO SKIPPING ESCALATION WHEN STUCK
+
+## The Process
+
+1. **Run iterate.ts** - Execute `node scripts/iterate.ts --workspace <path> --max-retries 3`.
+2. **Read benchmark results** - Parse score, fixSuggestions, and improvementPotential.
+3. **Identify improvement areas** - Prioritize changes with highest impact.
+4. **Apply fixes** - Address each suggestion systematically.
+5. **Re-run iteration** - Verify score movement.
+6. **Repeat until threshold** - Continue until score is 85 or higher (`score >= 85`) or no improvement is possible.
+7. **Escalate if stuck** - If score remains below 85 after 3 attempts, escalate.
+
+## Red Flags
+
+- Improvement is claimed without fresh benchmark evidence
+- Fix suggestions are ignored
+- Loop runs beyond max retries
+- Escalation is skipped despite stalled score
+
+## Anti-Rationalization Table
+
+| Thought | Reality |
+|---------|---------|
+| "I will just run it again" | Re-running without fixes wastes cycles. |
+| "The score improved by one point" | Marginal gains are not enough. Target is 85 or higher. |
+| "I will keep iterating until it works" | Maximum 3 attempts, then escalate. |
+
+## Sub-Skill Dispatch
+
+- `status = passed` (`score >= 85`) -> `nextSkill = none`.
+- `status = failed` (`score < 85` after max retries) -> `nextSkill = none` and require human follow-up.
+- `status = escalated` (critical blocker prevents safe continuation) -> `nextSkill = none`.
+
+## Report Format
+
+```json
+{
+  "skill": "iteration",
+  "status": "passed",
+  "timestamp": "2026-04-08T00:00:00Z",
+  "findings": ["Resolved two repeated edge-case failures"],
+  "recommendations": ["Run final validation and testing before delivery"],
+  "metrics": {
+    "scoreBefore": 81,
+    "scoreAfter": 88,
+    "iterationsRun": 2
+  },
+  "nextSkill": "none"
+}
+```
+
+Allowed `status` values: `passed`, `failed`, `escalated`.
+
+Allowed `nextSkill` values: `none`.
+
+## Integration
+
+- Works after testing or prompt-engineering when quality is stuck.
+- Hands final results back to validation and completion checks.

package/templates/.workspace-templates/skills/prompt-engineering/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: prompt-engineering
+description: "Improves CONTEXT.md and SYSTEM.md prompts for better agent behavior. Use when workspace score is 80 or lower, prompts need improvement, or after validation identifies content gaps."
+triggers: ["improve prompts", "fix content gaps", "optimize prompts", "clarify instructions"]
+---
+
+## Overview
+
+Optimize workspace prompts for clarity, completeness, and agent guidance. Prompt engineering resolves content-level quality issues without structural redesign.
+
+## When to Use
+
+- Score is 80 or lower in benchmark results (`score <= 80`)
+- Validation identifies missing or weak content
+- Prompts are vague or incomplete
+- Agent behavior does not match expectations
+
+## When Not to Use
+
+- For structural issues (use architecture or fixer)
+- When workspace has no content yet (use worker)
+- For dependency installation (use tooling)
+
+## The Iron Law
+
+NO COSMETIC CHANGES WITHOUT FUNCTIONAL IMPROVEMENT
+NO CHANGING PROMPTS WITHOUT RE-VALIDATING
+NO REMOVING CONTENT WITHOUT REPLACEMENT
+NO CLAIMING IMPROVEMENT WITHOUT SCORE CHECK
+
+## The Process
+
+1. **Identify weak prompts** - Read benchmark findings and validation failures.
+2. **Analyze current prompts** - Identify what is missing, vague, or contradictory.
+3. **Apply prompt patterns** - Use clear structure, examples, constraints, and output format guidance.
+4. **Update CONTEXT.md files** - Improve stage-specific instructions.
+5. **Update SYSTEM.md if needed** - Improve folder map, rules, and tool inventory guidance.
+6. **Re-run validation** - Verify improvements did not break compliance.
+7. **Re-run benchmark** - Confirm score movement.
+
+## Red Flags
+
+- Cosmetic wording changes with no measurable improvement
+- Prompt edits made without re-validation
+- Content removed without replacement
+- No before/after score comparison
+
+## Anti-Rationalization Table
+
+| Thought | Reality |
+|---------|---------|
+| "This wording change is enough" | Wording changes must produce functional improvement. |
+| "I will remove vague sections" | Removing sections creates gaps. Improve, do not delete. |
+| "The score did not change, but it is better" | No score change means no proven improvement. Iterate again. |
+
+## Sub-Skill Dispatch
+
+- `status = passed` (`scoreAfter > 80`) -> `nextSkill = testing`.
+- `status = failed` (`scoreAfter <= 80` or no measurable improvement) -> `nextSkill = iteration`.
+- `status = escalated` (requirements conflict or critical blocker) -> `nextSkill = none`.
+
+## Report Format
+
+```json
+{
+  "skill": "prompt-engineering",
+  "status": "passed",
+  "timestamp": "2026-04-08T00:00:00Z",
+  "findings": ["Clarified output constraints in two stage prompts"],
+  "recommendations": ["Run testing to verify edge-case behavior"],
+  "metrics": {
+    "scoreBefore": 74,
+    "scoreAfter": 83,
+    "promptsUpdated": 3
+  },
+  "nextSkill": "testing"
+}
+```
+
+Allowed `status` values: `passed`, `failed`, `escalated`.
+
+Allowed `nextSkill` values: `testing`, `iteration`, `none`.
+
+## Integration
+
+- Consumes findings from validation and benchmark.
+- Produces higher-quality prompt content for testing and iteration.

package/templates/.workspace-templates/skills/research/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: research
+description: "Investigates patterns, gathers context, and identifies best practices for workspace design. Use when starting a new workspace, researching workflow patterns, or before architecture planning."
+triggers: ["research workflow", "gather context", "identify patterns", "best practices"]
+---
+
+## Overview
+
+Gather context and identify patterns before building. Research ensures the workspace design is informed by real requirements, not assumptions.
+
+## When to Use
+
+- Phase 1 of the hybrid flow (always first)
+- Before architecture planning
+- When the user asks for a novel workflow type
+- When existing patterns do not fit the use case
+
+## When Not to Use
+
+- After architecture is already planned (use architecture sub-skill)
+- When workspace structure already exists (use validation sub-skill)
+- For simple file creation (use direct file operations)
+
+## The Iron Law
+
+NO BUILD WITHOUT RESEARCH
+NO GENERIC FINDINGS
+NO SKIPPING INPUT/OUTPUT ANALYSIS
+NO ASSUMPTIONS WITHOUT EVIDENCE
+
+## Scope Guardrails
+
+- Research the workflow needed to produce outcomes, not the product implementation stack.
+- Convert domain asks (for example, "football predictor") into stageable workflow responsibilities.
+- Keep research outputs markdown-first and suitable for numbered folder CONTEXT contracts.
+- Do not produce backend/frontend/data-model implementation plans in this phase.
+
+## The Process
+
+1. **Identify workflow type** - Determine what process is being automated as a file-structured markdown workflow.
+2. **Research similar patterns** - Review existing workspaces, docs, and best practices.
+3. **Identify key stages** - Define the natural workflow phases.
+4. **Determine inputs and outputs** - Capture what goes in and what markdown artifacts come out at each stage.
+5. **Identify tooling needs** - List tools commonly needed for this workflow.
+6. **Document findings** - Create a concise research summary for architecture.
+
+## Red Flags
+
+- Research is too generic and not tied to the requested workflow
+- Input and output analysis is missing
+- Tooling assessment is missing
+- Architecture starts before research findings are complete
+- Findings drift into app architecture, model design, or runtime repository scaffolding
+
+## Anti-Rationalization Table
+
+| Thought | Reality |
+|---------|---------|
+| "I already know this workflow type" | Knowledge is not research. Document findings for the next agent. |
+| "Research is taking too long" | Research prevents wasted build time. Be thorough. |
+| "I will figure it out while building" | Building without research produces generic, non-optimal workspaces. |
+| "The user will clarify later" | Ask now. Ambiguous requirements produce ambiguous workspaces. |
+
+## Sub-Skill Dispatch
+
+- `status = passed` -> `nextSkill = architecture`.
+- `status = failed` (research incomplete but recoverable) -> `nextSkill = none` and request missing inputs before rerun.
+- `status = escalated` (blocking ambiguity or conflicting constraints) -> `nextSkill = none`.
+
+## Report Format
+
+```json
+{
+  "skill": "research",
+  "status": "passed",
+  "timestamp": "2026-04-08T00:00:00Z",
+  "findings": ["Identified three reusable workflow stage patterns"],
+  "recommendations": ["Use a three-stage layout with explicit input/output boundaries"],
+  "metrics": {
+    "patternsIdentified": 3,
+    "stagesIdentified": 3
+  },
+  "nextSkill": "architecture"
+}
+```
+
+Allowed `status` values: `passed`, `failed`, `escalated`.
+
+Allowed `nextSkill` values: `architecture`, `none`.
+
+## Integration
+
+- Feeds architecture with concrete findings and stage proposals.
+- Reduces rework by grounding structure decisions in evidence.

package/templates/.workspace-templates/skills/testing/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: testing
+description: "Generates and runs test cases, evaluates results, and identifies gaps. Use when testing workspace quality, generating test cases, or after prompt improvements."
+triggers: ["generate test cases", "run tests", "test workspace", "evaluate quality"]
+---
+
+## Overview
+
+Verify workspace quality through systematic testing. Testing confirms outputs across sample, edge-case, and empty-input scenarios.
+
+## When to Use
+
+- After prompt-engineering improvements
+- When no tests exist for the workspace
+- Before claiming delivery
+- When benchmark score is strictly between 80 and 85 (`80 < score < 85`)
+- When score is 85 or higher and final evidence is still required
+
+## When Not to Use
+
+- Before workspace build is complete (run scaffold.ts first)
+- For structural validation (use validation sub-skill)
+- When applying direct fixes to failures (use fixer sub-skill)
+- When benchmark score is 80 or lower (`score <= 80`) (use prompt-engineering first)
+
+## The Iron Law
+
+NO SKIPPING TEST GENERATION
+NO IGNORING FAILED TESTS
+NO CLAIMING QUALITY WITHOUT EVIDENCE
+NO TESTING WITHOUT TEST CASES
+
+## The Process
+
+1. **Generate test cases** - Run `node scripts/generate-tests.ts --workspace <path> --output ./tests.json`.
+2. **Read test cases** - Parse generated test cases and expected outcomes.
+3. **Run generation tests** - Produce sample content each stage should output.
+4. **Run evaluation tests** - Review CONTEXT.md files against expected behavior.
+5. **Aggregate results** - Identify recurring patterns and quality gaps.
+6. **Document findings** - Create a pass/fail report per test case.
+
+## Red Flags
+
+- Test generation is skipped
+- Generation tests run without evaluation tests
+- Failed test cases are ignored
+- Failure patterns are undocumented
+
+## Anti-Rationalization Table
+
+| Thought | Reality |
+|---------|---------|
+| "The workspace looks fine, no need to test" | Looks can deceive. Tests reveal behavior. |
+| "One failed test is a fluke" | Failed tests are signals. Investigate each one. |
+| "I will test after delivery" | Untested delivery is a gamble. Test first. |
+
+## Sub-Skill Dispatch
+
+- `status = passed` (all required tests pass and `benchmarkScore >= 85`) -> `nextSkill = none`.
+- `status = failed` (any required test fails or `benchmarkScore < 85`) -> `nextSkill = iteration`.
+- `status = escalated` (testing cannot run reliably due to blockers) -> `nextSkill = none`.
+
+## Report Format
+
+```json
+{
+  "skill": "testing",
+  "status": "failed",
+  "timestamp": "2026-04-08T00:00:00Z",
+  "findings": ["Two edge-case outputs failed acceptance checks"],
+  "recommendations": ["Run iteration to address repeated edge-case defects"],
+  "metrics": {
+    "benchmarkScore": 82,
+    "testCasesGenerated": 9,
+    "testCasesPassed": 7,
+    "testCasesFailed": 2
+  },
+  "nextSkill": "iteration"
+}
+```
+
+Allowed `status` values: `passed`, `failed`, `escalated`.
+
+Allowed `nextSkill` values: `iteration`, `none`.
+
+## Integration
+
+- Uses generate-tests.ts output as primary test input.
+- Supplies pass/fail evidence for iteration and final verification.

package/templates/.workspace-templates/skills/tooling/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: tooling
+description: "Assesses, installs, and configures tools for the workspace. Use when tools are missing, tool inventory needs updating, or workspace requires specific dependencies."
+triggers: ["install tools", "assess tooling", "update tool inventory", "configure dependencies"]
+---
+
+## Overview
+
+Ensure workspace has the right tools installed and configured. Tooling manages the dependency layer of the workspace.
+
+## When to Use
+
+- Tool inventory is empty or incomplete
+- Workspace requires specific dependencies
+- Architecture identifies missing tooling needs
+- User requests specific tool installation
+
+## When Not to Use
+
+- For non-tool structural changes (use architecture)
+- For content quality improvements (use prompt-engineering)
+- When no additional tools are needed
+
+## The Iron Law
+
+NO INSTALLING TOOLS WITHOUT USER APPROVAL
+NO SKIPPING TOOL INVENTORY UPDATES
+NO INSTALLING UNNECESSARY TOOLS
+NO SKIPPING VERIFICATION AFTER INSTALLATION
+
+## The Process
+
+1. **Scan current tools** - Read SYSTEM.md tool inventory.
+2. **Identify missing tools** - Compare requirements against installed tools.
+3. **Propose tools** - Provide recommended tools with justification.
+4. **Get approval** - Present the tool plan before installing.
+5. **Install tools** - Run `node scripts/install-tool.ts --tool <name> --manager <mgr> --workspace <path>`.
+6. **Update inventory** - Confirm SYSTEM.md or inventory section is updated.
+7. **Verify installation** - Confirm each installed tool is accessible.
+
+## Red Flags
+
+- Tools installed without approval
+- Inventory not updated after install
+- Unnecessary tools installed
+- Installation not verified
+
+## Anti-Rationalization Table
+
+| Thought | Reality |
+|---------|---------|
+| "This tool might be useful" | "Might" is not enough. Every tool needs explicit justification. |
+| "I will install now and tell the user later" | Approval must come before installation. |
+| "The install probably worked" | Probably is not verified. Validate each install. |
+
+## Sub-Skill Dispatch
+
+- `status = passed` (approved tooling installed and verified) -> `nextSkill = none`.
+- `status = failed` (installation incomplete or verification failed) -> `nextSkill = none`.
+- `status = escalated` (blocked by permissions, policy, or unresolved conflicts) -> `nextSkill = none`.
+
+## Report Format
+
+```json
+{
+  "skill": "tooling",
+  "status": "passed",
+  "timestamp": "2026-04-08T00:00:00Z",
+  "findings": ["Installed two approved dependencies"],
+  "recommendations": ["Run validation to confirm inventory consistency"],
+  "metrics": {
+    "toolsInstalled": 2,
+    "toolsProposed": 2,
+    "toolsFailed": 0
+  },
+  "nextSkill": "none"
+}
+```
+
+Allowed `status` values: `passed`, `failed`, `escalated`.
+
+Allowed `nextSkill` values: `none`.
+
+## Integration
+
+- Consumes architecture and requirement signals to propose tools.
+- Produces verified dependency state for downstream validation.

package/templates/.workspace-templates/skills/validation/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: validation
+description: "Checks workspace ICM compliance and benchmarks batch outputs. Use when validating a workspace, checking compliance, running validation, benchmarking batch results, or after making changes to workspace structure."
+triggers: ["validate batch", "check results", "run validation", "benchmark outputs", "check compliance"]
+---
+
+## Overview
+
+Ensure workspace meets ICM standards and benchmark batch outputs through systematic validation. Validate both workspace structure and worker or fixer outputs before any completion claim.
+
+## When to Use
+
+- After workspace scaffolding
+- After any structural change
+- After worker batch completes
+- After fixer applies fixes
+- Before claiming delivery
+- When score drops below threshold
+
+## When Not to Use
+
+- Generating outputs (use worker sub-skill)
+- Fixing failures (use fixer sub-skill)
+- Researching patterns (use research sub-skill)
+
+## The Iron Law
+
+NO SCORE INFLATION
+NO SKIPPING FAILURES
+NO VALIDATING WITHOUT BENCHMARK
+NO PASSING WITHOUT EVIDENCE
+
+## The Process
+
+1. **Run validate.ts** - Execute `node scripts/validate.ts --workspace <path>`
+2. **Parse validation results** - Read exit code and output; collect structural findings
+3. **Check batch outputs** - For each test case in `.agents/iteration/batch-<N>/`, verify `output.md` and `report.json` exist
+4. **Run benchmark.ts** - Execute `node scripts/benchmark.ts --workspace <path>` to compute benchmark scoring
+5. **Aggregate scores** - Combine structural validation score and benchmark score into a single batch score
+6. **Generate findings** - List failures with concrete fix suggestions mapped to each failing test case
+7. **Write batch-report.json** - Structured JSON with `{skill, status, timestamp, batchId, findings, fixSuggestions, recommendations, metrics, nextSkill}` where `nextSkill` is one of `fixer`, `orchestrator`, or `none`
+
+## Batch-Level Validation
+
+When validating a batch:
+- Read all `report.json` files in `.agents/iteration/batch-<N>/`
+- Verify each worker or fixer output matches its test case expectations
+- Calculate per-test-case pass/fail status
+- Calculate overall batch score using benchmark weights
+- If score < threshold, dispatch fixer with findings
+
+## Red Flags
+
+- Reporting inflated scores to force a pass
+- Skipping failing findings because they look minor
+- Running validation without benchmark evidence
+- Returning a passing status without per-case verification
+
+## Anti-Rationalization Table
+
+| Thought | Reality |
+|---------|---------|
+| "This workspace looks good enough" | Good enough is the enemy of excellent. Run validation. |
+| "The score is close, I will round up" | Score inflation hides real problems. Report the true score. |
+| "One failure does not matter" | Every failure matters. Report it and route it to fixer. |
+| "I already validated this" | Validation is a snapshot. Re-validate after every change. |
+| "The benchmark is too strict" | The benchmark is the standard. Meet it or escalate. |
+
+## Sub-Skill Dispatch
+
+- If batch score < threshold -> fixer sub-skill (`nextSkill = fixer`)
+- If batch score >= threshold -> orchestrator (batch complete, `nextSkill = orchestrator`)
+- If critical failures (for example missing SYSTEM.md) -> escalate to human and set `nextSkill = none`
+
+## Report Format
+
+```json
+{
+  "skill": "validation",
+  "status": "passed",
+  "timestamp": "2026-04-08T00:00:00Z",
+  "batchId": 1,
+  "findings": ["All required files present"],
+  "fixSuggestions": ["No fixes required"],
+  "recommendations": ["Proceed to next batch"],
+  "metrics": {
+    "score": 94,
+    "benchmarkScore": 92,
+    "itemsChecked": 18,
+    "itemsPassed": 17,
+    "testCasesPassed": 7,
+    "testCasesFailed": 1
+  },
+  "nextSkill": "orchestrator"
+}
+```
+
+Allowed `nextSkill` values: `fixer`, `orchestrator`, `none`.
+
+## Integration
+
+- Consumes worker and fixer reports from `.agents/iteration/batch-<N>/`.
+- Produces `batch-report.json` that drives fixer routing or orchestrator continuation.

package/templates/.workspace-templates/skills/worker/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: worker
+description: "Executes a single test case against the workspace and produces output. Use when running test cases, executing workspace tasks, or processing stage-specific work."
+triggers: ["run test case", "execute workspace task", "process stage", "generate output"]
+---
+
+## Overview
+
+Execute a single test case by reading the relevant workspace sections, performing the required work, and producing structured output. Each worker runs with fresh context - no assumptions about prior runs.
+
+## When to Use
+
+- Dispatched by orchestrator as part of a batch
+- User asks to run a specific test case
+- User asks to execute a workspace stage task
+
+## When Not to Use
+
+- Validating outputs (use validation sub-skill)
+- Fixing failed outputs (use fixer sub-skill)
+- Planning workspace structure (use architecture sub-skill)
+
+## The Iron Law
+
+NO SKIPPING TEST CASE STEPS
+NO MODIFYING WORKSPACE STRUCTURE
+NO CLAIMING DONE WITHOUT OUTPUT
+NO ASSUMING PRIOR CONTEXT
+
+## The Process
+
+1. **Read test case** - Load the test case JSON from `.agents/iteration/batch-<N>/<testCaseId>/` or orchestrator input
+2. **Load workspace context** - Read `SYSTEM.md` and relevant stage `CONTEXT.md` files
+3. **Execute the task** - Follow the test case input/expected instructions
+4. **Write output.md** - Human-readable output in `.agents/iteration/batch-<N>/<testCaseId>/output.md`
+5. **Write report.json** - Structured JSON with `{skill, status, timestamp, testCaseId, batchId, findings, recommendations, metrics, nextSkill}`
+6. **Dispatch validation** - Signal that output is ready for validation
+
+## External Runner Contract
+
+- Worker execution in autonomous iteration is orchestrated via `--subagent-runner`.
+- Direct worker dispatch must provide `--runner-command` with placeholders `{skill}`, `{workspace}`, `{batchId}`, `{testCaseId}`.
+- Runner output must be JSON and include `report.json` compatible fields:
+  - `skill`, `status`, `timestamp`, `findings`, `recommendations`, `metrics`, `nextSkill`
+- Missing/invalid runner output is a failure, not a simulated success path.
+- Use `.agents/iteration/runs/*.json` telemetry to debug command rendering and runner payload issues.
+
+## Anti-Rationalization Table
+
+| Thought | Reality |
+|---------|---------|
+| "I already know what this stage does" | Read the CONTEXT.md. Assumptions cause failures. |
+| "The output is good enough" | Good enough fails validation. Follow the test case exactly. |
+| "I'll modify the workspace structure to make this easier" | Workers don't modify structure. That's the fixer's job. |
+| "This test case is redundant" | Every test case exists for a reason. Execute it. |
+| "I'll skip writing report.json" | Validation depends on report.json. It's mandatory. |
+
+## Sub-Skill Dispatch
+
+- After output complete -> validation sub-skill
+
+## Report Format
+
+```json
+{
+  "skill": "worker",
+  "status": "passed|failed|escalated",
+  "timestamp": "2026-04-08T00:00:00Z",
+  "testCaseId": "tc-001",
+  "batchId": 1,
+  "findings": ["Output generated with required sections"],
+  "recommendations": ["Proceed to validation"],
+  "metrics": {
+    "executionTimeMs": 120,
+    "outputLength": 640
+  },
+  "nextSkill": "validation"
+}
+```

package/templates/.workspace-templates/workspace/00-meta/CONTEXT.md

@@ -0,0 +1,6 @@
+# 00-meta CONTEXT.md
+
+## Workspace Metadata
+- Created: [date]
+- Purpose: [description]
+- Status: active

package/templates/.workspace-templates/workspace/00-meta/execution-log.md

@@ -0,0 +1,27 @@
+# Execution Log
+
+## Stage Checklist
+
+- [ ] 01-input
+- [ ] 02-process
+- [ ] 03-output
+
+## Rules
+
+1. Check stages in order from top to bottom.
+2. Do not mark a stage complete without required evidence.
+3. Add handoff notes before moving to the next stage.
+
+## Evidence Notes
+
+### 01-input
+- Artifacts:
+- Handoff Summary:
+
+### 02-process
+- Artifacts:
+- Handoff Summary:
+
+### 03-output
+- Artifacts:
+- Handoff Summary: