oh-my-customcode 1.1.50 → 1.1.52

package/dist/cli/index.js

@@ -243,7 +243,7 @@ var init_package = __esm(() => {
     workspaces: [
       "packages/*"
     ],
-    version: "1.1.50",
+    version: "1.1.52",
     description: "Batteries-included agent harness for Claude Code",
     type: "module",
     bin: {

package/dist/index.js

@@ -2031,7 +2031,7 @@ var package_default = {
   workspaces: [
     "packages/*"
   ],
-  version: "1.1.50",
+  version: "1.1.52",
   description: "Batteries-included agent harness for Claude Code",
   type: "module",
   bin: {

package/package.json

@@ -3,7 +3,7 @@
   "workspaces": [
     "packages/*"
   ],
-  "version": "1.1.50",
+  "version": "1.1.52",
   "description": "Batteries-included agent harness for Claude Code",
   "type": "module",
   "bin": {

package/templates/.claude/rules/MUST-agent-design.md

@@ -194,6 +194,8 @@ Hook JSON output `terminalSequence` field for desktop notifications, window titl
 
 > **`MessageDisplay`는 표시 전용 — `additionalContext` 미지원**: `MessageDisplay`는 `hookSpecificOutput.displayContent`로 **화면 표시 텍스트만** 교체하며, 트랜스크립트와 Claude가 보는 내용은 원본이 유지된다. 따라서 advisory 훅을 `MessageDisplay`에 배선하면 **모델에 도달하지 않는다**. `additionalContext`(모델 컨텍스트 주입)를 지원하는 이벤트는 SessionStart, Setup, SubagentStart, UserPromptSubmit, UserPromptExpansion, PreToolUse, PostToolUse, PostToolUseFailure, PostToolBatch, Stop, SubagentStop이다. (이전 판이 나열하던 `PostMessage`는 문서화된 이벤트가 아니다 — 실제 이벤트명은 `MessageDisplay`.)
 
+> **문서 시차 노트 — `PreModelSwitch`/`PostModelSwitch` 및 `PostCompact`**: 33종 중 `PreModelSwitch`/`PostModelSwitch`(v2.1.251)는 CHANGELOG(2026-08-28)에는 명시되나 공식 hooks.md "Hook events" 카탈로그 페이지에는 실측일(2026-08-29) 기준 헤더가 없다 — changelog→hooks.md 반영 시차로 판단(오류 아님, hook-events-audit 2026-08-29 실측). 또한 `PostCompact`는 공식 문서상 `additionalContext`/decision-control이 정의돼 있지 않다 — 재주입(compact 후 규칙 재주입) 용도로는 `PostCompact`가 아니라 `SessionStart`(matcher `*`)를 쓸 것(cross-ref R021 「Prompt-based」 각주). PostCompact dispatch 경로는 바이너리 실측으로 실재 확인(2026-08-29 probe) — 상세는 R021 각주.
+
 > **신규 이벤트 발동 시점**: `Setup` — `--init-only`, 또는 `-p` 모드에서 `--init`/`--maintenance`로 시작할 때. `UserPromptExpansion` — 사용자가 입력한 커맨드가 프롬프트로 확장될 때(모델 도달 전; 확장 차단 가능). `PostToolUseFailure` — 도구 호출이 실패한 뒤. `PostToolBatch` — 병렬 도구 호출 배치 전체가 끝난 뒤, 다음 모델 호출 전. `MessageDisplay` — assistant 메시지 텍스트가 표시되는 동안(실시간 스트리밍). `DirectoryAdded` (v2.1.219+) — `/add-dir` 또는 SDK `register_repo_root`로 작업 디렉토리가 세션 중 추가될 때. (그 밖의 신규 이벤트 — `PermissionRequest`, `StopFailure`, `InstructionsLoaded`, `ConfigChange`, `WorktreeCreate`, `WorktreeRemove` — 는 발동 시점을 미실측이므로 서술하지 않는다.)
 
 <!-- DETAIL: Hook Event Types Full Reference
@@ -202,8 +204,8 @@ Hook JSON output `terminalSequence` field for desktop notifications, window titl
 |-------|---------|---------------|---------------|------------|
 | `PreToolUse` | Before tool execution | tool, tool_input | command, prompt | v2.1.63+ |
 | `PostToolUse` | After tool execution | tool, tool_input, tool_output | command, prompt | v2.1.63+ |
-| `PreCompact` | Before context compaction | — | command, prompt | v2.1.76+ |
-| `PostCompact` | After context compaction | — | command, prompt | v2.1.76+ |
+| `PreCompact` | Before context compaction | trigger | command, prompt | v2.1.76+ |
+| `PostCompact` | After context compaction | trigger, compact_summary | command, prompt | v2.1.76+ |
 | `Stop` | Session ending | — | command, prompt | v2.1.63+ |
 | `SessionStart` | Session begins | — | command | v2.1.63+ |
 | `SessionEnd` | Session fully closes | — | command | v2.1.76+ |

package/templates/.claude/rules/MUST-completion-verification.md

@@ -135,6 +135,13 @@ Cross-reference: R018 (Member Completion Verification), `feedback_release_delega
 3. **설명력**: 이것은 **왜 clause 강화가 14회 내내 실패했는지**를 설명한다 — 에이전트에게 "종료하지 말라"고 지시해도 **절단 주체가 에이전트가 아니면 지시가 닿지 않는다**. 역으로 「위임 경계를 Phase 개수로 설계」가 효과적이었던 이유도 설명된다: 작업이 작으면 턴 한도 안에 끝나기 때문이지 에이전트가 더 순종적이어서가 아니다.
 4. **정량 기준 신설**: 위임 크기 판정을 "Phase가 몇 개인가"에서 **"필요 tool call이 20턴 안에 들어가는가"**로 바꾼다. 파일 1개당 Read + Edit + 미러 Edit + diff 확인 = 약 4턴이므로, **파일 편집형 위임은 담당 파일 4~5개가 실질 상한**이다. v1.1.50 세션의 절단 3건은 담당 파일이 각각 4개·3개·7개였고 파일당 신규 노트 추가·은퇴 판정·미러 동기화를 함께 요구했다 — 산술적으로 20턴에 들어갈 수 없는 위임이었다. **이는 에이전트의 실패가 아니라 오케스트레이터의 위임 설계 결함이다.**
 5. **완화책**: 미러 동기화처럼 **후행 필수 작업은 마지막에 몰지 말고 파일 단위로 즉시 수행**한다 — 절단은 항상 마지막 작업을 자르므로, 마지막에 몰린 작업은 절단 시 전량 유실된다.
+6. **정량 기준 정밀화 — 산술 단위는 파일이 아니라 편집 항목 (Origin: #1621 #2a, v1.1.51 세션)**: 위 4항의 "파일 4~5개 상한"은 신설 당일 재절단을 막지 못했다 — R017 그룹은 담당 6파일로 상한 인접이었으나, 실제 초과 원인은 파일 수가 아니라 **조항 2개 신설**이었다. 파일당 편집 항목이 1개라는 암묵 가정이 깨지면 파일 수 기준 산술이 무의미해진다. 위임 크기 산술의 단위는 **편집 항목 수**(신설 조항 1개, 버전 노트 1개, 사본 배선 1개 등)로 바꾼다: **항목당 약 2턴(Edit + 위치 탐색) + 파일당 고정비(Read 1 + 미러 Edit 1 + diff 1 = 3턴)**로 계산한다. 같은 세션에서 4파일·항목 소수 위임들은 완주해 대조를 이룬다.
+7. **리서치형 위임의 산출물 우선 기록 (Origin: #1621 #2b, v1.1.51 세션)**: 파일 편집형뿐 아니라 리서치형(수집 중심) 위임도 절단에 취약하다 — v1.1.51 세션에서 훅 이벤트 감사 위임이 22회 도구 호출(WebFetch/Read)을 전부 수집에 쓰고 **아티팩트를 1회도 Write하지 않은 채 절단**되어, 수집한 산출물 전량이 에이전트 컨텍스트에만 존재하고 파일에는 남지 않았다(재개 지시 "산출물 우선 기록"으로 복구). 리서치형 위임의 표준 문안에는 **"첫 2턴 안에 아티팩트 골격을 Write하고 수집 즉시 증분 Edit하라 — 수집 완료 후 일괄 기록 금지"**를 포함한다. 절단은 항상 마지막 작업을 자르므로, 기록을 마지막에 몰면 절단 시 산출물이 전량 유실된다 — 위 5항(파일 편집형의 "미러 즉시 동기화")의 리서치형 대응이다.
+
+| Anti-pattern | Required |
+|--------------|----------|
+| 파일 수만 세어 위임 크기 판정 → 조항 다수 파일에서 절단 | 편집 항목 수 × 2턴 + 파일 고정비(3턴)로 산술 |
+| 리서치 위임이 수집을 끝낸 뒤 일괄 기록 | 첫 2턴 내 골격 Write + 증분 Edit |
 
 Cross-reference: R018 (v2.1.246 maxTurns partial-marking 노트), R009 (Member Prompt Size Cap — 프롬프트 토큰 상한과 별개로 턴 수 상한도 위임 크기 설계 변수임을 추가).
 

package/templates/.claude/rules/MUST-enforcement-policy.md

@@ -4,7 +4,9 @@
 
 ## Core Policy
 
-oh-my-customcode uses an **advisory-first enforcement model**. Most rules are enforced through prompt engineering (CLAUDE.md, rules/, PostCompact hook) rather than hard-blocking hooks. This is intentional — it preserves agent flexibility while maintaining behavioral standards.
+oh-my-customcode uses an **advisory-first enforcement model**. Most rules are enforced through prompt engineering (CLAUDE.md, rules/, `SessionStart` re-injection[^postcompact]) rather than hard-blocking hooks. This is intentional — it preserves agent flexibility while maintaining behavioral standards.
+
+[^postcompact]: compact 후 재주입의 문서상 보장 경로는 `SessionStart`(matcher `*`, `claude-md-reinject.sh` — v1.1.50 #1617)이다. 기존 PostCompact prompt 배선은 유지되나 공식 문서상 `additionalContext`가 정의돼 있지 않아 효과 미보장·발동 미검증(hook-events-audit 2026-08-29). 후속 바이너리 프로브(postcompact-probe 2026-08-29, CC 2.1.251)에서 dispatch 경로 실재가 확인됨(전용 실행 함수·payload 스키마 `trigger`/`compact_summary`·dispatch map 등록, PreCompact 대비 동형 구조). 따라서 '발동 미검증'은 'dispatch 실재하나 라이브 발동·prompt 핸들러 효과는 미검증'으로 좁혀진다 — `additionalContext` 미정의는 불변이므로 재주입 보장 경로는 여전히 SessionStart다. Origin: #1619 #7 — 최초 보고는 'PostCompact 공식 부재'였으나 감사 실측 결과 실재하되 additionalContext 미정의로 정정됨. 서브에이전트 보고의 검증 없는 인용이 틀린 전제를 회고 이슈까지 전파시킨 사례 (R020 원인 분석 검증 조항의 실증).
 
 ## Enforcement Tiers
 
@@ -17,7 +19,7 @@ oh-my-customcode uses an **advisory-first enforcement model**. Most rules are en
 | Advisory (proactive) | UserPromptSubmit + SubagentStop + PostToolUse hooks | R007, R008 (`r007-r008-drift-advisor.sh` — #1229 UserPromptSubmit, #1545 SubagentStop, #1553 PostToolUse) | Reads last assistant turn; emits advisory if header/prefix absent. SubagentStop wiring (#1545) closes the no-user-input autonomous-loop gap (`/fsd`); PostToolUse (#1553) covers the orchestrator-only stretch before the first subagent spawn. Complements retroactive Stop-hook (`session-reflection.sh`, #1190). **v1.1.43부터 실제 발화 — 아래 각주 참조.** v1.1.49부터 역방향(announce > tool_use) 신호 포함, 기본 off 옵트인 (#1595 #6). |
 | Advisory (telemetry) | PostToolUseFailure hook | — (계측 전용, 규칙 강제 없음) | `failure-ledger.sh` (#1561, v1.1.44) — 도구 실패를 JSONL 원장에 append. stdout/stderr 무출력이라 모델에 도달하지 않으며 절대 차단하지 않음 |
 | Advisory (proactive) | UserPromptSubmit hook | R020 (원인 진단) | `fail-axis-cause-advisor.sh` (#1561, v1.1.44) — 원장에 실패 기록이 있는데 원인 진술 없는 재촉 프롬프트가 오면 `hookSpecificOutput.additionalContext`로 "원인 가설 되묻기" advisory 전달. 원장 부재 시 조용히 통과 |
-| Prompt-based | CLAUDE.md + rules/ + PostCompact | All MUST rules | Behavioral guidance in context |
+| Prompt-based | CLAUDE.md + rules/ + `SessionStart` 재주입(matcher `*`; PostCompact 이벤트 배선은 유지되나 효과 미보장[^postcompact]) | All MUST rules | Behavioral guidance in context |
 
 > **Advisory (proactive/retroactive) 발화 결함과 해소 (실측)**: `hookSpecificOutput.additionalContext` **전달 경로 자체는 #1547(v1.1.40)에서 구현**됐으나, 그 앞단 **파서 셀렉터 결함**으로 advisory가 **v1.1.42까지 한 번도 발화하지 못했다** — `jq -r '.role'`로 읽었으나 트랜스크립트 최상위에 `role` 키가 없어(실제는 `.message.role`) `last_assistant`가 항상 비고 즉시 `exit 0`으로 종료됐다. 당시 실측: 트랜스크립트 771개 전수에서 `"additionalContext":` 출현 0건, 라이브 프로브 stdout/stderr 각 0바이트. **proactive(`r007-r008-drift-advisor.sh`)와 retroactive(`session-reflection.sh`, 동일 결함) 두 계층 모두 미발화**였다. **v1.1.43에서 양 계층 파서 복구 + `PostToolUse` 배선을 완료했고, 라이브 프로브로 최초 발화를 확인했다(#1553).** 후속으로 v1.1.44에서 R008 판정을 블록 인접 비교 → 턴 단위 개수 비교로 전환(#1563), v1.1.45에서 Skill 도구 면제를 추가했다(#1569). **v1.1.49에서 역방향 신호**(announce > tool_use — 도구 호출을 예고해 놓고 tool_use 블록 없이 턴을 종료한 방향)**를 추가했다(#1595 #6)** — 기존 판정식 `max(0, tool_use − announce)`는 이 방향을 **구조적으로 0으로 처리**해 원리적으로 탐지 불가였다. 역방향은 **전용 앵커 정규식**(`$an_anchored`, 줄 시작 앵커 있음 — forward의 `$an_tool`에는 적용하지 않는다. forward는 announce를 덜 세면 위반이 **늘어나기** 때문)을 쓰고, **Skill 포함 전체 tool_use가 0건**일 때만 계상한다(Skill 제외 카운트를 쓰면 Skill만 호출한 준수 턴에서 오발화). 기본 off 옵트인(`OMCUSTOM_R008_REVERSE=on`으로 활성)이다 — 482턴 실측에서 순진한 `announce − ntools > 0` 구현은 36턴에 발화해 advisory 총량을 2배로 만들었고(16건은 Skill 제외 아티팩트, 15건은 앵커 없는 정규식의 산문 매칭), 협소화 후 3/3 진양성·오탐 0(앵커 비용은 실제 announce 969줄 중 1줄, 0.1%)이 되었으나 표본이 3건이라 기본 활성은 보류했다. **배선 구조상 예방 효과가 없다는 점도 보류 근거다** — 결함 턴은 tool_use가 0이라 `PostToolUse`·`SubagentStop`이 발화하지 않고, `UserPromptSubmit`은 사용자가 이미 개입한 뒤 발화한다. 정시에 발화하는 유일한 이벤트는 `Stop`이며 거기 걸린 훅은 `session-reflection.sh`다. 역방향은 그래서 **의도적으로 advisor 전용**이며 `session-reflection.sh`에는 복제하지 않았다(같은 결함을 두 번 보고하면서 교정 기회는 여전히 0이 되고, 되돌릴 지점만 두 곳이 된다).
 >
@@ -44,7 +46,7 @@ oh-my-customcode uses an **advisory-first enforcement model**. Most rules are en
 1. **Agent flexibility**: Hard blocks can trap agents in unrecoverable states
 2. **Graceful degradation**: Missing dependencies (jq, etc.) don't break the session
 3. **Composability**: External skills and internal rules can coexist without deadlocks
-4. **PostCompact reinforcement**: R007/R008/R009/R010/R018 are re-injected after context compaction
+4. **Post-compact reinforcement**: R007/R008/R009/R010/R018 are re-injected after context compaction via `SessionStart`(matcher `*`/`compact`) — not via the PostCompact event itself[^postcompact]
 
 ## Hard Enforcement Candidates — R010 git-delegation-guard (conditional), R007/R008 advisory **implemented & firing** (#1229 UserPromptSubmit, proactive) + **#1545 SubagentStop** (closes autonomous-loop gap) + **#1553 PostToolUse** + retroactive Stop-hook (#1190); `additionalContext` 전달 경로는 #1547(v1.1.40)에서 구현됐으나 파서 셀렉터 결함으로 v1.1.42까지 **양 계층 모두 미발화**였고, **v1.1.43에서 수정 완료·발화 확인**(#1553); hard-block variant still candidate if advisory insufficient (#1096). Promoted: rule-deletion-guard.sh (2026-04-08). See details via Read tool.
 
@@ -71,4 +73,4 @@ Promotion requires: (1) measured violation rate data, (2) user approval, (3) rol
 |------|-------------|
 | R010 | git-delegation-guard.sh is advisory; could promote to blocking |
 | R016 | Violations trigger rule updates, not enforcement changes |
-| PostCompact | Re-injects critical rules to combat context compaction amnesia |
+| SessionStart (compact re-entry) | Re-injects critical rules to combat context compaction amnesia — see [^postcompact] |

package/templates/.claude/rules/MUST-orchestrator-coordination.md

@@ -388,6 +388,18 @@ Origin: #1595 #2 (v1.1.48 세션 — `git checkout -b release/v1.1.48 develop`
 
 > Origin: #1574 (v1.1.44 세션 대조 실증 — 동일 고지를 받은 3개 병렬 에이전트 중 [1]은 `bun test` 11 fail을 "형제가 그 파일 편집 중"으로 정황 귀속해 오답, [2]/[3]은 개입 실험으로 정확히 귀속). Cross-ref: R020 (Read-Before-Characterize — 정황으로 특성화 금지).
 
+#### 형제 결과의 교차 서술 금지 (Origin: #1619 #3)
+
+병렬 위임서에 **형제 그룹의 결과를 서술·집계하는 작업을 포함하지 않는다** ("전 그룹 공통 결과는 X" 류). 형제 고지는 담당 범위 구분용이지, 형제 결과를 인용할 권한이 아니다 — 위 「고지는 귀속 후보를 늘릴 뿐 증거 등급을 올리지 않는다」와 같은 계열로, 고지가 형제에 대한 서술 권한까지 주지는 않는다.
+
+형제 결과의 집계·서술은 **전 그룹 완료 후 오케스트레이터가 대조해 직접 확정**하거나, 전 그룹 완료를 실측한 뒤 별도 위임으로 수행한다.
+
+| Anti-pattern | Required |
+|--------------|----------|
+| 병렬 그룹 위임서에 "전 그룹 공통 결과" 서술 작업 포함 → 기재 시점 참이 완료 순서에 따라 거짓화 | 교차 서술은 전 그룹 완료 실측 후 오케스트레이터 대조 또는 후속 위임으로 |
+
+> Origin: #1619 #3 (v1.1.50 세션 — 4개 병렬 룰편집 그룹 중 Group 4가 R016 실적 문단에 "은퇴 0건(전 그룹 공통)"을 기재. 기재 시점(Group 1·3 완료, Group 2 미완)에는 참이었으나 Group 2가 이후 2건을 은퇴시켜 서술이 거짓이 되었고 정정 왕복 1회 발생 — 교차 서술은 본질적으로 스냅샷이다). Cross-ref: 위 「고지는 귀속 후보를 늘릴 뿐 증거 등급을 올리지 않는다」.
+
 ##### "플래키"는 원인이 아니다 (Origin: #1598)
 
 간헐 실패에 **"플래키"·"부하 의존"이라는 판정을 결론으로 쓰지 않는다** — 그것은 "재현 조건을 아직 못 찾았다"는 뜻이지 "원인이 무작위"라는 뜻이 아니다. 각 서브에이전트는 격리 컨텍스트라 **형제가 같은 스위트를 동시에 도는 것을 구조적으로 볼 수 없으므로**, 형제 경합이 원인인 실패에 대해 각자 합리적이지만 틀린 "부하 의존 플래키" 결론에 도달한다. 간헐 실패는 개입 실험(단독 재실행 / 격리 `$TMPDIR` 재측정 / 형제 완료 후 재현)으로 귀속하고, 귀속에 실패하면 **"원인 미귀속 — 재현 조건 미확보"로 보고**한다.

package/templates/.claude/rules/MUST-sync-verification.md

@@ -93,6 +93,20 @@ Wiki verification is also enforced by CI (`.github/workflows/wiki-sync.yml`).
 
 Origin: #1512 (v1.1.28 커밋 staging에 dist/ 2파일 포함, 커밋 전 실측으로 정정; v1.1.12 dist/ untrack 회귀 방지); #1531 (`.omcustom.lock.json`이 v1.1.29 이후 4개 릴리즈 연속 누락 — 혼입 방지 단방향 조항의 반대편 공백). Cross-ref: R020 (완료 검증 — "실행됨 ≠ 성공").
 
+### 버전 범프 원자 순서 (Origin: #1619 #4)
+
+버전을 보유하는 파일은 3종이다 — `package.json`(generatorVersion 출처), `templates/manifest.json`(templateVersion 출처), `.omcustom.lock.json`(`bun run build`가 위 두 값을 읽어 각인하는 **파생 산출물**). 세 파일은 **원자적으로** 갱신해야 한다: package.json과 templates/manifest.json을 **동시에** 범프 → 그 다음 `bun run build` → build가 갱신한 lockfile을 스테이징. `bun run build`를 두 범프 사이에 끼우면(예: package.json만 먼저 범프하고 build) lockfile이 **구버전 templateVersion을 무경고로 각인**한다 — CI Version Sync가 3-way(package.json / manifest.json / lockfile) 대조라서 이 상태는 뒤늦게 차단된다.
+
+**범프 위임 표준 문안**: 버전 범프를 서브에이전트에 위임할 때, 위임 프롬프트에 3파일을 **전부 열거**한다 — "package.json과 templates/manifest.json을 동시에 범프한 뒤 `bun run build`를 실행하고 lockfile을 스테이징하라." 메모리에 이 순서에 대한 학습이 있어도 위임서에 배선되지 않으면 서브에이전트에 전달되지 않는다(R010 「표 조회 배선」과 동형 — 텍스트 존재 ≠ 배선).
+
+| Anti-pattern | Required |
+|--------------|----------|
+| package.json만 먼저 범프 후 `bun run build` 실행 → manifest.json은 나중에 범프 | package.json + templates/manifest.json 동시 범프 → `bun run build` → lockfile 스테이징 |
+| `bun run build`를 두 범프 사이에 끼워 실행 | build는 두 파일이 모두 범프된 **이후에만** 실행 |
+| 위임서에 "버전 범프"만 지시하고 3파일 미열거 | 위임서에 package.json / templates/manifest.json / lockfile 3파일을 전부 열거 |
+
+Origin: #1619 #4 (v1.1.50 세션 실측) — 범프 위임이 3파일 중 templates/manifest.json을 누락해 CI Version Sync 1차 실패(`manifest=1.1.49`). manifest 수정 후에도 2차 실패(`lock.tpl=1.1.49`) — `bun run build`가 manifest 범프 **전에** 실행돼 lockfile에 구버전 templateVersion이 각인된 상태였다. CI 처방 원문: "bump package.json AND templates/manifest.json first, then re-run 'bun run build' and stage the lockfile". Cross-ref: 위 Release Commit Staging Hygiene((b) 누락 방지 — tracked 변경 잔존 확인), R016(Rule Wiring Check — auto-dev.yaml 배선 필요), #1593(v1.1.47 세션에서 밝힌 `bun run build` → `sync-source-lockfile.ts` → `loadVersions()` 메커니즘).
+
 ### Count Sync — Exhaustive Grep, Not File Enumeration
 
 카운트(스킬/에이전트/룰/가이드 수) 동기화는 **파일 목록 열거가 아니라 저장소 전수 grep + 의미 판별**로 수행한다. 같은 카운트가 15곳 이상에 흩어져 있어 열거식 위임은 목록에서 빠진 곳을 구조적으로 놓친다.
@@ -198,6 +212,19 @@ Origin: #1574 (v1.1.44 세션 — mgr-sauron 브리핑의 "선재 항목" 4건
 - **버전 판정**: 세션 메모리에 "agora 정식 마이너 릴리즈 예정"이 기록돼 있었고, 오케스트레이터가 이를 semver 판정(minor vs patch) 근거로 인용했다가 사용자 정정("스킬 하나 추가한다고 마이너패치를?")을 받았다. 메모리 스냅샷은 판정을 정당화하지 못한다 — **직전 세션도 같은 오독을 했을 수 있기 때문**이다.
 - **테스트 baseline**: verify-build 단계에서 baseline을 메모리의 "138 pass"로 삼았으나 실측은 **2291 pass / 0 fail**이었다(138은 부분집합에 불과했다). 이번엔 fail이 0이라 판정에 영향이 없었으나, **fail이 0이 아니었다면 잘못된 baseline이 회귀를 통과시켰을 것**이다. baseline은 메모리 기록이 아니라 **전체 실행 실측값**으로 잡는다.
 
+## 릴리즈 전 배포 자격증명 유효성 (Origin: #1619 #5)
+
+릴리즈 착수 전, 배포 토큰(NPM_TOKEN 등)의 만료 가능성을 사전에 확인한다: `gh secret list`로 해당 secret의 갱신일을 조회하고, 발급일로부터 90일 경과 여부를 실측한다(값 자체는 조회 불가·불필요 — 메타데이터만 확인, R001 자격증명 가드레일). 90일 경과 시 갱신 필요 가능성을 먼저 사용자에게 보고한 뒤 릴리즈를 진행한다.
+
+**npm publish 실패의 오진 위험**: npm은 PUT 요청의 인증 실패를 **404로 위장**해 반환할 수 있다 — "패키지 없음"처럼 보이는 오류가 실제로는 "토큰 만료"일 수 있다는 뜻이다. publish 실패 시 워크플로우를 영구 변경하기 전, (a) ground-truth(`npm view <pkg> version`)로 실제 미배포 여부를 확정하고, (b) 비파괴적 재실행을 먼저 시도하며, (c) 재현되면 그때 토큰 만료 가설을 `gh secret list` 갱신일 대조로 검증한다.
+
+| Anti-pattern | Required |
+|--------------|----------|
+| 릴리즈 착수 전 토큰 만료 가능성을 확인하지 않고 진행 → publish 단계에서야 실패 발견 (fail-late) | 착수 전 `gh secret list` 갱신일 + 90일 경과 여부 사전 확인 |
+| npm E404-on-PUT을 "패키지 부재"로 진단해 워크플로우/재배포 로직을 변경 | ground-truth(`npm view`)로 미배포 확정 → 비파괴 재실행 → 재현 시에만 토큰 만료 가설 검증 |
+
+Origin: #1619 #5 (v1.1.50 세션 실측) — NPM_TOKEN이 90일 만료 정책으로 05-20 발급 → 08-17 마지막 성공 → 08-29 시점 E404-on-PUT 2회로 fail-late 발견. Cross-ref: R020 「CI Publish-Step Error vs Published-Artifact Ground Truth」, R020 Diagnostic Hypothesis Verification(#1217 npm E403 오진 선례 — 같은 계열의 npm 오류코드 오진 패턴), 위 Pre-Release Target Version Ground-Truth Gate(릴리즈 착수 전 실측 원칙의 자격증명 각도).
+
 ## CC 버전 노트 반영 전 — 스코프 상한 이후 릴리즈 확인 (Origin: #1584 #1)
 
 CC 버전 노트를 룰에 반영하기 **전**, `npm view @anthropic-ai/claude-code version` + `claude --version`을 실측해 **스코프 상한 버전 이후의 릴리즈 존재 여부**를 확인한다. 있으면 그 CHANGELOG를 먼저 읽어 **롤백·후속 변경**을 파악한 뒤 반영한다. 이슈 생성과 작업 사이의 간극 동안 플랫폼이 스스로 뒤집을 수 있으므로 — **이슈 번호는 최신 릴리즈를 의미하지 않는다**.

package/templates/.claude/skills/pipeline/workflows/auto-dev.yaml

@@ -418,6 +418,7 @@ steps:
               no error. Observed contamination: v1.1.47 shipped generatorVersion=1.1.47 / templateVersion=1.1.46
               because the bump commit created package.json + lockfile together and manifest.json was bumped in
               a later commit. Do NOT run this step until BOTH c and d are staged.   [on release/v{NEW}]
+              ⚠ Recap (R017 「버전 범프 원자 순서」, #1619 #4, v1.1.50 실측): package.json과 templates/manifest.json을 동시에 범프한 뒤 bun run build를 실행하고, build가 갱신한 lockfile을 스테이징한다 — 순서 위반 시 CI Version Sync 3-way(package.json/manifest.json/lockfile) 대조가 차단한다. v1.1.50에서 manifest.json 범프 누락 → 1차 실패, build를 manifest 범프 전에 실행 → 2차 실패(lockfile에 구버전 templateVersion 각인)했다.
            f. git status --short — enumerate ALL tracked drift (`^ M`) the build produced; stage EVERY one (esp. .omcustom.lock.json) before commit.
               (#1531 — .omcustom.lock.json missed staging across 4 consecutive releases after v1.1.29; root cause was no build step between version bump and commit.)   [on release/v{NEW}]
            g. mgr-gitnerd commit: "chore(release): bump to v<NEW>" — MUST include the drift from step f.

package/templates/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.50",
+  "version": "1.1.52",
   "lastUpdated": "2026-07-14T00:00:00.000Z",
   "omcustomMinClaudeCode": "2.1.121",
   "omcustomMinClaudeCodeReason": "Sensitive-path direct Write/Edit on .claude/** under bypassPermissions (R010 deprecation, #1101)",

package/templates/workflows/auto-dev.yaml

@@ -418,6 +418,7 @@ steps:
               no error. Observed contamination: v1.1.47 shipped generatorVersion=1.1.47 / templateVersion=1.1.46
               because the bump commit created package.json + lockfile together and manifest.json was bumped in
               a later commit. Do NOT run this step until BOTH c and d are staged.   [on release/v{NEW}]
+              ⚠ Recap (R017 「버전 범프 원자 순서」, #1619 #4, v1.1.50 실측): package.json과 templates/manifest.json을 동시에 범프한 뒤 bun run build를 실행하고, build가 갱신한 lockfile을 스테이징한다 — 순서 위반 시 CI Version Sync 3-way(package.json/manifest.json/lockfile) 대조가 차단한다. v1.1.50에서 manifest.json 범프 누락 → 1차 실패, build를 manifest 범프 전에 실행 → 2차 실패(lockfile에 구버전 templateVersion 각인)했다.
            f. git status --short — enumerate ALL tracked drift (`^ M`) the build produced; stage EVERY one (esp. .omcustom.lock.json) before commit.
               (#1531 — .omcustom.lock.json missed staging across 4 consecutive releases after v1.1.29; root cause was no build step between version bump and commit.)   [on release/v{NEW}]
            g. mgr-gitnerd commit: "chore(release): bump to v<NEW>" — MUST include the drift from step f.