@su-record/vibe 3.2.64 → 4.0.1

package/skills/vibe.run/references/process-steps.md

@@ -1,179 +0,0 @@
-# vibe.run — Process Steps 1–8 (상세)
-
-> vibe.run SKILL.md 의 Process 표에서 참조. 각 단계의 전체 절차·체크포인트 템플릿·코드 예시.
-
-### 1. Load SPEC + Feature
-
-**Search order:**
-```
-Step 1: Check split structure (folder)
-  .vibe/specs/{feature-name}/        → Folder: _index.md + phase files
-  .vibe/features/{feature-name}/     → Folder: _index.feature + phase files
-
-Step 2: If no folder, check single file
-  .vibe/specs/{feature-name}.md
-  .vibe/features/{feature-name}.feature
-
-Step 3: If neither → Error: "Run /vibe.spec first"
-```
-
-**Split structure:** Load `_index.md` first, then phase files in order. Execute phases sequentially (or per `--phase` flag).
-
-### 1-0. Compile + validate execution packet (MANDATORY)
-
-For a monolithic SPEC, compile it after resolving the canonical path. For a split SPEC, do not compile `_index.md`; defer this step until each active phase file is loaded in Phase Isolation Step B. Compile with `writeExecutionPacket`, then immediately verify the saved artifact with `validateExecutionPacket`.
-
-```bash
-node -e "import('file://{{VIBE_PATH}}/dist/tools/spec/index.js').then(t => {
-  const projectPath=process.cwd(), specPath='.vibe/specs/{feature-name}.md';
-  const profile='{codex-or-claude-code}';
-  const written=t.writeExecutionPacket({projectPath,specPath,profile});
-  if(!written.ok){console.error(JSON.stringify(written.errors));process.exit(1)}
-  const checked=t.validateExecutionPacket({projectPath,specPath,packetPath:written.packetPath});
-  if(!checked.valid){console.error(checked.code);process.exit(1)}
-  console.log(written.packetPath);
-})"
-```
-
-- Codex uses profile `codex`; Claude Code uses `claude-code`.
-- Split SPECs compile each active `phase-N-*.md` immediately before that phase runs; `_index.md` remains the overview ANCHOR and is not treated as a phase contract.
-- Use the packet only when validation returns `valid: true`.
-- `STALE_PACKET`, invalid packet, preservation-audit failure, or budget failure is blocking: recompile from the canonical SPEC and never silently fall back to an unvalidated packet.
-- The packet is a derived execution view. The canonical SPEC remains the ANCHOR and source of truth.
-
-### 1-1. Phase Isolation Protocol (Large SPEC Guard, MANDATORY for 3+ phases)
-
-```
-Step A: Read _index.md (overview only — phase list, REQ IDs)
-Step B: For each Phase N:
-  1. RE-READ Phase N SPEC section (every time, no memory)
-  2. Compile + validate Phase N execution packet using the phase file path
-  3. RE-READ Phase N Feature scenarios
-  4. Extract Phase N scope: files, scenarios, requirements
-  5. Implement Phase N scenarios
-  6. Verify Phase N
-  7. Write Phase Checkpoint → .vibe/checkpoints/
-  8. DISCARD Phase N details from working memory
-Step C: Next Phase
-```
-
-**Phase Checkpoint** (`.vibe/checkpoints/{feature}-phase-{N}.md`):
-
-```markdown
-# Checkpoint: {feature} Phase {N}
-
-## Completed
-- Scenario 1: {name} ✅
-
-## Files Changed
-- src/auth.service.ts (added login(), validateToken())
-
-## State for Next Phase
-- Auth service exports: login(), logout(), validateToken()
-
-## Remaining Phases
-- Phase {N+1}: {name} — {scenario count} scenarios
-```
-
-**SPEC Re-anchoring (Before EVERY scenario):** Re-read the EXACT Given/When/Then from Feature file (not from memory). Compare: "Am I implementing what the SPEC says, or what I think it says?"
-
-**Scope Lock (Per Phase):**
-
-```
-At Phase start, declare:
-  MODIFY: [list of files this phase will touch]
-  CREATE: [list of files this phase will create]
-  DO NOT TOUCH: everything else
-```
-
-**Context Pressure:**
-
-| Context Level | Action |
-|---------------|--------|
-| < 50% | Normal execution |
-| 50-85% | Save checkpoint, trim exploration results |
-| 85%+ | Save checkpoint → `/new` → resume from checkpoint |
-| Phase boundary | Always save checkpoint |
-
-### 1-2. SPEC-First Gate
-
-> SPEC is the source of truth for code. To modify code, update the SPEC first.
-
-```
-Discovery: "An API endpoint not in SPEC is needed"
-    ├─ Already in SPEC? YES → Implement
-    ├─ Not in SPEC but within scope? → Add to SPEC + Feature → Implement
-    └─ Outside scope? → TODO in .vibe/todos/out-of-scope-{item}.md
-```
-
-SPEC changes and code changes must be in the **same commit**.
-
-### 2. Extract Scenario List
-
-```markdown
-| # | Scenario | Status |
-|---|----------|--------|
-| 1 | Valid login success | ⬜ |
-| 2 | Invalid password error | ⬜ |
-```
-
-### 3. Scenario-by-Scenario Implementation
-
-> Read `references/parallel-agents.md` for full parallel exploration patterns, background agents, parallel subagent group selection, and model routing.
-
-**For each scenario:**
-1. [Parallel exploration] Delegate up to 3 independent workers through native collaboration — related code, deps, patterns. Claude Code maps workers to Task/Agent; Codex maps them to native collaboration; inherit the session model by default.
-2. [Implement] Write/edit the minimum required code
-3. [Verify] Check Given/When/Then; E2E if UI scenario
-4. [Auto-fix loop] On failure: collect evidence → root cause → fix → re-verify
-
-**UI/UX Design Intelligence (auto-triggered before Phase 1 if UI keywords in SPEC):**
-- Delegate `design-system-gen` through native collaboration: framework-specific component guidelines + chart/viz library advice (viz advice conditional on chart keywords). Inherit the session model.
-- Load `.vibe/design-system/{project}/MASTER.md` if present
-
-### 4. Brand Assets (New project only)
-
-> Read `references/brand-assets.md` when SPEC contains brand context and this is the first run.
-
-Trigger conditions: first run (no favicon.ico) + SPEC has brand context + Antigravity API key configured.
-
-### 5. Race Code Review
-
-> Read `references/race-review.md` for full Race Review invocation, confidence matrix, and quality gate thresholds.
-
-After all scenarios: GPT + Antigravity review in parallel. ULTRAWORK enables this by default.
-
-### 6. Quality Report (Auto-generated)
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│  QUALITY REPORT: {feature}                                       │
-├─────────────────────────────────────────────────────────────────┤
-│  Scenarios: N/N passed                                          │
-│  Quality score: 94/100                                          │
-│  Build: ✅ | Tests: ✅ | Types: ✅ | Race review: ✅             │
-│  Started: {start_time}  Completed: {system clock result}        │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-### 7. Update Feature File
-
-Auto-update scenario status with `Last verified` timestamp and quality score.
-
-### 8. Coverage Verification Loop (RTM)
-
-> 루프 시맨틱은 `vibe/rules/loop-contract.md`를 따른다. 여기서의 exit 기준은 `coveragePercent === 100`. RTM 다이어그램, 출력 형식, 반복 규칙: `references/coverage-loop.md`
-
-After ALL phases complete:
-
-```bash
-# generateTraceabilityMatrix is synchronous — no .then()
-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)); })"
-```
-
-> Default SPEC path is `.vibe/specs/<feature>.md`. `status === 'empty'` must be treated as failed/not-applicable — never as 100% pass.
-
-JUDGE: `coveragePercent === 100` → 루프 종료. stuck(연속 2회 동일 발견 해시 — `loop-ledger.js check-stuck`; 커버리지 수치가 아니라 발견으로 판정한다) → **어느 automationLevel 에서도 루프를 종료한다**; confirm이면 사용자 질문, autonomous이면 TODO 기록 후 다음 독립 단위로. 미달 커버리지를 완료로 기록하지 않는다 (SSOT: `vibe/rules/loop-contract.md`).
-
----
-

package/skills/vibe.run/references/race-review.md

@@ -1,272 +0,0 @@
-# Race Code Review & Quality Gate — Full Reference
-
-> Loaded by vibe.run SKILL.md when Race Review (GPT+Antigravity), quality gate thresholds, or type safety details are needed.
-
-## Race Code Review (GPT + Antigravity) + Auto-Fix (v2.6.9)
-
-After all scenarios are implemented, **GPT and Antigravity review in parallel with cross-validation**:
-
-> **ULTRAWORK Default**: In ULTRAWORK mode, race review is automatically enabled.
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-RACE CODE REVIEW (GPT + Antigravity)
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-[Step 1] Parallel review execution...
-  ├─ GPT Codex: Reviewing...
-  └─ Antigravity: Reviewing...
-
-[Step 2] Cross-validation results:
-  ┌──────────────────────────────────────────────────────────────────┐
-  │ Issue                          │ GPT │ Antigravity │ Codex │ Confidence│
-  │────────────────────────────────│─────│────────│───────│───────────│
-  │ Timing attack in password      │     │        │       │ 100% → P1 │
-  │ Rate limiting missing          │     │        │       │ 100% → P1 │
-  │ Magic number usage             │     │        │       │ 50% → P2  │
-  └──────────────────────────────────────────────────────────────────┘
-
-  Summary: 3 issues (P1: 2, P2: 1)
-
-[Step 3] Auto-fixing P1/P2 issues...
-  auth.service.ts:24 - Applied timingSafeEqual (P1)
-  auth.controller.ts:15 - Added rate limiter (P1)
-  auth.service.ts:42 - Extracted constant (P2)
-
-[Step 4] Re-verifying...
-  Build succeeded
-  Tests passed
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Race review complete! 3 improvements (2 P1, 1 P2)
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Race Review Invocation
-
-**Use --input file to avoid CLI argument length limits and Windows pipe issues.**
-
-1. Save code to review into `[SCRATCHPAD]/review-code.txt` (using Write tool)
-2. Write JSON input file `[SCRATCHPAD]/review-input.json` (using Write tool):
-   - `{"prompt": "Review this code for security, performance, and best practices. Return JSON: {issues: [{id, title, description, severity, suggestion}]}. Code: [CODE_CONTENT]"}`
-3. Script path: `[LLM_SCRIPT]` = `{{VIBE_PATH}}/hooks/scripts/llm-orchestrate.js`
-4. Run GPT + Antigravity in PARALLEL (two Bash tool calls at once):
-
-```bash
-# GPT review (Bash tool call 1)
-node "[LLM_SCRIPT]" gpt orchestrate-json --input "[SCRATCHPAD]/review-input.json"
-```
-
-```bash
-# Antigravity review (Bash tool call 2 - run in parallel)
-node "[LLM_SCRIPT]" antigravity orchestrate-json --input "[SCRATCHPAD]/review-input.json"
-```
-
-**Confidence-based Priority:**
-
-| Confidence | Priority | Action |
-|------------|----------|--------|
-| 100% (3/3 or 2/2) | P1 | Auto-fix immediately |
-| 67% (2/3) | P1 | Auto-fix immediately |
-| 50% (1/2) or 33% (1/3) | P2 | Auto-fix with review |
-
-**Fallback handling:**
-- If one LLM fails → Use remaining LLM results (reduced confidence)
-- If all fail → Skip and proceed (log warning)
-
-**Review application rules:**
-
-| Feedback Type | Action |
-|---------------|--------|
-| Security vulnerability (P1) | Auto-fix immediately |
-| Performance improvement (P1/P2) | Auto-fix immediately |
-| Best practices (P2) | Auto-fix |
-| Style/preference (P3) | Apply selectively |
-
-**Conditions:**
-- **ULTRAWORK**: Race review enabled by default
-- **Normal mode**: Use `--race` flag to enable
-- Must re-verify build/tests after fixes
-
-### Codex Code Review (Codex 플러그인 활성화 시)
-
-GPT+Antigravity race와 **동시에** Codex review 실행:
-
-```
-/codex:review
-```
-
-결과를 race review 교차 검증에 포함 — 3중 리뷰:
-
-```markdown
-| Issue | GPT | Antigravity | Codex | Confidence |
-|-------|-----|--------|-------|------------|
-| {이슈} | ✅/❌ | ✅/❌ | ✅/❌ | {%} |
-```
-
-## Implementation Quality Checklist
-
-Before marking any scenario as complete, ALL items must pass:
-
-| Category | Check Item | Weight |
-|----------|------------|--------|
-| **Functionality** | All Given/When/Then conditions verified | 20% |
-| **Functionality** | Edge cases handled per scenario | 10% |
-| **Code Quality** | No `any` types in TypeScript | 10% |
-| **Code Quality** | Functions ≤50 lines, nesting ≤3 levels | 10% |
-| **Code Quality** | No hardcoded values (use constants) | 5% |
-| **Security** | Input validation implemented | 10% |
-| **Security** | Authentication/authorization checked | 5% |
-| **Error Handling** | Try-catch or error states present | 10% |
-| **Error Handling** | User-friendly error messages | 5% |
-| **Testing** | Unit tests exist for core logic | 10% |
-| **Performance** | No N+1 queries or unnecessary loops | 5% |
-
-## Quality Score Calculation
-
-```
-Score = Σ(checked items × weight) / 100
-
-Grades:
-- 95-100: EXCELLENT - Ready to merge
-- 90-94:  GOOD - Minor improvements required before merge
-- 80-89:  FAIR - Significant improvements required
-- 0-79:   POOR - Major fixes needed
-```
-
-## Quality Gate Thresholds
-
-| Gate | Minimum Score | Condition |
-|------|---------------|-----------|
-| **Scenario Complete** | 95 | Each scenario must score ≥95 |
-| **Phase Complete** | 95 | Average of all scenarios ≥95 |
-| **Feature Complete** | 95 | All phases complete + Antigravity review |
-
-## Auto-Fix Triggers
-
-| Issue Type | Auto-Fix Action |
-|------------|-----------------|
-| Missing error handling | Add try-catch wrapper |
-| Hardcoded values | Extract to constants file |
-| Missing input validation | Add validation schema |
-| Function too long | Suggest split points |
-| N+1 query detected | Add eager loading |
-
-### Auto-Fix 실패 시 Codex Rescue (Codex 플러그인 활성화 시)
-
-P1 auto-fix가 **3회 실패** 시, Codex에 위임:
-
-```
-/codex:rescue "Fix P1 issue: {issue-description}. File: {file-path}. Error: {error-message}"
-```
-
-## Forbidden Patterns (Detected — Injected as additionalContext, Block at Commit Gate)
-
-> Detection results are injected as `additionalContext` into the model; commit-level blocking occurs via the auto-commit verify gate and pr-test-gate. These patterns do not block file edits directly.
-
-| Pattern | Why Forbidden | Detection |
-|---------|---------------|-----------|
-| `console.log` | Debug code in production | Regex scan |
-| `// TODO` without issue | Untracked work | Comment scan |
-| `any` type | Type safety bypass | TypeScript check |
-| `@ts-ignore` | Type error suppression | TypeScript check |
-| Empty catch blocks | Silent error swallowing | AST analysis |
-| Commented-out code | Dead code | Comment scan |
-
-## Type Safety — Language-Specific Guidelines
-
-### Universal Anti-Patterns (All Languages)
-
-| Forbidden Pattern | Why | Instead |
-|---------------------|-----|-----------|
-| Type escape hatches (`any`, `Any`, `Object`, `void*`, `interface{}`) | Loses type info, runtime errors | Concrete types or `unknown` + guards |
-| Type suppression (`@ts-ignore`, `# type: ignore`, `@SuppressWarnings`) | Hides errors | Fix actual type issues |
-| Raw generic types (`List`, `Map` without params) | Loses type safety | `List<User>`, `Map<String, Order>` |
-| Excessive casting (`as`, `(Type)`, `unsafe`) | Bypasses compiler | Type guards or pattern matching |
-
-### TypeScript/JavaScript
-
-```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');
-}
-```
-
-### Python
-
-```python
-# BAD
-def process(data: Any) -> Any: return data["key"]
-
-# GOOD
-def process(data: UserData) -> str: return data["name"]
-```
-
-### Java/Kotlin
-
-```java
-// BAD
-List items = new ArrayList();  // Raw type
-
-// GOOD
-List<User> users = new ArrayList<>();
-```
-
-### Go
-
-```go
-// BAD
-func process(data interface{}) interface{} { ... }
-
-// GOOD
-func process(data UserRequest) (UserResponse, error) { ... }
-```
-
-### Rust
-
-```rust
-// BAD (unnecessary unsafe or Box<dyn Any>)
-let data: Box<dyn Any> = get_data();
-
-// GOOD
-let data: UserData = get_data()?;
-```
-
-### C\#
-
-```csharp
-// BAD
-object data = GetData();
-dynamic result = Process(data);
-
-// GOOD
-UserData data = GetData();
-Result result = Process(data);
-```
-
-### Type Safety Rules
-
-| Rule | Description |
-|------|-------------|
-| **Boundary Validation** | Validate only at system boundaries (API, JSON, user input) |
-| **Internal Trust** | After validation, pass only precise types internally |
-| **No Type Escape** | Never use escape hatches to "fix" type errors |
-| **Explicit Signatures** | Specify types in function/method signatures |
-| **Generics with Params** | Always use generics with type parameters |
-
-### Type Violations — Detection & Escalation
-
-> Type violations are detected by static analysis and injected as `additionalContext` for the model to act on. Commit-level enforcement occurs at the auto-commit verify gate.
-
-| Violation | Detection outcome |
-|-----------|--------|
-| Type escape hatches (`any`, `Any`, `Object`, `interface{}`, etc.) | Injected as P1 finding |
-| Type suppression comments | Injected as P1 finding |
-| Raw generic types | Injected as P1 finding |
-| Missing function return types | Injected as warning |
-| Excessive type casting | Injected as warning |

package/skills/vibe.run/references/restraint.md

@@ -1,66 +0,0 @@
-# Restraint — Don't Write It, Don't Tune It (Yet)
-
-> vibe.run 내부 구현. YAGNI 사다리 · Pike 최적화 규칙 · 차단 충동 · 무효화 불가 예외의 전문.
-
-# Restraint — Don't Write It, Don't Tune It (Yet)
-
-Two constraints, one gate:
-
-- **No premature code.** New abstractions must be *pulled* by a demonstrated
-  need, never pushed by "might need it later." Once the code exists, deleting
-  it costs more than never writing it.
-- **No premature optimization.** Performance work must be *pulled* by a
-  measurement, never by a hunch.
-
-## The YAGNI Ladder (code axis)
-
-Satisfy the need at the **highest** rung that covers it; lower rungs are
-blocked while a higher one applies:
-
-1. **Not needed** — the requirement doesn't ask for it → don't build it
-2. **Stdlib / built-ins** already do it (`crypto`, `Intl`, `pathlib`, …)
-3. **Native platform feature** does it (`<input type="date">`, CSS `:has()`, DB constraints)
-4. **Already-installed dependency** covers it — check the lockfile, don't guess
-5. **One line** — a single expression; no new file, no class
-6. **Minimal code** — only now, and nothing for "later"
-
-Tie-break: native beats a one-liner; stdlib beats a dependency. Generalize
-only when a *second* caller exists.
-
-## Pike's Rules (optimization axis)
-
-- You can't tell where a program spends its time — bottlenecks surprise.
-  **Measure; don't guess.**
-- Don't tune until one part *measurably* overwhelms the rest.
-- Fancy algorithms are slow when n is small — and n is usually small.
-  Ask "what's n?" before "what's the Big-O?"
-- Simple algorithms + the right data structures beat clever code. Data dominates.
-
-Optimization is justified only when ALL hold: a measured bottleneck exists →
-it dominates runtime → the fix is the simplest change addressing it → you
-re-measure after.
-
-## Blocked Impulses
-
-| Impulse | Constraint | Counter |
-|---|---|---|
-| helper / utility / wrapper / manager class | rungs 1–5 | a stdlib call or one line usually suffices |
-| config system for one value | rung 1 | a `const` is the config |
-| generic `Processor(strategy, validator…)` | rung 1 | one concrete function until a second caller exists |
-| "add a cache here" / "parallelize this" | measure first | is this path even hot? Often it's I/O |
-| swap in a B-tree / trie / skip list | what's n? | O(n²) with n=100 is microseconds |
-| "this loop looks slow" | measure first | the bottleneck is probably elsewhere |
-
-## Overrides — Restraint Never Erodes These
-
-1. **Security and trust-boundary work are requirements**, not optional
-   complexity. Input validation, auth checks, escaping stay in — "one line"
-   is no excuse to drop them.
-2. **Deliberate simplifications get a comment + upgrade path**, so the next
-   reader sees a *choice*, not an oversight:
-
-   ```ts
-   // Global lock is enough at current throughput.
-   // Switch to per-account locking if write contention shows up.
-   const lock = new Mutex();
-   ```