@su-record/vibe 3.2.7 → 3.2.8

package/skills/vibe.run/references/parallel-agents.md

@@ -2,52 +2,36 @@
 
 > Loaded by vibe.run SKILL.md when parallel execution patterns, parallel subagent groups, or model selection details are needed.
 
-## Model Orchestration (Intelligent Routing)
+## Model Orchestration — Inherit by Default
 
-Automatically select optimal model based on **task complexity analysis**.
+**Do not pass a `model` parameter.** Subagents inherit the session model.
 
-### Complexity-Based Model Selection
+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.
 
-| Complexity Score | Model | When to Use |
-|------------------|-------|-------------|
-| 0-7 (Low) | **Haiku** | Simple fixes, searches, single file changes |
-| 8-19 (Medium) | **Sonnet** | Standard features, 3-5 files, integrations |
-| 20+ (High) | **Opus** | Architecture, security, multi-service, 6+ files |
+### The only exception
 
-### Complexity Signals
+| 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 |
 
-| Signal | Score |
-|--------|-------|
-| Architecture change | +15 |
-| Security implication | +12 |
-| Multi-service | +8 |
-| Refactoring | +12 |
-| 6+ files | +15 |
-| 3-5 files | +8 |
-| New feature | +5 |
-| Bug fix | -3 |
-| Documentation | -5 |
+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`.
 
-### Agent × Model Selection
+> 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.
 
-Tier-variant agents were consolidated — the model is a Task parameter, not a separate agent:
+### What still scales with complexity
 
-| Agent | Low | Medium | High |
-|-------|-------------|-----------------|-------------|
-| Explore (native) | `model: "haiku"` | `model: "sonnet"` | `model: "opus"` |
-| implementer | `model: "haiku"` | `model: "sonnet"` | `model: "opus"` |
-| architect | `model: "haiku"` | `model: "sonnet"` | `model: "opus"` |
-
-### Task Calls by Role
-
-| Task Type | Model | Task Parameter |
-|-----------|-------|----------------|
-| Simple search | Haiku | `model: "haiku"` |
-| Codebase exploration | Haiku/Sonnet | Auto-selected |
-| Core implementation | Sonnet | `model: "sonnet"` |
-| Test writing | Haiku | `model: "haiku"` |
-| Architecture decisions | Opus | Main session |
-| Final review | Opus | Main session |
+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)
 
@@ -59,11 +43,11 @@ Tier-variant agents were consolidated — the model is a Task parameter, not a s
 │                                                                 │
 │  Launch ALL of these in ONE message:                            │
 │                                                                 │
-│  Task(haiku) ─┬─→ "Analyze related files in <context>"          │
-│               │                                                 │
-│  Task(haiku) ─┼─→ "Check dependencies and imports"              │
-│               │                                                 │
-│  Task(haiku) ─┴─→ "Find existing patterns and conventions"      │
+│  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]"
@@ -71,7 +55,7 @@ Tier-variant agents were consolidated — the model is a Task parameter, not a s
                               │
                               ↓ (wait for all to complete)
 ┌─────────────────────────────────────────────────────────────────┐
-│  STEP 2: SYNTHESIZE (Opus)                                      │
+│  STEP 2: SYNTHESIZE                                      │
 │  - Review all exploration results                               │
 │  - Decide implementation approach                               │
 │  - Identify files to modify/create                              │
@@ -81,10 +65,10 @@ Tier-variant agents were consolidated — the model is a Task parameter, not a s
 ┌─────────────────────────────────────────────────────────────────┐
 │  STEP 3: IMPLEMENT + BACKGROUND AGENTS (PARALLEL)               │
 │                                                                 │
-│  Main Agent (sonnet):                                           │
+│  Main Agent:                                           │
 │  └─→ Execute current phase implementation                       │
 │                                                                 │
-│  Background Agents (haiku, run_in_background=true):             │
+│  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"         │
@@ -97,7 +81,7 @@ Tier-variant agents were consolidated — the model is a Task parameter, not a s
 │  STEP 4: TEST + PHASE PIPELINING                                │
 │                                                                 │
 │  Current Phase:                                                 │
-│  └─→ Task(haiku): Write tests using pre-generated cases         │
+│  └─→ Task: Write tests using pre-generated cases                │
 │                                                                 │
 │  Next Phase Prep (from background results):                     │
 │  └─→ Already have file analysis, ready to start immediately     │
@@ -109,18 +93,18 @@ Tier-variant agents were consolidated — the model is a Task parameter, not a s
 **Correct — Single message with multiple parallel Tasks:**
 ```
 <message>
-  Task(haiku, "Analyze src/components/ for existing patterns")
-  Task(haiku, "Check package.json dependencies")
-  Task(haiku, "Find usage of similar features in codebase")
+  Task("Analyze src/components/ for existing patterns")
+  Task("Check package.json dependencies")
+  Task("Find usage of similar features in codebase")
 </message>
 → All 3 run simultaneously, ~3x faster
 ```
 
 **WRONG — Sequential calls (DO NOT DO THIS):**
 ```
-<message>Task(haiku, "Analyze...")</message>
-<message>Task(haiku, "Check...")</message>
-<message>Task(haiku, "Find...")</message>
+<message>Task("Analyze...")</message>
+<message>Task("Check...")</message>
+<message>Task("Find...")</message>
 → 3x slower, wastes time
 ```
 
@@ -141,27 +125,27 @@ No status polling is needed — the harness re-invokes you when each background
 ```
 Phase N Start
     │
-    ├─→ [PARALLEL] Task(haiku) × 3: Exploration
+    ├─→ [PARALLEL] Task × 3: Exploration
     │       - Related code analysis
     │       - Dependency check
     │       - Pattern discovery
     │
     ↓ (all complete)
     │
-    ├─→ Opus: Synthesize and decide
+    ├─→ Synthesize and decide
     │
     ├─→ [PARALLEL PIPELINE] ←── KEY SPEED OPTIMIZATION
     │       │
-    │       ├─→ Main: Task(sonnet) Implementation
+    │       ├─→ Main: Task Implementation
     │       │
     │       └─→ Background (run_in_background=true):
-    │               ├─→ Task(haiku): Phase N+1 file analysis
-    │               ├─→ Task(haiku): Test case preparation
-    │               └─→ Task(haiku): Type/interface lookup
+    │               ├─→ Task: Phase N+1 file analysis
+    │               ├─→ Task: Test case preparation
+    │               └─→ Task: Type/interface lookup
     │
     ↓ (main completes)
     │
-    ├─→ Task(haiku): Tests (uses pre-generated cases)
+    ├─→ Task: Tests (uses pre-generated cases)
     │
     ↓
 Phase N Complete

package/skills/vibe.run/references/ultrawork-mode.md

@@ -10,7 +10,7 @@
 
 | Feature | Description |
 |---------|-------------|
-| **Parallel Exploration** | 3+ Task(haiku) agents run simultaneously (ACT 병렬화) |
+| **Parallel Exploration** | 3+ Task agents run simultaneously (ACT 병렬화) |
 | **Loop (기본 동작)** | 모든 실행의 기본 — exit=게이트 통과 또는 stuck 또는 max_iterations |
 | **Context Compression** | Aggressive auto-save at 70%+ context |
 | **No Pause** | stuck·SPEC 게이트 외 확인 없음 (`automationLevel: autonomous`) |

package/skills/vibe.spec/SKILL.md

@@ -99,7 +99,7 @@ ARGUMENTS: $ARGUMENTS
 | 입력 | 처리 |
 |---|---|
 | 자연어 요구사항 | 그대로 SPEC 패스의 주 입력 |
-| 📎 첨부 (md/txt/pdf/이미지 등) | Read 도구로 분석 후 요구사항에 병합 |
+| 📎 첨부 (md/txt/pdf/이미지 등) | 하네스의 파일 읽기 수단(CC `Read` 도구 / Codex 셸 등)으로 전체를 읽어 분석 후 요구사항에 병합 |
 | 파일 경로 인자 (PRD 등) | 존재 확인 후 Read — 첨부와 동일 취급 |
 | **레거시 아티팩트** `.vibe/interviews/{feature}.md`, `.vibe/plans/{feature}.md` | 존재하면 **입력 컨텍스트로만** 읽는다. 절대 요구하거나 재생성하지 않는다 — 없어도 정상 경로 |
 

package/vibe/rules/principles/dual-harness-doctrine.md

@@ -34,17 +34,18 @@
 
 CC의 풍부한 hook 모델(PreToolUse/PostToolUse/UserPromptSubmit/Stop)에는 Codex에 완전한 등가물이 없다. hook의 **의도**별로 하네스에 맞는 메커니즘에 매핑한다.
 
+Codex도 이제 네이티브 hook을 지원한다(`codex features list` → `hooks: stable`). vibe는 두 메커니즘을 **모두** 사용하며, hook의 **의도**별로 매핑한다.
+
 | hook 의도 | Claude Code | Codex |
 |---|---|---|
-| 라이프사이클 (turn 완료, 세션 시작/종료) | `Stop` / `SessionStart` hook | `config.toml`의 `notify` 프로그램 (agent-turn-complete 시 JSON 발화) |
-| pre-edit / scope guard | `PreToolUse` (동기 deny) | ❌ 동기 인터셉트 없음 → AGENTS.md 운영 규칙 + notify 기반 사후 검증 |
-| 키워드 디스패치 (ralph/ultrawork) | `UserPromptSubmit` | AGENTS.md 지시 (Codex가 직역 실행) |
-| 금지 패턴 차단 | `PreToolUse` | AGENTS.md 규칙 + 에이전트에게 실행하라 지시한 check 명령 |
+| 라이프사이클 (turn 완료) | `Stop` hook | `config.toml`의 `notify` (agent-turn-complete 시 JSON 발화) |
+| 세션 시작 | `SessionStart` hook | `.codex/hooks.json` → `SessionStart` |
+| pre-edit / scope guard | `PreToolUse` (동기 deny) | `.codex/hooks.json` → `PreToolUse` (동기 deny) |
+| 키워드 디스패치 | `UserPromptSubmit` | `.codex/hooks.json` → `UserPromptSubmit` |
+| 금지 패턴 차단 | `PreToolUse` | `PreToolUse` + AGENTS.md 규칙 (이중 방어) |
 
-**핵심 통찰: Codex의 직역 성향이 AGENTS.md "soft hook"을 신뢰성 있게 만든다.** CC는 soft 지시를 가끔 무시해 hard hook이 필요하지만, Codex는 적힌 대로 실행한다. 따라서:
+**구현**: `hooks/scripts/codex-hook-adapter.js`가 Codex hook 이벤트를 기존 vibe hook 스크립트로 번역하고 deny 결정(JSON)을 보존한다. 설치는 `installProjectCodexHooks()` → `.codex/hooks.json` (프로젝트 로컬, gitignored). 라이프사이클 후처리(auto-commit·devlog)는 `codex-notify.js`가 `notify` 경로로 담당한다.
 
-- **하드 라이프사이클 이벤트** → Codex `config.toml notify` (실제·결정적). `stop-dispatcher` 로직(auto-commit, devlog, review gate) 재사용 가능.
-- **행동 가드** → AGENTS.md 운영 규칙. 직역이라 *오히려* 신뢰성 있음.
-- **진짜 동기 pre-edit 차단은 Codex에서 불가** — 사후 검증을 완화책으로 수용한다.
+**핵심 통찰: Codex의 직역 성향이 AGENTS.md "soft hook"을 신뢰성 있게 만든다.** CC는 soft 지시를 가끔 무시해 hard hook이 필요하지만, Codex는 적힌 대로 실행한다. 따라서 AGENTS.md 운영 규칙은 네이티브 hook이 생긴 뒤에도 **폐기하지 않고 2차 방어선으로 유지한다** — hook이 설치되지 않은 환경(전역 설치만 한 경우, 다른 클론)에서도 가드가 남는다.
 
-> **Action item (미구현):** `.codex/settings.local.json`에 죽은 hook을 쓰는 것을 중단하고, 대신 `.codex/config.toml`에 `notify` 핸들러를 생성해 `stop-dispatcher` 로직을 재사용하며, 가드 규칙은 AGENTS.md로 방출한다.
+> ⚠️ **훅은 "설치돼 있다"고 가정하지 않는다.** 훅은 프로젝트 로컬 아티팩트라 `vibe upgrade` 만으로는 설치되지 않는다(전역 자산만 갱신). `vibe status` 가 하네스별 훅 설치 여부를 보고하고, `vibe upgrade` 는 현재 프로젝트의 누락 훅을 복구한다. 결정론적 가드의 생사는 **관측 가능해야** 한다 — 조용히 죽은 가드는 없는 가드보다 나쁘다.