@su-record/vibe 2.9.13 → 2.9.15

package/hooks/scripts/llm-orchestrate.js

@@ -1,11 +1,11 @@
 /**
- * UserPromptSubmit Hook - LLM 오케스트레이션 (GPT/Gemini)
+ * UserPromptSubmit Hook - LLM 오케스트레이션 (GPT/Gemini/Claude)
  *
  * Usage:
  *   node llm-orchestrate.js <provider> <mode> "prompt"
  *   node llm-orchestrate.js <provider> <mode> "systemPrompt" "prompt"
  *
- *   provider: gpt | gemini
+ *   provider: gpt | gemini | claude
  *   mode: orchestrate | orchestrate-json | image | analyze-image
  *
  * Image Mode:
@@ -13,7 +13,7 @@
  *   node llm-orchestrate.js gemini image "prompt" --output "./image.png" --size "1920x1080"
  *
  * Features:
- *   - CLI-based: GPT → codex exec, Gemini → gemini -p
+ *   - CLI-based: GPT → codex exec, Gemini → gemini -p, Claude → claude --print
  *   - Exponential backoff retry (3 attempts)
  *   - Auto fallback: gpt ↔ gemini
  *   - Overload/rate-limit detection
@@ -103,9 +103,31 @@ function resolveModel(providerName, config) {
   if (providerName === 'gpt-codex') return config.models?.gptCodex || 'gpt-5.3-codex';
   if (providerName === 'gpt') return config.models?.gpt || 'gpt-5.4';
   if (providerName === 'gemini') return config.models?.gemini || 'gemini-3.1-pro-preview';
+  if (providerName === 'claude') return 'claude';
   return providerName;
 }
 
+/**
+ * 주관 LLM 자동 감지 — Claude가 보조로 사용되어야 하는 환경인지 판별
+ *
+ * true인 경우:
+ * - vibe-codex: ANTHROPIC_BASE_URL이 localhost (프록시 모드)
+ * - coco: ~/.coco/ 존재 또는 COCO_HOME 설정
+ * - 명시적: VIBE_SECONDARY_LLM=claude
+ */
+function useClaudeAsSecondary() {
+  // 1. 명시적 환경변수
+  if (process.env.VIBE_SECONDARY_LLM === 'claude') return true;
+  // 2. vibe-codex 프록시 모드
+  const baseUrl = process.env.ANTHROPIC_BASE_URL || '';
+  if (baseUrl.includes('localhost') || baseUrl.includes('127.0.0.1')) return true;
+  // 3. coco 환경
+  if (process.env.COCO_HOME) return true;
+  const cocoDir = path.join(os.homedir(), '.coco');
+  if (fs.existsSync(cocoDir)) return true;
+  return false;
+}
+
 // Errors that should skip retry and go to fallback immediately
 const SKIP_RETRY_PATTERNS = [
   /rate.?limit/i,
@@ -283,6 +305,43 @@ function callGeminiCli(prompt, sysPrompt, jsonMode, model, timeoutMs) {
   });
 }
 
+function callClaudeCli(prompt, sysPrompt, jsonMode, timeoutMs) {
+  const fullPrompt = buildCliPrompt(prompt, sysPrompt, jsonMode);
+  const args = ['--print', '--dangerously-skip-permissions'];
+  const effectiveTimeout = timeoutMs || CLI_TIMEOUT_MS;
+
+  // 재귀 가드 — 자식 Claude 세션의 UserPromptSubmit hook이 또 claude CLI를
+  // spawn하는 포크 폭탄을 차단 (prompt-dispatcher.js가 이 env를 보고 즉시 종료).
+  const currentDepth = parseInt(process.env.VIBE_HOOK_DEPTH || '0', 10);
+  const childEnv = { ...process.env, VIBE_HOOK_DEPTH: String(currentDepth + 1) };
+
+  return new Promise((resolve, reject) => {
+    const proc = spawnCli('claude', args, {
+      stdio: ['pipe', 'pipe', 'pipe'],
+      timeout: effectiveTimeout,
+      env: childEnv,
+    });
+    proc.stdin.end(fullPrompt);
+
+    let stdout = '';
+    let stderr = '';
+    proc.stdout.on('data', (d) => { stdout += d.toString(); });
+    proc.stderr.on('data', (d) => { stderr += d.toString(); });
+
+    proc.on('close', (code) => {
+      if (code === 0 && stdout.trim()) {
+        resolve(stdout.trim());
+      } else {
+        reject(new Error(`claude cli failed (code ${code}): ${(stderr || stdout).slice(0, 500)}`));
+      }
+    });
+
+    proc.on('error', (err) => {
+      reject(new Error(`claude cli spawn error: ${err.message}`));
+    });
+  });
+}
+
 async function callProvider(providerName, prompt, sysPrompt, jsonMode, timeoutMs) {
   const vibeConfig = readVibeConfig();
 
@@ -303,6 +362,10 @@ async function callProvider(providerName, prompt, sysPrompt, jsonMode, timeoutMs
     return await callGeminiCli(prompt, sysPrompt, jsonMode, model, timeoutMs);
   }
 
+  if (providerName === 'claude') {
+    return await callClaudeCli(prompt, sysPrompt, jsonMode, timeoutMs);
+  }
+
   throw new Error(`Unknown provider: ${providerName}`);
 }
 
@@ -526,14 +589,24 @@ async function main() {
   }
 
   // Provider chain: primary → cross fallback
-  // WHY GPT → Gemini (not reverse): GPT is the primary code/reasoning model;
-  // Gemini serves as cross-vendor fallback so a single vendor outage never
-  // blocks the user. When Gemini is primary (e.g. web-search), GPT is fallback.
-  const providerLabels = { gpt: 'GPT', 'gpt-codex': 'GPT Codex', gemini: 'Gemini' };
-  const isGpt = provider === 'gpt' || provider === 'gpt-codex';
-  const providerChain = isGpt
-    ? [provider, 'gemini']
-    : ['gemini', 'gpt'];
+  // 프록시 모드 (주관=GPT): 보조로 Claude CLI 사용
+  // 직접 모드 (주관=Claude): 보조로 GPT/Gemini 사용
+  const providerLabels = { gpt: 'GPT', 'gpt-codex': 'GPT Codex', gemini: 'Gemini', claude: 'Claude' };
+  const isGpt = provider === 'gpt' || provider === 'gpt-codex' || provider === 'gpt-spark';
+  const isClaude = provider === 'claude';
+  const claudeSecondary = useClaudeAsSecondary();
+
+  let providerChain;
+  if (isClaude) {
+    // 명시적 claude 호출
+    providerChain = ['claude', 'gemini'];
+  } else if (isGpt) {
+    // GPT 주관 → claude fallback (vibe-codex/coco), gemini fallback (직접 모드)
+    providerChain = claudeSecondary ? [provider, 'claude'] : [provider, 'gemini'];
+  } else {
+    // gemini 주관 → claude fallback (vibe-codex/coco), gpt fallback (직접 모드)
+    providerChain = claudeSecondary ? ['gemini', 'claude'] : ['gemini', 'gpt'];
+  }
 
   const vibeConfig = readVibeConfig();
 

package/hooks/scripts/post-edit-dispatcher.js

@@ -0,0 +1,24 @@
+#!/usr/bin/env node
+/**
+ * PostToolUse dispatcher — Write/Edit 이후 순차 실행.
+ *
+ * 기존: PostToolUse.Write|Edit 배열에 3개 스크립트가 병렬 spawn (프로세스 피크 3배)
+ *       + PostToolUse.Edit 추가로 post-edit.js 1개 더
+ * 현재: 단일 디스패처에서 순차 실행. config.hooks.{name}.enabled로 개별 토글.
+ *
+ * 실행 순서:
+ *   1. auto-format — 코드 스타일 정규화
+ *   2. code-check — 린트/품질 검사
+ *   3. auto-test — 관련 테스트 실행
+ *   4. post-edit — Edit 전용 후처리 (Write에서는 스크립트 내부에서 스킵)
+ *
+ * 실패 격리: 한 스크립트 실패해도 다음은 계속 진행.
+ */
+import { dispatch } from './lib/dispatcher.js';
+
+await dispatch([
+  { name: 'auto-format', script: 'auto-format.js' },
+  { name: 'code-check',  script: 'code-check.js'  },
+  { name: 'auto-test',   script: 'auto-test.js'   },
+  { name: 'post-edit',   script: 'post-edit.js'   },
+]);

package/hooks/scripts/pre-tool-dispatcher.js

@@ -0,0 +1,31 @@
+#!/usr/bin/env node
+/**
+ * PreToolUse dispatcher — Bash/Edit/Write 공용.
+ *
+ * 기존: matcher별로 2~3개 스크립트가 병렬 spawn.
+ *       - Bash: sentinel-guard + pre-tool-guard + command-log
+ *       - Edit: sentinel-guard + pre-tool-guard
+ *       - Write: sentinel-guard + pre-tool-guard
+ * 현재: 단일 디스패처가 tool name을 인자로 받아 순차 실행.
+ *
+ * Deny 시맨틱 보존:
+ *   sentinel-guard / pre-tool-guard가 exit 2(deny)를 반환하면 dispatcher도
+ *   즉시 exit 2로 상위에 전파 → Claude Code가 도구 실행을 차단.
+ *
+ * 사용법: node pre-tool-dispatcher.js <Bash|Edit|Write>
+ */
+import { dispatch } from './lib/dispatcher.js';
+
+const toolName = process.argv[2] || '';
+
+const steps = [
+  { name: 'sentinel-guard', script: 'sentinel-guard.js', args: [toolName], denyOnExit2: true },
+  { name: 'pre-tool-guard', script: 'pre-tool-guard.js', args: [toolName], denyOnExit2: true },
+];
+
+// command-log은 Bash 전용
+if (toolName === 'Bash') {
+  steps.push({ name: 'command-log', script: 'command-log.js' });
+}
+
+await dispatch(steps);

package/hooks/scripts/pre-tool-guard.js

@@ -160,10 +160,9 @@ function formatOutput(toolName, validation) {
 function readStdinSync() {
   try {
     if (process.stdin.isTTY) return null;
-    const fd = fs.openSync('/dev/stdin', 'r');
+    // fd 0을 직접 사용 (Windows는 '/dev/stdin'이 없음)
     const buf = Buffer.alloc(65536);
-    const bytesRead = fs.readSync(fd, buf, 0, buf.length, null);
-    fs.closeSync(fd);
+    const bytesRead = fs.readSync(0, buf, 0, buf.length, null);
     if (bytesRead > 0) {
       return JSON.parse(buf.toString('utf-8', 0, bytesRead));
     }

package/hooks/scripts/prompt-dispatcher.js

@@ -16,6 +16,11 @@ import path from 'path';
 
 const __dirname = path.dirname(fileURLToPath(import.meta.url));
 
+// 재귀 가드 — 자식 Claude 세션에서 이 hook이 다시 실행되는 것 차단.
+// llm-orchestrate.js의 callClaudeCli가 VIBE_HOOK_DEPTH=1을 주입하므로,
+// 값이 있으면 즉시 종료해 프로세스 폭탄을 막는다.
+if (process.env.VIBE_HOOK_DEPTH) process.exit(0);
+
 // stdin에서 prompt 읽기
 let inputData = '';
 for await (const chunk of process.stdin) {

package/hooks/scripts/sentinel-guard.js

@@ -98,10 +98,9 @@ import fs from 'fs';
 function readStdinSync() {
   try {
     if (process.stdin.isTTY) return null;
-    const fd = fs.openSync('/dev/stdin', 'r');
+    // fd 0을 직접 사용 (Windows는 '/dev/stdin'이 없음)
     const buf = Buffer.alloc(65536);
-    const bytesRead = fs.readSync(fd, buf, 0, buf.length, null);
-    fs.closeSync(fd);
+    const bytesRead = fs.readSync(0, buf, 0, buf.length, null);
     if (bytesRead > 0) {
       return JSON.parse(buf.toString('utf-8', 0, bytesRead));
     }

package/hooks/scripts/stop-dispatcher.js

@@ -0,0 +1,27 @@
+#!/usr/bin/env node
+/**
+ * Stop dispatcher — Claude 응답 종료 시 4개 스크립트 순차 실행.
+ *
+ * 기존: Stop 배열에 4개 병렬 spawn (codex-review-gate + stop-notify + auto-commit + devlog-gen)
+ *       → auto-commit의 git cascade와 겹쳐 프로세스 폭주 유발 가능.
+ * 현재: 단일 디스패처에서 순차 실행.
+ *
+ * 실행 순서:
+ *   1. codex-review-gate — 리뷰 필요 여부 판단 (stdout → Claude 지시 주입)
+ *   2. stop-notify       — 완료 알림
+ *   3. auto-commit       — 변경 자동 커밋 (git hook cascade 주의)
+ *   4. devlog-gen        — 개발 로그 기록
+ *
+ * 재귀 가드 상속: callClaudeCli가 VIBE_HOOK_DEPTH=1 env를 자식에 주입했다면
+ * 이 Stop dispatcher도 건너뛴다 (자식 세션에서 auto-commit 등이 돌 이유 없음).
+ */
+import { dispatch } from './lib/dispatcher.js';
+
+if (process.env.VIBE_HOOK_DEPTH) process.exit(0);
+
+await dispatch([
+  { name: 'codex-review-gate', script: 'codex-review-gate.js' },
+  { name: 'stop-notify',       script: 'stop-notify.js'       },
+  { name: 'auto-commit',       script: 'auto-commit.js'       },
+  { name: 'devlog-gen',        script: 'devlog-gen.js'        },
+]);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@su-record/vibe",
-  "version": "2.9.13",
+  "version": "2.9.15",
   "description": "AI Coding Framework for Claude Code — 56 agents, 45 skills, multi-LLM orchestration",
   "type": "module",
   "main": "dist/cli/index.js",

package/skills/rob-pike/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: rob-pike
+tier: core
+description: "Rob Pike's 5 Rules — block premature optimization. Auto-activates on optimize, slow, performance, cache, parallelize keywords."
+triggers: [optimize, slow, performance, cache, parallelize, bottleneck, speed up, faster, latency, benchmark]
+priority: 90
+---
+
+# Rob Pike's 5 Rules of Programming
+
+## The Rules
+
+1. **You can't tell where a program is going to spend its time.** Bottlenecks occur in surprising places. Don't guess — prove it.
+2. **Measure.** Don't tune for speed until you've measured. Even then, don't unless one part of the code overwhelms the rest.
+3. **Fancy algorithms are slow when n is small, and n is usually small.** Big-O doesn't matter when constants dominate. Use Rule 2 first.
+4. **Fancy algorithms are buggier than simple ones.** Use simple algorithms and simple data structures.
+5. **Data dominates.** Choose the right data structures and the algorithms become self-evident. "Write stupid code that uses smart objects."
+
+## Before Any Optimization
+
+### Step 0: Check for Existing Instrumentation
+
+Before asking "have you measured?", determine whether measurement is even **possible** right now.
+
+**Scan the codebase** for signs of existing instrumentation:
+- Logging: logger imports, log calls, structured logging libraries
+- Profiling: profiler imports, benchmark files, tracing setup
+- Timing: duration measurements, stopwatch patterns, timing decorators
+- APM/Observability: metrics exports, spans, trace contexts
+
+**Then ask the user:**
+
+1. If instrumentation **exists**: "I found logging/profiling in [locations]. Are there specific areas you suspect are slow, or should we look at what the existing measurements tell us?"
+2. If instrumentation is **missing**: "There's no measurement in place. Before optimizing anything — where do you suspect the bottleneck is? Let's add measurement there first, then let the data decide."
+
+### Step 1: Ask the Measurement Questions
+
+Stop and ask these questions in order:
+
+1. **"Have I measured?"** — If no, measure first.
+2. **"Does one part overwhelm the rest?"** — If no single area dominates, nothing worth optimizing.
+3. **"What's n?"** — If n is small (and it usually is), the simple O(n^2) approach likely beats the clever O(n log n) one.
+4. **"Is this a data structure problem?"** — Before changing the algorithm, consider whether a different data structure makes the problem trivial.
+5. **"Is the added complexity worth it?"** — Simple code that is 10% slower is almost always preferable to clever code that is fragile.
+
+## Anti-Patterns to Block
+
+| Impulse | Rule violated | Response |
+|---|---|---|
+| "This loop looks slow, let me optimize it" | Rule 1 | Have you profiled? The bottleneck may be elsewhere entirely. |
+| "Let me add a cache here" | Rule 2 | Measure first. Does this path actually dominate runtime? |
+| "Let me use a B-tree / trie / skip list" | Rule 3 | What's n? If small, a sorted slice + binary search wins. |
+| "Let me implement a custom allocator" | Rule 4 | Start simple. Measure. Only get fancy if data forces you. |
+| "The algorithm is O(n^2), needs fixing" | Rule 3 | What's n? O(n^2) with n=100 is 10us. Measure first. |
+| "Let me parallelize this" | Rule 2 | Is this actually CPU-bound? Measure. Often it's I/O. |
+
+## When Optimization IS Justified
+
+Proceed only when ALL of these are true:
+
+- You have measurement data showing a specific bottleneck
+- That bottleneck dominates overall runtime (not just 5-10% of it)
+- The proposed fix is the simplest change that addresses the measured problem
+- You will re-measure after the change to confirm improvement

package/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: systematic-debugging
+tier: core
+description: "Enforce reproduce-first, root-cause-first, failing-test-first debugging. Auto-activates on bug, error, fail, broken, crash, flaky keywords."
+triggers: [bug, error, fail, broken, crash, flaky, not working, regression, unexpected, stack trace, exception, debug]
+priority: 90
+---
+
+# Systematic Debugging
+
+## Hard Gates
+
+These rules have NO exceptions:
+
+1. **Never fix before reproducing or observing the failure.**
+2. **State a root-cause hypothesis before changing code.**
+3. **Write a failing test (or equivalent) before fixing.**
+4. **Test one hypothesis at a time.**
+5. **No "while I'm here" refactoring during a fix.**
+6. **3 failed fixes → suspect structural issue, stop patching.**
+
+These excuses are NOT allowed:
+- "It looks simple, I'll just fix it"
+- "No time, let me patch and move on"
+- "This seems like the issue, let me just change it"
+
+## Workflow
+
+Follow this order strictly.
+
+### Phase 1. Define The Problem
+
+```text
+Problem: <expected> but got <actual> under <condition>
+```
+
+Good: "Product detail API returns 500 when brand is null."
+Bad: "Serializer is broken because brand mapping seems wrong."
+
+### Phase 2. Reproduce Or Instrument
+
+Priority:
+1. Reproduce with existing test
+2. Minimal integration test
+3. Unit test
+4. Reproduction script/command
+5. Add logging/instrumentation to observe
+
+Rules:
+- Make reproduction path as small as possible.
+- If UI-only bug, prefer reproducing at a lower layer.
+- If flaky, add logging for inputs, timing, concurrency conditions.
+- If can't reproduce, do NOT proceed to fix — increase observability first.
+
+### Phase 3. Gather Evidence
+
+Collect observable facts only:
+- Full error message and stack trace
+- Failing input values
+- Recent changed files/commits
+- Environment/config differences
+- Call path and data flow
+
+At each boundary (controller → service → repository), check:
+- What came in?
+- What went out?
+- What was transformed?
+- Under what condition does it break?
+
+Do NOT fix before locating the problem.
+
+### Phase 4. Isolate Root Cause
+
+State exactly one candidate:
+
+```text
+Hypothesis: <root cause> because <evidence>
+```
+
+Good hypothesis conditions:
+- Points to a single cause
+- Connected to observed evidence
+- Falsifiable with a small experiment
+
+Bad: "Something async seems wrong" / "The whole serializer area is unstable"
+
+### Phase 5. Lock The Failure
+
+Before fixing, lock the failure:
+1. Automated failing test (preferred)
+2. Add regression case to existing test
+3. Minimal reproduction script
+4. Temporary log/assertion guard
+
+The test MUST fail before fix, pass after fix.
+
+### Phase 6. Single Fix
+
+Allowed:
+- Minimal code change addressing the root cause
+- Minimal supporting changes for verification
+
+Forbidden:
+- Bundling multiple "related" fixes
+- Refactoring alongside the fix
+- Formatting/renaming/cleanup
+- Adding null-guards without evidence
+- Swallowing exceptions
+
+If fix fails → go back to Phase 3. Previous hypothesis was wrong.
+
+### Phase 7. Verify And Close
+
+ALL must be true:
+1. Original reproduction path no longer fails
+2. New failing guard now passes
+3. Related tests don't break
+4. Fix addresses cause, not symptom
+
+For flaky bugs: single pass is not enough. Repeat or vary conditions.
+
+## Red Flags — Stop Immediately
+
+If you think any of these, STOP and go back:
+
+- "Let me just change this one line"
+- "I'll check logs later, let me fix first"
+- "I'll add the test later"
+- "Let me fix this and that together"
+- "The error is gone so it doesn't matter what caused it"
+
+## Completion Checklist
+
+- [ ] Problem defined in one sentence
+- [ ] Failure reproduced or made observable
+- [ ] Evidence collected
+- [ ] Single root-cause hypothesis stated
+- [ ] Failing guard created before fix
+- [ ] Single fix applied
+- [ ] Verified via same reproduction path