Module Overview

This is the Dev Track's equivalent of Module 2. The core program teaches Evaluate → Plan → Apply → Validate as a discipline you apply by hand, in a chat window, to any artifact. nexus-dev-toolkit encodes exactly that cycle as four skills for the Developer role — each one a markdown file in .claude/commands/ (or .opencode/commands/ — same filenames, same behavior), each one enforcing the same gate the core program teaches: no code until a plan is approved. A fifth command, /code-review, isn't one of the four EPAV phases — it's a separate reviewer skill — but it's the recommended last step before calling any task done, so treat it as part of the daily loop, covered alongside the other four below.

Same Gates, Mechanical Enforcement

Module 2 teaches that a gate is a checkpoint, a handoff, and a commitment — and that a failed gate sends work back, never forward. EPAV enforces the same shape, just inside a single session instead of across a week:

The CSV Is Still the Prompt

Nothing about the artifact chain changes. docs/dev-tasks/epic-N-...-tasks.csv — produced in the core program's Week 2 by the Tech Lead — still has user_story, description, acceptance_criteria, and dependencies. /evaluate's context-loading step reads that CSV row first, then AGENTS.md, then the architecture doc, then knowledge/. You don't re-type any of it — the argument to /evaluate is just which task. Under the hood, the MCP tool load_task is what actually pulls the matching CSV row plus the knowledge-graph blast radius into context at the start of /evaluate — it's already wired up by nexus init, so you never call it directly.

/evaluate TASK-014

reads the same as the core program's manual prompt sequence:

[EVALUATE] Load: docs/arch-docs/, the epic CSV, AGENTS.md
I'm implementing TASK-014: approve/reject decision endpoint + audit record.
Walk me through how the approval queue (TASK-013) and the data
model work so I understand where to integrate.

— except nexus already knows which files to load, in what order, and what format to answer in.

Walkthrough: One Task, Five Commands

1 — /evaluate TASK-014

EVALUATE SUMMARY
────────────────
Task:        Approve/reject decision endpoint + audit record (US-03)
Touches:     POST /api/leave-requests/:id/decision, leave_requests, audit_log
Depends on:  TASK-013 (manager approval queue, scoped to direct reports)
Constraints: error format from AGENTS.md; 403 if requester is not a direct
             report (PRD US-03 AC3); no hard-delete anywhere (BRD BR-04)
Risk:        leave_requests.manager_id filter is security-relevant —
             getting the scope check wrong is a data-exposure bug, not a
             cosmetic one (ARCH-LeaveTrack-v1.0 security note)

"Ready to /plan. Type /plan when you want the implementation blueprint."

2 — /plan

PLAN
────
1. src/app/api/leave-requests/[id]/decision/route.ts — new route handler
2. src/lib/leave-requests.ts — add decideRequest(), enforces manager_id
   filter in the query itself, not in a post-query check
3. src/lib/audit.ts — write the audit_log row on every decision

Files created:   route.ts, audit.ts
Files modified:  leave-requests.ts
Files deleted:   (none)

Blast radius:    TASK-013's queue query and TASK-015's audit report both
                 read leave_requests/audit_log — schema unchanged, no
                 breaking impact
God nodes touched: none

"Waiting for approval. Reply /apply to implement, or give feedback to revise the plan."

3 — /apply (only after you approve)

APPLY COMPLETE
──────────────
Created:   route.ts, audit.ts
Modified:  leave-requests.ts
Skipped:   (none)

"Ready to /validate. Type /validate to check against acceptance criteria."

4 — /validate

[x] AC1: approving decrements balance, sets status=approved, writes audit_log — PASS
[x] AC2: rejecting requires a reason, no balance change, writes audit_log — PASS
[ ] AC3: acting on a non-direct-report's request returns 403 — FAIL
    (filter was applied after the row was already fetched, not in the query)

[BLOCKER] Move the manager_id filter into the query itself, per the arch
          doc's security note — fixed
[BACKLOG] Add a rate limit on repeated decision attempts — logged to knowledge/retros/

VALIDATE COMPLETE
─────────────────
Criteria passed:  3/3 (after fix)
"Task complete. Ready for the next /evaluate."

5 — /code-review (not an EPAV phase, but the recommended close)

## Repo Context
- Stack: Next.js 16, TypeScript, Supabase
- Conventions: error format from AGENTS.md; soft-delete only (no hard-delete)

```json
{
  "blocked": false,
  "overall_severity": "low",
  "summary": "TASK-014 implementation is correct post-fix; one minor logging note.",
  "findings": [
    { "id": "CR-001", "severity": "low", "category": "maintainability",
      "file": "src/lib/audit.ts", "line": 18,
      "title": "Audit log write not wrapped in the same transaction as the decision",
      "description": "A crash between the two writes could leave a decision without an audit row.",
      "suggestion": "Wrap the balance update and audit_log insert in one DB transaction." }
  ]
}
```

blocked: false and nothing critical — clear to close the task out. If a critical finding had come back, /code-review would block the task the same way an unresolved [BLOCKER] in /validate does.

Closing Out: /commit and /create-pr

Two more skills round out the loop, grouped by nexus's own docs under "Git" rather than EPAV or Reviewers — they turn a validated, reviewed task into something on its way to merge.

/evaluate TASK-014 → /plan → /apply → /validate → /code-review → /commit → /create-pr

Self-Check

• I can name what each of the four EPAV skills does and where it stops.
• I understand that /plan never proceeds to code without an explicit approval.
• I can trace how the Dev Tasks CSV becomes /evaluate's context without retyping it, and I know load_task is the MCP tool doing that behind the scenes.
• I know what happens when /apply discovers out-of-scope work mid-task.
• I know the difference between [BLOCKER], [FIX NOW], and [BACKLOG] in /validate's output.
• I can explain why /code-review isn't one of the four EPAV phases but is still part of the daily loop, and what /commit and /create-pr add after it.