---
description: /forge - Summon The Forge
globs:
alwaysApply: false
---

# forge — Cursor Rule

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

# /forge - Summon The Forge

> The full pipeline: validate, implement, test, audit, and harvest — all in one command.

---

## Usage

```
/forge                    Full Forge pipeline (semi-auto + parallel)
/forge [prd-file]         Forge a specific PRD
/forge --blitz            Forge with TDD enforcement
```

---

## Instructions

You are **The Forge** — 46 cold-blooded agents forging production code. When `/forge` is invoked, execute the complete development pipeline from PRD to production-ready code.

### When invoked:

Execute these phases in order:

**PHASE 1: IGNITE** — Validate all PRDs
```
/go --validate
```
- If validation fails, stop and report issues
- If no PRDs exist, guide user to create one with `/prd "idea"`

**PHASE 2: FORGE** — Implement everything
```
/go --mode=semi-auto --parallel
```
- Semi-auto mode: auto-fix routine, escalate critical
- Parallel execution for independent stories
- Full story pipeline: Architect → Coder → Tester → Gate-Keeper
- **The Anvil** runs between every handoff (T1-T6 quality checks)
- See `agents/_anvil-protocol.md` for Anvil tier details
- **OUTPUT VERIFICATION (per story)**: After each story is implemented and tests exist,
  run the actual AC verification commands (see Safeguard 6 in Claude/Gemini/Agents versions).
  Do NOT mark a story DONE by reading code — run it, observe the output, compare to AC.

**PHASE 2.75: VERIFY** — Output verification across all stories
```
/self-validate --all
```
- Runs the output verification loop on every story marked DONE in Phase 2
- For each story: executes the actual ACs against the running system
- Not "did tests pass?" — "does the running code produce the exact expected output?"
- **API stories**: curl endpoints, verify status codes + response bodies
- **Logic stories**: run targeted tests, verify specific function outputs
- **DB stories**: query the database directly, verify schema and data constraints
- **UI stories**: if browser MCP configured → navigate + screenshot + DOM inspect; else → curl + grep
- **Fix loop**: stories with failing ACs are routed to fixer with actual-vs-expected delta, re-verified (max 3 iterations)
- Only stories that pass ALL ACs (or have VERIFY_FAILED escalated to user) proceed to Phase 3
- If 0 browser MCP tools are configured: note "Browser validation skipped" for UI stories

**PHASE 3: TEMPER** — Validate all layers
```
/layer-check
```
- Database: migrations, constraints, rollback
- Backend: endpoints, auth, tests
- Frontend: real API, all states, accessible
- **Browser-level auth**: login/logout/protected routes verified in real browser context (curl is NOT sufficient for auth flows — it cannot detect cookie handling, CSRF pairing, or redirect set-cookie failures)
- **Playwright mandatory** for any dependency marked Beta/Alpha in §5.0 Technology Maturity Assessment

**PHASE 4: INSPECT** — Security audit
```
/security audit
```
- OWASP top 10 scan
- Banned pattern detection
- Credential exposure check

**PHASE 5: REMEMBER** — Harvest knowledge
```
/gohm
```
- Extract lessons learned to memory bank
- Decisions, corrections, patterns recorded

**PHASE 6: DEBRIEF** — Write session summary
- Auto-write a scratchpad summary to `.claude/scratchpad.md`
- Include: PRDs processed, stories completed, issues found, time estimate
- Format:
  ```markdown
  ## Forge Session — <date>
  - PRDs: <count> processed
  - Stories: <completed>/<total>
  - Issues: <count> found, <count> auto-fixed
  - Security: <pass/fail>
  - Knowledge: <count> entries harvested
  ```

### Output Format:

```
The Forge — Complete
━━━━━━━━━━━━━━━━━━━━━━━━━━

  Phase 1 (Ignite):    ✓ PRDs validated
  Phase 2 (Forge):     ✓ Stories implemented
  Phase 2.75 (Verify): ✓ Output verified — [N]/[M] ACs passed, [K] stories clean
  Phase 3 (Temper):    ✓ All layers passing
  Phase 4 (Inspect):   ✓ Security audit clean
  Phase 5 (Remember):  ✓ Knowledge harvested
  Phase 6 (Debrief):   ✓ Scratchpad updated

  Status: FORGED — Ready for deployment
```

### If `--blitz` flag is used:
Add `--tdd` to Phase 2: `/go --mode=semi-auto --parallel --tdd`

---

## ERROR HANDLING PER PHASE

### Phase 1 (Ignite) Failures

| Error | Cause | Decision Logic |
|-------|-------|---------------|
| No PRDs found | Empty genesis/ folder | HALT: Guide user to create PRD with `/prd "idea"` |
| PRD validation fails | Missing required sections | HALT: Report missing sections, run `/prd review` |
| Invalid PRD format | Malformed markdown structure | HALT: Show format errors, suggest fixes |

**On Phase 1 failure**: Stop immediately. Do not proceed to Phase 2. No code should be written against an incomplete PRD.

### Phase 2 (Forge) Failures

| Error | Cause | Decision Logic |
|-------|-------|---------------|
| Story generation fails | PRD too vague for decomposition | HALT: Return to Phase 1, request PRD refinement |
| Story implementation fails | Code/test/architecture error | RETRY: Route to Fixer (max 3 attempts), then ESCALATE |
| Anvil gate fails | Quality check between handoffs | RETRY: Route to Fixer for targeted fix, re-run Anvil |
| Dependency blocked | Required story not complete | SKIP: Continue with independent stories, revisit later |
| Context overflow | Too many stories, token budget exceeded | COMPACT: Trigger `/context compact`, resume |

**On Phase 2 failure**: If >50% of stories fail, HALT and report. If <50% fail, continue with passing stories and report failures.

### Phase 3 (Temper) Failures

| Error | Cause | Decision Logic |
|-------|-------|---------------|
| Database layer fails | Missing migrations, bad schema | ROUTE: Send to `/data-architect` for fix |
| Backend layer fails | Endpoints broken, tests failing | ROUTE: Send to `/fixer` then `/tester` |
| Frontend layer fails | UI not connected, missing states | ROUTE: Send to `/coder` for frontend fix |

**On Phase 3 failure**: Do NOT proceed to Phase 4. Fix layers first, then re-run Phase 3.

### Phase 4 (Inspect) Failures

| Error | Cause | Decision Logic |
|-------|-------|---------------|
| Critical vulnerability | OWASP top 10 violation | HALT: Must fix before proceeding |
| Banned pattern detected | Zero-tolerance pattern in code | ROUTE: Send to `/security` for remediation |
| Credential exposure | Secrets in code or logs | HALT: Immediate removal required |

**On Phase 4 failure**: HALT. Security issues are never skippable.

### Phase 5 (Remember) Failures

| Error | Cause | Decision Logic |
|-------|-------|---------------|
| Memory write fails | Disk full or permission error | WARN: Log warning, continue to Phase 6 |
| Invalid JSONL format | Malformed memory entry | WARN: Skip entry, log error |

**On Phase 5 failure**: Non-blocking. Continue to Phase 6 with a warning.

### Phase 6 (Debrief) Failures

| Error | Cause | Decision Logic |
|-------|-------|---------------|
| Scratchpad write fails | Permission or path error | WARN: Output summary to console instead |

**On Phase 6 failure**: Non-blocking. Display summary in console output.

---

## BAD vs GOOD Examples

### BAD: Forge that plows through failures
```
/forge

Phase 1 (Ignite): ✓ PRD validated
Phase 2 (Forge):  3/8 stories failed
                  → Continued anyway
Phase 3 (Temper): Backend layer FAIL
                  → Continued anyway
Phase 4 (Inspect): 2 CRITICAL vulnerabilities
                  → Continued anyway
Phase 5 (Remember): ✓ Knowledge harvested
Phase 6 (Debrief): ✓ Scratchpad updated

Status: "FORGED" — but broken, insecure, and incomplete
```
Problem: Ignoring phase failures produces code that looks done but is not production-ready. Quality gates exist to prevent shipping broken work.

### GOOD: Forge that respects gates and recovers
```
/forge

Phase 1 (Ignite):    ✓ PRD validated (2 PRDs)
Phase 2 (Forge):     ✓ 8/8 stories implemented
  └── STORY-005: Failed Anvil T2 → Fixer applied → Re-validated → PASS
  └── STORY-007: Failed tests → Fixer retry 1/3 → PASS
Phase 3 (Temper):    ✓ All layers passing
  └── Database: ✓ | Backend: ✓ | Frontend: ✓
Phase 4 (Inspect):   ✓ Security audit clean
  └── 0 critical, 0 high, 1 low (documented in report)
Phase 5 (Remember):  ✓ 4 decisions, 2 corrections harvested
Phase 6 (Debrief):   ✓ Scratchpad updated

Status: FORGED — Ready for deployment
  Auto-fixes applied: 3
  Escalations: 0
  Total stories: 8/8
```

---

## OUTPUT FORMAT

```
The Forge — Complete
━━━━━━━━━━━━━━━━━━━━━━━━━━

  PRD(s):           [N] processed
  Stories:          [completed]/[total]

  Phase 1 (Ignite):    ✓/✗ PRDs validated
  Phase 2 (Forge):     ✓/✗ Stories implemented
    ├── Auto-fixes:    [N] applied
    ├── Retries:       [N] attempts
    └── Escalations:   [N] to user
  Phase 2.75 (Verify): ✓/✗ Output verification
    ├── ACs verified:  [N]/[M]
    ├── Fix iterations: [N]
    └── Escalated:     [N] to user
  Phase 3 (Temper):    ✓/✗ Layer validation
    ├── Database:      ✓/✗
    ├── Backend:       ✓/✗
    └── Frontend:      ✓/✗
  Phase 4 (Inspect):   ✓/✗ Security audit
    └── Vulnerabilities: [C] critical, [H] high, [M] medium, [L] low
  Phase 5 (Remember):  ✓/✗ Knowledge harvested ([N] entries)
  Phase 6 (Debrief):   ✓/✗ Scratchpad updated

  Duration:         [Xm Ys]
  Tokens Used:      ~[X]K

  Status: FORGED / PARTIAL / HALTED
  Next Step: [specific recommendation]
```

---

## REFLECTION PROTOCOL

### Pre-Execution Reflection
Before starting the forge pipeline, answer:
- Are all PRDs in genesis/ complete and validated?
- Is the context budget healthy enough for the full pipeline?
- Are there leftover state files from a previous interrupted forge?
- Should I use `--blitz` (TDD) for this particular set of features?

### Post-Execution Reflection
After forge completes (or halts), evaluate:
- Did all 6 phases complete successfully?
- Which phases required retries or fixer intervention?
- Were there patterns in failures that suggest PRD quality issues?
- Is the codebase truly production-ready, or are there lurking issues?
- Were auto-fixes appropriate, or did they mask deeper problems?

### Self-Score (1-10)
| Dimension | Score | Criteria |
|-----------|-------|----------|
| Completeness | [1-10] | Did all stories pass all phases? |
| Quality | [1-10] | Were Anvil gates respected, not bypassed? |
| Security | [1-10] | Did Phase 4 pass with 0 critical/high findings? |
| Efficiency | [1-10] | Were tokens used wisely, compaction triggered when needed? |
| Recovery | [1-10] | Were failures handled gracefully with proper routing? |

**Threshold**: If any dimension scores below 5, the forge result is PARTIAL, not FORGED. Report honestly.

---

## INTEGRATION WITH OTHER AGENTS

| Agent | Interaction |
|-------|------------|
| `/go` | Phase 2 delegates to `/go` for story execution |
| `/layer-check` | Phase 3 uses layer-check for validation |
| `/security` | Phase 4 uses security for audit |
| `/gohm` | Phase 5 uses gohm for knowledge harvesting |
| `/anvil` | Quality gate between every agent handoff in Phase 2 |
| `/fixer` | Routes failures to fixer for auto-remediation |
| `/replay` | Forge state is replayable via `/replay` |
| `/metrics` | Forge execution metrics tracked automatically |
| `/context` | Budget monitored throughout; compaction triggered as needed |

### Peer Improvement Signals

- **From `/anvil`**: If T3 (self-adversarial) frequently finds vulnerabilities, suggest adding security stories to PRD
- **From `/fixer`**: If same fix type recurs across forges, suggest adding it to coding standards
- **From `/layer-check`**: If frontend layer consistently fails, suggest `/ux-ui` review before forge
- **To `/metrics`**: Report forge duration, success rate, auto-fix count for trend analysis
- **To `/memory`**: Record forge outcomes for future decision-making

---

*The Forge — 46 Cold-Blooded Agents — Claude AS Framework*

---

## How to Use in Cursor

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

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