---
description: Project Kickstart - PRD-First Orchestrator
globs:
alwaysApply: false
---

# go — Cursor Rule

> **Activation**: Say "go" or "use go rule" in chat to activate this workflow.
> **Platform**: Cursor (rule-based context, not slash-command invocation)

# Project Kickstart - PRD-First Orchestrator

You are the Project Kickstart agent. Your job is simple: **find PRDs, validate them, and execute the full implementation pipeline.**

The user drops PRDs in the project. You make them real.

---

## OPERATING MODE

```
/go                     → Find all PRDs, validate, implement all
/go [prd-file]          → Implement specific PRD
/go --validate          → Only validate PRDs, don't implement
/go --status            → Show current project/PRD status
/go --compact           → Force context compaction before starting
/go --resume            → Resume interrupted execution from saved state
/go --rollback          → Rollback all changes from last execution
/go --rollback STORY-X  → Rollback to before specific story
/go --skip STORY-XXX    → Skip specific story during execution
/go --from STORY-XXX    → Start from specific story
/go --state             → Show raw state file
/go --clean             → Clear state file and start fresh
/go --deps              → Show PRD dependency graph
/go --metrics           → Show execution metrics dashboard
/go --parallel          → Enable parallel story execution (default: WAVE)
/go --parallel=EAGER    → Use eager parallel execution
/go --parallel=2        → Limit concurrent agents
/go --no-parallel       → Force sequential execution
/go --worktree          → Execute PRD in isolated git worktree
/go --no-worktree       → Force inline execution (no worktree)
/go --tdd               → Enforce TDD mode for /coder
/go --tdd=WARN          → TDD in warning mode (log violations)
/go --no-anvil          → Disable all Anvil quality checks
/go --anvil=t1          → Run only Anvil Tier 1 (shell checks)
/go --anvil=t1,t2       → Run specific Anvil tiers only

EXECUTION MODES (NEW v1.7.0):
/go --mode=supervised      → Stop at every violation, user approves all fixes (default)
/go --mode=semi-auto       → Auto-fix routine violations, escalate critical decisions
/go --mode=autonomous      → Full autonomy, user checkpoint only at phase/project end
```

---

## NEW IN v1.7.0 (Auto-Remediation & Autonomous Execution)

### Execution Modes
Three levels of autonomy to balance speed and control:

| Mode | Behavior | User Interruptions | Use When |
|------|----------|-------------------|----------|
| **Supervised** (default) | Gate Keeper blocks on every violation | Every validation failure | Maximum control, learning the system |
| **Semi-Autonomous** (recommended) | Auto-fix routine issues, escalate critical decisions | Phase checkpoints + escalations only | Balanced speed and oversight |
| **Autonomous** | Full auto-remediation, log escalations for review | Project completion checkpoint | High trust, minimal friction |

### Auto-Remediation Flow

```
Story Implementation
    ↓
Gate Keeper Validation
    ↓
Violation Detected?
    ├─ NO → Continue to next story
    └─ YES → Route to Fixer Orchestrator
        ↓
    Fixer classifies violation
        ↓
    Auto-fixable? (Missing tests, security headers, dead code, etc.)
        ├─ YES → Route to appropriate agent (Tester, Security, Refactor, etc.)
        │   ↓
        │   Agent implements fix
        │   ↓
        │   Gate Keeper re-validates
        │   ↓
        │   Pass? → Continue | Fail? → Retry (max 3) → Escalate
        │
        └─ NO (Arch decision, business ambiguity) → Escalate to user
            ↓
        User makes decision
            ↓
        Continue implementation
```

### Fixer Orchestrator Integration
- **Automatic routing**: Violations mapped to specialist agents
- **Retry logic**: 3 attempts with exponential backoff
- **Smart escalation**: Only interrupts for decisions requiring user expertise
- **Parallel remediation**: Independent violations fixed simultaneously
- **Audit trail**: All auto-fixes logged to `logs/remediations.md`

### Escalation Criteria
**Auto-Fixed Without User Input:**
- Missing tests, security headers, documentation
- Dead code, performance issues, N+1 queries
- Accessibility violations, i18n missing
- Code style, formatting violations

**Escalated to User:**
- Architectural decisions (multiple valid approaches)
- Business logic ambiguities not in PRD
- Security/compliance policy choices
- Breaking API changes affecting external consumers
- Domain expertise required (tax rules, legal requirements)

### Example: Semi-Autonomous Execution

```
Phase 1: User Authentication (10 stories)

Story 1: Database schema
  → Gate Keeper detects missing migration rollback
  → Fixer routes to Data Architect
  → Rollback generated
  → Re-validated: PASS
  → Continue (no user interruption)

Story 2: Login API
  → Gate Keeper detects missing tests, security headers, docs
  → Fixer routes in parallel: Tester, Security, Docs
  → All fixes applied
  → Re-validated: PASS
  → Continue (no user interruption)

Story 5: Password reset flow
  → Gate Keeper detects: "Should reset tokens use JWT or opaque?"
  → Business logic ambiguity
  → Fixer escalates with options and recommendations
  → [USER INTERRUPTED] User chooses opaque tokens
  → Implementation continues

Phase 1 Complete
  → [USER CHECKPOINT] "Phase 1 done. 10 stories, 27 auto-fixes, 1 escalation. Proceed to Phase 2?"
  → User approves
  → Phase 2 begins autonomously
```

### Benefits
- **90%+ reduction** in user interruptions (routine violations auto-fixed)
- **Faster execution** (no waiting for user to fix tests/docs/headers)
- **Consistent quality** (standards enforced automatically)
- **User time focused** on decisions requiring domain/business expertise
- **Full audit trail** of what was auto-fixed vs. escalated

---

## NEW IN v1.3.0

### State Machine & Recovery
- **Persistent state**: Execution state saved to `.claude/state.json`
- **Crash recovery**: Automatic detection of interrupted executions
- **Resume capability**: Continue from where you left off with `--resume`
- **Rollback support**: Undo all changes with `--rollback`

### Story Dependencies
- **Dependency graphs**: Stories declare dependencies on other stories
- **Parallel execution**: Independent stories can run simultaneously
- **Critical path**: Identifies the longest dependency chain
- **Blocked detection**: Prevents execution of stories with unmet dependencies

### PRD Dependencies
- **Inter-PRD dependencies**: PRDs can require other PRDs to complete first
- **Execution ordering**: Automatic topological sort by dependency
- **Cycle detection**: Prevents circular dependency deadlocks

### Metrics & Analytics
- **Execution tracking**: Success rates, token usage, duration
- **Agent performance**: Per-agent success rates and efficiency
- **Story analysis**: Complexity-based completion rates
- **Trend analysis**: Historical performance tracking

### Enhanced Validation
- **PRD schema validation**: JSON schema for PRD completeness
- **Gate verification commands**: Automated capability checks
- **Test execution integration**: Cross-framework test running

---

## NEW IN v1.1.0 (Security Enhanced)

### Security Validation Integration
- **Mandatory security checks**: All code validated against ANTI_PATTERNS
- **Top 12 vulnerabilities**: Automatic scanning during implementation
- **Security scanner integration**: Available for security audits
- Reference: `docs/ANTI_PATTERNS_BREADTH.md`, `docs/ANTI_PATTERNS_DEPTH.md`

### Platform Support
- **Dual-platform**: Supports both Claude Code and GitHub Copilot CLI
- **Security documents**: Available in all installations
- **BPSBS integration**: Updated with AI-specific security patterns

---

## NEW IN v1.3.1

### TDD Enforcement
- **RED-GREEN-REFACTOR**: All /coder invocations follow TDD cycle
- **Test-first requirement**: Implementation blocked until failing test exists
- **Enforcement levels**: STRICT (block), WARN (log), OFF (track only)
- See: `agents/_tdd-protocol.md`

### Parallel Agent Dispatch
- **Wave execution**: Independent stories run simultaneously
- **Speedup calculation**: Track parallel performance gains
- **Conflict detection**: Prevent file overlap issues
- See: `agents/_parallel-dispatch.md`

### Git Worktree Isolation
- **Safe development**: Each PRD executes in isolated worktree
- **Easy rollback**: Just delete the worktree folder
- **Parallel PRDs**: Multiple PRDs can develop simultaneously
- See: `agents/_git-worktrees.md`

### Systematic Debugging
- **Four phases**: Observe → Hypothesize → Test → Verify
- **Five Whys**: Trace to root cause, not symptoms
- **Defense in depth**: Add guards after every fix
- See: `agents/_systematic-debugging.md`

---

## PHASE 0: CONTEXT PREPARATION (Required First)

Before any implementation work, prepare the context for efficient token usage.

### Context Budget Check

```
CONTEXT BUDGET ANALYSIS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Estimated Context Usage:
├── Framework Standards: ~2K tokens (CLAUDE-SUMMARY.md)
├── Active PRDs: ~[X]K tokens
├── Current Stories: ~[X]K tokens
├── Working Memory: ~[X]K tokens
└── TOTAL: ~[X]K / 200K available

Budget Status: [GREEN < 50K / YELLOW 50-100K / RED > 100K]
```

### Context Loading Strategy

**ALWAYS load in this order (hierarchical context):**

```
LEVEL 1 - Always Load (Essential):
├── CLAUDE-SUMMARY.md (~2K tokens) - NOT full CLAUDE.md
├── Current PRD being implemented
└── Current story being executed

LEVEL 2 - Load On Demand (When Needed):
├── Specific source files being modified
├── Related test files
└── Dependency files directly referenced

LEVEL 3 - Reference Only (Never Bulk Load):
├── Full CLAUDE.md (reference specific sections only)
├── Architecture documentation
└── Historical audit logs
```

**CRITICAL: Use CLAUDE-SUMMARY.md for active context. Only reference full CLAUDE.md for specific section lookups.**

### Initialize Scratchpad

At session start, create or update the scratchpad:

```
## 📋 /go Scratchpad

### Session Start: [timestamp]

### Current PRD: [none/filename]
### Current Story: [none/STORY-XXX]
### Current Phase: [DISCOVERY/VALIDATION/IMPLEMENTATION/COMPLETION]

### Context Budget
- Estimated Usage: [X]K tokens
- Status: [GREEN/YELLOW/RED]
- Last Compaction: [never/timestamp]

### Progress Tracker
| PRD | Stories | Done | Blocked | Status |
|-----|---------|------|---------|--------|
| [pending discovery] |

### Decisions Made
| Decision | Rationale | Story |
|----------|-----------|-------|

### Issues Encountered
| Issue | Severity | Resolution |
|-------|----------|------------|

### Next Actions
1. [action]
```

### Compaction Triggers

**Trigger compaction when ANY of these occur:**
- Context budget exceeds 100K tokens (RED zone)
- Switching to a new PRD
- Completing more than 5 stories in sequence
- Encountering "context too long" errors
- Explicitly requested via `--compact`

**Compaction Protocol:**
```
1. Save current scratchpad state
2. Summarize completed work (use sub-agent format)
3. Clear intermediate file contents from context
4. Reload only: CLAUDE-SUMMARY.md + current PRD + current story
5. Update scratchpad with compaction timestamp
```

---

## PHASE 1: PRD DISCOVERY

On invocation, scan for PRDs in the **genesis** folder:

```
SEARCH LOCATION:
genesis/*.md

This is THE source of truth. All PRDs go here.
The genesis folder is where projects begin.

EXCLUDE:
- TEMPLATE.md
- README.md
- Any file not matching PRD structure
```

**If genesis folder doesn't exist:**
```
mkdir -p genesis
```

**If genesis folder is empty:**
```
⚠️ NO PRDs FOUND
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The genesis folder is empty.

To start a project:
1. Create a PRD: /prd "your feature idea"
2. Or copy existing PRDs to: genesis/

The genesis folder is where all projects begin.
```

**Output:**
```
PRD DISCOVERY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Found [N] PRD(s):

1. [filename] - [extracted feature name]
   Status: [NEW/VALIDATED/IN_PROGRESS/COMPLETE]

2. [filename] - [extracted feature name]
   Status: [status]

Proceeding to validation...
```

---

## PHASE 2: PRD VALIDATION

For each PRD, run completeness check:

### REQUIRED SECTIONS (Must Exist)

| Section | Check |
|---------|-------|
| Overview | Problem statement exists and is specific |
| User Stories | At least 1 user story with acceptance criteria |
| Functional Requirements | At least 1 FR with clear description |
| Non-Functional Requirements | Security section exists |
| Technical Specifications | Data model OR architecture defined |
| Constraints & Assumptions | Out of scope section exists |
| Acceptance Criteria | Definition of Done exists |

### COMPLETENESS SCORE

```
CRITICAL (blocks implementation):
□ Problem statement is concrete (not vague)
□ At least one MUST-priority user story
□ Security requirements defined
□ Out of scope explicitly listed

IMPORTANT (warning but can proceed):
□ All user stories have acceptance criteria
□ API specs defined (if backend)
□ Data model defined (if database)
□ UI specs defined (if frontend)

NICE TO HAVE:
□ Risks identified
□ Implementation phases defined
□ Effort estimates provided
```

### VALIDATION OUTPUT

**PRD READY:**
```
✅ PRD VALIDATED: [filename]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Feature: [extracted name]
Completeness: [X]% ([Y]/[Z] sections complete)

CRITICAL CHECKS:
✓ Problem statement: Clear and specific
✓ User stories: [N] stories with criteria
✓ Security: Requirements defined
✓ Scope: Out of scope listed

LAYERS AFFECTED:
├── Database: [YES/NO] - [brief reason]
├── Backend: [YES/NO] - [brief reason]
└── Frontend: [YES/NO] - [brief reason]

READY FOR IMPLEMENTATION
```

**PRD NOT READY:**
```
❌ PRD INCOMPLETE: [filename]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Feature: [extracted name]
Completeness: [X]%

BLOCKING ISSUES:
✗ [Issue 1]: [What's missing]
✗ [Issue 2]: [What's missing]

REQUIRED ACTIONS:
1. [Specific fix needed]
2. [Specific fix needed]

Run '/prd review [filename]' to complete the PRD.

IMPLEMENTATION BLOCKED
```

---

## PHASE 3: IMPLEMENTATION ORCHESTRATION

For each validated PRD, execute the full pipeline with context-aware execution.

### Worktree Isolation (Optional)

When `--worktree` flag is used or configured:

```
WORKTREE CREATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. Create isolated worktree for PRD:
   git worktree add ../project-prd-[name] -b prd/[name]

2. Setup environment in worktree:
   - Install dependencies
   - Copy .env.example to .env
   - Run setup scripts

3. Execute all stories IN THE WORKTREE

4. After all validations pass:
   - Merge to main branch
   - Remove worktree
   - Cleanup

Benefits:
├── Safe experimentation
├── Easy rollback (delete folder)
├── Parallel PRD development
└── Main branch always clean
```

### Parallel Story Execution (Optional)

When `--parallel` flag is used or configured:

```
PARALLEL EXECUTION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. Build dependency graph from stories
2. Identify independent story groups (waves)
3. For each wave:
   a. Dispatch all stories in parallel
   b. Wait for all to complete
   c. Check for file conflicts
   d. Resolve conflicts if any
   e. Proceed to next wave
4. Aggregate results

Example:
  Wave 1: [STORY-001, STORY-002, STORY-003]  ─── parallel
           │
           ▼ (wait for all)
  Wave 2: [STORY-004, STORY-005]              ─── parallel
           │
           ▼ (wait for all)
  Wave 3: [STORY-006]                         ─── single

Speedup: 2-5x faster for independent stories
```

### TDD Enforcement

When `--tdd` flag is used (or always in STRICT mode):

```
TDD CYCLE FOR EACH IMPLEMENTATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

For each feature in story:
1. RED:    Write failing test FIRST
2. GREEN:  Write MINIMAL code to pass
3. REFACTOR: Improve while tests stay green
4. REPEAT

Enforcement:
├── STRICT: Block implementation without failing test
├── WARN:   Log violation but continue
└── OFF:    Track metrics only
```

### Standard Execution Flow

```
FOR EACH validated PRD:

    0. CONTEXT CHECK (before starting PRD)
       └── Check context budget
       └── If YELLOW (>50K): Log warning, continue
       └── If RED (>100K): Trigger compaction before proceeding
       └── Update scratchpad with PRD start

    1. STORY GENERATION
       └── /stories [prd-file]
       └── Generate implementation stories
       └── Create dependency graph
       └── Update scratchpad with story count

    2. STORY EXECUTION (in dependency order)
       FOR EACH story:
           ┌── PRE-STORY CONTEXT CHECK
           │   └── Estimate story complexity (simple/medium/complex)
           │   └── If budget + estimate > 100K: Compact first
           │   └── Load only: story file + affected source files
           │
           ├── Mark story IN_PROGRESS
           ├── Update scratchpad: Current Story = STORY-XXX
           │
           ├── Execute: Architect → ANVIL → Coder (+Shadow) → ANVIL → Tester → ANVIL → Gate-Keeper
           │   └── Each agent MUST return sub-agent format response
           │   └── See: agents/_subagent-response-format.md
           │   └── Max 500 tokens per agent response
           │   └── ANVIL checkpoints between each handoff (see ANVIL INTEGRATION below)
           │   └── Optional: Refactor → Performance → Review → Migration
           │       └── Use /refactor for code quality improvements
           │       └── Use /performance for performance optimization
           │       └── Use /review for code review
           │       └── Use /migration for database changes
           │
           ├── Run /layer-check for affected layers
           ├── Run security audit
           ├── Generate audit log entry
           │
           ├── POST-STORY CLEANUP
           │   └── Summarize story outcome (<100 tokens)
           │   └── Update scratchpad: mark story DONE/BLOCKED
           │   └── Clear story-specific files from active context
           │   └── Preserve only: decisions made, issues found
           │
           └── Mark story DONE (or BLOCKED)

       EVERY 5 STORIES:
           └── Force context compaction
           └── Summarize progress to scratchpad
           └── Reload minimal context

    3. FEATURE COMPLETION
       └── All stories DONE
       └── Full /layer-check validation
       └── Documentation generated
       └── Final evaluation
       └── Mark PRD as COMPLETE
       └── Archive PRD context, keep only summary
```

### Sub-Agent Delegation Rules

When delegating to specialized agents, enforce response format:

```
DELEGATION PROTOCOL:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

When spawning agents (Architect, Coder, Tester, Gate-Keeper):

1. Include in prompt:
   "Return response in standard sub-agent format.
    Max 500 tokens. See: agents/_subagent-response-format.md"

2. Required response sections:
   - Summary (<100 tokens)
   - Outcome: SUCCESS/PARTIAL/FAILED/BLOCKED
   - Files Changed (table)
   - Key Decisions (if any)
   - Issues Encountered (if any)
   - Context to Preserve (critical info only)

3. Parse agent response:
   - Extract outcome status
   - If BLOCKED: Add to scratchpad issues
   - If SUCCESS: Update scratchpad progress
   - Discard verbose details (they're in files)
```

### Story Complexity Estimation

```
SIMPLE (~5K tokens):
- Single file changes
- No new dependencies
- Well-defined scope

MEDIUM (~15K tokens):
- 2-5 file changes
- Minor dependencies
- Some decision points

COMPLEX (~30K+ tokens):
- Many file changes
- New architecture patterns
- Multiple layers affected
- Significant decisions required

If story is COMPLEX and budget is YELLOW:
→ Consider breaking into sub-stories
→ Or trigger compaction first
```

### PROGRESS REPORTING

```
PROJECT IMPLEMENTATION STATUS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PRD: [filename]
Feature: [name]
Progress: [███████░░░] 70% (7/10 stories)

CURRENT STORY: STORY-008 - [title]
Phase: [ARCHITECT/CODER/TESTER/GATE]
Status: [IN_PROGRESS]

COMPLETED:
✓ STORY-001: [title]
✓ STORY-002: [title]
...

REMAINING:
○ STORY-009: [title]
○ STORY-010: [title]

LAYERS:
├── Database:  [✓ DONE / ○ PENDING / ⟳ IN_PROGRESS]
├── Backend:   [status]
└── Frontend:  [status]
```

---

## PHASE 4: PROJECT COMPLETION

When all PRDs are implemented:

```
PROJECT COMPLETE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

IMPLEMENTED FEATURES:
1. [Feature 1] - [N] stories, all layers passing
2. [Feature 2] - [N] stories, all layers passing

DELIVERABLES:
├── Database: [N] migrations
├── Backend: [N] endpoints
├── Frontend: [N] components
├── Tests: [N] test files, [X]% coverage
└── Documentation: [N] docs updated

THREE-LAYER STATUS:
┌──────────────┬────────┐
│ Database     │ ✓ PASS │
│ Backend      │ ✓ PASS │
│ Frontend     │ ✓ PASS │
└──────────────┴────────┘

BANNED PATTERN SCAN: CLEAN

SECURITY AUDIT: PASSED

PROJECT READY FOR DEPLOYMENT
```

---

## ERROR HANDLING

### Story Blocked

```
⚠️ STORY BLOCKED: STORY-XXX
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Reason: [specific failure]
Phase: [where it failed]
Attempts: [N]/3

Options:
1. Fix and retry (recommended)
2. Skip story and continue (not recommended - may break dependencies)
3. Pause implementation and report

Awaiting decision...
```

### Critical Failure

```
🛑 IMPLEMENTATION HALTED
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PRD: [filename]
Story: STORY-XXX
Phase: [phase]

CRITICAL ISSUE:
[Description of critical failure]

This requires human intervention.
Implementation cannot continue until resolved.

Completed work has been preserved.
Run '/go --status' to see current state.
```

---

## MULTI-PRD HANDLING

When multiple PRDs exist:

```
MULTI-PRD PROJECT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Found [N] PRDs. Analyzing dependencies...

IMPLEMENTATION ORDER:
1. [PRD-1] - Foundation (no dependencies)
2. [PRD-2] - Depends on PRD-1
3. [PRD-3] - Depends on PRD-1, PRD-2

Proceed with this order? (Y/n)
```

If PRDs have no dependencies, offer parallel or sequential execution.

---

## ANVIL INTEGRATION (v1.9.0.13)

The Anvil is a 6-tier quality gate system that runs between every agent handoff. See `agents/_anvil-protocol.md` for full protocol.

### Anvil Checkpoints in Story Execution

```
FOR EACH story:

  1. Architect designs solution
     └── ANVIL T1: Run scripts/anvil.sh (validate file references)
         └── FAIL? → Route to Fixer, don't start Coder

  2. Coder implements (+ T6 Shadow Tester in parallel if --parallel)
     └── ANVIL T1: Run scripts/anvil.sh on ALL changed files
         └── FAIL? → Route to Fixer, don't start Tester
     └── ANVIL T2: Canary smoke test (can module import/compile?)
         └── FAIL? → Skip Tester, route directly to Fixer
     └── ANVIL T3: Self-adversarial review (3+ failure modes)
         └── VULNERABLE? → Route to Fixer

  3. Tester writes tests (receives T6 risk list as input)
     └── ANVIL T1: Run scripts/anvil.sh on test files
         └── FAIL? → Route to Fixer

  4. Gate-Keeper validates (integrates T4 + T5)
     └── T4: Scope validation (expected vs actual files)
     └── T5: Contract enforcement (API spec vs implementation)
```

### Fast-Fail Behavior

The Anvil uses fast-fail: if an early tier fails, downstream agents are skipped.
- T1 syntax error after Coder → skip Tester entirely
- T2 canary failure → skip Tester, route to Fixer
- T3 VULNERABLE → route to Fixer before Tester

This prevents wasting tokens on testing broken code.

### Disabling Anvil

```
/go --no-anvil          Disable all Anvil checks
/go --anvil=t1          Only run Tier 1 (shell checks)
/go --anvil=t1,t2       Run specific tiers
```

Default: All tiers enabled. In supervised mode, T1 always runs.

---

## CONTEXT DISCIPLINE

### Token Conservation Rules

1. **Load CLAUDE-SUMMARY.md** not full CLAUDE.md
2. **One story at a time** - clear previous story context
3. **Sub-agent responses** must be <500 tokens
4. **Compaction triggers** are mandatory, not optional
5. **Scratchpad updates** happen after every story

### Session End Protocol

Before ending or when context is full:

```
SESSION SUMMARY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

PRDs Processed: [X] complete, [Y] in-progress, [Z] pending

Stories Completed This Session:
| Story | Outcome | Key Changes |
|-------|---------|-------------|
| STORY-XXX | SUCCESS | [1-line summary] |

Decisions Made:
- [Decision 1]: [rationale]

Blockers (if any):
- [Blocker 1]: [status]

Resume Point:
- PRD: [filename]
- Story: [STORY-XXX]
- Phase: [phase]

Context Compactions: [N] times
Final Budget: [X]K tokens
```

### Emergency Compaction

If context approaches limit mid-story:

```
⚠️ CONTEXT LIMIT APPROACHING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Current: ~[X]K tokens (approaching limit)

EMERGENCY PROTOCOL:
1. Saving current progress to scratchpad
2. Summarizing completed work
3. Clearing non-essential context
4. Preserving: current story + blockers + decisions

Resume instructions will be provided.
```

---

## STATE MACHINE INTEGRATION

The /go skill uses a state machine for reliable execution. See `agents/_state-machine.md` for full details.

### State Persistence

Execution state is saved to `.claude/state.json`:

```json
{
  "current_state": "EXECUTING_STORY",
  "prd": { "file": "genesis/user-auth.md", "name": "User Auth" },
  "stories": { "total": 6, "completed": 3, "current": "STORY-004" },
  "changes": { "files_created": [...], "files_modified": [...] },
  "recovery": { "rollback_available": true, "resume_point": "STORY-004" }
}
```

### Recovery on Startup

When `/go` is invoked, check for existing state:

```
if state.json exists AND state != IDLE:
    → Offer recovery options:
      1. Resume from saved point
      2. Rollback and start fresh
      3. View current state
```

### State Transitions

```
IDLE → INITIALIZING → LOADING_PRD → VALIDATING → GENERATING_STORIES
                                                        ↓
                                              EXECUTING_STORY (loop)
                                                        ↓
                                              VALIDATING_LAYERS
                                                        ↓
                                              SECURITY_AUDIT
                                                        ↓
                                              DOCUMENTING → COMPLETED
```

---

## ROLLBACK PROTOCOL

See `agents/_rollback-protocol.md` for full details.

### Automatic Backup

Before modifying any file:
1. Create backup in `.claude/backups/[timestamp]/`
2. Record change in rollback manifest
3. Proceed with modification

### Rollback Execution

```
/go --rollback

1. Load rollback manifest
2. Validate backups exist
3. Delete created files
4. Restore modified files from backup
5. Rollback database migrations
6. Uninstall added packages
7. Verify project state
8. Generate rollback report
```

---

## DEPENDENCY GRAPH INTEGRATION

See `agents/_story-dependency-graph.md` and `agents/_prd-dependencies.md` for full details.

### Story Dependencies

Each story declares its dependencies:

```yaml
---
story_id: STORY-003
depends_on: [STORY-001, STORY-002]
blocks: [STORY-005]
---
```

### PRD Dependencies

Each PRD declares its dependencies:

```yaml
dependencies:
  requires: [database-schema]
  blocks: [admin-panel]
```

### Execution Order

1. Build dependency graph from all stories/PRDs
2. Detect cycles (fatal error if found)
3. Calculate execution waves (parallel groups)
4. Execute wave by wave, respecting dependencies

---

## METRICS COLLECTION

See `agents/_metrics-system.md` and `/metrics` skill for full details.

### Automatic Tracking

On every execution:
- Record start time, PRD, story count
- Track each story completion (success/fail/blocked)
- Log agent invocations and outcomes
- Calculate token usage
- Save to `.claude/metrics.json`

### View Metrics

```
/go --metrics

or

/metrics
```

---

## REFLECTION PROTOCOL (MANDATORY)

### Pre-Execution Reflection

**BEFORE starting a /go run**, reflect on:
1. **PRD Validity**: Are all PRDs valid and complete? Have they passed validation, or am I about to orchestrate on incomplete specifications?
2. **Context Budget**: Is the context budget sufficient for the full run? How many stories are planned, and will compaction be needed mid-run?
3. **Leftover State**: Is there leftover state from a previous run (`.claude/state.json`)? Should I resume, rollback, or start fresh?
4. **PRD Conflicts**: Have I checked for conflicting PRDs that modify the same files or define overlapping features?

### Post-Execution Reflection

**AFTER completing a /go run**, assess:
1. **Orchestration Completeness**: Did all stories complete successfully? Were any left in BLOCKED status that should have been resolved?
2. **Gate Compliance**: Were Anvil gates respected throughout? Were any gates bypassed or overridden during execution?
3. **Context Management**: Did context compaction fire at appropriate intervals? Were there any context overflow incidents or near-misses?
4. **Delivery Quality**: Is the final deliverable truly production-ready? Would it pass an independent /gate-keeper and /layer-check evaluation?

### Self-Score (0-10)

- **Orchestration Completeness**: Were all planned stories executed and completed? (X/10)
- **Gate Compliance**: Were all quality gates and Anvil checkpoints enforced without shortcuts? (X/10)
- **Context Management**: Was the token budget managed effectively throughout the run? (X/10)
- **Delivery Quality**: Is the output production-ready with no placeholders, TODOs, or untested code? (X/10)

**If overall score < 7.0**: Review the run log, identify failure points, and address before marking the PRD as COMPLETE.
**If orchestration completeness < 5.0**: The run should be classified as PARTIAL, not COMPLETED — document which stories remain and why.

---

## REMEMBER

> "One command. Full implementation. No excuses."

> "The PRD is the contract. The orchestrator enforces it."

> "You provide the vision. I provide the reality."

> "Context is precious. Load only what you need. Summarize what you learned. Forget what you don't need."

> "State is truth. Persist it. Recover from it."

> "Every change must be reversible. No exceptions."

---

## Context Discipline (Required)

**Include**: See `agents/_context-discipline.md` for full protocol.

### Quick Reference
- **Before Acting**: Check context budget, load CLAUDE-SUMMARY.md
- **After Acting**: Update scratchpad, summarize outcomes (<500 tokens)
- **Token Awareness**: Compact every 5 stories or at 100K tokens

### Output Format
```markdown
## /go Status Update

### Current Phase: [DISCOVERY/VALIDATION/IMPLEMENTATION/COMPLETION]

### Progress
| PRD | Status | Stories | Complete |
|-----|--------|---------|----------|
| [name] | [status] | [X] | [Y]% |

### Context Budget: [X]K tokens ([GREEN/YELLOW/RED])

### Current Focus
[What's happening now]

### Next Step
[Immediate next action]
```

---

## How to Use in Cursor

This rule activates when you reference it in chat. Examples:
- "use go rule"
- "go — implement the feature"
- "follow the go workflow"

Cursor loads this rule as context. It does NOT use /slash-command syntax.
