@su-record/vibe 3.2.64 → 4.0.1

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

@@ -1,43 +0,0 @@
-# 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 | Playwright Test Runner | 테스트 코드 실행, **pass/fail 만** 소비 | `npx playwright install chromium` |
-| 2nd | Playwright MCP (DOM) | spec 으로 표현 못 하는 확인, 최후 수단 | — |
-
-> 검증 비용이 루프 횟수를 정한다. 1순위는 상호작용 내용을 spec 파일에 남기고
-> 컨텍스트에는 exit code 만 들인다. DOM 을 컨텍스트로 끌어오는 2순위는 2~3회면
-> 예산을 태우므로 기본값이 아니라 예외로 쓴다.
-
-**활성화 조건:** 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 경고 1줄**을 적는다. run-ledger 에는 적재하지 않는다 (경고 필드 없음). advisory — 게이트 통과 여부는 불변.
-
----
-

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

@@ -1,145 +0,0 @@
-# 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

@@ -1,84 +0,0 @@
-# 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

@@ -1,253 +0,0 @@
-# Parallel Agents & Model Orchestration — Full Reference
-
-> Loaded by vibe.run SKILL.md when parallel execution patterns, parallel subagent groups, or model selection details are needed.
-
-## Model Orchestration — Inherit by Default
-
-**Do not pass a `model` parameter.** Subagents inherit the session model.
-
-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.
-
-### The only exception
-
-| 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 |
-
-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`.
-
-> 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.
-
-### What still scales with complexity
-
-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)
-
-**BEFORE any implementation, you MUST launch these Task calls IN PARALLEL (single message, multiple tool calls):**
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│  STEP 1: PARALLEL EXPLORATION (REQUIRED)                        │
-│                                                                 │
-│  Launch ALL of these in ONE message:                            │
-│                                                                 │
-│  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]"
-└─────────────────────────────────────────────────────────────────┘
-                              │
-                              ↓ (wait for all to complete)
-┌─────────────────────────────────────────────────────────────────┐
-│  STEP 2: SYNTHESIZE                                      │
-│  - Review all exploration results                               │
-│  - Decide implementation approach                               │
-│  - Identify files to modify/create                              │
-└─────────────────────────────────────────────────────────────────┘
-                              │
-                              ↓
-┌─────────────────────────────────────────────────────────────────┐
-│  STEP 3: IMPLEMENT + BACKGROUND AGENTS (PARALLEL)               │
-│                                                                 │
-│  Main Agent:                                           │
-│  └─→ Execute current phase implementation                       │
-│                                                                 │
-│  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"         │
-│                                                                 │
-│  [ULTRAWORK] All 4 agents run simultaneously!                   │
-└─────────────────────────────────────────────────────────────────┘
-                              │
-                              ↓ (main completes, check backgrounds)
-┌─────────────────────────────────────────────────────────────────┐
-│  STEP 4: TEST + PHASE PIPELINING                                │
-│                                                                 │
-│  Current Phase:                                                 │
-│  └─→ Task: Write tests using pre-generated cases                │
-│                                                                 │
-│  Next Phase Prep (from background results):                     │
-│  └─→ Already have file analysis, ready to start immediately     │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-### Parallel Task Call Pattern (MUST FOLLOW)
-
-**Correct — Single message with multiple parallel spawns:**
-```
-<message>
-  Agent("Analyze src/components/ for existing patterns")
-  Agent("Check package.json dependencies")
-  Agent("Find usage of similar features in codebase")
-</message>
-→ 세 건이 동시에 돈다. 벽시계 시간은 **가장 느린 하나**로 수렴한다
-```
-
-**WRONG — Sequential calls (DO NOT DO THIS):**
-```
-<message>Agent("Analyze...")</message>
-<message>Agent("Check...")</message>
-<message>Agent("Find...")</message>
-→ 벽시계 시간이 **셋의 합**이 된다. 서로 읽지 않는 작업을 줄 세운 대가다
-```
-
-> 도구 이름은 하네스가 바꾼다 — 서브에이전트 툴은 `Task` 에서 `Agent` 로 옮겨갔다
-> (2026-08 실측: 세션 로그 60개에서 `Agent` 13회 / `Task` 0회). Codex 에는 이 이름의
-> 도구가 없으므로 **호출 문법이 아니라 의도**로 읽는다 — "독립 작업은 한 번에 띄운다".
->
-> **배수로 말하지 않는다.** 이전 판에는 "~3x faster" 라고 적혀 있었는데 근거가 없고
-> 사실도 아니다 — 병렬 실행의 벽시계 시간은 개수로 나눠지지 않고 가장 느린 항목과
-> 스폰 오버헤드로 정해진다. 측정하지 않은 배수는 적지 않는다.
-
-### Background Agent Pattern (autonomous + parallel ACT)
-
-Use the harness's native background subagents — spawn them in one message and continue working; completion notifications arrive automatically:
-
-```
-Task (Explore, background): "Phase 2 prep: Analyze auth API endpoints"
-Task (tester, background): "Pre-generate test cases for login form"
-Task (Explore, background): "Find existing validation patterns"
-```
-
-No status polling is needed — the harness re-invokes you when each background agent completes. (구 자체 오케스트레이터 runAgent/status/getResult 체계는 제거됨 — 네이티브 background subagent 가 대체.)
-
-### Phase Execution Flow (ULTRAWORK Pipeline)
-
-```
-Phase N Start
-    │
-    ├─→ [PARALLEL] Task × 3: Exploration
-    │       - Related code analysis
-    │       - Dependency check
-    │       - Pattern discovery
-    │
-    ↓ (all complete)
-    │
-    ├─→ Synthesize and decide
-    │
-    ├─→ [PARALLEL PIPELINE] ←── KEY SPEED OPTIMIZATION
-    │       │
-    │       ├─→ Main: Task Implementation
-    │       │
-    │       └─→ Background (run_in_background=true):
-    │               ├─→ Task: Phase N+1 file analysis
-    │               ├─→ Task: Test case preparation
-    │               └─→ Task: Type/interface lookup
-    │
-    ↓ (main completes)
-    │
-    ├─→ Task: Tests (uses pre-generated cases)
-    │
-    ↓
-Phase N Complete
-    │
-    ↓ (Background results ready — NO WAIT for Phase N+1 exploration!)
-    │
-Phase N+1 Start (IMMEDIATE — exploration already done!)
-```
-
-**Speed Comparison:**
-
-| Mode | Phase Time | 5 Phases Total |
-|------|------------|----------------|
-| Sequential | ~2min/phase | ~10min |
-| Parallel Exploration | ~1.5min/phase | ~7.5min |
-| **ULTRAWORK Pipeline** | **~1min/phase** | **~5min** |
-
-**Why Pipeline is Faster:**
-- Background agents prepare next phase WHILE current phase implements
-- No idle time between phases
-- Test cases pre-generated during implementation
-- Cache stays warm across parallel tasks
-
-## Parallel Subagent Groups
-
-> 별도 "팀" 에이전트는 없다 — 상황별로 **네이티브 서브에이전트를 병렬 스폰**한다
-> (단일 메시지, 다중 Task 호출). 아래는 상황 → 병렬 구성 매핑.
-
-**병렬 구성 선택 기준:**
-
-| 조건 | 병렬 구성 |
-|------|-----------|
-| 시나리오 1-2개, 파일 1-2개 | 기존 병렬 모드 (추가 구성 없음) |
-| 시나리오 3개+, 일반 모드 | implementer + tester + Explore (3 병렬) |
-| ULTRAWORK 또는 복잡도 20+ | architect + implementer + tester + code-reviewer (4 병렬) |
-
-**상황별 병렬 스폰:**
-
-| 상황 | 활성화 조건 | 병렬 서브에이전트 |
-|------|------------|------------------|
-| Review Debate | `/vibe.review` 후 P1/P2 이슈 2개 이상 | security-reviewer + code-reviewer 인스턴스(focus별) |
-| Debug | 동일 빌드/테스트 실패 3회 이상, 또는 root cause stuck | build-error-resolver + Explore + code-reviewer (focus: correctness) |
-| Research | `/vibe.spec` Step 3 리서치 단계 | Explore × N + native WebSearch |
-| Security | auth/payment/user-data/crypto 파일 변경, 또는 `security` 키워드 | security-reviewer + code-reviewer (focus: data-integrity) |
-| Migration | package.json 주요 의존성 버전 변경, 또는 `migration` 키워드 | Explore(변경 영향 조사) + implementer + tester |
-| Fullstack | SPEC에 frontend + backend 파일 모두 포함, 또는 `fullstack` 키워드 | implementer(FE) + implementer(BE) + tester |
-
-## External LLM Usage (When Enabled)
-
-When external LLMs are enabled in `.vibe/config.json`:
-
-| Role | Method | Condition |
-|------|--------|-----------|
-| User direct query | `gpt.question`, `antigravity.question` | Hook auto-handles |
-| Internal orchestration | Call global script via Bash | Claude calls directly |
-
-**Claude internal calls (directly via Bash):**
-```bash
-# [LLM_SCRIPT] = {{VIBE_PATH}}/hooks/scripts/llm-orchestrate.js
-
-# GPT call (short prompt - CLI arg)
-node "[LLM_SCRIPT]" gpt orchestrate-json "[question content]"
-
-# Antigravity call
-node "[LLM_SCRIPT]" antigravity orchestrate-json "[question content]"
-
-# Long prompt - use --input file (write JSON file first with Write tool)
-node "[LLM_SCRIPT]" gpt orchestrate-json --input "[SCRATCHPAD]/input.json"
-```
-
-### External LLM Fallback
-
-**When GPT/Antigravity hook fails, Claude MUST handle the task directly:**
-- Do NOT retry the external LLM call
-- Claude handles the task using its own capabilities
-- Continue with the implementation without interruption
-- Log the fallback but don't block progress
-
-## Codex Plugin Integration
-
-> **Codex 플러그인 감지**: 워크플로우 시작 시 아래 명령으로 자동 감지.
-
-```bash
-CODEX_AVAILABLE=$(node "{{VIBE_PATH}}/hooks/scripts/codex-detect.js" 2>/dev/null || echo "unavailable")
-```
-
-`available`이면 `/codex:rescue` (구현 위임), `/codex:review` (코드 리뷰) 자동 호출.
-
-**독립 시나리오 위임:**
-```
-/codex:rescue "Implement scenario: {scenario-name}. Files: {file-list}. Requirements: {requirements-summary}" --background
-```
-
-**위임 기준:**
-- 시나리오 간 파일 의존성 없음 (독립적)
-- 시나리오 복잡도 중간 이하
-- 의존성 있는 시나리오는 Claude가 직접 구현