@uzysjung/agent-harness 26.148.0 → 26.149.0

package/dist/trust-tier-drift.js

@@ -15,7 +15,7 @@ import {
   init_esm_shims,
   residentCost,
   resolveBundleRoot
-} from "./chunk-PTUM2NI3.js";
+} from "./chunk-YSW3OLH4.js";
 
 // src/trust-tier-drift.ts
 init_esm_shims();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uzysjung/agent-harness",
-  "version": "26.148.0",
+  "version": "26.149.0",
   "description": "Curate vetted AI-coding skills & plugins by your tech stack — install only what you need, across Claude Code, Codex, OpenCode & Antigravity",
   "type": "module",
   "publishConfig": {
@@ -35,6 +35,7 @@
     "cost:report": "npm run build && node scripts/context-cost-report.mjs",
     "cost:baseline": "npm run build && node scripts/context-cost-baseline.mjs",
     "assets:history": "bash scripts/asset-history.sh",
+    "release:audit": "node scripts/release-audit.mjs",
     "security": "npm audit --omit=dev --audit-level=high && npx --yes ecc-agentshield@1.4.0 scan --baseline security-baseline.json --gate",
     "security:baseline": "npx --yes ecc-agentshield@1.4.0 scan --save-baseline security-baseline.json"
   },

package/templates/rules/ship-checklist.md

@@ -1,10 +1,11 @@
 # Delivery
 
-무엇으로 검증할지는 이 저장소가 정한다. 아래는 그 선택과 무관하게 지켜야 하는 것들이다.
+무엇으로 검증할지는 이 저장소가 정한다. **어느 정도까지**는 Testing 룰이, 그 결과가 **언제** 있어야 하는지는 이 룰이 정한다.
 
 - **완료 판정은 만든 쪽이 아니라 검증자가 내린다.** 요구사항·변경분·검증 결과를 **직접 다시 확인**한 뒤 판정한다 — 보고를 읽고 승인하는 것은 판정이 아니다.
-- 배포 전에 이 저장소가 정의한 검증을 **실행하고 결과를 확인한다.**
-- **게시·배포 경로가 그 검증 통과에 의존해야 한다.** 별개 경로면 아무도 우회하려 하지 않았는데 red 가 그대로 나간다. 의존하지 않는 상태를 발견하면 경로를 고치기 전에 먼저 보고한다.
+- **머지 전**: 변경 위험에 맞는 검증을 **실행하고 결과를 확인한다.** high risk 는 더 많은 증거를 갖고 들어오고, **실행하지 않은 상태는 통과가 아니다.**
+- **배포**: 머지 전에 검증된 것과 **같은 artifact** 를 내보내고, 배포 뒤 실제 환경에서 smoke · health · 핵심 기능을 확인한다.
+- **머지·게시 경로가 그 검증 통과에 의존해야 한다.** 별개 경로면 아무도 우회하려 하지 않았는데 red 가 그대로 나간다. 의존하지 않는 상태를 발견하면 경로를 고치기 전에 먼저 보고한다.
 - 변경분이 사용자에게 닿는 경로가 여럿이면 **경로마다 실행 증거를 따로** 확보한다. 한 경로의 증거를 다른 경로에 전용하지 않는다.
 - 이 저장소가 정의한 **보안·취약점 검사도** 실행하고 결과를 확인한다 — 테스트만 돌리고 나가는 것이 기본값이 되기 쉽다.
 - 추적 문서가 코드와 어긋난 채로 나가지 않게 한다. **이 하네스가 설치해 둔 검사기**를 쓴다(스스로는 존재를 알 수 없으므로 여기 적는다): `bash .uzys-agent-harness/spec-drift-check.sh ship` — **exit 2 면 차단**(동기화 후 재시도), 1 은 경고, 0 이 통과. 백로그는 `ship-gate:ignore` 구간으로 감싸 면제한다(표식이 안 닫히면 면제를 통째로 무시한다).

package/templates/rules/test-policy.md

@@ -1,10 +1,19 @@
 # Testing
 
+**How far** to verify scales with the risk of the change; **when** those results must exist
+belongs to the Delivery rule.
+
+- An ordinary change gets the repository's baseline CI, regression across the affected scope, and
+  whatever independent verification it warrants. A high-risk one widens that in proportion to what
+  it touches and what its failure would cost.
+- High-risk includes at least authentication, authorization, payments and settlement, personal
+  data, data integrity, concurrency, state transitions, and migrations.
+- Full regression, full E2E, full mutation, and periodic security scanning belong to the CI/CD
+  schedule, not to a per-change decision.
 - Test observable behavior — contracts and invariants — at whichever level best exposes
   plausible failures.
-- For high-risk changes—including authentication, authorization, payments, personal data, data
-  integrity, concurrency, and migrations—cover normal, boundary, failure, misuse, and recovery
-  paths, omitting one only when failure on it is not plausible.
+- For a high-risk change, cover normal, boundary, failure, misuse, and recovery paths,
+  omitting one only when failure on it is not plausible.
 - Keep tests deterministic: time, randomness, shared state, execution order, network, and
   external services.
 - Use production-compatible dependencies when a substitute's behavioral differences could affect

package/templates/skills/humanize-korean/SKILL.md

@@ -0,0 +1,228 @@
+---
+name: humanize-korean
+description: 한국어 글에서 실제로 어색한 문체 문제를 진단하고, 근거가 있는 부분만 최소 수정해 자연스럽게 다듬는다. 번역투, AI 상투구, 기계적 구조, 접속사·형식명사·완곡 표현의 반복, 불필요한 영어 장식 등을 다루며 의미·사실·수치·전문용어·말투는 보존한다. "AI 티 없애줘", "자연스럽게 다듬어줘", "번역투 고쳐줘", "사람이 쓴 글처럼", "문체 진단 후 고쳐줘" 같은 요청에 사용한다.
+---
+
+# Humanize Korean
+
+## 목적
+
+글을 많이 바꾸는 것이 목적이 아니다.
+
+**어디가 실제로 어색한지 먼저 진단하고, 왜 문제인지 근거를 잡은 뒤, 필요한 부분만 고친다.**
+
+기본 흐름:
+
+> **진단 → 최소 수정 → 의미 검증**
+
+---
+
+## 핵심 원칙
+
+1. **진단 없이 전면 재작성하지 않는다.**
+2. **문제로 확인된 부분만 수정한다.**
+3. **표현 하나가 존재한다는 이유만으로 AI 티라고 판단하지 않는다.**
+4. **사실·주장·수치·고유명사·인용·전문용어·논리관계는 보존한다.**
+5. **장르와 말투(register)를 유지한다.**
+6. **원문에 없던 주장·근거·감정·비유·상투구를 추가하지 않는다.**
+7. **이미 자연스러운 문장은 그대로 둔다.**
+
+---
+
+## 1. 진단
+
+글 전체를 먼저 읽고 **체감되는 문제만 최대 3~6개** 고른다.
+
+각 finding에는 반드시 다음이 있어야 한다.
+
+- **문제**: 무엇이 어색한가
+- **근거**: 실제 표현 또는 반복되는 구조
+- **영향**: 왜 글이 번역투·기계적·과장된 느낌을 주는가
+- **수정 방향**: 어떻게 고칠 것인가
+
+다음 중 하나에도 해당하지 않으면 문제로 올리지 않는다.
+
+- 한국어 문장으로 명백히 부자연스럽다.
+- 같은 표현이나 문형이 반복돼 기계적인 리듬을 만든다.
+- 내용보다 형식·수사 장치가 앞선다.
+- 불필요하게 간접적이어서 의미 전달을 약하게 만든다.
+- 장르·독자·목적에 맞지 않는다.
+
+### 우선순위
+
+- **P1**: 의미 전달을 방해하는 번역투·비문·직역, 반복되는 강한 상투구
+- **P2**: 반복될 때 거슬리는 접속사·완곡 표현·형식명사·영어 병기·기계적 구조
+- **P3**: 취향 차이 수준의 표현
+
+P3만 있다면 **큰 문제 없음**으로 판단하고 과도하게 수정하지 않는다.
+
+---
+
+## 2. 주요 진단 관점
+
+아래는 탐지 목록이 아니라 **판단 관점**이다. 존재 자체가 아니라 문맥과 반복을 본다.
+
+### 번역투·직역
+
+예:
+- "~에 있어서", "~와 관련하여"처럼 불필요하게 긴 연결
+- "~에 의해" 중심의 부자연스러운 피동
+- "판단되어진다" 같은 이중 피동
+- "경쟁력을 가지고 있다", "회의를 가지다" 같은 직역
+- "~에서의", "~으로의"처럼 조사가 겹쳐 무거운 문장
+- "~에 대해", "~를 통해", "~을 기반으로"가 만능 연결어처럼 반복되는 경우
+
+수정:
+- 주어·목적어·동사를 직접 연결한다.
+- 명사화보다 자연스러운 동사형을 우선한다.
+- 피동은 필요한 경우만 유지한다.
+- 긴 수식은 필요할 때만 나눈다.
+
+### AI 상투구·과장
+
+예:
+- "결론적으로", "요약하면", "정리하자면"
+- "시사하는 바가 크다", "주목할 만하다"
+- "크게 세 가지로 나눌 수 있다"
+- 근거 없는 "혁신적", "획기적", "압도적"
+- "~할 때다", "X를 넘어 Y로" 같은 공식형 표현의 반복
+
+수정:
+- 라벨을 지우고 내용을 직접 말한다.
+- 중요하다고 설명하지 말고 이유나 사실을 남긴다.
+- 과장 수식은 삭제하거나 구체 근거가 있을 때만 유지한다.
+
+### 기계적인 구조
+
+예:
+- "첫째/둘째/셋째"가 필요 이상으로 반복
+- 모든 문단이 같은 방식으로 시작·종결
+- "A가 아니라 B", "A인가 B인가" 같은 대구의 반복
+- 불필요한 불릿·헤딩·볼드·이모지·따옴표
+
+수정:
+- 정보 구조에 실제로 도움이 되는 목록과 헤딩은 보존한다.
+- 장식용 구조와 반복되는 문형만 줄인다.
+- 보고서·기술 문서의 구조를 억지로 산문화하지 않는다.
+
+### 간접 표현·반복
+
+예:
+- 문장마다 "또한", "따라서", "즉", "나아가"로 시작
+- "이 점에서", "이 관점에서", "이는"의 반복
+- "~라는 것이다", "~라는 점이다", "~할 필요가 있다"의 반복
+- 같은 종결어미·문장 구조가 길게 연속
+
+수정:
+- 문맥으로 충분한 연결어는 삭제한다.
+- 형식명사를 걷어내고 핵심 동사로 직접 쓴다.
+- 반복되는 구조만 자연스럽게 분산한다.
+- 리듬을 만들기 위해 문장 길이나 종결어미를 인위적으로 조작하지 않는다.
+
+### 영어·전문용어
+
+- 같은 용어의 한글/영어 병기를 반복하지 않는다.
+- 불필요한 buzzword는 줄인다.
+- API, LLM, GPU, prompt처럼 업계에서 원어가 자연스러운 용어는 유지한다.
+- 전문용어를 억지로 한국어화하지 않는다.
+
+---
+
+## 자동으로 문제라고 보지 말 것
+
+다음은 **그 자체로 AI 티가 아니다.**
+
+- "~를 통해"
+- "~할 수 있다"
+- "~것이다"
+- "~적", "~성", "~화"
+- 피동문
+- 불릿과 헤딩
+- 볼드와 대시
+- 영어 전문용어
+- 격식 있는 문체
+- 비슷한 길이의 문장
+
+**반복·밀도·문맥·장르상 실제 문제가 있을 때만 수정한다.**
+
+특히 금지:
+
+- 패턴 매칭만으로 정상 문장 수정
+- 모든 피동을 능동으로 변경
+- 모든 불릿을 산문으로 변경
+- 모든 영어를 번역
+- 가능성 표현을 임의로 단정
+- 문장 길이를 일부러 들쭉날쭉하게 만들기
+- 감탄·반문·구어체를 새로 넣어 "사람처럼" 보이게 만들기
+- 원문보다 더 문학적이거나 더 격식 있게 만들기
+
+---
+
+## 3. 수정
+
+P1부터 고치고, P2는 실제로 반복이 거슬리는 범위까지만 고친다.
+
+기본 수정 단위는 **표현 또는 문장**이다.
+
+우선순위:
+
+1. 불필요한 표현 삭제
+2. 직접적인 한국어 구문으로 단순화
+3. 반복되는 표현 분산
+4. 필요한 경우에만 문장 분리·병합
+5. 마지막으로 어휘 교체
+
+문단 전체 재작성은 최소화한다.
+
+---
+
+## 4. 의미 검증
+
+수정 후 반드시 원문과 다시 대조한다.
+
+확인:
+
+- 정보가 빠지거나 새로 생기지 않았는가
+- 사실·수치·고유명사·인용이 유지됐는가
+- 인과·조건·부정/긍정이 바뀌지 않았는가
+- 가능성·추정의 강도가 달라지지 않았는가
+- 장르와 말투가 유지됐는가
+- 처음 진단한 문제가 실제로 줄었는가
+- 문제 없던 부분까지 과도하게 다시 쓰지 않았는가
+- 수정하면서 새로운 상투구나 과장을 만들지 않았는가
+
+문제가 생긴 수정은 전체를 다시 쓰지 말고 **해당 edit만 롤백**한다.
+
+---
+
+## 출력
+
+기본 출력:
+
+### 진단
+최대 3~6개.
+
+| 우선순위 | 문제 | 근거 | 수정 방향 |
+|---|---|---|---|
+| P1/P2 | 문제 유형 | 실제 표현 또는 반복 구조 | 수정 원칙 |
+
+문제가 거의 없으면 표를 억지로 채우지 말고 **큰 문제 없음**이라고 말한다.
+
+### 수정본
+진단을 반영한 전체 글을 제공한다.
+
+- 사용자가 **진단만** 요청하면 수정하지 않는다.
+- 사용자가 **결과만** 요청하면 진단은 내부적으로 수행하고 수정본만 보여준다.
+- taxonomy ID, AI 확률, 등급, 변경률 같은 메타데이터는 요청이 없으면 출력하지 않는다.
+
+---
+
+## 성공 기준
+
+좋은 결과는 많이 바뀐 글이 아니다.
+
+- 무엇이 문제였는지 설명할 수 있다.
+- 모든 수정에 원문 근거가 있다.
+- 핵심 문제는 줄고 글의 목적·개성·말투는 유지된다.
+- 원문에 없던 정보나 수사가 생기지 않는다.
+- 이미 좋았던 부분은 거의 그대로다.

package/templates/skills/north-star/NORTH_STAR.template.md

@@ -1,11 +1,14 @@
 # [Project Name] — North Star
 
-> 장기 방향성. PRD/SPEC이 "무엇을 어떻게"를 다루면, 본 문서는 **왜·어디로**를 다룬다.
-> 의사결정이 모호할 때 본 문서를 기준으로 우선순위를 판정한다.
+> **지속되는 방향의 SSOT.** PRD/SPEC이 "무엇을 어떻게"를 다루면, 본 문서는 **왜·어디로**를
+> 다룬다. 의사결정이 모호할 때 본 문서를 기준으로 우선순위를 판정한다.
+>
+> 여기 적는 것은 **서비스가 존재하는 동안 계속 추구하는 것**뿐이다. 끝나는 것(Initiative의
+> 완료 조건)과 유지하는 것(운영 SLO/Guardrail의 상세)은 §8 이 가리키는 문서가 소유한다.
 
 ---
 
-## 1. North Star Statement
+## 1. Product North Star
 
 > **"[한 문장: 5년 뒤 이 프로젝트가 무엇이 되어 있어야 하는가. 도메인 명사 + 사용자 + 측정 가능한 결과]"**
 
@@ -16,29 +19,48 @@
 ## 2. North Star Metric (NSM)
 
 > [진짜 목표가 직접 측정 불가하면 여기서 프록시를 선언: "진짜 목표 X 는 (외부적/지연이라)
-> 직접 측정 불가하므로, Y(양) + Z(사후 품질)를 프록시로 최적화한다. 근거: …" — 기능은
-> "이 프록시를 올리는가"로 평가한다.]
+> 직접 측정 불가하므로, Y(양) + Z(사후 품질)를 프록시로 최적화한다. 근거: …"]
 
-**1차 지표 (현재 단계)**: **[지표 약어 — 풀네임]**
+### 2.1 Definition — 무엇을 어떻게 재는가
+
+**[지표 약어 — 풀네임]**
 - 정의: [어떻게 계산하는가]
-- 목표: [수치 + 도달 시점]
-- 의미: [이 지표가 달성되면 무엇이 증명되는가. 미달 시 무엇이 부족함을 시사하는가]
+- 의미: [이 지표가 올라가면 무엇이 증명되는가. 내려가면 무엇이 부족함을 시사하는가]
+- 측정 환경: [single-user / team / public 등]에서 자가 수집.
+
+> Definition 변경은 **Major CR** 이다 — "이제 다른 것을 재기로 했다"는 방향 변경이다.
+
+### 2.2 Current Target — 지금 겨냥하는 수치
+
+| Target | 시점 | 현재 값 | 근거 |
+|---|---|---|---|
+| [수치] | [YYYY-Qn] | [측정값 또는 "미측정"] | [왜 이 수치인가] |
+
+> **Target 에 도달했다고 Definition 을 바꾸지 않는다.** 그때 하는 일은 다음 Target 을
+> 정하는 것이다. Target 갱신은 Clarification 이다.
 
-**2차 보조 지표**
+> 결정 기준: Leading(원인) 우선 · 단일 행동만 측정(composite 금지) · Target 명시 ·
+> 가치 없이 직접 올릴 수 있는(게임 가능한) 지표는 기각 ·
+> **달성하면 추적을 그만두게 되는 목표는 NSM 이 아니라 Initiative 의 Finish Line 이다.**
 
-| Metric | 정의 | 목표 |
-|--------|------|------|
-| [Metric A] | [계산법] | [수치] |
-| [Metric B] | [계산법] | [수치] |
-| [Metric C] | [계산법] | [수치] |
+---
+
+## 3. Inputs — 직접 움직일 수 있는 레버 (3–5개)
+
+NSM 은 결과이고 Inputs 는 원인이다. **계획은 여기에 붙는다.**
 
-> 모든 지표는 [환경 — single-user / team / public 등]에서 자가 수집. [향후 단계 진입 시 재정의 조건].
-> 결정 기준: Leading(원인) 우선 · 단일 행동만 측정(composite 금지) · 목표값 명시 ·
-> 가치 없이 직접 올릴 수 있는(게임 가능한) 지표는 기각.
+| Input | 정의 | 현재 | 목표 방향 | NSM 을 움직인다고 믿는 이유 |
+|---|---|---|---|---|
+| [Input A] | [어떻게 재는가] | [값 또는 "미측정"] | [↑ / ↓ / 유지] | [1줄] |
+| [Input B] | | | | |
+| [Input C] | | | | |
+
+> 측정되지 않는 Input 은 **"미측정"이라고 적는다** — 빈칸은 "없음"과 구분되지 않는다.
+> 미측정 자체가 갭이다.
 
 ---
 
-## 3. Pillars (전략 축)
+## 4. Strategic Pillars (전략 축)
 
 각 축은 North Star 로 가는 단계이며, 모든 모듈은 최소 1개 축에 속한다.
 
@@ -63,20 +85,19 @@
 | [공통 인프라 — 인증·관리 등] | 공통 | 축을 가로지르는 플랫폼 |
 
 > 어떤 신규 모듈이 위 축 어디에도 매핑되지 않으면, **착수 전에 북극성 정렬을 재검토**한다.
-> 로드맵 항목도 정기 리뷰 때 축에 매핑해 "새 축·방향 변경 필요 여부"를 판정·기록한다.
 
 ---
 
-## 4. Strategic Boundaries (방향성 경계)
+## 5. Strategic Boundaries (방향성 경계)
 
-### 4.1 Will (집중)
+### 5.1 Will (집중)
 
 - **[집중 영역 1]**: [짧은 설명]
 - **[집중 영역 2]**: [짧은 설명]
 - **[집중 영역 3]**: [짧은 설명]
 - **[집중 영역 4]**: [짧은 설명]
 
-### 4.2 Won't (의도적 비-방향)
+### 5.2 Won't (의도적 비-방향)
 
 scope creep의 1차 방어선. "X는 안 한다"를 **5-8개** 명시.
 
@@ -86,7 +107,7 @@ scope creep의 1차 방어선. "X는 안 한다"를 **5-8개** 명시.
 - **[안 하는 것 4]**: [근거]
 - **[안 하는 것 5]**: [근거]
 
-### 4.3 Trade-offs (의식적 선택)
+### 5.3 Trade-offs (의식적 선택)
 
 | 선택 | 포기한 것 | 근거 |
 |------|----------|------|
@@ -96,47 +117,85 @@ scope creep의 1차 방어선. "X는 안 한다"를 **5-8개** 명시.
 
 ---
 
-## 5. Roadmap — 여기 두지 않는다
+## 6. Alignment Rules
 
-> 시간축(단계 · 마일스톤 · 일정)은 TODO/로드맵 문서 소관. 본 문서는 방향만 담는다.
+### 6.1 Lifecycle 판정 — 목표·지표를 정의할 때 가장 먼저
 
----
+> **달성하면 더 이상 추적할 필요가 없는가?**
 
-## 6. Decision Heuristics (의사결정 휴리스틱)
+| 답 | 분류 | 어디에 사는가 |
+|---|---|---|
+| YES | **Finite** | Initiative 의 Finish Line / Exit Criterion — **이 문서 밖** |
+| NO | **Persistent** | NSM · Input(이 문서) 또는 SLO · Guardrail(운영 SSOT) |
+
+### 6.2 Work Type
+
+| Work Type | 의미 | 게이트 | 순위 |
+|---|---|---|---|
+| **Product Initiative** | 사용자 가치·경험을 바꾸는 유한한 작업 | 6.3 전부 | RICE/ICE + 판단 |
+| **Enabler Initiative** | 기술·운영 capability 를 바꾸는 유한한 작업 | 6.3 (Value 는 간접 경로) | RICE/ICE + 판단 |
+| **Operational Work** | 서비스 유지를 위한 반복적·사건 기반 업무 | 기계적 적용 안 함 | severity·위험·기한 |
 
-### 6.1 4-Gate — "할 것인가"
+### 6.3 4-Gate — "할 것인가"
 
-신규 요청·제안이 들어왔을 때 다음 4 게이트를 **모두** 통과해야 우선순위 진입.
+신규 Initiative 는 4 게이트를 **모두** 통과해야 우선순위 진입.
 
-| Gate | 질문 | Pass/Fail 기준 |
+| Gate | 질문 | Pass 기준 |
 |------|------|---------------|
-| **1. Trend** | 본 프로젝트의 핵심 트렌드/원칙(섹션 X 참조) 1개 이상에 매핑되는가? | 매핑 명시 = Pass |
-| **2. Persona** | Primary persona([이름])에게 직접 가치를 주는가? Anti-persona 위주면 거절 | YES = Pass |
-| **3. Capability** | [도메인 특수 능력 — 예: MCP 노출 / API 제공 / 키보드 단축키]가 동등하게 가능한가? | YES = Pass (UI-only면 -1) |
-| **4. Lean** | 4.1 Will 범위 내에 있는가? 외부면 Open Question으로 적재 | YES = Pass |
+| **1. Trend** | 본 프로젝트의 핵심 트렌드/원칙 1개 이상에 매핑되는가? | 매핑 명시 |
+| **2. Value** | 사용자 가치에 닿는 경로가 있는가? | **직접** — Primary persona([이름])에게 직접 가치. Anti-persona 위주면 거절 <br> **간접** — 막아 주는 Guardrail/SLO 또는 가능하게 하는 Initiative·Pillar capability 를 **이름으로** 지목 |
+| **3. Capability** | [도메인 특수 능력 — 예: MCP 노출 / API 제공]이 동등하게 가능한가? | YES (UI-only면 -1) |
+| **4. Lean** | §5.1 Will 범위 내인가? 외부면 Open Question 으로 적재 | YES |
+
+> Security · Reliability · Observability · Migration 은 게이트 2 의 **간접** 경로로 통과한다.
+> NSM 을 직접 움직이지 않아도 정당하다 — 다만 무엇을 위해서인지 이름을 못 대면 탈락이다.
+
+### 6.4 순위에서 제외되는 작업
 
-4개 모두 Pass = 우선순위 진입. 1개라도 Fail = 보류 또는 거절.
+다음은 optional feature 와 RICE/ICE 로 경쟁시키지 않는다. severity·위험·기한·의존성·
+저장소 정책으로 먼저 판정한다.
 
-### 6.2 우선순위 순서 — "언제 할 것인가"
+> Security violation · Data integrity risk · Critical incident · SLO/Guardrail breach ·
+> Required migration · Release blocker · Regulatory / Mandatory requirement
 
-무엇을 먼저 할지 모호하면 이 순서로 판정한다. **상위 순위에 미완이 있으면 하위로 건너뛰지
-않는다** (긴급 hotfix·사용자 명시 지시 예외).
+### 6.5 Initiative Sequencing Heuristic
 
-1. **기본 필수 기능** — 없으면 제품이 성립 안 되는 기본기.
-2. **기능 완성도** — shipped 기능이 사용자 관점 end-to-end 완결인가. 단순 존재 ≠ 완결.
-3. **차별화 깊이** — 핵심 경쟁력의 advanced 구현. research/ADR 선행 필수.
+**적용 범위: 신규 구축 · 신규 Feature Initiative · 아직 Finish Line 을 통과하지 못한 기능.**
+운영 중인 backlog 전체의 절대 규칙이 아니다.
+
+1. **Foundation** — 없으면 제품이 성립 안 되는 기본기.
+2. **End-to-End Completeness** — shipped 기능이 사용자 관점 end-to-end 완결인가. 존재 ≠ 완결.
+3. **Differentiation** — 핵심 경쟁력의 advanced 구현. research/ADR 선행 필수.
+
+### 6.6 Initiative 완료 시 전환
+
+1. Finish Line 은 **종료**한다 — 지속 KPI 로 남기지 않는다.
+2. Initiative Metric 은 **자동으로** Persistent Metric 이 되지 않는다. 승격은 결정이다.
+3. 계속 유지해야 하는 성질만 명시적으로 넘긴다 — 사용자 가치의 지속 개선이면 §2/§3 으로,
+   운영 중 지켜야 하는 조건이면 운영 SSOT 의 SLO/Guardrail 로. 이유를 한 줄 남긴다.
+4. 넘길 것이 없으면 아무것도 안 남기고 닫는다.
 
 ---
 
-## 7. Versioning & Review
+## 7. Review & Versioning
 
-- 본 문서는 **분기 1회** 또는 **NSM 도달/미달** 시 갱신.
-- 주요 갱신 (Major CR): NSM 변경 / Pillar 변경 / Won't 변경.
-- 가벼운 갱신 (Clarification): Trade-off 추가, 트렌드 매핑 보강.
+- 본 문서는 **분기 1회** 또는 **NSM Current Target 도달/미달** 시 갱신.
+- **Major CR**: NSM Definition 변경 / Pillar 변경 / Won't 변경.
+- **Clarification**: Current Target 갱신, Trade-off 추가, 매핑 보강.
 - 갱신 사유는 커밋 메시지에 남긴다 — 본문에 이력을 쌓지 않는다.
+- 본 문서가 바뀌면 그 아래 계획·로드맵 문서는 자동으로 최신이 아니다. 같은 갱신 단위에서
+  재검토 대상으로 표시한다.
 
 ---
 
-## 8. Changelog — 여기 두지 않는다
+## 8. 이 문서가 소유하지 않는 것
+
+| 소유하지 않는 것 | 어디가 소유하나 |
+|---|---|
+| Initiative Finish Line · Initiative KPI · Release 완료 조건 · Feature checklist | [계획 문서 경로 — 예: `docs/plans/`] |
+| Now / Next / Later 상세 backlog | [로드맵 SSOT 경로] |
+| 상세 SLO · Runbook · Incident procedure | [운영 SSOT 경로] |
+| 갱신 이력 | 버전 관리 이력 |
 
-> 갱신 이력은 버전 관리 이력 소관. 본문에는 현행만 남긴다.
+> 방향은 여기가 소유하고, 실행 계획과 운영 기준의 상세는 중복해서 소유하지 않는다.
+> 시간축을 이 문서에 끌어들이는 순간 방향 문서와 일정 문서가 서로를 덮어쓴다.