oh-my-customcode 0.106.0 → 0.107.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -13,7 +13,7 @@
13
13
 
14
14
  **[한국어 문서 (Korean)](./README_ko.md)**
15
15
 
16
- 48 agents. 113 skills. 22 rules. One command.
16
+ 49 agents. 113 skills. 22 rules. One command.
17
17
 
18
18
  ```bash
19
19
  npm install -g oh-my-customcode && cd your-project && omcustom init
@@ -111,7 +111,7 @@ Agent(arch-documenter):haiku ┘
111
111
 
112
112
  ---
113
113
 
114
- ### Agents (48)
114
+ ### Agents (49)
115
115
 
116
116
  | Category | Count | Agents |
117
117
  |----------|-------|--------|
@@ -126,7 +126,7 @@ Agent(arch-documenter):haiku ┘
126
126
  | QA | 3 | qa-planner, qa-writer, qa-engineer |
127
127
  | Security | 1 | sec-codeql |
128
128
  | Managers | 6 | mgr-creator, mgr-updater, mgr-supplier, mgr-gitnerd, mgr-sauron, mgr-claude-code-bible |
129
- | System | 2 | sys-memory-keeper, sys-naggy |
129
+ | System | 3 | sys-memory-keeper, sys-naggy, tracker-checkpoint |
130
130
 
131
131
  Each agent declares its tools, model, memory scope, and limitations in YAML frontmatter. Tool budgets are enforced per agent type for accuracy.
132
132
 
@@ -271,7 +271,7 @@ omcustom serve-stop # Stop Web UI
271
271
  your-project/
272
272
  ├── CLAUDE.md # Entry point
273
273
  ├── .claude/
274
- │ ├── agents/ # 48 agent definitions
274
+ │ ├── agents/ # 49 agent definitions
275
275
  │ ├── skills/ # 113 skill modules
276
276
  │ ├── rules/ # 22 governance rules (R000-R021)
277
277
  │ ├── hooks/ # 15 lifecycle hook scripts
package/dist/cli/index.js CHANGED
@@ -2334,7 +2334,7 @@ var init_package = __esm(() => {
2334
2334
  workspaces: [
2335
2335
  "packages/*"
2336
2336
  ],
2337
- version: "0.106.0",
2337
+ version: "0.107.0",
2338
2338
  description: "Batteries-included agent harness for Claude Code",
2339
2339
  type: "module",
2340
2340
  bin: {
package/dist/index.js CHANGED
@@ -2014,7 +2014,7 @@ var package_default = {
2014
2014
  workspaces: [
2015
2015
  "packages/*"
2016
2016
  ],
2017
- version: "0.106.0",
2017
+ version: "0.107.0",
2018
2018
  description: "Batteries-included agent harness for Claude Code",
2019
2019
  type: "module",
2020
2020
  bin: {
package/package.json CHANGED
@@ -3,7 +3,7 @@
3
3
  "workspaces": [
4
4
  "packages/*"
5
5
  ],
6
- "version": "0.106.0",
6
+ "version": "0.107.0",
7
7
  "description": "Batteries-included agent harness for Claude Code",
8
8
  "type": "module",
9
9
  "bin": {
@@ -0,0 +1,72 @@
1
+ ---
2
+ name: tracker-checkpoint
3
+ description: Pipeline execution state tracker with checkpoint persistence. Reads/writes /tmp/.claude-pipeline-*-{PPID}.json state files and validates state transitions. Used by dag-orchestration for resume-after-failure and pipeline-guards for quality gate state.
4
+ model: sonnet
5
+ effort: medium
6
+ tools: [Read, Write, Edit, Bash, Glob, Grep]
7
+ memory: project
8
+ skills: [dag-orchestration, pipeline-guards]
9
+ domain: universal
10
+ permissionMode: bypassPermissions
11
+ ---
12
+
13
+ # Tracker Checkpoint Agent
14
+
15
+ ## Purpose
16
+
17
+ Pipeline 실행 상태를 persistent checkpoint 파일로 관리. `/pipeline resume`, `dag-orchestration`, `pipeline-guards`와 협력하여 실패 후 재개를 가능하게 합니다.
18
+
19
+ ## Capabilities
20
+
21
+ - Read/write `/tmp/.claude-pipeline-{name}-{PPID}.json` state files
22
+ - Validate state transitions (pending → running → completed | failed)
23
+ - Coordinate with dag-orchestration for step-level checkpointing
24
+ - Coordinate with pipeline-guards for gate-level state snapshots
25
+ - Support `/pipeline resume` by loading last known state
26
+
27
+ ## Workflow
28
+
29
+ ### 1. Pipeline Start (Bootstrap)
30
+ - Create `/tmp/.claude-pipeline-{name}-{PPID}.json` with initial state
31
+ - Record: pipeline name, started timestamp, total steps, current_step=0
32
+
33
+ ### 2. Per-Step Checkpoint
34
+ - After each step: update state file atomically
35
+ - Record: step name, status, duration_ms, output artifacts paths
36
+ - Status transitions: pending → running → completed | failed
37
+
38
+ ### 3. Failure Freeze
39
+ - On step failure: mark status=halted, preserve state for resume
40
+ - Capture: error message, stack trace (if any), partial artifacts
41
+
42
+ ### 4. Resume Coordination
43
+ - On `/pipeline resume`: scan `/tmp/.claude-pipeline-*-{PPID}.json`
44
+ - Return state to orchestrator: name, failed step, error, options (retry/skip/abort)
45
+ - On retry: reset failed step to pending, resume execution
46
+
47
+ ## State File Schema
48
+
49
+ ```json
50
+ {
51
+ "pipeline": "{name}",
52
+ "started": "ISO-8601",
53
+ "status": "running|completed|halted",
54
+ "current_step": 0,
55
+ "steps": [
56
+ {"name": "triage", "status": "completed", "duration_ms": 5000, "artifacts": []},
57
+ {"name": "plan", "status": "running"}
58
+ ]
59
+ }
60
+ ```
61
+
62
+ ## Integration Points
63
+
64
+ - `dag-orchestration` skill — step dependency resolution + tracker coordination
65
+ - `pipeline-guards` skill — guard gate state preservation
66
+ - `pipeline` skill — `/pipeline resume` state loader
67
+
68
+ ## Rules Compliance
69
+
70
+ - R006: Agent artifact; skills (dag-orchestration, pipeline-guards) are source
71
+ - R010: File modifications via Write/Edit (prefer over Bash for .claude/ paths)
72
+ - R017: Structural changes require sauron verification
@@ -234,26 +234,21 @@ Skills persist output to `.claude/outputs/sessions/{YYYY-MM-DD}/{skill-name}-{HH
234
234
 
235
235
  CC treats `.claude/` as a sensitive directory, enforced across **all tool categories** — Bash, Write, and Edit. The sensitive-path check runs **above** `bypassPermissions` and explicit allow rules (e.g., `Write(.claude/**)`), so operations on sensitive paths may trigger permission prompts regardless of settings.
236
236
 
237
- #### Scope
237
+ #### Sensitive Path Behavior
238
238
 
239
- | Path pattern | Sensitive? | Applies to |
240
- |--------------|-----------|-----------|
241
- | `.claude/**` | Yes | Bash (`cp`, `mkdir`, `rm`), Write, Edit |
242
- | `templates/.claude/**` | Yes | Bash, Write, Edit (confirmed v2.1.116+, 3x repeat v0.105.0 session) |
243
- | `.claude/outputs/**` | No (artifact convention) | |
244
-
245
- #### Behavior
246
-
247
- | Tool | Allow rule | Result |
248
- |------|-----------|--------|
249
- | `Bash(cp ...)` on `.claude/` | `Bash(*)` allowed | Prompt (sensitive-path overrides) |
250
- | `Write(.claude/**)` | `Write(.claude/**)` allowed | Prompt (sensitive-path overrides) |
251
- | `Edit(templates/.claude/**)` | `Edit(templates/.claude/**)` allowed | Prompt (sensitive-path overrides) |
239
+ | Path | Tool | Allow rule | Result |
240
+ |------|------|-----------|--------|
241
+ | `.claude/**` | Bash (`cp`, `mkdir`, `rm`) | `Bash(*)` allowed | Prompt (sensitive-path overrides) |
242
+ | `.claude/**` | Write, Edit | `Write(.claude/**)` allowed | Prompt (sensitive-path overrides) |
243
+ | `templates/.claude/**` | Write, Edit | `Write(templates/.claude/**)` allowed | Prompt (confirmed CC v2.1.116+; see #960, #961, #981) |
244
+ | `.claude/outputs/**` | Any | — | Allowed (artifact convention) |
252
245
 
253
246
  #### Recommended practice
254
247
 
255
- 1. **Prefer `Write`/`Edit` over `Bash(cp)`/`Bash(mkdir)`** — even though both trigger prompts, `Write`/`Edit` provide better auditability and avoid shell injection risk
248
+ 1. **Prefer `Write`/`Edit` over `Bash(cp)`/`Bash(mkdir)`** — `Write`/`Edit` provide better auditability and avoid shell injection risk
256
249
  2. **Add allow rules defensively** — `Write(.claude/**)`, `Edit(.claude/**)`, `Write(templates/.claude/**)`, `Edit(templates/.claude/**)` in `.claude/settings.local.json`. Rules may not bypass sensitive-path check but document intent and aid future CC behavior changes
250
+
251
+ <!--
257
252
  3. **Accept interactive prompts as a release-pipeline constraint** — `templates/.claude/` sync during release automation requires human approval; plan release windows accordingly
258
253
  4. **This is CC design behavior, not a bug** — sensitive-path check is a defense-in-depth layer. File upstream as a documentation request (not bug report) if behavior is unclear
259
254
 
@@ -261,6 +256,7 @@ CC treats `.claude/` as a sensitive directory, enforced across **all tool catego
261
256
 
262
257
  - `feedback_sensitive_path.md` — session memory with Bash + Write scope (#960, #961, #981)
263
258
  - `feedback_templates_claude_glob.md` — `.claude/**` glob does not cover `templates/.claude/**`, separate allow rules required
259
+ -->
264
260
 
265
261
  ### Artifact Channel Protocol
266
262
 
@@ -57,7 +57,7 @@ nodes:
57
57
  depends_on: [test, review, docs]
58
58
 
59
59
  config:
60
- max_parallel: 4 # R009 limit
60
+ max_parallel: 4 # R009 soft default (hard cap: 5)
61
61
  failure_strategy: stop # stop | skip | retry
62
62
  retry_count: 2 # Max retries per node (if strategy=retry)
63
63
  timeout_per_node: 300 # Seconds per node (0 = no limit)
@@ -76,7 +76,11 @@ config:
76
76
  c. On completion:
77
77
  - Success → decrement in-degree of dependents
78
78
  - Failure → apply failure_strategy
79
- d. Enqueue newly-ready nodes (in-degree = 0)
79
+ d. Stall check:
80
+ - If running node duration > 2x average completed duration
81
+ - AND pending nodes exist with in-degree = 0 (ignoring stalled node's edges)
82
+ - THEN enqueue those independent nodes immediately (adaptive split)
83
+ e. Enqueue newly-ready nodes (in-degree = 0)
80
84
  6. Verify all nodes executed (detect unreachable nodes)
81
85
  ```
82
86
 
@@ -84,11 +88,12 @@ config:
84
88
 
85
89
  | Rule | Detail |
86
90
  |------|--------|
87
- | Max parallel | 4 concurrent nodes (R009) |
91
+ | Max parallel | 5 concurrent nodes max, 4 default (R009) |
88
92
  | Agent Teams gate | 3+ parallel nodes → check R018 eligibility |
89
93
  | Orchestrator only | DAG scheduling runs in main conversation (R010) |
90
94
  | Node execution | Each node = one Task tool call to specified agent |
91
95
  | State tracking | `/tmp/.claude-dag-$PPID.json` |
96
+ | Stall detection | Running node > 2x avg completed duration → enqueue independent pending nodes early |
92
97
 
93
98
  ## Failure Strategies
94
99
 
@@ -193,9 +198,47 @@ Execute? [Y/n]
193
198
 
194
199
  The orchestrator builds the DAG from this inline format and executes using the same algorithm.
195
200
 
201
+ ## State Management via tracker-checkpoint
202
+
203
+ Pipeline 상태는 `tracker-checkpoint` 에이전트로 위임됩니다.
204
+
205
+ ### Flow
206
+
207
+ 1. Pipeline 시작 → orchestrator가 tracker-checkpoint 호출 → 초기 state 파일 생성 (`/tmp/.claude-pipeline-{name}-{PPID}.json`)
208
+ 2. 각 step 후 → tracker-checkpoint가 state 업데이트 (atomic write)
209
+ 3. step 실패 → tracker-checkpoint가 halted 상태로 freeze
210
+ 4. `/pipeline resume` → tracker-checkpoint가 state 로드 → orchestrator에 복원 옵션 제공
211
+
212
+ ### Integration
213
+
214
+ - PPID-scoped state file 경로: `/tmp/.claude-pipeline-{name}-{PPID}.json`
215
+ - step 실행 전후로 tracker-checkpoint delegation
216
+ - resume 시 checkpoint → dag 재빌드 → 미완료 step부터 재개
217
+
218
+ See `.claude/agents/tracker-checkpoint.md` for agent spec.
219
+
196
220
  ## Limitations
197
221
 
198
222
  - No cycles allowed (DAG = acyclic)
199
223
  - Max 20 nodes per workflow (complexity guard)
200
224
  - Nested DAGs not supported (flatten instead)
201
225
  - Cross-workflow dependencies not supported
226
+
227
+ ## External References
228
+
229
+ ### Multica — Managed Agent Platform
230
+
231
+ > Reference: [Multica](https://github.com/multica-ai/multica) — managed agent platform for Claude Code/Codex.
232
+ > Verdict: INTEGRATE (external reference, not internalize)
233
+
234
+ Multica's task lifecycle pattern (enqueue → claim → start → complete/fail) is a useful reference for DAG node state management:
235
+
236
+ | Multica State | DAG Equivalent | Notes |
237
+ |---------------|---------------|-------|
238
+ | enqueue | pending | Node waiting for dependencies |
239
+ | claim | ready | Dependencies resolved, ready to execute |
240
+ | start | running | Agent spawned and executing |
241
+ | complete | completed | Node finished successfully |
242
+ | fail | failed | Node execution failed |
243
+
244
+ Consider this pattern when extending DAG node state tracking or implementing retry logic.
@@ -19,11 +19,13 @@ Defines mandatory safety constraints for all pipeline, workflow, and iterative e
19
19
  | Max iterations | 3 | 5 | worker-reviewer-pipeline |
20
20
  | Max DAG nodes | 20 | 30 | dag-orchestration |
21
21
  | Max parallel agents | 4 | 5 | R009 (all pipelines) |
22
+ | Max parallel steps | 4 | 4 | pipeline parallel blocks |
22
23
  | Timeout per node | 300s | 600s | dag-orchestration nodes |
23
24
  | Timeout per pipeline | 900s | 1800s | worker-reviewer-pipeline |
24
25
  | Max retry count | 2 | 3 | Failure retry strategies |
25
26
  | Max PR improvement items | 20 | 50 | pr-auto-improve |
26
27
  | Max auto-improve items | 20 | 50 | omcustom-auto-improve |
28
+ | Max files per agent | 10 | 15 | All agent spawns (advisory) |
27
29
 
28
30
  ## Enforcement
29
31
 
@@ -82,6 +84,23 @@ When guards are triggered, they integrate with existing advisory systems:
82
84
  | Timeout approaching (80%) | → warn user, suggest early termination |
83
85
  | Hard cap hit | → force stop, report to user |
84
86
 
87
+ ## Task Granularity Guard
88
+
89
+ Advisory guard for agent task scope. When a single agent is assigned too many files, it becomes a bottleneck in parallel execution.
90
+
91
+ | Signal | Default | Action |
92
+ |--------|---------|--------|
93
+ | Files per agent > 10 | Advisory warning | Suggest splitting by layer/domain |
94
+ | Files per agent > 15 | Hard warning | Require explicit user override |
95
+
96
+ Display:
97
+ ```
98
+ [Guard] ⚠ Agent assigned {n} files (> 10) — consider splitting by layer
99
+ [Guard] 🛑 Agent assigned {n} files (> 15) — requires explicit override
100
+ ```
101
+
102
+ This integrates with R009 Adaptive Parallel Splitting: if a stalled agent is detected AND it was assigned > 10 files, the splitting recommendation is stronger.
103
+
85
104
  ## Guard Configuration
86
105
 
87
106
  Pipelines can override defaults (within hard caps):
@@ -157,6 +176,26 @@ Guard warnings appear inline:
157
176
  | omcustom-auto-improve | Auto-improve item count limits |
158
177
  | stuck-recovery | Guard triggers feed into stuck detection |
159
178
  | model-escalation | Repeated failures trigger escalation advisory |
179
+ | task-decomposition | Subtask file counts validated against granularity guard thresholds |
180
+
181
+ ## Checkpoint Gate Integration
182
+
183
+ 각 guard 통과/실패 시 `tracker-checkpoint` 에이전트로 gate state 기록.
184
+
185
+ ### Flow
186
+
187
+ 1. Guard 진입 → tracker-checkpoint에 gate state: running 기록
188
+ 2. Guard 통과 → tracker-checkpoint에 gate state: passed + metrics 기록
189
+ 3. Guard 실패 → tracker-checkpoint에 gate state: failed + failure reason freeze
190
+ 4. 다음 단계는 checkpoint state 참조하여 재개/중단 판단
191
+
192
+ ### Benefits
193
+
194
+ - 긴 파이프라인에서 guard 지점마다 복원점 확보
195
+ - 부분 실패 시 직전 guard 지점부터 재시도 가능 (비용 절감)
196
+ - guard metrics 축적으로 품질 추이 관찰 가능
197
+
198
+ See `.claude/agents/tracker-checkpoint.md` for the tracker spec.
160
199
 
161
200
  ## Override Policy
162
201
 
@@ -2,7 +2,7 @@
2
2
  name: sdd-dev
3
3
  description: Spec-Driven Development workflow — enforces sdd/ folder hierarchy with planning-first gates, current-state artifacts, and completion verification
4
4
  scope: core
5
- version: 1.0.0
5
+ version: 1.1.0
6
6
  user-invocable: true
7
7
  argument-hint: "[task description or leave empty for guided workflow]"
8
8
  ---
@@ -27,7 +27,8 @@ sdd/
27
27
  ├── 03_build/ # Current build state, implementation notes
28
28
  ├── 04_verify/ # Verification evidence, test results, residual risks
29
29
  ├── 05_operate/ # Deployment notes, runbooks (conditional)
30
- └── 99_toolchain/ # Tool configs, scripts, environment setup
30
+ ├── 99_toolchain/ # Tool configs, scripts, environment setup
31
+ └── decisions/ # Decision records for major design choices
31
32
  ```
32
33
 
33
34
  **Key Principle**: These folders are **current-state artifacts**, not history archives. Each file reflects the current state of the work — update in place rather than appending new versions.
@@ -44,7 +45,7 @@ ls sdd/ 2>/dev/null || echo "sdd/ folder not found"
44
45
 
45
46
  If `sdd/` does not exist:
46
47
  1. Inform the user that SDD workflow requires a `sdd/` folder
47
- 2. Offer to create the folder structure: `mkdir -p sdd/{01_planning,02_plan,03_build,04_verify,05_operate,99_toolchain}`
48
+ 2. Offer to create the folder structure: `mkdir -p sdd/{01_planning,02_plan,03_build,04_verify,05_operate,99_toolchain,decisions}`
48
49
  3. Ask user to confirm before proceeding
49
50
 
50
51
  If `sdd/` exists, continue to Step 1.
@@ -121,6 +122,7 @@ Artifact to produce or update: `sdd/03_build/current.md`
121
122
 
122
123
  ## Decisions Made
123
124
  - {decision}: {rationale}
125
+ - Write DR for major decisions: sdd/decisions/{YYYY-MM-DD}-{topic}.md (template: templates/decision-record.md)
124
126
 
125
127
  ## Known Issues
126
128
  - {issue}: {planned resolution}
@@ -235,6 +237,18 @@ Final display:
235
237
  3. **Checkboxes reflect reality**: Do NOT pre-check criteria. Update checkboxes as work is verified.
236
238
  4. **Residual risks are honest**: List known risks even after passing. Hiding risks defeats the purpose.
237
239
 
240
+ ## Decision Record Template
241
+
242
+ Major design decisions during Step 3 are recorded in `sdd/decisions/{YYYY-MM-DD}-{topic}.md` using the template at `templates/decision-record.md` (relative to this skill directory).
243
+
244
+ When to create a Decision Record:
245
+ - Architectural choice between 2+ viable options
246
+ - Trade-off accepted (e.g., complexity for performance)
247
+ - Deferred decision (waiting for data/approval)
248
+ - Superseding a previous decision
249
+
250
+ See `guides/harness-engineering/` for harness-level decision context that DRs may reference.
251
+
238
252
  ## Integration with Other Skills
239
253
 
240
254
  | Skill | When to Use Together |
@@ -0,0 +1,45 @@
1
+ ---
2
+ title: {Decision title}
3
+ date: YYYY-MM-DD
4
+ status: proposed | accepted | superseded | deprecated
5
+ context: guides/harness-engineering/README.md
6
+ decision_makers: [{agent or role}]
7
+ ---
8
+
9
+ # {Decision title}
10
+
11
+ ## Context
12
+
13
+ {What is the problem and why is a decision needed? Include relevant constraints, goals, and the situation that makes this decision necessary.}
14
+
15
+ ## Options Considered
16
+
17
+ 1. **Option A**: {Description}
18
+ - Pros: {benefits}
19
+ - Cons: {drawbacks, trade-offs}
20
+
21
+ 2. **Option B**: {Description}
22
+ - Pros: {benefits}
23
+ - Cons: {drawbacks, trade-offs}
24
+
25
+ 3. **Option C** *(if applicable)*: {Description}
26
+ - Pros: {benefits}
27
+ - Cons: {drawbacks, trade-offs}
28
+
29
+ ## Decision
30
+
31
+ **Chosen**: Option {A|B|C}
32
+
33
+ {Explain the rationale for the choice. Why does this option best satisfy the constraints and goals from the Context section?}
34
+
35
+ ## Consequences
36
+
37
+ - **Positive**: {What improves as a result of this decision}
38
+ - **Negative**: {Trade-offs and costs accepted}
39
+ - **Risks**: {Future considerations, potential issues to monitor}
40
+
41
+ ## References
42
+
43
+ - guides/harness-engineering/README.md
44
+ - {related skill or agent, e.g. .claude/skills/action-validator/SKILL.md}
45
+ - {link to issue or PR if applicable}
@@ -114,7 +114,7 @@ oh-my-customcode로 구동됩니다.
114
114
  project/
115
115
  +-- CLAUDE.md # 진입점
116
116
  +-- .claude/
117
- | +-- agents/ # 서브에이전트 정의 (48 파일)
117
+ | +-- agents/ # 서브에이전트 정의 (49 파일)
118
118
  | +-- skills/ # 스킬 (113 디렉토리)
119
119
  | +-- rules/ # 전역 규칙 (R000-R022)
120
120
  | +-- hooks/ # 훅 스크립트 (보안, 검증, HUD)
@@ -173,8 +173,8 @@ oh-my-customcode는 소프트웨어 컴파일과 동일한 구조를 따릅니
173
173
  | Infra Engineer | 2 | infra-docker-expert, infra-aws-expert |
174
174
  | QA Team | 3 | qa-planner, qa-writer, qa-engineer |
175
175
  | Manager | 6 | mgr-creator, mgr-updater, mgr-supplier, mgr-gitnerd, mgr-sauron, mgr-claude-code-bible |
176
- | System | 3 | sys-memory-keeper, sys-naggy, wiki-curator |
177
- | **총계** | **48** | |
176
+ | System | 4 | sys-memory-keeper, sys-naggy, tracker-checkpoint, wiki-curator |
177
+ | **총계** | **49** | |
178
178
 
179
179
  ## Agent Teams (MUST when enabled)
180
180
 
@@ -0,0 +1,93 @@
1
+ # PAL Router vs model-escalation — Cost Routing Analysis
2
+
3
+ > Source: #992 (ouroboros PAL Router internalization analysis)
4
+ > Date: 2026-04-24
5
+ > Release: v0.107.0
6
+
7
+ ## Executive Summary
8
+
9
+ **Decision**: Option C — Defer + observe
10
+
11
+ Current model-escalation system's actual failure and escalation frequency is unmeasured. Premature PAL Router internalization without baseline data risks double-routing complexity without clear benefit. Introduce escalation metrics first, re-evaluate after 3 months of data collection.
12
+
13
+ ## Background
14
+
15
+ ### model-escalation (현재)
16
+ - 철학: reactive — 실패 후 상위 모델 재시도
17
+ - 트리거: 에이전트 실패 횟수 임계치 (기본 2회)
18
+ - 경로: haiku → sonnet → opus
19
+ - R016 연계: 연속 실패 패턴 감지 시 스킬 업데이트 후보
20
+
21
+ ### PAL Router (ouroboros)
22
+ - 철학: proactive — 사전 복잡도 평가
23
+ - 트리거: 작업 입력의 복잡도 스코어 (프롬프트 길이, 키워드, 파일 범위)
24
+ - 비용 티어: 1x (haiku, $0.25/M) / 10x (sonnet, $3/M) / 30x (opus, $15/M)
25
+ - 장점: 오버킬/언더킬 최소화, 초기 티어 자동 선택
26
+
27
+ ## Comparison Matrix
28
+
29
+ | 기준 | model-escalation (현재) | PAL Router (ouroboros) |
30
+ |------|------------------------|----------------------|
31
+ | 철학 | Reactive | Proactive |
32
+ | 실패 복구 | 자동 escalation | N/A (사전 선택) |
33
+ | 초기 비용 | 최저 (haiku) | 복잡도 맞춤 |
34
+ | 오버킬 위험 | 낮음 (점진 증가) | 중간 (threshold 민감) |
35
+ | 언더킬 위험 | 중간 (1회 실패 후 해결) | 낮음 (사전 적정) |
36
+ | 구현 복잡도 | 기존 활용 | 신규 복잡도 평가 로직 |
37
+ | 비용 효율 | 실패율 낮으면 최적 | 복잡도 예측 정확하면 최적 |
38
+ | 부작용 | 실패 시 재실행 오버헤드 | 오분류 시 과도한 비용 |
39
+ | 디버깅 | escalation trace 명확 | 복잡도 스코어 설명 필요 |
40
+
41
+ ## Option A — pal-cost-routing 신설 스킬
42
+
43
+ **장점**:
44
+ - 명확한 관심사 분리 (proactive ≠ reactive, 독립)
45
+ - model-escalation과 orthogonal (양쪽 활성 가능)
46
+ - ouroboros 구현 참조 직접 활용
47
+
48
+ **단점**:
49
+ - 스킬 카운트 113 → 114 (context fork cap 12/12 포화 상태, fork 스킬 아니므로 무관하긴 함)
50
+ - 라우팅 결정 보드에 두 메커니즘 공존 → decision boundary 명시 필요
51
+ - 복잡도 스코어 튜닝 비용 (프로젝트마다 분포 다름)
52
+
53
+ ## Option B — model-escalation 확장 (pre-assessment 추가)
54
+
55
+ **장점**:
56
+ - 단일 스킬에서 reactive + proactive 통합
57
+ - 사용자 단일 진입점
58
+ - 마이그레이션 불필요 (기존 호출부 유지)
59
+
60
+ **단점**:
61
+ - 스킬 스코프 확장 → 단일 책임 원칙 희석
62
+ - 기존 advisory-first 특성과 pre-assessment의 predictive 특성 충돌 가능
63
+ - 테스트 복잡도 증가 (두 플로우 경로)
64
+
65
+ ## Option C — Defer + observe (권장)
66
+
67
+ **근거**:
68
+ 1. **데이터 부재**: model-escalation 현재 실패율, escalation 빈도, 시간당 비용 메트릭이 없음
69
+ 2. **선제 내재화의 함정**: 내재화 없이도 기존 시스템이 충분한지 증거 부재
70
+ 3. **측정 가능성**: R012 HUD statusline에 escalation 카운터 추가는 경량 작업
71
+
72
+ **행동 계획**:
73
+ - Phase 1 (즉시): R012 statusline에 `ESC:{count}/{total}` 지표 추가
74
+ - Phase 2 (4주): model-escalation 스킬이 로그 파일에 escalation 기록 축적
75
+ - Phase 3 (3개월): 데이터 분석 — 실패 → escalation 빈도, 비용 절감률, 오버킬 패턴
76
+ - Phase 4 (결정): 데이터 기반으로 Option A vs B vs 현상 유지 재평가
77
+
78
+ ## Recommendation
79
+
80
+ **Option C**로 진행. #992를 closed 처리 (분석 완료), Phase 1-2 구현은 별도 P3 이슈로 트래킹.
81
+
82
+ ## Decision Record
83
+
84
+ To be created when implementation path is finalized (Phase 4):
85
+ - `sdd/decisions/2026-XX-XX-pal-router-internalization.md` (per #985 DR template)
86
+
87
+ ## References
88
+
89
+ - #992 (source issue)
90
+ - #966 (ouroboros 저장소 재평가)
91
+ - `.claude/skills/model-escalation/SKILL.md`
92
+ - `.claude/rules/SHOULD-hud-statusline.md` (R012 statusline 통합 지점)
93
+ - ouroboros PAL Router docs (GitHub)
@@ -0,0 +1,61 @@
1
+ # Claude Code Version Compatibility
2
+
3
+ > Updated: 2026-04-24
4
+ > Source: Claude Code release notes (#967, #968, #969 auto-detected by claude-native skill)
5
+
6
+ ## Compatibility Baseline
7
+
8
+ oh-my-customcode v0.107.0 targets Claude Code v2.1.116+. All v2.1.117-119 additions are backward-compatible — no config changes required.
9
+
10
+ ## v2.1.117 (2026-04-22)
11
+
12
+ **Key changes relevant to oh-my-customcode:**
13
+
14
+ - `CLAUDE_CODE_FORK_SUBAGENT=1` enables forked subagents on external builds — relevant for R018 Agent Teams expansion
15
+ - Main-thread agent `mcpServers` frontmatter loading via `--agent` — broadens MCP integration scope (affects sys-memory-keeper, claude-mem users)
16
+ - `/model` persistence across restarts — reduces repeated model selection in long sessions
17
+ - `/resume` summarization of stale sessions — aligns with R013 ecomode context budget
18
+ - Concurrent MCP server startup — shorter session bootstrap
19
+
20
+ **Action items**: None. Features are additive.
21
+
22
+ ## v2.1.118 (2026-04-23)
23
+
24
+ **Key changes relevant to oh-my-customcode:**
25
+
26
+ - `/cost` + `/stats` → merged into `/usage` — update CLAUDE.md quick-reference if these appear (they don't in current docs)
27
+ - Vim visual modes (`v`, `V`) — orthogonal to harness
28
+ - Custom themes via `~/.claude/themes/` + plugin `themes/` directory — R012 HUD statusline unaffected
29
+ - **Hooks can invoke MCP tools directly (`type: "mcp_tool"`)** — new hook capability, R022 wiki-sync or memory hooks could benefit
30
+ - `DISABLE_UPDATES` env var — stricter than `DISABLE_AUTOUPDATER`
31
+
32
+ **Action items**: Consider R022/R011 hooks migration to `type: "mcp_tool"` for direct wiki/memory integration (P3 follow-up).
33
+
34
+ ## v2.1.119 (2026-04-23)
35
+
36
+ **Key changes relevant to oh-my-customcode:**
37
+
38
+ - `/config` persistence to `~/.claude/settings.json` with proper override precedence — project/local/policy stacking more predictable
39
+ - `prUrlTemplate` setting — useful if mirroring to GitHub Enterprise or GitLab
40
+ - `CLAUDE_CODE_HIDE_CWD` env var — cosmetic
41
+ - `--from-pr` now accepts GitLab MR, Bitbucket PR, GitHub Enterprise URLs — widens reviewer scenarios
42
+ - **`--print` mode honors agent `tools:` and `disallowedTools:` frontmatter** — fixes a long-standing gap, relevant for CI runs using `--print`
43
+
44
+ **Action items**: Verify `--print` based CI scripts (if any) work correctly with restricted-tools agents like `arch-documenter` (which has `disallowedTools: [Bash]`).
45
+
46
+ ## Action Items Summary
47
+
48
+ | Version | oh-my-customcode action | Priority |
49
+ |---------|------------------------|----------|
50
+ | v2.1.117 | None (additive) | — |
51
+ | v2.1.118 | Evaluate hooks `type: mcp_tool` for R022/R011 | P3 follow-up |
52
+ | v2.1.119 | Audit `--print` CI with disallowedTools agents | P3 follow-up |
53
+
54
+ ## References
55
+
56
+ - #967 — Claude Code v2.1.117 release note
57
+ - #968 — Claude Code v2.1.118 release note
58
+ - #969 — Claude Code v2.1.119 release note
59
+ - `.claude/skills/claude-native/` — auto-generation source
60
+ - `.claude/rules/SHOULD-hud-statusline.md` — R012 statusline integration
61
+ - `.claude/rules/MUST-agent-design.md` — R006 agent frontmatter spec
@@ -46,9 +46,9 @@ Deep Insight가 제안하는 4계층 구조는 oh-my-customcode에 이미 구현
46
46
  메인 대화 → Agent(mgr-creator, mode: "bypassPermissions") → Write(".claude/agents/new.md", content)
47
47
  ```
48
48
 
49
- ### Tracker 체크포인트 패턴 (v0.106.0+ 이관)
49
+ ### Tracker 체크포인트 패턴
50
50
 
51
- 현재 파이프라인 상태 추적은 `/tmp/.claude-pipeline-{PID}.json` 파일과 `.claude/outputs/sessions/{YYYY-MM-DD}/` 아티팩트 규약으로 구현되어 있습니다. 전용 Tracker 에이전트(dag-orchestration / pipeline-guards 통합형) `context: fork` cap 확장 이후 후속 릴리즈로 이관합니다.
51
+ 현재 파이프라인 상태 추적은 `/tmp/.claude-pipeline-{PID}.json` 파일과 `.claude/outputs/sessions/{YYYY-MM-DD}/` 아티팩트 규약으로 구현되어 있습니다. ✅ 구현 완료 (v0.106.1 via #983 — `.claude/agents/tracker-checkpoint.md`): 전용 Tracker 에이전트(dag-orchestration / pipeline-guards 통합형) 배포되어 checkpoint persistence, resume-after-failure, gate state 기록을 담당합니다.
52
52
 
53
53
  ---
54
54
 
@@ -185,7 +185,7 @@ opt-in: hard-enforce (filter 모드, --hard-enforce 플래그) — 명시적 사
185
185
 
186
186
  | 항목 | 이관 이유 | 예상 릴리즈 |
187
187
  |------|----------|-----------|
188
- | **Tracker 체크포인트 에이전트** — dag-orchestration / pipeline-guards 통합형 전용 Tracker | `context: fork` cap(현재 12/12) 확장 필요 | v0.106.0+ |
188
+ | **Tracker 체크포인트 에이전트** — dag-orchestration / pipeline-guards 통합형 전용 Tracker | 구현 완료 (v0.106.1 via #983 — `.claude/agents/tracker-checkpoint.md`) | |
189
189
  | **hierarchical-agent-topology 스킬** — 4계층 구조를 자동 검증하는 전용 스킬 | fork 스킬 cap 해소 후 추가 | v0.106.0+ |
190
190
  | **sdd-dev Harness Decision Record 템플릿** — 하네스 설계 결정을 ADR 형식으로 기록 | sdd-dev 스킬 업데이트와 병행 | v0.107.0+ |
191
191
  | **harness-synthesizer 2단계 격리 구현 예시** — Base64 인코딩 + subprocess 격리의 실제 YAML 예시 | 보안 리뷰 후 추가 | v0.107.0+ |
@@ -1,5 +1,5 @@
1
1
  {
2
- "version": "0.106.0",
2
+ "version": "0.107.0",
3
3
  "lastUpdated": "2026-04-24T07:30:00.000Z",
4
4
  "components": [
5
5
  {
@@ -12,7 +12,7 @@
12
12
  "name": "agents",
13
13
  "path": ".claude/agents",
14
14
  "description": "AI agent definitions (flat .md files with prefixes)",
15
- "files": 48
15
+ "files": 49
16
16
  },
17
17
  {
18
18
  "name": "skills",