@su-record/vibe 3.2.64 → 4.0.0

package/skills/vibe.run/internal/exec-plan/orchestrator.md

@@ -1,72 +0,0 @@
----
-name: exec-plan-orchestrator
-type: orchestrator
-agents: [decomposer, dependency-mapper, estimator, validator]
----
-
-# Exec-Plan Orchestrator
-
-> 구조·섹션·네이밍은 vibe/rules/orchestrator-contract.md (SSOT) 를 따른다.
-
-## Workflow
-
-### Phase 1: Decompose
-- **Agent**: decomposer
-- **Input**: SPEC document (phases, requirements, acceptance criteria)
-- **Output**: Flat task list `[{taskId, title, phase, files[], description}]`
-- **Parallel**: no — sequential read of SPEC structure
-
-### Phase 2: Map Dependencies
-- **Agent**: dependency-mapper
-- **Input**: Task list from Phase 1
-- **Output**: DAG as adjacency list `{taskId: [dependsOn[]]}` + critical path
-- **Parallel**: no — requires complete task list to resolve cross-task deps
-
-### Phase 3: Estimate
-- **Agent**: estimator
-- **Input**: Task list + DAG from Phases 1–2
-- **Output**: Per-task complexity score, parallelization opportunities, estimated effort tiers (S/M/L)
-- **Parallel**: yes — each task scored independently
-
-### Phase 4: Validate
-- **Agent**: validator
-- **Input**: Task list + SPEC requirements + acceptance criteria
-- **Output**: Coverage report — uncovered requirements flagged, missing tasks identified
-- **Parallel**: no — cross-references full SPEC against task list
-
-### Phase 5: Output Plan
-- **Agent**: orchestrator (self)
-- **Input**: All outputs from Phases 1–4
-- **Output**: Execution plan with DAG visualization, effort summary, parallelization batches
-- **Parallel**: no
-
-## DAG (Dependency Graph)
-
-```mermaid
-graph TD
-    A[Phase 1: Decomposer] --> B[Phase 2: Dependency-Mapper]
-    A --> D[Phase 4: Validator]
-    B --> C[Phase 3: Estimator\nparallel per task]
-    C --> E[Phase 5: Output Plan]
-    D --> E
-```
-
-## Error Handling
-
-| Phase | Failure Mode | Strategy |
-|-------|-------------|----------|
-| Phase 1 | SPEC missing or malformed | Escalate — cannot proceed without SPEC |
-| Phase 1 | SPEC has no phases defined | Treat entire SPEC as single phase, continue |
-| Phase 2 | Circular dependency detected | Flag cycle, escalate to user for resolution |
-| Phase 2 | Isolated task (no deps, no dependents) | Include as standalone, note in plan |
-| Phase 3 | Estimator cannot classify complexity | Default to M (medium), flag for manual review |
-| Phase 4 | Uncovered requirements found | Add placeholder tasks, mark as `needs-spec-clarification` |
-| Phase 5 | DAG too large to render (>20 nodes) | Render phase-level DAG only, link to task list |
-
-## Scalability Modes
-
-| Mode | When | Agents Used |
-|------|------|-------------|
-| Full | Normal operation | decomposer + dependency-mapper + estimator + validator |
-| Reduced | Small SPEC (<5 tasks) | decomposer + dependency-mapper only |
-| Single | Quick task list | decomposer only — flat list without DAG or estimates |

package/skills/vibe.run/internal/exec-plan/rubrics/complexity-scoring.md

@@ -1,75 +0,0 @@
-# Complexity Scoring Rubric
-
-Use this rubric to decide whether a task needs an ExecPlan and how to decompose it.
-
-## Scoring Dimensions
-
-Score each dimension 1–3. Total determines the approach.
-
-### Dimension 1: File Scope
-
-| Score | Criteria |
-|-------|----------|
-| 1 | 1–2 files touched |
-| 2 | 3–5 files touched |
-| 3 | 6+ files, or new module created |
-
-### Dimension 2: Dependency Depth
-
-| Score | Criteria |
-|-------|----------|
-| 1 | No external deps; isolated change |
-| 2 | 1–2 existing modules depended on |
-| 3 | Cross-layer dependencies; DB schema; API contract changes |
-
-### Dimension 3: Ambiguity
-
-| Score | Criteria |
-|-------|----------|
-| 1 | Requirement is explicit; no design decisions needed |
-| 2 | 1–2 decision points that need resolution before coding |
-| 3 | Architecture-level decisions; unknown patterns; research needed |
-
-### Dimension 4: Test Surface
-
-| Score | Criteria |
-|-------|----------|
-| 1 | Existing test file; trivial assertion additions |
-| 2 | New test file needed; mocking required |
-| 3 | Integration tests; DB fixtures; snapshot regeneration |
-
-### Dimension 5: Session Risk
-
-| Score | Criteria |
-|-------|----------|
-| 1 | Fits in one session; easy to resume |
-| 2 | May span sessions; partial state is safe |
-| 3 | Long-running; partial state is dangerous; handoff required |
-
----
-
-## Decision Matrix
-
-| Total Score | Approach |
-|-------------|----------|
-| 5–7 | Plan Mode (in-head plan, no file needed) |
-| 8–10 | Light ExecPlan (phases only, no inline patterns) |
-| 11–13 | Full ExecPlan (all fields, inline patterns, phase gates) |
-| 14–15 | ExecPlan + parallel research before starting |
-
----
-
-## Decomposition Rules
-
-When total ≥ 11, decompose into phases:
-
-1. **One phase = one deployable unit** — each phase leaves the codebase in a working state
-2. **Max 3 scenarios per phase** — more means the phase is too large; split it
-3. **Phase gate before next phase** — build + tests must pass at each boundary
-4. **No implicit dependencies between phases** — phase 2 must not assume phase 1 code style; document patterns inline
-
-## Anti-patterns
-
-- Scoring 1 on all dimensions then creating an ExecPlan → overhead without benefit
-- Scoring 3 on ambiguity without resolving decisions first → plan will fail
-- Skipping phase gates to go faster → regressions compound

package/skills/vibe.run/internal/exec-plan/templates/plan.md

@@ -1,147 +0,0 @@
-# ExecPlan: {{FEATURE_NAME}}
-
-## Meta
-
-| Field | Value |
-|-------|-------|
-| SPEC | `.vibe/specs/{{FEATURE_NAME}}.md` |
-| Feature | `.vibe/features/{{FEATURE_NAME}}.feature` |
-| Generated | {{GENERATED_DATE}} |
-| Phases | {{PHASE_COUNT}} |
-| Scenarios | {{SCENARIO_COUNT}} |
-| Estimated effort | {{EFFORT_ESTIMATE}} |
-
----
-
-## Pre-flight Checks
-
-Run these before starting any phase. All must pass.
-
-- [ ] `npm run build` — clean build
-- [ ] `npx vitest run` — baseline tests pass ({{BASELINE_TEST_COUNT}} tests)
-- [ ] Required files exist:
-  - `{{REQUIRED_FILE_1}}`
-  - `{{REQUIRED_FILE_2}}`
-- [ ] Dependencies installed: `{{DEPENDENCY_CHECK_COMMAND}}`
-
----
-
-## Phase 1: {{PHASE_1_NAME}}
-
-### Environment
-
-| Item | Detail |
-|------|--------|
-| Files to modify | `{{PHASE_1_MODIFY_FILES}}` |
-| Files to create | `{{PHASE_1_CREATE_FILES}}` |
-| Dependencies | `{{PHASE_1_DEPENDENCIES}}` |
-| Pattern to follow | See inline snippet below |
-
-**Pattern (copy from codebase, do not paraphrase):**
-
-```typescript
-{{PHASE_1_PATTERN_SNIPPET}}
-```
-
-### Scenario 1.1: {{SCENARIO_1_1_NAME}}
-
-**REQ**: {{REQ_ID}}
-
-**Given**: {{GIVEN_CONDITION}}
-→ Setup:
-```typescript
-{{SETUP_CODE}}
-```
-
-**When**: {{ACTION}}
-→ Implement in `{{TARGET_FILE}}`, after line containing `{{ANCHOR_TEXT}}`:
-```typescript
-{{IMPLEMENTATION_SNIPPET}}
-```
-Imports needed: `{{IMPORTS_LIST}}`
-
-**Then**: {{EXPECTED_RESULT}}
-→ Verify:
-```bash
-{{VERIFY_COMMAND}}
-```
-Expected output: `{{EXPECTED_OUTPUT}}`
-Fallback if fails: {{FALLBACK_INSTRUCTION}}
-
----
-
-### Scenario 1.2: {{SCENARIO_1_2_NAME}}
-
-**Given**: {{GIVEN_CONDITION}}
-→ Setup: {{SETUP_INSTRUCTION}}
-
-**When**: {{ACTION}}
-→ Implement: {{IMPLEMENTATION_INSTRUCTION}}
-
-**Then**: {{EXPECTED_RESULT}}
-→ Verify: `{{VERIFY_COMMAND}}`
-
----
-
-### Phase 1 Gate
-
-- [ ] `npm run build` — no type errors
-- [ ] `npx vitest run {{PHASE_1_TEST_FILES}}` — all pass
-- [ ] `npx tsc --noEmit` — clean
-
----
-
-## Phase 2: {{PHASE_2_NAME}}
-
-### Environment
-
-| Item | Detail |
-|------|--------|
-| Files to modify | `{{PHASE_2_MODIFY_FILES}}` |
-| Files to create | `{{PHASE_2_CREATE_FILES}}` |
-| Dependencies | `{{PHASE_2_DEPENDENCIES}}` |
-
-### Scenario 2.1: {{SCENARIO_2_1_NAME}}
-
-**Given**: {{GIVEN_CONDITION}}
-→ Setup: {{SETUP_INSTRUCTION}}
-
-**When**: {{ACTION}}
-→ Implement: {{IMPLEMENTATION_INSTRUCTION}}
-
-**Then**: {{EXPECTED_RESULT}}
-→ Verify: `{{VERIFY_COMMAND}}`
-
----
-
-### Phase 2 Gate
-
-- [ ] `npm run build`
-- [ ] `npx vitest run {{PHASE_2_TEST_FILES}}`
-- [ ] `npx tsc --noEmit`
-
----
-
-## Completion Criteria
-
-- [ ] All scenarios passing
-- [ ] Coverage: ≥ {{COVERAGE_THRESHOLD}}%
-- [ ] No regressions in existing tests
-- [ ] `npm run build` exits 0
-- [ ] RTM generated: `generateTraceabilityMatrix("{{FEATURE_NAME}}")`
-
----
-
-## Handoff (if incomplete)
-
-Save state before ending session:
-
-```
-save_memory("execplan-{{FEATURE_NAME}}", {
-  "last_completed": "Phase X, Scenario Y.Z",
-  "next_step": "{{NEXT_STEP_DESCRIPTION}}",
-  "blockers": "{{BLOCKERS_IF_ANY}}"
-})
-```
-
-Resume: `/vibe.continue` → load this file.

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

@@ -1,178 +0,0 @@
-# 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/automation-level.md

@@ -1,51 +0,0 @@
-# Automation Level — vibe.run 자율성 축
-
-> vibe.run SKILL.md 에서 `automationLevel` 동작이 필요할 때 로드한다.
->
-> **SSOT는 `vibe/rules/loop-contract.md`다.** 이 파일은 그 계약이 vibe.run 안에서
-> 구체적으로 무엇을 바꾸는지만 설명한다. 값·별칭·exit 조건을 여기서 새로 정의하지 않는다.
-
-## 값은 둘뿐이다
-
-| `automationLevel` | 사람 개입 |
-|---|---|
-| `confirm` (기본) | SPEC 승인 1회 + stuck 시 질문 |
-| `autonomous` | SPEC 승인·stuck 질문 모두 skip |
-
-> ⚠️ **stuck 은 두 값 모두에서 루프를 종료한다.** `autonomous` 가 바꾸는 것은 "사람에게 묻는지" 뿐이며, stuck 난 루프를 더 돌린다는 뜻이 아니다 (2회 연속 동일 발견은 정의상 재시도가 무의미). 미달은 TODO 로 남기고 다음 독립 단위로 넘어가며, **완료로 기록하지 않는다.** SSOT: `vibe/rules/loop-contract.md` stuck 절.
-
-`.vibe/config.json` 에서 설정한다. 루프 자체(ANCHOR→ACT→JUDGE→RECORD)는 두 값에서
-**동일하게** 돌아간다 — automationLevel 은 루프의 유무가 아니라 **질문 여부**를 바꾼다.
-
-> ⛔ L0/L1/L4 같은 레벨 체계는 없다. 과거 이 문서가 5단계 레벨과 confirmation matrix 를
-> 정의했지만 loop-contract 에 그런 값은 존재하지 않았다 — 실행할 수 없는 스펙이었다.
-> `manual`/`guided`/`full-auto` 를 요구하는 지시를 만나면 위 두 값으로 환원한다.
-
-## `autonomous` 가 vibe.run 에서 바꾸는 것
-
-| 항목 | `confirm` | `autonomous` |
-|---|---|---|
-| stuck 처리 | **루프 종료** + 사용자에게 질문 | **루프 종료** + TODO 기록 후 다음 시나리오 (질문 없음) |
-| ACT 병렬화 | 순차 허용 | 서로 의존하지 않는 시나리오 병렬 |
-| 컨텍스트 85%+ | 경고 | 자동 저장 |
-| 외부 LLM (GPT/Antigravity) | 명시 요청 시 | 활성화돼 있으면 자동 상담 |
-| Race Review | 명시 요청 시 | 기본 활성 |
-
-**바뀌지 않는 것**: 시나리오 단위 구현→검증 원자성. `autonomous` 라도 여러 시나리오를
-묶어 빅뱅으로 만들지 않는다 (SSOT: SKILL.md "하네스-안전 증분").
-
-## 파괴적 작업은 자율성과 무관하다
-
-`autonomous` 는 **파일 수정·테스트 실행**의 확인을 없애는 것이고, 아래는 어느 값에서도
-사람 확인을 받는다:
-
-- push / release / 배포 / 버전 범프 — 루프의 권한 밖 (loop-contract "금지")
-- 되돌리기 어려운 삭제, 외부 발송
-
-## Deprecated 별칭
-
-매핑 SSOT 는 `vibe/rules/loop-contract.md` 의 Deprecated 별칭 표다.
-**여기에 요약도 두지 않는다** — 별칭을 만나면 그 표를 읽어서 환원한다.
-
-> WHY: 이 자리에 요약을 두었더니 `quick` 의 "최소 JUDGE" 가 빠지고 `ralplan` 이 아예
-> 누락돼 SSOT 와 어긋났다. 부분 요약은 전체 사본보다 드리프트를 알아채기 어렵다.

package/skills/vibe.run/references/brand-assets.md

@@ -1,59 +0,0 @@
-# Brand Assets Generation — Full Reference
-
-> Loaded by vibe.run SKILL.md when starting a new project with brand context in SPEC.
-
-## Brand Assets Generation (Optional)
-
-When starting a **new project** with brand context in SPEC, auto-generate app icons and favicons:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-BRAND ASSETS GENERATION
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-[Check] Brand assets exist? → Skip if favicon.ico exists
-[Check] Antigravity API configured? → Required for image generation
-[Check] SPEC has brand context? → Extract app name, colors, style
-
-[Generate] Creating app icon with Antigravity Image API...
-  - Prompt: "App icon for [AppName], [style], [color]..."
-  - Generated: 512x512 master icon
-
-[Resize] Creating platform variants...
-  favicon.ico (16/32/48)
-  favicon-16x16.png
-  favicon-32x32.png
-  apple-touch-icon.png (180x180)
-  android-chrome-192x192.png
-  android-chrome-512x512.png
-  site.webmanifest
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Brand assets generated in public/
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## SPEC Brand Context Example
-
-```xml
-<context>
-Brand:
-  - App Name: MyApp
-  - Primary Color: #2F6BFF
-  - Style: Modern, minimalist, flat design
-  - Icon Concept: Abstract geometric shape
-</context>
-```
-
-## Trigger Conditions
-
-- First `/vibe.run` execution (no existing icons)
-- SPEC contains brand/design context
-- Antigravity API key configured (`vibe antigravity key <key>`)
-
-## Manual Generation
-
-```bash
-# [LLM_SCRIPT] = {{VIBE_PATH}}/hooks/scripts/llm-orchestrate.js
-node "[LLM_SCRIPT]" antigravity image "App icon for MyApp, primary color #2F6BFF, square format 1:1, simple recognizable design, works well at small sizes, no text or letters, solid or gradient background, modern minimalist" --output "./public/app-icon.png"
-```

package/skills/vibe.run/references/coverage-loop.md

@@ -1,94 +0,0 @@
-# Coverage Loop — RTM 기반 완료 판정
-
-> vibe.run SKILL.md 에서 RTM/커버리지 검증이 필요할 때 로드한다.
->
-> **루프 시맨틱(ANCHOR/ACT/JUDGE/RECORD/stuck/max_iterations)의 SSOT 는
-> `vibe/rules/loop-contract.md` 다.** 이 파일은 vibe.run 의 JUDGE 를 RTM 커버리지로
-> 구체화하는 방법만 다룬다.
-
-## 문제와 해법
-
-모델은 구현이 부분적일 때도 "완료"라고 보고한다. 그래서 완료 판정을 자기보고가 아니라
-**RTM 커버리지 수치**에 맡긴다 — JUDGE 기준은 `coveragePercent === 100`.
-
-> ⚠️ **"루프 종료" ≠ "feature 완료".** stuck·max_iterations 로 루프가 끝나도 커버리지가
-> 100% 미만이면 **미달로 기록**한다. 미달을 완료로 표기하는 것은 이 게이트의 존재 이유를
-> 무효화한다 — 그게 바로 막으려던 자기보고다.
-
-```
-모든 phase 종료
-   ↓
-   (stuck 판정은 커버리지 수치가 아니라 **발견 해시**로 한다 — 커버리지가 그대로여도
-    남은 항목이 달라졌으면 진전이 있는 것이고, 반대로 커버리지가 올라도 같은 발견이
-    반복되면 막힌 것이다. SSOT: loop-contract stuck 절)
-   ↓
-RTM 생성 → coveragePercent, uncoveredRequirements[]
-   ↓
-100%? ──YES──→ 완료 (최종 RTM 보고)
-   │
-   NO
-   ↓
-uncoveredRequirements 를 구현 → RTM 재생성
-   ↓
-stuck? (연속 2회 동일 발견(discover/findings) 해시 — loop-ledger.js check-stuck)
-   ├─ confirm    → 루프 종료 + 사용자 질문 (값 제공 / sub-100 승인 / 중단)
-   └─ autonomous → 루프 종료 + 미달 커버리지를 TODO 로 기록 (질문 없음)
-   ↓
-max_iterations(기본 10) 도달 → 잔여 인박스 이월
-```
-
-## RTM 생성
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/spec/index.js').then(t => { const r = t.generateTraceabilityMatrix('{feature-name}', {projectPath: process.cwd()}); console.log(JSON.stringify(r, null, 2)); })"
-```
-
-`generateTraceabilityMatrix` 는 동기 함수다 — 반환값에 `.then()` 을 쓰지 않는다.
-
-> SPEC 기본 경로는 `.vibe/specs/<feature>.md` (레거시 프로젝트는 `.claude/vibe/specs/`
-> → `.claude/specs/` 로 폴백).
-> **`status === 'empty'` 는 게이트 실패/판정불가로 취급한다 — 절대 100% 통과로 읽지 않는다.**
-
-## RTM 지표
-
-| 지표 | 의미 |
-|---|---|
-| `totalRequirements` | SPEC 의 REQ-* 총 개수 |
-| `specCovered` | SPEC 매핑이 있는 요구사항 |
-| `featureCovered` | Feature 시나리오가 있는 요구사항 |
-| `testCovered` | 테스트 파일이 있는 요구사항 |
-| `coveragePercent` | 전체 커버리지 |
-| `uncoveredRequirements` | 누락된 REQ-* 목록 |
-
-## 루프 규칙
-
-| 규칙 | 내용 |
-|---|---|
-| 범위 축소 금지 | "간단히 구현했다"/"기본 버전" 으로 끝내지 않는다 — 요청 전체를 구현한다 |
-| 갭 목록은 RTM 이 준다 | `uncoveredRequirements` 배열을 쓴다. 수동 대조하지 않는다 |
-| 반복 표시 | 진행 상황에 회전 번호를 표시한다 |
-| 수확 체감 | 3회전 이후는 핵심 요구사항(REQ-*-001~003) 우선, P2/P3 는 계속하되 후순위 |
-
-## 금지 표현
-
-커버리지 미달을 완료로 포장하는 문장들 — 발견하면 그 자리에서 구현으로 대체한다.
-
-| 쓰지 않는다 | 대신 |
-|---|---|
-| "기본 버전을 구현했다" | 전체 버전을 구현한다 |
-| "단순화된 접근이다" | 명세대로 구현한다 |
-| "X 는 나중에 추가할 수 있다" | X 를 지금 추가한다 |
-| "데모 목적으로는" | 프로덕션 수준으로 구현한다 |
-| "핵심 기능은 완료됐다" | 모든 기능이 완료돼야 한다 |
-
-## 출력 형식
-
-회전마다 아래를 보고한다 (RTM 원본을 그대로 덤프하지 않는다):
-
-```
-Coverage [회전 N]: {coveragePercent}%  (spec {specCovered}/{total} · feature {featureCovered}/{total} · test {testCovered}/{total})
-Uncovered: REQ-login-004, REQ-login-007
-→ 미달 — uncovered 구현 진행
-```
-
-100% 도달 시 build/test 결과를 함께 붙이고 RTM 저장 경로를 보고한다.