@su-record/vibe 3.2.6 → 3.2.8

package/skills/vibe.run/references/arch-guard.md

@@ -0,0 +1,178 @@
+# Arch Guard — Architecture Boundary Test Generator
+
+> vibe.run 내부 구현. **아키텍처 경계 테스트를 생성/검증할 때만 로드한다** — 매 run 마다 필요하지 않다.
+
+# Arch Guard — Architecture Boundary Test Generator
+
+> **Principle**: "Mechanical enforcement over documentation." If a rule exists only in docs, it will be violated. Turn architecture constraints into failing tests.
+
+## When to Use
+
+| Scenario | Signal |
+|----------|--------|
+| `vibe init` / `vibe update` | Auto-generate for detected stack |
+| New layer/module added | Boundaries need enforcement |
+| Architecture violation found in review | Prevent recurrence with test |
+| "Services should not import UI" type rules | Turn into automated check |
+
+## Core Flow
+
+```
+DETECT → INFER → GENERATE → VERIFY
+```
+
+### Step 1: DETECT — Identify Project Architecture
+
+Analyze the project to determine its layer structure:
+
+```
+Parallel exploration:
+- Agent 1: Scan directory structure (src/, app/, lib/, etc.)
+- Agent 2: Read existing architecture docs (CLAUDE.md, README, ADR)
+- Agent 3: Analyze import graph (which files import what)
+```
+
+**Common patterns to detect:**
+
+| Pattern | Layers | Typical Stacks |
+|---------|--------|----------------|
+| MVC | Controller → Service → Model | Rails, NestJS, Spring |
+| Clean Architecture | UI → Application → Domain → Infrastructure | General |
+| Feature-based | Feature A ↛ Feature B internals | Next.js, React |
+| Hexagonal | Adapters → Ports → Domain | DDD projects |
+| Component hierarchy | Page → Feature → Shared → UI Primitives | Frontend |
+
+### Step 2: INFER — Define Boundary Rules
+
+From detected structure, generate rules:
+
+```typescript
+// Rule format
+interface ArchRule {
+  name: string;           // "service-no-ui-import"
+  from: string;           // Glob pattern: "src/services/**"
+  cannotImport: string[]; // ["src/components/**", "src/pages/**"]
+  canImport: string[];    // ["src/models/**", "src/utils/**"]
+  reason: string;         // "Services must be UI-agnostic"
+}
+```
+
+**Default rules by stack:**
+
+| Stack | Rule |
+|-------|------|
+| Next.js / React | `components/` cannot import from `pages/` or `app/` |
+| Next.js / React | `lib/` cannot import from `components/` |
+| NestJS | `*.service.ts` cannot import from `*.controller.ts` |
+| NestJS | `*.module.ts` is the only valid cross-boundary import |
+| General TS | `src/domain/` cannot import from `src/infra/` |
+| General TS | No circular dependencies between top-level dirs |
+| Python Django | `models.py` cannot import from `views.py` |
+| Python FastAPI | `schemas/` cannot import from `routers/` |
+
+### Step 3: GENERATE — Create Test File
+
+Output: `tests/arch-guard.test.ts` (or equivalent for stack)
+
+```typescript
+/**
+ * Architecture Boundary Tests
+ * Generated by arch-guard skill
+ *
+ * These tests enforce architectural constraints mechanically.
+ * If a test fails, it means an import violates the intended architecture.
+ */
+import { describe, it, expect } from 'vitest';
+import fs from 'fs';
+import path from 'path';
+
+// Helper: extract imports from a file
+function extractImports(filePath: string): string[] {
+  const content = fs.readFileSync(filePath, 'utf-8');
+  const importRegex = /(?:import|require)\s*\(?['"]([^'"]+)['"]\)?/g;
+  const imports: string[] = [];
+  let match;
+  while ((match = importRegex.exec(content)) !== null) {
+    imports.push(match[1]);
+  }
+  return imports;
+}
+
+// Helper: resolve relative import to absolute path
+function resolveImport(fromFile: string, importPath: string): string {
+  if (importPath.startsWith('.')) {
+    return path.resolve(path.dirname(fromFile), importPath);
+  }
+  return importPath; // external package
+}
+
+// Helper: glob files matching pattern
+function globFiles(pattern: string, baseDir: string): string[] {
+  // Use fast-glob or manual recursive scan
+  // Implementation depends on available dependencies
+}
+
+describe('Architecture Boundaries', () => {
+  // GENERATED RULES GO HERE
+  // Each rule becomes a test case:
+
+  it('services cannot import UI components', () => {
+    const serviceFiles = globFiles('src/services/**/*.ts', process.cwd());
+    const violations: string[] = [];
+
+    for (const file of serviceFiles) {
+      const imports = extractImports(file);
+      for (const imp of imports) {
+        const resolved = resolveImport(file, imp);
+        if (resolved.includes('/components/') || resolved.includes('/pages/')) {
+          violations.push(`${file} imports ${imp}`);
+        }
+      }
+    }
+
+    expect(violations).toEqual([]);
+  });
+});
+```
+
+### Step 4: VERIFY — Run and Fix
+
+1. Run the generated tests: `npx vitest run tests/arch-guard.test.ts`
+2. If violations found:
+   - Report each violation with file:line
+   - Suggest fix (move shared code to appropriate layer)
+   - Do NOT auto-fix — violations need human review
+
+## Output Files
+
+| File | Purpose |
+|------|---------|
+| `tests/arch-guard.test.ts` | Executable boundary tests |
+| `.vibe/arch-rules.json` | Machine-readable rules (for CI) |
+
+## Customization
+
+Users can add custom rules to `.vibe/arch-rules.json`:
+
+```json
+{
+  "rules": [
+    {
+      "name": "no-direct-db-in-handlers",
+      "from": "src/handlers/**",
+      "cannotImport": ["src/db/**"],
+      "reason": "Handlers must use services, not direct DB access"
+    }
+  ]
+}
+```
+
+The test generator reads this file and adds custom rules to the test suite.
+
+## Integration
+
+- `vibe init` → auto-detect and generate initial arch-guard tests
+- `vibe update` → refresh rules if directory structure changed
+- Explicit pre-commit JUDGE → run arch-guard tests before commit; a lifecycle hook may accelerate this check
+- `vibe.review` (skill) → code-reviewer (focus: architecture) checks against arch-rules.json
+

package/skills/vibe.run/references/e2e-and-autofix.md

@@ -0,0 +1,40 @@
+# vibe.run — E2E Closed Loop & Auto-Fix
+
+> vibe.run SKILL.md Automated Verification 에서 참조. UI 시나리오 E2E 루프와 실패 시 자동 수정 절차.
+
+### E2E Closed Loop (UI Scenarios)
+
+**UI 시나리오가 포함된 Feature일 때 자동 활성화.**
+
+Browser Tool Priority:
+
+| Priority | Tool | 용도 |
+|----------|------|------|
+| 1st | Agent Browser (접근성 트리) | AI 직접 조작, 최소 토큰 |
+| 2nd | Playwright Test Runner | 테스트 코드 실행, pass/fail 반환 |
+| 3rd | Playwright MCP (DOM) | 최후 수단, 토큰 비효율 |
+
+**활성화 조건:** Feature 파일에 UI 관련 시나리오 존재 + `.vibe/e2e/config.json`의 `closedLoop.enabled: true` (기본값) + dev server가 실행 중
+
+### Auto-Fix on Failure
+
+```
+Scenario verification failed
+      ↓ [Collect evidence]
+      ↓ [Root cause analysis]
+      ↓ [Read target file FULLY]
+      ↓ [Implement fix]
+      ↓ [Re-verify failed scenario only]
+      Repeat until pass (stuck 감지로 종료)
+```
+
+**Termination conditions (loop-contract JUDGE):**
+- PASS → 다음 scenario
+- stuck (같은 failure가 이전 라운드와 동일, `loop-ledger.js check-stuck`) → automationLevel confirm: 사용자 질문; autonomous: TODO + next scenario
+
+**Stakes 프로파일 (SSOT: `vibe/rules/loop-contract.md` Stakes 표):**
+- `demo`/`prototype` → max_iterations 1, 리뷰 1패스, **검증 스크립트 신규 생성 금지** — 검증은 기존 테스트 러너·브라우저 게이트만 사용한다. 새 verify_*.py / 검증 전용 스크립트 파일을 만들지 않는다.
+- JUDGE 검증 산출물 절제 (모든 stakes): 이번 feature 신규 검증 코드 바이트 합이 신규 구현 코드 바이트 합을 초과하면 (`git diff --numstat` 기준) P2 경고를 run-ledger 에 기록한다. advisory — 게이트 통과 여부는 불변.
+
+---
+

package/skills/vibe.run/references/exec-plan.md

@@ -0,0 +1,145 @@
+# ExecPlan — Self-Contained Execution Plan Generator
+
+> vibe.run 내부 구현. **Step 1-0 (execution packet 컴파일) 에서만 로드한다.**
+
+# ExecPlan — Self-Contained Execution Plan Generator
+
+> **Principle**: "If the agent can't see it, it doesn't exist." Every decision, file path, pattern, and verification step must be explicit in the plan — no implicit knowledge allowed.
+
+## When to Use
+
+Before `/vibe.run`, generate an ExecPlan to make execution deterministic:
+
+| Scenario | Signal |
+|----------|--------|
+| Complex SPEC (3+ phases) | Agent needs long autonomous execution |
+| Team/multi-agent execution | Multiple agents need shared understanding |
+| Context window pressure | Plan survives `/new` session handoff |
+| Unfamiliar codebase | Agent can't rely on implicit knowledge |
+
+## Core Flow
+
+```
+SPEC + Feature → ANALYZE → RESOLVE → GENERATE → PERSIST
+```
+
+### Step 1: ANALYZE — Extract Everything Needed
+
+Read the SPEC and Feature files, then extract:
+
+```
+For each Phase → For each Scenario:
+  1. Requirements (REQ-* IDs)
+  2. Given/When/Then conditions
+  3. Affected files (MUST exist — verify with Glob)
+  4. Dependencies (imports, packages)
+  5. Existing patterns to follow (read actual code, don't assume)
+```
+
+**Parallel exploration** (3+ agents):
+- Agent 1: Map all file paths mentioned/implied in SPEC → verify they exist
+- Agent 2: For each affected file, extract current interfaces/types/exports
+- Agent 3: Find existing patterns (naming conventions, error handling, test structure)
+
+### Step 2: RESOLVE — Eliminate All Ambiguity
+
+For every decision point in the SPEC, resolve it NOW:
+
+| Ambiguity | Resolution |
+|-----------|------------|
+| "Add validation" | → Which fields? What rules? What error messages? |
+| "Handle errors" | → Which error codes? What response format? |
+| "Follow existing pattern" | → Copy the ACTUAL pattern code into the plan |
+| "Update tests" | → Which test file? What test framework? What assertions? |
+
+**Rule**: If you'd need to "figure it out later", resolve it now. The plan must be executable by an agent with ZERO codebase knowledge.
+
+### Step 3: GENERATE — Write the ExecPlan
+
+Output format: `.vibe/specs/{feature-name}-execplan.md`
+
+```markdown
+# ExecPlan: {feature-name}
+
+## Meta
+- SPEC: .vibe/specs/{name}.md
+- Feature: .vibe/features/{name}.feature
+- Generated: {timestamp}
+- Phases: {count}
+- Scenarios: {count}
+
+## Pre-flight Checks
+- [ ] `npm run build` passes
+- [ ] `npx vitest run` passes (baseline)
+- [ ] Required files exist: {list}
+
+## Phase {N}: {phase-name}
+
+### Environment
+- Files to modify: {exact paths}
+- Files to create: {exact paths}
+- Dependencies to add: {package@version}
+- Patterns to follow: (inline code snippets from codebase)
+
+### Scenario {N}.{M}: {scenario-name}
+
+**Given**: {precondition}
+→ Setup: {exact code/commands to establish precondition}
+
+**When**: {action}
+→ Implement: {step-by-step implementation instructions}
+  - File: {path}
+  - Location: after line containing `{anchor text}`
+  - Code: (inline snippet)
+  - Imports needed: {list}
+
+**Then**: {expected result}
+→ Verify:
+  - Command: `{test command}`
+  - Expected: {output/behavior}
+  - Fallback: {what to do if verification fails}
+
+### Phase {N} Gate
+- [ ] Build: `npm run build`
+- [ ] Tests: `npx vitest run {relevant-test-files}`
+- [ ] Type check: `npx tsc --noEmit`
+
+## Completion Criteria
+- Coverage threshold: ≥95%
+- All scenarios passing
+- No regressions in existing tests
+- RTM: `generateTraceabilityMatrix("{feature-name}")`
+```
+
+### Step 4: PERSIST — Save and Link
+
+1. Save ExecPlan to `.vibe/specs/{feature-name}-execplan.md`
+2. Save session context: `save_memory("execplan-{feature}", {summary})`
+3. Output execution command:
+
+```
+Ready to execute:
+  /vibe.run "{feature-name}" ultrawork
+
+Or hand off to new session:
+  /vibe.continue
+  → Load: .vibe/specs/{feature-name}-execplan.md
+```
+
+## Quality Checks
+
+| Check | Criteria |
+|-------|----------|
+| No implicit knowledge | Every file path verified with Glob |
+| No "figure it out" | Every decision resolved with actual code |
+| Survives handoff | Plan readable without any prior context |
+| Inline patterns | Actual code snippets, not "follow existing pattern" |
+| Verification steps | Every scenario has a concrete verification command |
+
+## Anti-patterns
+
+- "See the existing implementation" → Copy the relevant code inline
+- "Follow the pattern in X" → Show the actual pattern
+- "Standard error handling" → Specify exact error codes and messages
+- "Update tests accordingly" → Name the test file, framework, and assertions
+

package/skills/vibe.run/references/guidelines-and-tools.md

@@ -0,0 +1,84 @@
+# vibe.run — Tools, Guidelines & Retrospective
+
+> vibe.run SKILL.md 에서 참조. 시맨틱 분석·메모리 도구, 코딩 가이드라인, rules 참조표, TRUST 5, 자동 회고 템플릿.
+
+## Core Tools (Semantic Analysis & Memory)
+
+```bash
+# All tools via:
+node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/index.js').then(t => t.TOOL_NAME({...args}).then(r => console.log(r.content[0].text)))"
+```
+
+| Tool | Purpose |
+|------|---------|
+| `analyzeComplexity` | Analyze code complexity |
+| `validateCodeQuality` | Validate code quality |
+| `saveMemory` | Save important decisions |
+| `recallMemory` | Recall saved memory |
+| `listMemories` | List all memories |
+
+Session management: explicitly load the latest checkpoint at start and persist a
+checkpoint before context reset. Lifecycle hooks may accelerate those steps when
+available, but completion never depends on them.
+
+---
+
+## Coding Guidelines (Mandatory)
+
+> Read `references/race-review.md` for full type safety guidelines, language-specific examples, and the type-violation detection/escalation table.
+
+**TypeScript — core rule:**
+```typescript
+// BAD
+function process(data: any): any { return data.foo; }
+
+// GOOD
+function process(data: unknown): Result {
+  if (isValidData(data)) return data.foo;
+  throw new Error('Invalid');
+}
+```
+
+No `any` / `as any` / `@ts-ignore` — fix at root. Explicit return types on all functions.
+
+**Detection outcome:** Run the project's explicit static type check and treat a
+non-zero exit as JUDGE failure. Harness diagnostics or auto-commit hooks may
+surface the same violations earlier, but they do not replace the command result.
+
+---
+
+## Rules Reference
+
+- `core/development-philosophy.md` — Surgical precision, modify only requested scope
+- `core/quick-start.md` — Korean, DRY, SRP, YAGNI
+- `standards/complexity-metrics.md` — Functions ≤50 lines, nesting ≤3 levels
+- `quality/checklist.md` — Code quality checklist
+- Language guide: `~/.claude/vibe/languages/{stack}.md`
+
+---
+
+## TRUST 5 Principles
+
+| Principle | Description |
+|-----------|-------------|
+| **T**est-first | Write tests first |
+| **R**eadable | Clear code |
+| **U**nified | Consistent style |
+| **S**ecured | Consider security |
+| **T**rackable | Logging, monitoring |
+
+---
+
+## Auto-Retrospective (Post-Implementation)
+
+After ALL phases complete, save to `.vibe/retros/{feature-name}.md`:
+
+```markdown
+## Retrospective: {feature-name}
+### What Worked / What Didn't / Key Decisions / Lessons Learned
+```
+
+Keep under 20 lines. Record key lessons in the project progress/checkpoint artifact and update `claude-progress.txt`.
+
+---
+

package/skills/vibe.run/references/parallel-agents.md

@@ -2,52 +2,36 @@
 
 > Loaded by vibe.run SKILL.md when parallel execution patterns, parallel subagent groups, or model selection details are needed.
 
-## Model Orchestration (Intelligent Routing)
+## Model Orchestration — Inherit by Default
 
-Automatically select optimal model based on **task complexity analysis**.
+**Do not pass a `model` parameter.** Subagents inherit the session model.
 
-### Complexity-Based Model Selection
+The complexity→tier routing that used to live here (Haiku for simple work, Sonnet
+for standard, Opus for architecture) is **retired**. It was written when the
+default session model was weak enough that routing *up* was the win. With a strong
+default, a hardcoded tier can only route *down* — and a downgraded subagent's
+misses land back on the session model to find and undo. That costs more than the
+tokens it saves.
 
-| Complexity Score | Model | When to Use |
-|------------------|-------|-------------|
-| 0-7 (Low) | **Haiku** | Simple fixes, searches, single file changes |
-| 8-19 (Medium) | **Sonnet** | Standard features, 3-5 files, integrations |
-| 20+ (High) | **Opus** | Architecture, security, multi-service, 6+ files |
+### The only exception
 
-### Complexity Signals
+| Agent | Tier | Why it overrides the session model |
+|-------|------|------------------------------------|
+| `architect` | `opus` | Design decisions are expensive to reverse — guarantee a floor even when the session runs lower |
 
-| Signal | Score |
-|--------|-------|
-| Architecture change | +15 |
-| Security implication | +12 |
-| Multi-service | +8 |
-| Refactoring | +12 |
-| 6+ files | +15 |
-| 3-5 files | +8 |
-| New feature | +5 |
-| Bug fix | -3 |
-| Documentation | -5 |
+Every other agent (`implementer`, `tester`, `e2e-tester`, `code-reviewer`,
+`security-reviewer`, `build-error-resolver`, UI/event agents) is `inherit`.
+SSOT: `CLAUDE_MODEL_MAPPING` in `src/cli/postinstall/constants.ts`.
 
-### Agent × Model Selection
+> Adding a new tier override requires an answer to: *"why must this run at this
+> tier regardless of what the session is running?"* "It's a simple task" is not
+> an answer — a strong model finishes simple tasks quickly at no quality cost.
 
-Tier-variant agents were consolidated — the model is a Task parameter, not a separate agent:
+### What still scales with complexity
 
-| Agent | Low | Medium | High |
-|-------|-------------|-----------------|-------------|
-| Explore (native) | `model: "haiku"` | `model: "sonnet"` | `model: "opus"` |
-| implementer | `model: "haiku"` | `model: "sonnet"` | `model: "opus"` |
-| architect | `model: "haiku"` | `model: "sonnet"` | `model: "opus"` |
-
-### Task Calls by Role
-
-| Task Type | Model | Task Parameter |
-|-----------|-------|----------------|
-| Simple search | Haiku | `model: "haiku"` |
-| Codebase exploration | Haiku/Sonnet | Auto-selected |
-| Core implementation | Sonnet | `model: "sonnet"` |
-| Test writing | Haiku | `model: "haiku"` |
-| Architecture decisions | Opus | Main session |
-| Final review | Opus | Main session |
+Complexity should change **how many agents you spawn and how deep they go**, not
+which model they run. See the Stakes table in `vibe/rules/loop-contract.md` — that
+is the SSOT for proportional execution.
 
 ## Mandatory Parallel Exploration (Phase Start)
 
@@ -59,11 +43,11 @@ Tier-variant agents were consolidated — the model is a Task parameter, not a s
 │                                                                 │
 │  Launch ALL of these in ONE message:                            │
 │                                                                 │
-│  Task(haiku) ─┬─→ "Analyze related files in <context>"          │
-│               │                                                 │
-│  Task(haiku) ─┼─→ "Check dependencies and imports"              │
-│               │                                                 │
-│  Task(haiku) ─┴─→ "Find existing patterns and conventions"      │
+│  Task ─┬─→ "Analyze related files in <context>"                 │
+│        │                                                        │
+│  Task ─┼─→ "Check dependencies and imports"                     │
+│        │                                                        │
+│  Task ─┴─→ "Find existing patterns and conventions"             │
 │                                                                 │
 │  [If GPT enabled] Bash: node "[LLM_SCRIPT]" gpt orchestrate-json "[question]"
 │  [If Antigravity enabled] Bash: node "[LLM_SCRIPT]" antigravity orchestrate-json "[question]"
@@ -71,7 +55,7 @@ Tier-variant agents were consolidated — the model is a Task parameter, not a s
                               │
                               ↓ (wait for all to complete)
 ┌─────────────────────────────────────────────────────────────────┐
-│  STEP 2: SYNTHESIZE (Opus)                                      │
+│  STEP 2: SYNTHESIZE                                      │
 │  - Review all exploration results                               │
 │  - Decide implementation approach                               │
 │  - Identify files to modify/create                              │
@@ -81,10 +65,10 @@ Tier-variant agents were consolidated — the model is a Task parameter, not a s
 ┌─────────────────────────────────────────────────────────────────┐
 │  STEP 3: IMPLEMENT + BACKGROUND AGENTS (PARALLEL)               │
 │                                                                 │
-│  Main Agent (sonnet):                                           │
+│  Main Agent:                                           │
 │  └─→ Execute current phase implementation                       │
 │                                                                 │
-│  Background Agents (haiku, run_in_background=true):             │
+│  Background Agents (run_in_background=true):             │
 │  ├─→ Task: "Prepare Phase N+1 - analyze required files"         │
 │  ├─→ Task: "Pre-generate test cases for current implementation" │
 │  └─→ Task: "Search for related types/interfaces needed"         │
@@ -97,7 +81,7 @@ Tier-variant agents were consolidated — the model is a Task parameter, not a s
 │  STEP 4: TEST + PHASE PIPELINING                                │
 │                                                                 │
 │  Current Phase:                                                 │
-│  └─→ Task(haiku): Write tests using pre-generated cases         │
+│  └─→ Task: Write tests using pre-generated cases                │
 │                                                                 │
 │  Next Phase Prep (from background results):                     │
 │  └─→ Already have file analysis, ready to start immediately     │
@@ -109,18 +93,18 @@ Tier-variant agents were consolidated — the model is a Task parameter, not a s
 **Correct — Single message with multiple parallel Tasks:**
 ```
 <message>
-  Task(haiku, "Analyze src/components/ for existing patterns")
-  Task(haiku, "Check package.json dependencies")
-  Task(haiku, "Find usage of similar features in codebase")
+  Task("Analyze src/components/ for existing patterns")
+  Task("Check package.json dependencies")
+  Task("Find usage of similar features in codebase")
 </message>
 → All 3 run simultaneously, ~3x faster
 ```
 
 **WRONG — Sequential calls (DO NOT DO THIS):**
 ```
-<message>Task(haiku, "Analyze...")</message>
-<message>Task(haiku, "Check...")</message>
-<message>Task(haiku, "Find...")</message>
+<message>Task("Analyze...")</message>
+<message>Task("Check...")</message>
+<message>Task("Find...")</message>
 → 3x slower, wastes time
 ```
 
@@ -141,27 +125,27 @@ No status polling is needed — the harness re-invokes you when each background
 ```
 Phase N Start
     │
-    ├─→ [PARALLEL] Task(haiku) × 3: Exploration
+    ├─→ [PARALLEL] Task × 3: Exploration
     │       - Related code analysis
     │       - Dependency check
     │       - Pattern discovery
     │
     ↓ (all complete)
     │
-    ├─→ Opus: Synthesize and decide
+    ├─→ Synthesize and decide
     │
     ├─→ [PARALLEL PIPELINE] ←── KEY SPEED OPTIMIZATION
     │       │
-    │       ├─→ Main: Task(sonnet) Implementation
+    │       ├─→ Main: Task Implementation
     │       │
     │       └─→ Background (run_in_background=true):
-    │               ├─→ Task(haiku): Phase N+1 file analysis
-    │               ├─→ Task(haiku): Test case preparation
-    │               └─→ Task(haiku): Type/interface lookup
+    │               ├─→ Task: Phase N+1 file analysis
+    │               ├─→ Task: Test case preparation
+    │               └─→ Task: Type/interface lookup
     │
     ↓ (main completes)
     │
-    ├─→ Task(haiku): Tests (uses pre-generated cases)
+    ├─→ Task: Tests (uses pre-generated cases)
     │
     ↓
 Phase N Complete