---
name: step-01-v4-execute
description: Continuous execution — delegate full module to /apex with quality gates
model: opus
next_step: steps/step-02-v4-verify.md
---

# Step 01-v4: Continuous Module Execution

## EXECUTION GUARANTEE — AUTONOMY RULES (MANDATORY)

> **NEVER stop between modules.** NEVER ask "shall I continue?". NEVER present options (1/2/3).
> **NEVER pause after a progress report.** Progress reports are LOG OUTPUT ONLY — print them and IMMEDIATELY continue to the next module.
> **The user invoked /business-analyse-develop to execute ALL modules to completion.** That is your mandate. Any stop that is not: all-complete, dead-end, or Ctrl+C is a **VIOLATION**.

## YOUR TASK

For each module in topological order, delegate the ENTIRE module implementation to `/apex -d` in a continuous session. Run quality gates at natural checkpoints. Let server-side compaction manage context.

---

## EXECUTION SEQUENCE

### 1. For Each Module in Queue

```
FOR module in topologicalOrder(modules):
  1. Build apex delegation command
  2. Delegate to /apex -d
  3. Run quality gates after delegation completes
  4. If gates fail → /apex fixes in same session
  5. Module complete → advance to next
```

### 2. Build Apex Delegation

Pass the FULL spec to apex — objectives, architecture, gates:

```
/apex -d .ralph/prd-{moduleCode}.json
```

Apex receives the v4 PRD and works autonomously through:
1. **Domain layer** — entities, value objects, enums
2. **Infrastructure** — EF configurations, DbContext registration
3. **Migration** — ONE migration per module
4. **Application** — services, DTOs, validators (implement ALL business rules)
5. **API** — controllers with correct permissions
6. **Seed data** — core (navigation, permissions, roles) + business
7. **Frontend** — pages via `/ui-components`, routes, translations
8. **Tests** — unit + integration via `scaffold_tests` (backend) + `scaffold_frontend_tests` (frontend). NO stubs, NO `Assert.True(true)`

> Apex decides the order and approach. Ralph does NOT micro-manage.

### 3. Quality Gates (Run After Apex Completes)

After `/apex -d` returns, run ALL gates:

```bash
# Gate 1: Backend build (BLOCKING)
dotnet build --no-restore 2>&1

# Gate 2: Backend tests (BLOCKING)
dotnet test --no-build 2>&1

# Gate 3: Frontend checks (BLOCKING if frontend exists)
npm run typecheck 2>&1
npm test -- --run 2>&1
```

**If any gate fails:**
1. DO NOT advance to next module
2. Show the error to Claude (same conversation — compaction preserves context)
3. Ask `/apex -d` to fix: `/apex -d "Fix build/test failures for module {moduleCode}"`
4. Re-run gates
5. Repeat until ALL gates pass (max 3 fix attempts per gate)

### 4. MCP Validation Gates

After build/test pass:

```javascript
// Security validation
mcp__smartstack__validate_security({ projectPath: "." })

// Convention validation
mcp__smartstack__validate_conventions({ projectPath: "." })

// Code review (semantic permission check)
mcp__smartstack__review_code({ files: changedFiles, focus: "security" })
```

**Semantic permission check:** Verify that write endpoints (POST/PUT/DELETE) do NOT use Read-only permissions. Fix if found.

### 5. BR Coverage Check

For each business rule in `prd.brToCodeMapping`:
1. Verify the target file exists on disk
2. Grep for the rule implementation (method name or comment reference)
3. If missing → delegate fix to apex: "Implement BR {ruleId} in {targetFile}"

### 6. Stub Test Detection

Grep test files for stub patterns:
```bash
grep -rn "Assert.True(true)\|Assert.Pass()\|// TODO\|throw new NotImplementedException" tests/ 2>/dev/null
```

If found → delegate fix to apex: "Replace stub tests with real implementations"

### 7. Module Complete — CONTINUE IMMEDIATELY

When ALL gates pass for a module:
1. Log checkpoint: `"Module {moduleCode}: ALL GATES PASS"`
2. Optionally append to progress.txt (human checkpoint)
3. **IMMEDIATELY** advance to next module in queue — DO NOT pause, DO NOT ask user, DO NOT present options

> **ANTI-STOP GUARD:** After logging the progress report, your VERY NEXT action MUST be starting the next module delegation (`/apex -d`). If there are no more modules, go to step-02-v4-verify. Outputting a progress report and then waiting for user input is a **VIOLATION** of the execution guarantee.

---

## ERROR RECOVERY (v4)

Unlike v3 (retry counter + re-delegation), v4 leverages compaction:

| Scenario | v3 behavior | v4 behavior |
|----------|-------------|-------------|
| Build fails | Inject fix task, re-iterate | Same session: Claude sees the error, fixes, re-builds |
| Test fails | Inject fix task, re-iterate | Same session: Claude reads failure, adjusts code, re-tests |
| MCP rejects | Mark task failed, retry 3x | Same session: Claude reads rejection reason, corrects |
| Apex crashes | State lost between batches | Compaction preserves context, resume from last point |

**Key advantage:** Claude has FULL context of what it just generated + the exact error. No context loss between retry attempts.

---

## NEXT STEP

After ALL modules complete → Load: `steps/step-02-v4-verify.md`
