@su-record/vibe 3.2.64 → 4.0.1

package/skills/vibe.review/references/todo-board-template.md

@@ -1,59 +0,0 @@
-# TODO Board: {{PROJECT_OR_FEATURE_NAME}}
-
-**Updated**: {{DATE}}
-**Branch**: {{GIT_BRANCH}}
-**Total open**: {{TOTAL_OPEN}} | P1: {{P1_COUNT}} | P2: {{P2_COUNT}} | P3: {{P3_COUNT}}
-
----
-
-## P1 — Blocks Merge ({{P1_COUNT}} open)
-
-> All P1 items must be resolved before this branch can be merged.
-
-| ID | Title | File:Line | Assigned | Status |
-|----|-------|-----------|----------|--------|
-| P1-{{ID_1}} | {{TITLE_1}} | `{{FILE_1}}:{{LINE_1}}` | {{ASSIGNEE_1}} | {{STATUS_1}} |
-| P1-{{ID_2}} | {{TITLE_2}} | `{{FILE_2}}:{{LINE_2}}` | {{ASSIGNEE_2}} | {{STATUS_2}} |
-
-{{#if P1_EMPTY}}
-_No P1 items. Merge is unblocked._
-{{/if}}
-
----
-
-## P2 — Fix Before PR ({{P2_COUNT}} open)
-
-> P2 items should be resolved before PR review. Warning only — does not block merge.
-
-| ID | Title | File:Line | Assigned | Status |
-|----|-------|-----------|----------|--------|
-| P2-{{ID_1}} | {{TITLE_1}} | `{{FILE_1}}:{{LINE_1}}` | {{ASSIGNEE_1}} | {{STATUS_1}} |
-| P2-{{ID_2}} | {{TITLE_2}} | `{{FILE_2}}:{{LINE_2}}` | {{ASSIGNEE_2}} | {{STATUS_2}} |
-
----
-
-## P3 — Backlog ({{P3_COUNT}} open)
-
-> P3 items do not block merge. Address during scheduled cleanup sessions.
-
-| ID | Title | File:Line | Notes |
-|----|-------|-----------|-------|
-| P3-{{ID_1}} | {{TITLE_1}} | `{{FILE_1}}:{{LINE_1}}` | {{NOTES_1}} |
-| P3-{{ID_2}} | {{TITLE_2}} | `{{FILE_2}}:{{LINE_2}}` | {{NOTES_2}} |
-
----
-
-## Completed (archived)
-
-| ID | Title | Resolved | PR/Commit |
-|----|-------|----------|-----------|
-| {{DONE_ID_1}} | {{DONE_TITLE_1}} | {{DONE_DATE_1}} | {{DONE_REF_1}} |
-
----
-
-## Merge Checklist
-
-- [ ] P1 count = 0
-- [ ] P2 items reviewed (resolved or documented)
-- [ ] index.md reflects current state
-- [ ] Completed items archived to `done/`

package/skills/vibe.review/references/todo-prioritization.md

@@ -1,70 +0,0 @@
-# TODO Prioritization Rubric
-
-Use these criteria to assign P1, P2, or P3 to any TODO item.
-
-## P1 — Blocks Merge
-
-Assign P1 when ANY of the following is true:
-
-| Criterion | Example |
-|-----------|---------|
-| Security vulnerability | SQL injection, XSS, unprotected endpoint, leaked secret |
-| Data loss or corruption risk | Missing transaction, overwrite without backup |
-| Type safety bypass | `: any`, `as any`, `@ts-ignore` hiding a real error |
-| Production breakage | Throws uncaught exception on valid input |
-| Broken CI/test | Failing test committed (not pre-existing) |
-| Missing auth/authz check | Unauthenticated access to protected resource |
-| Regulatory non-compliance | GDPR PII without consent, HIPAA violation |
-
-**Decision rule**: Would this cause an incident if it shipped? → P1
-
----
-
-## P2 — Fix Before PR
-
-Assign P2 when ANY of the following is true AND it is not P1:
-
-| Criterion | Example |
-|-----------|---------|
-| Performance regression | O(n²) loop, N+1 query, synchronous blocking call |
-| Missing test coverage | New feature with no tests |
-| Architecture violation | Layer boundary crossed (service imports UI) |
-| `console.log` in committed code | Debug output in production path |
-| Function > 50 lines | Complexity limit exceeded |
-| Nesting depth > 4 | Readability and test difficulty |
-| Duplicate logic across 2+ files | Maintenance hazard; divergence risk |
-| TODO/FIXME without tracking ticket | Ambiguous ownership |
-
-**Decision rule**: Would a reviewer request changes on this in a PR review? → P2
-
----
-
-## P3 — Backlog
-
-Assign P3 when the issue is real but has no immediate consequence:
-
-| Criterion | Example |
-|-----------|---------|
-| Style inconsistency | Different quote styles, inconsistent naming |
-| Magic numbers with low risk | Timeout values, display constants |
-| Commented-out code | Dead code left behind |
-| Missing JSDoc on internal helpers | Not public API |
-| File nearing complexity limit | 150–200 lines, not there yet |
-| Refactoring opportunity | Could be cleaner but works correctly |
-
-**Decision rule**: Could this be deferred a week without risk? → P3
-
----
-
-## Upgrade / Downgrade Rules
-
-| Situation | Action |
-|-----------|--------|
-| P3 item appears in 3+ files | Upgrade to P2 (systemic issue) |
-| P2 item has no fix path identified | Keep P2, add a note |
-| P1 item is in dead code (never executed) | Downgrade to P2 with justification |
-| P2 item found in P1 audit | Upgrade to P1 if it compounds the P1 issue |
-
-## When Uncertain
-
-Default to the higher priority. It is cheaper to over-prioritize than to ship a P1 labeled as P3.

package/skills/vibe.review/references/ui-ux-review.md

@@ -1,39 +0,0 @@
-# Phase 2.5 — UI/UX Review Agents
-
-> vibe.review SKILL.md Phase 2.5 에서 **변경 파일에 UI 파일이 있을 때만** 로드한다.
-> UI 변경이 없는 리뷰(백엔드·CLI·설정만 변경)는 이 파일을 읽지 않는다.
-
-### Phase 2.5: UI/UX Review Agents (Auto-triggered)
-
-> **활성화 조건**: 변경된 파일 중 UI 파일 존재 (`.tsx`, `.jsx`, `.vue`, `.svelte`, `.html`, `.css`, `.scss`)
-> **비활성화**: `.vibe/config.json`에 `"uiUxAnalysis": false` 설정
-
-**기존 Phase 2 리뷰 에이전트와 병렬 실행 — `design-reviewer` 인스턴스 3개 (관점별):**
-
-| Agent (관점) | Role | Output |
-|-------|------|--------|
-| ⑥ design-reviewer (UX 준수) | UX 가이드라인 준수 검증 | P1/P2/P3 findings |
-| ⑦ design-reviewer (접근성) | WCAG 2.1 AA 접근성 감사 | P1/P2/P3 findings |
-| ⑧ design-reviewer (안티패턴) | UI 안티패턴 + 디자인 시스템 일관성 | P1/P2/P3 findings |
-
-**실행 방법 — 기존 Phase 2 에이전트와 병렬 실행:**
-
-Use the harness's native collaboration capability for these independent
-`design-reviewer` workers. Claude Code maps them to Task/Agent; Codex maps them
-to native collaboration. Inherit the session model by default and run them
-concurrently when capacity permits:
-
-- UX compliance: review `{changed_ui_files}` against UX and web-interface guidance.
-- Accessibility: audit `{changed_ui_files}` for WCAG 2.1 AA compliance.
-- Anti-patterns: inspect `{changed_ui_files}` and compare with `.vibe/design-system/{project}/MASTER.md` when present.
-
-#### Visual P1 Baseline
-
-- 프로젝트 루트에 `DESIGN.md` 가 존재하면 **시각 P1 의 1 차 baseline** 으로 사용한다 (§2 Color Palette / §7 Do's & Don'ts).
-- `DESIGN.md` 부재 시 기존 폴백을 사용 (WCAG 2.1 AA + `MASTER.md` + design-review(audit 모드) 기본 5 차원).
-- v1 범위: hex 컬러 드리프트만 P1 후보. spacing / font 드리프트는 Phase 2+ 에서 추가.
-- 안티패턴 검출(⑧) 은 `DESIGN.md §7` 의 "DON'T" 항목을 우선 규칙으로 사용한다.
-
-**findings 통합**: ⑥⑦⑧ findings를 기존 findings[]와 병합 → P1/P2/P3 통합 정렬
-
-**⑦ Critical finding 에스컬레이션**: design-reviewer(접근성)의 P1 finding은 Review Debate(Phase 4.5)에 자동 포함

package/skills/vibe.review/references/worked-examples.md

@@ -1,94 +0,0 @@
-# Review Worked Examples — Full Reference
-
-> Loaded by vibe.review SKILL.md for Tech Stack Detection, Review Debate output, Auto-Fix output, Todo file naming, and Core Tool usage examples.
-
-## Phase 1 Tech Stack Detection — Full Detection List
-
-```
-Read package.json      -> TypeScript, React, Node.js
-Read pyproject.toml    -> Python, FastAPI, Django
-Read Gemfile           -> Ruby, Rails
-Read pubspec.yaml      -> Flutter, Dart
-Read go.mod            -> Go
-Read CLAUDE.md         -> Explicit tech stack declaration
-```
-
-## Phase 4.5 Review Debate — Example Output
-
-**토론 결과 예시:**
-
-```
-🤝 REVIEW DEBATE RESULTS
-
-Consensus (4 parallel reviewers):
-
-✅ Validated P1 (unanimous):
-  1. [SECURITY] SQL Injection — 4/4 agree critical
-
-⬆️ Upgraded P2→P1 (debate result):
-  2. [PERF] Unbounded query — code-reviewer (focus: architecture) pointed out
-     cascading failure risk under load → agreed P1
-
-⬇️ Downgraded P1→P2 (debate result):
-  3. [SECURITY] CSRF on read-only endpoint — code-reviewer (focus: complexity)
-     noted endpoint has no side effects → agreed P2
-
-❌ Removed (false positive):
-  4. [ARCH] "Circular dependency" — code-reviewer (focus: architecture) confirmed
-     this is intentional bi-directional reference, not a cycle
-
-🆕 New findings (cross-review discussion):
-  5. [DATA] Race condition in concurrent updates — emerged from
-     security + performance cross-review
-```
-
-## Phase 5 Auto-Fix — Example Output
-
-```
-🔧 AUTO-FIX Starting...
-
-P1 Critical:
-  1. [SECURITY] SQL Injection → Fixed with parameterized query ✅
-  2. [DATA] Missing transaction rollback → Added try-finally ✅
-
-P2 Important:
-  3. [PERF] N+1 query → Added select_related ✅
-  4. [ARCH] Circular dependency → Separated dependencies ✅
-  5. [TEST] Missing edge case → Added test ✅
-
-🔍 Re-validating...
-  ✅ Build successful
-  ✅ Tests passed
-
-✅ 5 issues auto-fixed!
-```
-
-## Phase 6 Todo File Creation — Naming Examples
-
-```
-{priority}-{category}-{short-desc}.md
-
-Examples:
-- P2-arch-large-refactor.md  (Cannot be auto-fixed)
-- P3-style-extract-helper.md (Backlog)
-```
-
-## Core Tools — Example Tool Usage in Review
-
-**1. Validate code quality before review:**
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/convention/index.js').then(t => t.validateCodeQuality({targetPath: 'src/', projectPath: process.cwd()}).then(r => console.log(r.content[0].text)))"
-```
-
-**2. Analyze complexity of changed files:**
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/convention/index.js').then(t => t.analyzeComplexity({targetPath: 'src/api/users.ts', projectPath: process.cwd()}).then(r => console.log(r.content[0].text)))"
-```
-
-**3. Save critical finding for reference:**
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/index.js').then(t => t.saveMemory({key: 'review-pr123-critical', value: 'SQL injection in users.py:42', category: 'review', projectPath: process.cwd()}).then(r => console.log(r.content[0].text)))"
-```

package/skills/vibe.run/SKILL.md

@@ -1,254 +0,0 @@
----
-name: vibe.run
-description: 승인된 SPEC이 있고 구현을 시작할 때 — `.vibe/specs/<feature>.md`를 읽어 코드와 검증 산출물로 전개한다.
-argument-hint: '"feature name" or --phase N'
-user-invocable: true
----
-
-# /vibe.run
-
-## 완료 기준
-
-- [ ] 구현 요구사항이 승인된 SPEC의 REQ ID로 추적된다.
-- [ ] 변경 범위에 존재하는 build, lint, typecheck, test gate가 통과한다.
-- [ ] run ledger에 검증 결과와 exit code가 기록되어 있다.
-- [ ] 미완료 요구사항이 있으면 TODO와 사유가 기록되어 있다.
-
-Execute **Scenario-Driven Implementation** with automatic quality verification.
-
-> **Core Principle**: Scenarios are both the implementation unit and verification criteria. All scenarios passing = Quality guaranteed.
-
-## Usage
-
-```
-/vibe.run "feature-name"              # Full implementation (loops to convergence)
-/vibe.run "feature-name" --phase 1    # Specific Phase only
-/vibe.run "feature-name" --interactive  # Step-by-step confirmation per iteration
-/vibe.run "feature-name" --max-iter 1   # Single-pass (no loop)
-/vibe.run "feature-name" ultrawork    # deprecated alias: automationLevel autonomous + parallel
-/vibe.run "feature-name" ulw          # deprecated alias: same as ultrawork
-```
-
----
-
-> **Timer**: Query the system clock at START and record the result as `{start_time}`.
-
-> **Step Counter Reset (MANDATORY at START)**: Run this Bash command once at the very start:
->
-> ```bash
-> mkdir -p .vibe/metrics && printf '{"feature":"%s","startedAt":"%s","steps":0}\n' "{feature-name}" "$(date -u +%Y-%m-%dT%H:%M:%SZ)" > .vibe/metrics/current-run.json
-> ```
-
-## File Reading Policy (Mandatory)
-
-> 규칙은 **전체 읽기**이지 특정 도구 이름이 아니다. 하네스가 제공하는 파일 읽기 수단을 쓴다 — Claude Code 는 `Read` 도구, Codex 는 셸(`cat`/`sed -n`) 등. 도구 이름이 없다고 규칙을 건너뛰지 않는다.
-
-- **SPEC/Feature 파일**: 전체를 읽는다 (검색 결과 일부만 보고 판단 금지)
-- **소스코드 파일**: 구현/수정 대상 파일은 전체를 읽은 후 작업한다
-- **검색 도구 사용 제한**: grep/ripgrep 류는 **파일 위치 탐색**(어떤 파일에 있는지)에만 쓴다. 내용 파악은 전체 읽기로 한다
-- **에이전트 실행 시**: 프롬프트에 "대상 파일을 전체 읽은 후 구현하라"를 포함한다
-
-## **Scenario-Driven Development (SDD)**
-
-> Automate **Scenario = Implementation = Verification** so even non-developers can trust quality
-
-### Pre-Run Regression Check (MANDATORY, before implementation starts)
-
-```
-Load skill `vibe.regress` with: list --feature "{feature-name}"
-```
-
-- Open regressions exist → automationLevel confirm: ask user; autonomous: auto-invoke `/vibe.regress generate <slug>`
-- No open regressions → silently continue
-
-Also load `.vibe/contracts/{feature-name}.md` if present — use it as the contract reference during implementation.
-
-### DESIGN.md Gate (UI stack only, before Phase 1)
-
-```bash
-test -f DESIGN.md
-```
-
-- **DESIGN.md present OR no UI stack** → silently continue
-- **DESIGN.md absent AND UI stack present**:
-  - automationLevel confirm: 한 줄 안내 — "UI 작업에 `DESIGN.md` 시각 SSOT 가 없습니다. `/vibe.design init` 으로 생성하면 시각 드리프트가 자동 검출됩니다. (생략 가능 — 1 회만 안내)"
-  - automationLevel autonomous: 무음 스킵
-
-> **권유 > 강제**. DESIGN.md 부재는 절대 vibe.run 을 블록하지 않는다.
-
-### Core Flow
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│                    SCENARIO-DRIVEN IMPLEMENTATION                │
-│                                                                  │
-│   Load Feature file                                              │
-│        ↓                                                        │
-│   ┌──────────────────────────────────────────────────────────┐  │
-│   │ Scenario 1: Happy Path                                    │  │
-│   │   Given → When → Then                                     │  │
-│   │        ↓                                                  │  │
-│   │   [Implement] → [Verify immediately] → Pass               │  │
-│   └──────────────────────────────────────────────────────────┘  │
-│        ↓                                                        │
-│   ┌──────────────────────────────────────────────────────────┐  │
-│   │ Scenario 2: Edge Case                                     │  │
-│   │   [Implement] → [Verify] → Fail → [Fix] → Pass            │  │
-│   └──────────────────────────────────────────────────────────┘  │
-│        ↓                                                        │
-│   [Quality Report: Scenarios N/N passed]                        │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-> **병렬 쓰기는 격리 없이 하지 않는다.** 병렬 항목이 **파일을 수정하면** 항목별 worktree 에서 실행한다 (`vibe.git-worktree` 패턴, `vibe.loop` 의 `isolation: worktree` 와 같은 축). 읽기 전용 병렬 탐색은 격리 불필요.
->
-> WHY: 같은 워킹트리에서 두 에이전트가 쓰면 경합한다 — 파일 덮어쓰기, 공유 git 명령 충돌. 프롬프트로 막을 수 있는 종류가 아니라 **구조로만** 막힌다. 실측 사례: Bun 팀이 대규모 포팅을 여러 에이전트로 팬아웃했을 때 공유 워크스페이스에서 서로를 덮어써 운영상 실패했고, 해결책은 프롬프트가 아니라 그룹별 worktree 분리였다.
->
-> 팬아웃 전에 답이 있어야 하는 3가지: **어디서 작업하는가 · 결과를 어떻게 병합하는가 · 둘이 충돌하면 어떻게 하는가.** 답이 없으면 병렬로 가지 않는다.
-
-> **하네스-안전 증분 (Dual-Harness Doctrine)**: 시나리오는 **가장 작은 검증 단위**다. 한 시나리오 구현 → 즉시 검증 → 다음. `automationLevel: autonomous`이라도 이 단위는 무너뜨리지 않는다 (병렬은 시나리오 간, 검증은 시나리오별). 전문: `vibe/rules/principles/dual-harness-doctrine.md`.
-
-### Automated Verification (Closed Loop)
-
-After implementing each scenario, **automatic verification**:
-
-| Verification Item | Auto Check | Method |
-|-------------------|------------|--------|
-| Given (precondition) | State/data preparation confirmed | Code analysis |
-| When (action) | Feature execution possible | Code analysis + Build |
-| Then (result) | Expected result matches | Code analysis + Test |
-| Code quality | Complexity, style, security | Static analysis |
-| **UI behavior** | **실제 브라우저에서 동작 확인** | **E2E Closed Loop** |
-
-> **E2E Closed Loop (UI 시나리오) 와 실패 시 Auto-Fix 절차**: `references/e2e-and-autofix.md`
-
-## **ULTRAWORK Mode** (ulw) — deprecated alias
-
-> 루프 시맨틱은 `vibe/rules/loop-contract.md`를 따른다. `ultrawork`/`ulw`는 `automationLevel: autonomous` + 병렬 ACT의 deprecated 별칭이다.
-> `autonomous`가 vibe.run 안에서 구체적으로 바꾸는 것: `references/automation-level.md`
-
-`ultrawork` 또는 `ulw` 포함 시 vibe.run-specific 동작:
-- 병렬 탐색 — 하네스의 네이티브 서브에이전트를 **동시 슬롯 한도까지** 스폰 (CC: 한 메시지에 3개 이상). 슬롯이 부족하면 개수를 줄이거나 순차 실행하되 탐색 항목을 버리지 않는다
-- 비대화형 (중단점 없음)
-- Race Review (GPT+Antigravity) 기본 활성화
-- stuck 시 TODO 기록 후 다음 시나리오로 (사용자 질문 없음)
-
----
-
-## Stakes 프로파일 (실행 강도 조절)
-
-**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 — 게이트 통과 여부는 불변.
----
-
-## Scope & Ledger Rules
-
-### Run Ledger Tracking
-
-Every `/vibe.run` invocation must explicitly initialize `.vibe/metrics/run-ledger.json` (fields: `runStarted`, `runFeature`, `verifyPassed`, `verifyAt`) and reset `verifyPassed` to `false`. Before completion, invoke `/vibe.verify`; its `verify-ledger.js` step must record `verifyPassed`, `verifyAt`, and command evidence, then read the ledger back and enforce `verifyPassed === true && verifyAt > runStarted`. Stop/auto-commit hooks may warn or short-circuit this sequence when available, but they are acceleration only and never the correctness basis.
-
-### Interactive Checkpoints (`--interactive` 전용)
-
-> ⚠️ **기본 실행에서는 발화하지 않는다.** SPEC 승인이 유일한 의무적 사람 개입이라는 loop-contract 계약을 깨지 않기 위해, 아래 체크포인트는 사용자가 `--interactive` 를 준 경우에만 사람에게 묻는다. 그 외에는 표의 기본 옵션으로 **자동 해소하고 기록만 남긴다** (`automationLevel` 값과 무관).
-
-| Type | 발화 시점 | 기본 옵션 |
-|------|--------------|----------------|
-| `requirements_confirm` | Phase 1 시작 전 | Confirm (a) |
-| `architecture_choice` | 아키텍처 접근이 모호할 때 | Clean/balanced (b) |
-| `implementation_scope` | 큰 범위 변경 전 (6+ 파일) | Approve (a) |
-| `fix_strategy` | 품질 게이트에서 critical 발견 시 | Fix all (a) |
-
-Checkpoint format example:
-```
-──────────────────────────────────────────────────
-CHECKPOINT: Requirements Confirmation
-──────────────────────────────────────────────────
-Options:
-  a) Confirm — Proceed as stated.
-  b) Revise — Modify before proceeding.
-  c) Abort — Cancel.
-Default: a
-──────────────────────────────────────────────────
-```
-
----
-
-## Process
-
-### Process 단계 (전체 절차: `references/process-steps.md`)
-
-| # | 단계 | 핵심 게이트 |
-|---|---|---|
-| 1 | Load SPEC + Feature | SPEC 부재 시 진행 금지 |
-| 1-0 | Compile + validate execution packet | **MANDATORY** — 컴파일 실패 시 중단 (`references/exec-plan.md`) |
-| 1-1 | Phase Isolation Protocol | 3+ phase SPEC 은 phase 단위 격리 + 체크포인트 필수 |
-| 1-2 | SPEC-First Gate | SPEC 에 없는 것을 구현하지 않는다 |
-| 2 | Extract Scenario List | Feature 파일의 시나리오가 작업 단위 |
-| 3 | Scenario-by-Scenario Implementation | 기본 순차. **구현→검증 쌍은 시나리오 단위로 쪼개지 않는다**. `autonomous` 에서 서로 의존하지 않는 시나리오는 병렬 가능하되 검증은 시나리오별로 각각 (SSOT: 위 "하네스-안전 증분"), **병렬 시 격리 필수** (아래) |
-| 4 | Brand Assets | 신규 프로젝트만 (`references/brand-assets.md`) |
-| 5 | Race Code Review | `references/race-review.md` |
-| 6 | Quality Report | 자동 생성 |
-| 7 | Update Feature File | 시나리오 상태 반영 |
-| 8 | Coverage Verification Loop (RTM) | 커버리지 미달 시 루프 |
-
-> 도구·코딩 가이드라인·TRUST 5·자동 회고: `references/guidelines-and-tools.md`
-
-### 1-0. Execution packet (MANDATORY — 본문 유지)
-
-단일 SPEC 은 canonical path 해석 후 컴파일한다. 분할 SPEC 은 `_index.md` 를 컴파일하지 않고, Phase Isolation Step B 에서 각 활성 phase 파일이 로드될 때까지 미룬다.
-`writeExecutionPacket` 으로 컴파일한 뒤 **즉시** `validateExecutionPacket` 으로 저장 산출물을 검증한다.
-`STALE_PACKET`·invalid packet·preservation-audit 실패·budget 실패는 **blocking** 이다 — canonical SPEC 에서 재컴파일하며, 검증되지 않은 패킷으로 조용히 폴백하지 않는다.
-
-> 전체 절차와 코드: `references/exec-plan.md` · `references/process-steps.md`
-
-## Input / Output
-
-**Input:** `.vibe/specs/{feature-name}.md`, `.vibe/features/{feature-name}.feature`, `CLAUDE.md`
-
-**Output:** Implemented code files, test files, updated SPEC (checkmarks)
-
----
-
-## Next Step
-
-```
-/vibe.verify "feature-name"
-```
-
----
-
-ARGUMENTS: $ARGUMENTS
-
-## Bundled internals (조건부 로드)
-
-이 세 구현은 `vibe.run` 의 일부지만 **매 실행에 전부 필요하지는 않다.** 해당 조건에 걸릴 때만 읽는다 —
-세 개를 항상 로드하면 호출당 컨텍스트의 약 45%가 쓰이지 않을 자료로 채워진다.
-
-| 내부 구현 | 로드 조건 | 본문 |
-|---|---|---|
-## Bundled internal: arch-guard
-
-번들 유지 — 별도 discovery 항목으로 노출하지 않는다. 본문: `references/arch-guard.md`
-## Bundled internal: exec-plan
-
-번들 유지 — 별도 discovery 항목으로 노출하지 않는다. 본문: `references/exec-plan.md`
-## Bundled internal: restraint
-
-번들 유지 — 별도 discovery 항목으로 노출하지 않는다. 본문: `references/restraint.md`
-
-| **arch-guard** | 아키텍처 경계 테스트를 생성·검증할 때 (레이어 위반 감지가 필요한 SPEC) | `references/arch-guard.md` |
-| **exec-plan** | Step 1-0 — execution packet 을 컴파일할 때 | `references/exec-plan.md` |
-| **restraint** | 아래 요약으로 판단이 서지 않을 때 (전문: 사다리 단계별 근거·차단 충동 목록) | `references/restraint.md` |
-
-**restraint 요약 (항상 적용 — 상세는 위 reference):**
-
-```
-YAGNI 사다리: 지금 필요한가? → 아니면 쓰지 않는다.
-  추상화는 3번째 중복에서. 설정 항목은 2번째 요구에서. 플러그인 구조는 외부 사용자가 생겼을 때.
-
-Pike 규칙: 측정 없이 최적화하지 않는다. 한 부분이 나머지를 압도하지 않으면 튜닝하지 않는다.
-  n 은 대체로 작다. 단순한 코드가 영리한 코드를 이긴다. 데이터가 지배한다.
-
-Restraint 가 무효화하지 못하는 것: 정확성 · 보안 · 데이터 무결성 · 사용자가 명시적으로 요청한 것
-```

package/skills/vibe.run/internal/arch-guard/agents/detector.md

@@ -1,48 +0,0 @@
----
-name: arch-detector
-role: Detects the project's architecture pattern by analyzing directory structure and import graph
-tools: [Glob, Grep, Read]
----
-
-# Arch Detector
-
-## Role
-Analyzes directory layout, existing documentation, and import relationships to classify the project into a known architecture pattern. Produces a structured architecture map that downstream agents use to generate rules and check violations.
-
-## Responsibilities
-- Scan top-level directory structure for known layer naming conventions
-- Read CLAUDE.md, README, and any ADR files for explicit architecture documentation
-- Sample import statements across files to infer actual dependency direction
-- Classify project into one of: MVC, Clean Architecture, Hexagonal, Feature-based, Component hierarchy, or Unknown
-- Produce a layer map with canonical names and glob patterns for each layer
-
-## Input
-- Project root path
-- Optional: explicit architecture hint from user (e.g., "this is Clean Architecture")
-
-## Output
-Architecture map JSON:
-```json
-{
-  "pattern": "Clean Architecture",
-  "confidence": "high",
-  "layers": [
-    { "name": "domain", "glob": "src/domain/**", "allowedDeps": [] },
-    { "name": "application", "glob": "src/application/**", "allowedDeps": ["domain"] },
-    { "name": "infrastructure", "glob": "src/infra/**", "allowedDeps": ["domain", "application"] },
-    { "name": "ui", "glob": "src/components/**", "allowedDeps": ["application"] }
-  ]
-}
-```
-
-## Communication
-- Reports architecture map to: `arch-rule-generator`
-- Receives instructions from: arch-guard orchestrator (SKILL.md)
-
-## Domain Knowledge
-Architecture pattern signals:
-- **MVC**: directories named `controllers/`, `models/`, `views/` or `services/`
-- **Clean Architecture**: `domain/`, `application/` or `use-cases/`, `infrastructure/` or `infra/`
-- **Hexagonal**: `adapters/`, `ports/`, `core/` or `domain/`
-- **Feature-based**: top-level feature folders each containing `components/`, `hooks/`, `api/`
-- **Component hierarchy**: `pages/`, `features/`, `shared/`, `ui/` in frontend projects

package/skills/vibe.run/internal/arch-guard/agents/reporter.md

@@ -1,48 +0,0 @@
----
-name: arch-reporter
-role: Formats the violation scan results into an actionable report with fix suggestions
-tools: [Read]
----
-
-# Arch Reporter
-
-## Role
-Transforms the raw violation list into a human-readable report grouped by rule and severity. For each violation, it provides a specific fix suggestion explaining which layer the import should move to or be replaced by. Produces both a console summary and a machine-readable output for CI.
-
-## Responsibilities
-- Group violations by rule name and severity
-- Generate a specific fix suggestion for each violation type
-- Calculate a health score (clean files / total scanned)
-- Produce a markdown summary for the user
-- Produce a JSON summary for CI badge / artifact storage
-
-## Input
-Violation list JSON from `arch-violation-checker` plus the rule set from `arch-rule-generator`.
-
-## Output
-Markdown report:
-```markdown
-## Architecture Boundary Report
-
-Health: 139/142 files clean (97.9%)
-
-### Violations (3 errors)
-
-#### Rule: domain-no-infra — Domain must not import Infrastructure
-- src/domain/user.ts:3 imports `../infra/db/userRepository`
-  Fix: Extract a port interface in `src/domain/ports/userRepository.ts` and inject via DI
-
-Total: 3 violations across 1 rule. Run `npx vitest run tests/arch-guard.test.ts` to enforce in CI.
-```
-
-## Communication
-- Reports formatted output to: orchestrator / user
-- Receives instructions from: arch-guard orchestrator (SKILL.md)
-
-## Domain Knowledge
-Fix suggestion patterns:
-- **Domain importing Infra**: introduce a port/interface in domain; implement in infra; inject via constructor
-- **Feature importing Feature internals**: move shared code to `shared/` layer
-- **Service importing Controller**: the logic belongs in a service method called by the controller
-- **UI importing Domain directly**: route through an application-layer use case or store
-- Suggest the minimal move — avoid recommending full refactors for single violations

package/skills/vibe.run/internal/arch-guard/agents/rule-generator.md

@@ -1,49 +0,0 @@
----
-name: arch-rule-generator
-role: Generates concrete import boundary rules from the detected architecture map
-tools: [Read]
----
-
-# Arch Rule Generator
-
-## Role
-Translates a detected architecture map into a precise, machine-checkable set of import boundary rules. Merges default rules for the detected pattern with any custom rules defined in `.vibe/arch-rules.json`. Outputs a normalized rule set ready for the violation checker.
-
-## Responsibilities
-- Select default rule templates for the detected architecture pattern
-- Merge with custom rules from `.vibe/arch-rules.json` if present
-- Resolve glob patterns to concrete layer names
-- Deduplicate and normalize rule list
-- Flag rules with low confidence (detected layer with no matching files)
-
-## Input
-Architecture map JSON from `arch-detector`, plus optional `.vibe/arch-rules.json` for user-defined overrides.
-
-## Output
-Normalized rule set JSON:
-```json
-{
-  "rules": [
-    {
-      "name": "domain-no-infra",
-      "from": "src/domain/**",
-      "cannotImport": ["src/infra/**"],
-      "reason": "Domain layer must not depend on infrastructure",
-      "severity": "error"
-    }
-  ],
-  "warnings": ["Layer 'adapters' detected but no files found — rule may be inaccurate"]
-}
-```
-
-## Communication
-- Reports rule set to: `arch-violation-checker`
-- Receives instructions from: arch-guard orchestrator (SKILL.md)
-
-## Domain Knowledge
-Default rules by pattern:
-- **Clean Architecture**: domain has no deps; application imports domain only; infra imports domain + application; ui imports application only
-- **MVC**: models have no deps on controllers or views; services import models only
-- **Hexagonal**: domain/core imports nothing internal; adapters import ports only
-- **Feature-based**: features must not import each other's internals; only `shared/` is cross-feature
-- **SOLID Dependency Inversion**: high-level modules must not import low-level modules directly