oh-my-customcode 1.1.34 → 1.1.36

package/dist/cli/index.js

@@ -241,7 +241,7 @@ var init_package = __esm(() => {
     workspaces: [
       "packages/*"
     ],
-    version: "1.1.34",
+    version: "1.1.36",
     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.34",
+  version: "1.1.36",
   description: "Batteries-included agent harness for Claude Code",
   type: "module",
   bin: {

package/package.json

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

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

@@ -217,8 +217,11 @@ npm publish E403을 `--provenance` attestation 충돌로 오진단 → release w
 1. 가설을 뒷받침하는 직접 증거(로그/에러 코드/문서)가 있는가?
 2. 비파괴적 방법으로 가설을 검증할 수 있는가?
 3. 변경이 되돌리기 쉬운가? (영구 워크플로우 변경 vs 일회성 시도)
+4. 결함이 발생한 실행 경로(워크플로우 YAML/스킬 정의/스크립트/CI 설정)를 직접 읽었는가? 수동 재현 성공으로 자동화 경로의 동작을 추정하지 않았는가?
 하나라도 NO면 검증을 먼저 수행한다. 근본 원인 진단은 `superpowers:systematic-debugging` 참조.
 
+Origin: #1533 (lockfile 4릴리즈 누락을 "스테이징 누락"으로 오진 — 실제 원인은 version-bump 절차에 build 단계 부재; 수동 재현 결과로 자동화 경로를 추정).
+
 ### Variant: Parallel Read + Permanent-Change Dispatch (#1250)
 
 진단 자료 수집(로그 조사, 파일 Read)과 그 진단에 의존하는 영구 변경(이슈 등록, 수정 에이전트 위임)을 **같은 메시지에서 병렬 실행**하면, Read 결과를 받기 전에 가설이 확정된다. 병렬 배치는 결과를 동시에 받으므로 "Read 후 판단"이 불가능하다.

package/templates/.claude/rules/MUST-continuous-improvement.md

@@ -13,8 +13,28 @@ Update the relevant rule rather than just acknowledging the violation.
 1. Acknowledge violation
 2. Identify root cause (which rule was weak/unclear?)
 3. Update the rule (add clarity, examples, self-checks)
-4. Commit the change
-5. Continue original task following updated rules
+4. Wiring check — confirm the rule is wired into an execution path, or mark it as wiring-not-required (see Rule Wiring Check below)
+5. Commit the change
+6. Continue original task following updated rules
+
+### Rule Wiring Check (배선 확인)
+
+규칙 텍스트를 추가하는 것과, 그 규칙이 실행 경로에서 발동되게 배선하는 것은 **별개 작업**이다. 텍스트만 추가하고 배선을 누락하면 동일 결함이 재발한다.
+
+**판단 항목** (규칙 승격 시 판단하고 기록):
+1. 이 규칙이 발동되어야 하는 **실행 경로**(워크플로우 YAML / 스킬 정의 / 훅 / CI 설정)가 있는가?
+2. 있다면 그 경로에 **실제로 반영**했는가?
+3. 배선 대상이 없는 순수 서술 규칙(용어 정의 등)이면 **"배선 불요"임을 명시**한다.
+
+배선이 필요한데 텍스트만 추가한 것은 **미완료**로 간주한다.
+
+| Anti-pattern | Required |
+|--------------|----------|
+| 규칙 조항만 추가하고 커밋 → 자동화 경로에 발동 지점이 없어 동일 결함 재발 | 발동 실행 경로 명시 + 반영 확인; 대상 없으면 "배선 불요" 명시 |
+
+Origin: #1533 (v1.1.35에서 R017 (b) 조항 추가했으나 auto-dev.yaml version-bump 절차에 bun run build 단계가 없어 발동 지점 부재 — mgr-sauron이 [FAIL]로 차단, 배선 후 통과).
+
+Cross-reference: R021(Enforcement Policy — advisory 규칙의 발동 지점), R017(구조 검증).
 
 ## Integration
 

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

@@ -77,16 +77,21 @@ Wiki verification is also enforced by CI (`.github/workflows/wiki-sync.yml`).
 ```
 -->
 
-### Release Commit Staging Hygiene (빌드 산출물 오염 방지)
+### Release Commit Staging Hygiene (빌드 산출물 오염/누락 방지)
 
-릴리즈 커밋(및 `bun run build`를 수행한 모든 커밋) 직전, `git diff --cached --name-only`로 **스테이징 목록을 실측**하여 `dist/` 등 빌드 산출물이 포함되지 않았는지 확인한다. gitignored 경로라도 `git add -f` 또는 광범위 `git add` 조합으로 스테이징될 수 있으므로, .gitignore 존재가 방어를 보장하지 않는다. 발견 시 `git reset dist/`로 제외한 뒤 커밋한다. 이는 v1.1.12의 `dist/` untrack 조치에 대한 **회귀 방지 게이트**다.
+릴리즈 커밋(및 `bun run build`를 수행한 모든 커밋) 직전, 스테이징 검증은 **양방향**이다 — (a) gitignored 빌드 산출물(`dist/` 등)이 **혼입**되지 않았는가, (b) 빌드가 갱신한 **tracked** 산출물(`.omcustom.lock.json` 등)이 **누락**되지 않았는가. 두 방향은 서로 다른 경로(gitignored vs tracked)를 대상으로 하므로, 한쪽만 확인하면 반대 방향 결함이 통과한다 — .gitignore 존재/부재 확인만으로는 부족하다.
+
+**(a) 혼입 방지**: `git diff --cached --name-only`로 **스테이징 목록을 실측**하여 `dist/` 등 빌드 산출물이 포함되지 않았는지 확인한다. gitignored 경로라도 `git add -f` 또는 광범위 `git add` 조합으로 스테이징될 수 있다. 발견 시 `git reset dist/`로 제외한 뒤 커밋한다. 이는 v1.1.12의 `dist/` untrack 조치에 대한 **회귀 방지 게이트**다.
+
+**(b) 누락 방지**: `bun run build` 실행 후 `git status --short`에 **tracked 변경(`^ M`)이 남아 있으면 스테이징 누락**이다. 커밋 직전 tracked 변경이 0인지 확인한다.
 
 | Anti-pattern | Required |
 |--------------|----------|
 | 빌드 후 광범위 `git add`로 커밋 → gitignored `dist/` force-add 위험 | 커밋 직전 `git diff --cached --name-only` 실측으로 빌드 산출물 부재 확인 |
 | .gitignore에 있으니 안전하다고 가정 | force-add 경로는 .gitignore를 우회하므로 실측 필요 |
+| `dist/` 미포함만 확인하고 커밋 → 빌드가 갱신한 tracked 산출물 누락 | `git status --short`로 tracked 변경 잔존 0 확인 |
 
-Origin: #1512 (v1.1.28 커밋 staging에 dist/ 2파일 포함, 커밋 전 실측으로 정정; v1.1.12 dist/ untrack 회귀 방지). Cross-ref: R020 (완료 검증 — "실행됨 ≠ 성공").
+Origin: #1512 (v1.1.28 커밋 staging에 dist/ 2파일 포함, 커밋 전 실측으로 정정; v1.1.12 dist/ untrack 회귀 방지); #1531 (`.omcustom.lock.json`이 v1.1.29 이후 4개 릴리즈 연속 누락 — 혼입 방지 단방향 조항의 반대편 공백). Cross-ref: R020 (완료 검증 — "실행됨 ≠ 성공").
 
 ### Count Sync — Exhaustive Grep, Not File Enumeration
 

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

@@ -307,9 +307,13 @@ steps:
            #   Edit ONLY the .version field — do NOT overwrite templates/manifest.json wholesale (e.g. a source-hash path→hash map).
            #   Recover a corrupted manifest: git show HEAD:templates/manifest.json | jq '.version="<NEW>"' > templates/manifest.json (#1423/#1154).
            b. templates/manifest.json: jq '.version = "<NEW>"' templates/manifest.json > templates/manifest.json.tmp && mv templates/manifest.json.tmp templates/manifest.json
-           c. mgr-gitnerd commit: "chore(release): bump to v<NEW>"
-           d. mgr-gitnerd push develop
-           e. mandatory verification (with existence guard for partial-update safety):
+           c. bun run build — run standalone (NO pipe), read exit code directly ($? after a pipe is the last command's, R005/#1492).
+              This regenerates .omcustom.lock.json (generatorVersion/templateVersion) to <NEW> via scripts/sync-source-lockfile.ts.
+           d. 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.)
+           e. mgr-gitnerd commit: "chore(release): bump to v<NEW>" — MUST include the drift from step d
+           f. mgr-gitnerd push develop
+           g. mandatory verification (with existence guard for partial-update safety):
               [ -f scripts/verify-version-sync.sh ] && bash scripts/verify-version-sync.sh || echo "::warning::verify-version-sync.sh not found, version sync verification skipped"
               (verify-version-sync.sh 가 exit 1 시 release 단계 halt)
 
@@ -325,12 +329,15 @@ steps:
       3. Adapt release mechanism to project (determines how steps 3-5 execute):
          - npm project with auto-tag.yml (this repo — release/v* PR pattern):
            a. mgr-gitnerd creates release/v{NEW} branch from develop with the version-bump commit
-           b. mgr-gitnerd creates PR: gh pr create --base develop --head release/v{NEW} --title "chore(release): bump to v{NEW}"
+           b. mgr-gitnerd creates PR: gh pr create --base develop --head release/v{NEW} --title "chore(release): bump to v{NEW}" --body "<MUST include 'Closes #N' for EVERY issue this release resolves>"
+              ⚠ auto-tag.yml closes issues by grep'ing Closes/Fixes/Resolves keywords in the PR BODY — NOT by milestone membership. If the keywords are missing, no issues close and the workflow still reports success (#1531).
+              Before creating the PR (whether via inline --body or --body-file), confirm the body text actually contains a Closes line per issue.
            c. mgr-gitnerd merges PR (admin merge required due to branch protection)
            d. DO NOT manually git tag or gh release create.
-              auto-tag.yml fires on release/v* PR merge → creates tag → closes linked issues → closes milestone → deletes release branch.
+              auto-tag.yml fires on release/v* PR merge → creates tag → closes issues linked via PR-body Closes/Fixes/Resolves keywords → closes milestone → deletes release branch.
               release.yml fires on the tag → npm publish + GitHub Release creation.
            Milestone close and issue close are handled downstream by auto-tag.yml — do NOT close them manually.
+           After merge, verify each targeted issue is actually CLOSED (gh issue view); close manually if still open. Workflow conclusion=success is not evidence of close (#1531 — v1.1.34 Closes-keyword omission left 5 issues open, manual close required).
          - Non-npm / no auto-tag.yml:
            mgr-gitnerd: git tag v{NEW} && git push origin v{NEW}
            mgr-gitnerd: gh release create v{NEW} (with release notes)

package/templates/manifest.json

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