okstra 0.34.1 → 0.36.1

package/docs/superpowers/plans/2026-05-24-implementation-lead-context-slimming.md

@@ -0,0 +1,1700 @@
+# Implementation Lead Context Slimming Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** `--task-type implementation` 의 Phase 6 (worker dispatch) 가 한 lead 세션 안에 끝나도록 lead context 누적 비용을 절감한다. 세 트랙(B/D/C) 을 통해 dispatch boilerplate, stage 실행 단위, profile baseline 무게를 동시에 줄인다.
+
+**Architecture:**
+- **Track B (cross-cutting)** — `okstra-team-contract` 가 worker prompt 본문에 verbatim inject 하라고 강제하는 `[Required reading]` (~48 lines) + `[Error reporting]` (~27 lines) clause 를 fragment file 1줄 pointer 로 압축한다. codex / gemini wrapper subagent 가 dispatch 직전 pointer 를 resolve 해서 외부 CLI 에 inline 한다 — lead context 는 pointer 만 통과한다.
+- **Track D (implementation-only)** — `implementation-planning` profile 의 stage-당 step 권장값을 "최대 6" 에서 "권장 ≤ 3, hard cap 6" 으로 강화한다. executor sync block (=phase 6 단일 stage wall-clock) 의 평균 길이를 절반으로 자른다.
+- **Track C (implementation-only, gated by B/D 실측)** — `prompts/profiles/implementation.md` 의 161 줄을 thin core (~50 줄) + 3 sidecar (`_implementation-executor.md` / `_implementation-verifier.md` / `_implementation-deliverable.md`) 로 split 한다. lead 는 Phase 5 진입 시 executor sidecar 만, Phase 5 verifier dispatch 직전 verifier sidecar 만, Phase 6 보고서 합성 직전 deliverable sidecar 만 lazy read 한다.
+
+**Tech Stack:** Python 3 (`scripts/okstra_ctl/`), Bash (worker wrapper scripts), Markdown (profile / skill / template), pytest (unit tests under `tests/`).
+
+---
+
+## Pre-flight: 작업 트리 준비
+
+이 plan 은 `prompts/`, `skills/`, `agents/`, `validators/`, `scripts/okstra_ctl/`, `templates/`, `tests/` 7개 디렉토리를 건드리며 빌드 산출 `runtime/` 은 자동 재생성 대상이다. **실행자는 plan 작성 위치(`main`)가 아니라 별도 worktree 에서 작업한다.**
+
+- [ ] **사전 0: worktree 생성**
+
+```bash
+git worktree add -b feat/impl-lead-slim ../Okstra-impl-lead-slim main
+cd ../Okstra-impl-lead-slim
+```
+
+이 plan 의 모든 후속 명령은 `../Okstra-impl-lead-slim` 을 cwd 로 가정한다.
+
+- [ ] **사전 1: 환경 sanity check**
+
+```bash
+node --version          # Node 20+
+python3 --version       # Python 3.11+
+npm run build           # runtime/ 재생성, 시작 baseline
+python3 -m pytest tests/ -x -q
+```
+
+위 둘 다 통과해야 plan 진입. 실패하면 main 자체가 깨져 있으므로 root cause 부터 해결.
+
+---
+
+## File Structure
+
+새로 만들거나 의미 있게 수정될 파일과 책임:
+
+**Track B — Required reading / Error reporting fragment 분리**
+
+| 종류 | 경로 | 책임 |
+|------|------|------|
+| Create | `prompts/fragments/required-reading-block.md` | `[Required reading]` clause 본문 SSOT (analysis worker / report-writer 공통, audience 토큰 치환 가능) |
+| Create | `prompts/fragments/error-reporting-block.md` | `[Error reporting]` clause 본문 SSOT (`<role-slug>` 치환 가능) |
+| Modify | `skills/okstra-team-contract/SKILL.md` | 두 clause 본문 verbatim → `Read <fragment-path>` pointer 룰로 교체. byte-identical 강제는 fragment 파일 자체에 위임 |
+| Modify | `agents/workers/codex-worker.md` | 새 step "Resolve required-reading + error-reporting pointers, expand fragments into the CLI prompt" 추가 |
+| Modify | `agents/workers/gemini-worker.md` | 동일 (codex-worker 와 byte-identical 변경) |
+| Modify | `agents/SKILL.md` | dispatch prompt 작성 룰을 fragment pointer 로 변경. 기존 "Asymmetry between claude-worker and codex/gemini-worker prompts" 박스도 업데이트 |
+| Modify | `tools/build.mjs` | `prompts/fragments/` 를 runtime sync 대상에 추가 |
+| Create | `tests/test_required_reading_fragment.py` | fragment 파일 존재, 기존 inline body 와 byte-identical (diff =0) 보장 |
+| Create | `tests/test_dispatch_prompt_pointer.py` | dispatch prompt 작성 helper 가 pointer 만 emit (verbatim body 포함 시 fail) |
+
+**Track D — Stage step 권장값 강화**
+
+| 종류 | 경로 | 책임 |
+|------|------|------|
+| Modify | `prompts/profiles/implementation-planning.md` | L64 `Effective row count ≤ 6` → `권장 ≤ 3, 절대 상한 6`. L95 Self-review step 7 도 동일 문구로. `Stage Map self-check` 단계에 "stage 가 4 step 이상이면 split 가능 여부 재검토" rationale 추가 |
+| Modify | `templates/reports/implementation-planning-input.template.md` | 예시 Stage Map 표의 step-count 컬럼 값을 2 / 3 으로 갱신. "권장 ≤ 3" 문구를 라이터용 가이드 라인으로 노출 |
+| Modify | `validators/validate-implementation-plan-stages.py` | `steps > 6` hard fail 유지 + `steps > 3` 시 warning 추가 (stderr 한 줄, exit code 영향 없음). warning emit 기준을 const 로 빼서 단위 테스트 가능하게 |
+| Create | `tests/test_validate_implementation_plan_stages_warnings.py` | step=2/3 → warning 없음, step=4/5/6 → warning 있음, step=7 → 기존 error 유지 |
+
+**Track C — implementation profile lazy split**
+
+| 종류 | 경로 | 책임 |
+|------|------|------|
+| Create | `prompts/profiles/_implementation-executor.md` | Pre-implementation context exploration + Stage execution contract + Allowed actions (executor 측) + TDD loop. Phase 5 진입 시점 lazy load. INCLUDE 대상이 아니라 lead 가 직접 Read |
+| Create | `prompts/profiles/_implementation-verifier.md` | Verifier QA duties (two-tier command lookup, deny-list, discrepancy rule, read-only command log) + verifier-specific forbidden actions. Phase 5 verifier dispatch 직전 lazy load |
+| Create | `prompts/profiles/_implementation-deliverable.md` | Required deliverable shape + Lead post-stage persistence + Self-review pass + Routing recommendation. Phase 6 report-writer dispatch 직전 lazy load |
+| Modify | `prompts/profiles/implementation.md` | thin core (~50 lines) 만 남김: Purpose, Required workers, Executor binding, `{{INCLUDE:_common-contract.md}}`, Pre-implementation gate, Task worktree, Forbidden actions (모든 phase 공통 위험), In-phase debugging, "Lazy section pointers" 박스 |
+| Modify | `agents/SKILL.md` | 신규 박스 "Implementation profile lazy reading discipline" — Phase 5 진입 시 executor sidecar / Phase 5 verifier dispatch 시 verifier sidecar / Phase 6 시 deliverable sidecar 를 read. 미read 상태에서 phase 진입 시 BLOCKING |
+| Modify | `validators/validate-run.py` | implementation profile 산출 보고서의 deliverable substring 검사가 sidecar split 후에도 작동하도록 — 현재 어떤 substring 을 검사하는지 확인 후 누락 없도록 갱신 |
+| Create | `tests/test_implementation_profile_split.py` | (1) thin core + 3 sidecar 합집합이 기존 161-line implementation.md 와 의미 동등 (substring 손실 0). (2) thin core 만으로는 phase 5 진입 가능 / verifier dispatch 시 sidecar 미read → assert fail. (3) sidecar 파일 자체에 `{{INCLUDE:}}` 토큰 없음 (lead 가 직접 Read 하므로 expand 불필요) |
+
+**모든 트랙 공통**
+
+| 종류 | 경로 | 책임 |
+|------|------|------|
+| Modify | `CHANGES.md` | 3개 사용자 영향 entry (B / D / C), 각각 `사용자 영향:` 한 줄 포함 |
+| Modify | `CLAUDE.md` "Where to find things" | fragment / sidecar 파일 위치 한 줄씩 추가 |
+
+`runtime/` 은 build 산출이므로 직접 편집 금지. 각 트랙 종료 시 `npm run build` 한 번씩.
+
+---
+
+## Track B — Required reading / Error reporting boilerplate fragment 분리
+
+**왜 먼저인가:** cross-cutting (모든 phase / 모든 worker dispatch). 작은 변경으로 가장 큰 누적 절감. Track D/C 와 직교라 충돌 없음.
+
+### Task B1: `[Required reading]` fragment 파일 생성
+
+**Files:**
+- Create: `prompts/fragments/required-reading-block.md`
+- Test: `tests/test_required_reading_fragment.py`
+
+- [ ] **Step 1: 실패 테스트 작성 (fragment 존재 + content 검증)**
+
+```python
+# tests/test_required_reading_fragment.py
+from pathlib import Path
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+FRAGMENT = REPO_ROOT / "prompts/fragments/required-reading-block.md"
+TEAM_CONTRACT = REPO_ROOT / "skills/okstra-team-contract/SKILL.md"
+
+
+def test_fragment_file_exists():
+    assert FRAGMENT.is_file(), f"missing fragment: {FRAGMENT}"
+
+
+def test_fragment_starts_with_block_marker():
+    content = FRAGMENT.read_text(encoding="utf-8")
+    assert content.startswith("[Required reading]\n"), \
+        "fragment must start with '[Required reading]\\n' so it slots into worker prompt verbatim"
+
+
+def test_fragment_contains_canonical_input_filenames():
+    # 본문 호환성 — 기존 team-contract 의 핵심 토큰이 모두 보존되어야 함
+    content = FRAGMENT.read_text(encoding="utf-8")
+    for token in [
+        "task-brief.md",
+        "analysis-profile.md",
+        "analysis-material.md",
+        "reference-expectations.md",
+        "clarification-response.md",
+        "final-report-template.md",
+        "REPORT WRITER ONLY",
+        "Reading Confirmation",
+        "audit sidecar",
+    ]:
+        assert token in content, f"fragment lost canonical token: {token!r}"
+```
+
+- [ ] **Step 2: 테스트 실패 확인**
+
+```bash
+python3 -m pytest tests/test_required_reading_fragment.py -v
+```
+
+Expected: 3 failures — `FileNotFoundError` / `AssertionError`.
+
+- [ ] **Step 3: fragment 파일 작성 (`skills/okstra-team-contract/SKILL.md` L111-159 본문을 그대로 옮긴다)**
+
+```bash
+mkdir -p prompts/fragments
+```
+
+```markdown
+<!-- prompts/fragments/required-reading-block.md -->
+[Required reading]
+You are required to read every input file listed below from the very first
+character to the very last character before you produce any analysis output.
+Skimming, partial reads, jumping to a single section, or relying on prior
+knowledge of a similar file's structure is not acceptable. Each file may
+contain decisive context that is not surfaced in its summary or first page.
+
+Required files for this run (read in this order, end-to-end, no exceptions):
+
+  1. <Project Root>/<instruction-set>/task-brief.md
+  2. <Project Root>/<instruction-set>/analysis-profile.md
+  3. <Project Root>/<instruction-set>/analysis-material.md   (only if present)
+  4. <Project Root>/<instruction-set>/reference-expectations.md
+  5. <Project Root>/<instruction-set>/clarification-response.md   (only if a carry-in was provided for this run)
+  6. <Project Root>/<instruction-set>/final-report-template.md   (REPORT WRITER ONLY — omit for analysis workers and reverify dispatches)
+
+Reading rules:
+
+  - Use a single Read tool call per file with no offset and no limit. Do not
+    page through the file with offset/limit unless the file is genuinely too
+    large for one read; if you must page, you MUST cover the entire file
+    before moving on, and you MUST state the page boundaries you used in your
+    Findings section.
+  - For the carry-in clarification response, read the conditional
+    `## 0. Clarification Response Carried In From Previous Run` section
+    (rendered only when carry-in is non-empty) and every row of
+    `## 5. Clarification Items` (`C-001`, `C-002`, ...) in full,
+    including rows whose `User input` cell is blank. The fact that you
+    will write your output into a file with a structurally similar
+    section 5 is NOT an excuse to skim — the prior `C-*` rows carry
+    context you cannot reconstruct from the new run alone.
+  - Write the Reading Confirmation block to your **audit sidecar** at
+    `runs/<task-type>/worker-results/<worker>-audit-<task-type>-<seq>.md`
+    (sibling to the main worker-results file). One short line per input
+    file confirming end-to-end reading, e.g. "Read task-brief.md
+    end-to-end (147 lines)." Do NOT include a `## 0. Reading Confirmation`
+    heading in the main worker-results file — the validator now fails
+    worker-results that contain one. If you cannot truthfully confirm a
+    file end-to-end, record a `tool-failure` in the errors sidecar
+    instead of fabricating Findings.
+  - Do not collapse multiple input files into a single mental summary before
+    reading them all individually. Each file has its own canonical role
+    (brief = the user's request, profile = the lead's rules for this phase,
+    reference-expectations = ground-truth config/deployment values,
+    clarification-response = prior run's open questions and the user's
+    answers, final-report-template = the structure your eventual writeup
+    must conform to). Conflating them loses signal.
+```
+
+- [ ] **Step 4: 테스트 통과 확인**
+
+```bash
+python3 -m pytest tests/test_required_reading_fragment.py -v
+```
+
+Expected: 3 PASS.
+
+- [ ] **Step 5: 커밋**
+
+```bash
+git add prompts/fragments/required-reading-block.md tests/test_required_reading_fragment.py
+git commit -m "feat(prompts/fragments): extract [Required reading] clause into SSOT fragment"
+```
+
+### Task B2: `[Error reporting]` fragment 파일 생성
+
+**Files:**
+- Create: `prompts/fragments/error-reporting-block.md`
+- Test: `tests/test_error_reporting_fragment.py`
+
+- [ ] **Step 1: 실패 테스트 작성**
+
+```python
+# tests/test_error_reporting_fragment.py
+from pathlib import Path
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+FRAGMENT = REPO_ROOT / "prompts/fragments/error-reporting-block.md"
+
+
+def test_fragment_file_exists():
+    assert FRAGMENT.is_file()
+
+
+def test_fragment_starts_with_block_marker():
+    content = FRAGMENT.read_text(encoding="utf-8")
+    assert content.startswith("[Error reporting]\n")
+
+
+def test_fragment_has_role_slug_placeholder():
+    content = FRAGMENT.read_text(encoding="utf-8")
+    assert "<role-slug>" in content, \
+        "fragment must keep <role-slug> placeholder so wrapper subagents substitute their own role"
+
+
+def test_fragment_preserves_schema_keys():
+    content = FRAGMENT.read_text(encoding="utf-8")
+    for key in ["ts", "phase", "errorType", "tool-failure", "commandKind",
+                "exitCode", "durationMs", "stderrExcerpt"]:
+        assert key in content, f"schema key dropped: {key!r}"
+```
+
+- [ ] **Step 2: 테스트 실패 확인**
+
+```bash
+python3 -m pytest tests/test_error_reporting_fragment.py -v
+```
+
+Expected: 4 failures.
+
+- [ ] **Step 3: fragment 작성 (`skills/okstra-team-contract/SKILL.md` L169-196 본문 그대로)**
+
+```markdown
+<!-- prompts/fragments/error-reporting-block.md -->
+[Error reporting]
+If any tool call you make (Bash, Read, Edit, MCP, etc.) returns a non-zero
+exit code, raises an exception, or otherwise fails its intended effect,
+append a single entry to your worker errors sidecar at:
+
+  runs/<task-type>/worker-results/<role-slug>-errors-<task-type>-<seq>.json
+
+Schema (create the file with {"schemaVersion": 1, "errors": []} if absent):
+
+  {
+    "ts": "<ISO 8601 UTC>",
+    "phase": "<current okstra phase>",
+    "errorType": "tool-failure",
+    "command": "<failed command/tool signature>",
+    "commandKind": "bash | tool:Read | tool:Edit | mcp | ...",
+    "exitCode": <int or null>,
+    "durationMs": <int or null>,
+    "message": "<one-line human summary>",
+    "stderrExcerpt": "<first ~2KB of stderr, or null>",
+    "context": { ... or null }
+  }
+
+Do NOT include source / recordedAt / agent / agentRole / model / taskKey —
+Lead will fill those in. Do NOT use errorType values other than
+"tool-failure" in the sidecar. Continue your task after recording; do not
+abort unless the failure makes the task impossible.
+```
+
+- [ ] **Step 4: 테스트 통과 확인**
+
+```bash
+python3 -m pytest tests/test_error_reporting_fragment.py -v
+```
+
+Expected: 4 PASS.
+
+- [ ] **Step 5: 커밋**
+
+```bash
+git add prompts/fragments/error-reporting-block.md tests/test_error_reporting_fragment.py
+git commit -m "feat(prompts/fragments): extract [Error reporting] clause into SSOT fragment"
+```
+
+### Task B3: `okstra-team-contract` skill 본문 → pointer 룰로 교체
+
+**Files:**
+- Modify: `skills/okstra-team-contract/SKILL.md` (L86-159 + L161-199 두 블록)
+- Test: 기존 `tests/` 풀 회귀로 검증
+
+- [ ] **Step 1: 실패 테스트 작성 (team-contract 의 verbatim body 가 제거되었는지)**
+
+```python
+# tests/test_team_contract_uses_pointers.py
+from pathlib import Path
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+TC = REPO_ROOT / "skills/okstra-team-contract/SKILL.md"
+
+
+def test_required_reading_body_replaced_with_pointer():
+    content = TC.read_text(encoding="utf-8")
+    # 본문에 있던 verbatim 첫 줄이 더 이상 없어야 함
+    assert "Required files for this run (read in this order, end-to-end" not in content, \
+        "team-contract still inlines [Required reading] body; expected pointer only"
+    # 대신 fragment 경로 pointer 가 있어야 함
+    assert "prompts/fragments/required-reading-block.md" in content
+
+
+def test_error_reporting_body_replaced_with_pointer():
+    content = TC.read_text(encoding="utf-8")
+    assert '"errorType": "tool-failure",' not in content, \
+        "team-contract still inlines [Error reporting] JSON schema; expected pointer only"
+    assert "prompts/fragments/error-reporting-block.md" in content
+
+
+def test_pointer_rules_remain_blocking():
+    content = TC.read_text(encoding="utf-8")
+    # BLOCKING 마커는 그대로 살아 있어야 함 (룰 자체는 사라진 게 아님)
+    assert "BLOCKING" in content
+    assert "byte-identical" in content
+```
+
+- [ ] **Step 2: 테스트 실패 확인**
+
+```bash
+python3 -m pytest tests/test_team_contract_uses_pointers.py -v
+```
+
+Expected: 2 FAIL (verbatim body 가 아직 있음), 1 PASS.
+
+- [ ] **Step 3: `Required reading clause` 섹션 교체**
+
+`skills/okstra-team-contract/SKILL.md` L86-159 (Required reading clause 섹션 전체) 를 다음으로 교체:
+
+```markdown
+### Required reading clause (analysis workers + report-writer worker)
+
+The clause body lives in `prompts/fragments/required-reading-block.md` (SSOT). Every analysis worker's prompt and the report-writer worker's prompt MUST embed that file's exact content verbatim — the lead's dispatch helper is responsible for the expansion (see `agents/workers/codex-worker.md` / `gemini-worker.md` "Resolve required-reading pointer" step for CLI workers; in-process `claude-worker` already mounts the same content through `## Required Reading Before Any Analysis` and does not need re-injection).
+
+Replace placeholder file paths in the block with the actual project-relative paths derived from the run's `instruction-set/` and (if applicable) the carry-in clarification response.
+
+**Audience-scoped enumeration (BLOCKING — performance optimization):**
+
+Different recipients need different files. Do NOT include `final-report-template.md` in analysis worker prompts: analysis workers produce findings (not the final report), and forcing them to read the template inflates token usage without changing finding quality.
+
+| Recipient | Files included in `[Required reading]` |
+|---|---|
+| Claude / Codex / Gemini analysis workers | task-brief, analysis-profile, analysis-material (if present), reference-expectations, clarification-response (if carry-in) |
+| Report writer worker (Phase 6) | all of the above **plus** `final-report-template.md` |
+| Reverify dispatches (Phase 5.5, lightweight mode) | **do NOT inject the `[Required reading]` clause at all** — see [okstra-convergence](../okstra-convergence/SKILL.md) "Reverify prompt: required-reading suppression". |
+
+**Asymmetry between claude-worker and codex/gemini-worker prompts (NOT a bug):**
+
+The dispatch prompt the lead constructs for `claude-worker` is intentionally shorter than for `codex-worker` / `gemini-worker`. Do NOT "fix" this by re-injecting `[Required reading]` / `[Error reporting]` / `[Output Contract]` blocks into the claude-worker prompt:
+
+- `claude-worker` is an in-process Claude subagent. The Agent SDK auto-loads `agents/claude-worker.md`, which already contains `## Required Reading Before Any Analysis`, `## Worker Output Structure`, and `## Error reporting`. Re-injecting them is redundant and wastes tokens.
+- `codex-worker` / `gemini-worker` shell out to a CLI. The CLI never sees the agent definition file — it only sees the prompt body passed via stdin. Therefore the lead's dispatch prompt for those workers MUST carry a single pointer line:
+
+  ```
+  [Required reading] — fragment: prompts/fragments/required-reading-block.md (resolve before CLI launch)
+  ```
+
+  The wrapper subagent (codex-worker / gemini-worker definition) is contractually required to read that fragment, perform the placeholder substitutions, and inline the resulting block into the CLI stdin payload before invoking `okstra-codex-exec.sh` / `okstra-gemini-exec.sh`. The lead MUST NOT inline the fragment body itself — the pointer-only form is what keeps lead context flat across runs.
+
+Worker definition file size (claude-worker ~106 lines vs codex/gemini ~175–179 lines) is NOT evidence of incompleteness — it reflects the in-process vs CLI-wrapper distinction.
+```
+
+- [ ] **Step 4: `Error reporting clause` 섹션 교체**
+
+`skills/okstra-team-contract/SKILL.md` L161-196 (`### Error reporting clause` 전체) 를 다음으로 교체:
+
+```markdown
+### Error reporting clause (analysis workers)
+
+The clause body lives in `prompts/fragments/error-reporting-block.md` (SSOT). Every analysis worker (Claude / Codex / Gemini) receives the same content; the wrapper subagent for codex/gemini resolves and inlines the fragment into the CLI stdin payload at dispatch time, substituting `<role-slug>` with the receiving role (`claude-worker` / `codex-worker` / `gemini-worker`).
+
+The lead's dispatch prompt for codex/gemini workers MUST carry a single pointer line:
+
+```
+[Error reporting] — fragment: prompts/fragments/error-reporting-block.md (resolve before CLI launch, substitute <role-slug>)
+```
+
+Subagent definitions for all three workers already carry an equivalent in-process contract (see each `agents/workers/*.md` "Error reporting" section). The fragment serves as a redundant safety net so any worker dispatched without its custom definition still receives identical instructions.
+```
+
+- [ ] **Step 5: 테스트 통과 확인**
+
+```bash
+python3 -m pytest tests/test_team_contract_uses_pointers.py -v
+python3 -m pytest tests/ -x -q  # 전체 회귀
+```
+
+Expected: 3 PASS. 회귀는 0 failure.
+
+- [ ] **Step 6: 커밋**
+
+```bash
+git add skills/okstra-team-contract/SKILL.md tests/test_team_contract_uses_pointers.py
+git commit -m "refactor(team-contract): replace [Required reading]/[Error reporting] body with fragment pointers"
+```
+
+### Task B4: codex-worker / gemini-worker wrapper 가 pointer 를 resolve 하는 step 추가
+
+**Files:**
+- Modify: `agents/workers/codex-worker.md` (Execution Rules 안에 step 추가)
+- Modify: `agents/workers/gemini-worker.md` (byte-identical 변경)
+- Test: `tests/test_dispatch_prompt_pointer.py`
+
+- [ ] **Step 1: 실패 테스트 작성**
+
+```python
+# tests/test_dispatch_prompt_pointer.py
+from pathlib import Path
+import re
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+CODEX = REPO_ROOT / "agents/workers/codex-worker.md"
+GEMINI = REPO_ROOT / "agents/workers/gemini-worker.md"
+FRAGMENT_RR = REPO_ROOT / "prompts/fragments/required-reading-block.md"
+FRAGMENT_ER = REPO_ROOT / "prompts/fragments/error-reporting-block.md"
+
+
+def _expect_resolve_step(path: Path):
+    content = path.read_text(encoding="utf-8")
+    # 본문 안에 "Resolve required-reading pointer" 헤딩이 있고
+    assert re.search(r"^##\s+Resolve required-reading.*pointer", content, re.M), \
+        f"{path.name} missing 'Resolve required-reading pointer' section"
+    # fragment 경로 두 개를 모두 참조해야 함
+    assert "prompts/fragments/required-reading-block.md" in content
+    assert "prompts/fragments/error-reporting-block.md" in content
+    # 그리고 절대 verbatim body 를 inline 하면 안 됨
+    assert "Required files for this run (read in this order" not in content, \
+        f"{path.name} inlines fragment body; pointer-resolve step must NOT duplicate it"
+
+
+def test_codex_worker_has_resolve_step():
+    _expect_resolve_step(CODEX)
+
+
+def test_gemini_worker_has_resolve_step():
+    _expect_resolve_step(GEMINI)
+
+
+def test_codex_and_gemini_resolve_steps_are_byte_identical():
+    """codex / gemini 워커의 Resolve 섹션 본문은 byte-identical 이어야 한다 (role 이름만 다름)."""
+    def _extract(path: Path) -> str:
+        content = path.read_text(encoding="utf-8")
+        m = re.search(
+            r"^##\s+Resolve required-reading.*?(?=^##\s)",
+            content, re.M | re.S,
+        )
+        assert m, f"{path.name} missing Resolve section"
+        body = m.group(0)
+        # role 이름만 다른 부분은 normalize
+        body = body.replace("codex-worker", "<ROLE>").replace("gemini-worker", "<ROLE>")
+        body = body.replace("Codex", "<ROLE_TITLE>").replace("Gemini", "<ROLE_TITLE>")
+        body = body.replace("okstra-codex-exec.sh", "<EXEC_SH>").replace("okstra-gemini-exec.sh", "<EXEC_SH>")
+        return body
+
+    assert _extract(CODEX) == _extract(GEMINI), \
+        "codex/gemini Resolve sections diverged — keep them byte-identical modulo role tokens"
+```
+
+- [ ] **Step 2: 테스트 실패 확인**
+
+```bash
+python3 -m pytest tests/test_dispatch_prompt_pointer.py -v
+```
+
+Expected: 3 FAIL.
+
+- [ ] **Step 3: codex-worker.md 에 `## Resolve required-reading + error-reporting pointers` 섹션 추가**
+
+`agents/workers/codex-worker.md` 의 기존 "Execution Rules" 섹션 직후에 다음을 삽입한다 (정확한 위치는 codex-worker.md L 의 첫 `## ` heading 바로 위; existing prompt persist step 직후가 자연스러움):
+
+```markdown
+## Resolve required-reading + error-reporting pointers
+
+Before launching `okstra-codex-exec.sh`, the lead's dispatch prompt arrives with two pointer lines instead of the legacy verbatim blocks:
+
+```
+[Required reading] — fragment: prompts/fragments/required-reading-block.md (resolve before CLI launch)
+[Error reporting] — fragment: prompts/fragments/error-reporting-block.md (resolve before CLI launch, substitute <role-slug>)
+```
+
+This wrapper subagent MUST expand both pointers in-process BEFORE writing the prompt history file and BEFORE shelling out to the CLI:
+
+1. `Read` the file at `<Project Root>/prompts/fragments/required-reading-block.md` (whole file, single Read call, no offset/limit). If the file is missing, return `CODEX_REQUIRED_READING_FRAGMENT_MISSING` without proceeding.
+2. Substitute the placeholders in the fragment with the actual run-specific paths the lead supplied in its dispatch prompt body (`<Project Root>`, `<instruction-set>` segments, and the conditional carry-in line). Omit row 6 (`final-report-template.md`) — this worker is NOT the report-writer.
+3. `Read` the file at `<Project Root>/prompts/fragments/error-reporting-block.md` and substitute `<role-slug>` with `codex-worker`.
+4. Replace the two pointer lines in the dispatch prompt body with the expanded blocks (Required reading first, Error reporting next, in their original order).
+5. Persist the **expanded** prompt to the assigned prompt history path — this is what gets piped into the CLI and what auditors will read later. The pointer-only form must not survive into the history file.
+6. Only then invoke `okstra-codex-exec.sh` with the expanded prompt path.
+
+Rationale: lead carries the pointer (~2 lines) in its own context instead of the full ~75-line clause body, so the lead's per-dispatch context cost drops by ~95% for these two clauses. The wrapper subagent's own context picks up the expansion cost (~2KB once per dispatch), but the wrapper is a fresh subagent per worker — that cost does not accumulate across dispatches the way lead context does.
+
+If either fragment file is missing on disk, abort with the `_FRAGMENT_MISSING` sentinel above — do NOT fall back to inlining a remembered version of the body. The fragment files are the SSOT; stale in-memory copies are a contract violation.
+```
+
+- [ ] **Step 4: gemini-worker.md 에 동일한 섹션을 byte-identical 로 삽입**
+
+`agents/workers/gemini-worker.md` 에 같은 위치 (Execution Rules 직후) 에 같은 블록을 삽입하되, 다음 토큰만 치환:
+
+- `okstra-codex-exec.sh` → `okstra-gemini-exec.sh`
+- `CODEX_REQUIRED_READING_FRAGMENT_MISSING` → `GEMINI_REQUIRED_READING_FRAGMENT_MISSING`
+- `codex-worker` (role-slug) → `gemini-worker`
+
+다른 모든 줄은 그대로.
+
+- [ ] **Step 5: 테스트 통과 확인**
+
+```bash
+python3 -m pytest tests/test_dispatch_prompt_pointer.py -v
+```
+
+Expected: 3 PASS.
+
+- [ ] **Step 6: 커밋**
+
+```bash
+git add agents/workers/codex-worker.md agents/workers/gemini-worker.md tests/test_dispatch_prompt_pointer.py
+git commit -m "feat(workers/codex,gemini): resolve required-reading + error-reporting pointers in wrapper subagent"
+```
+
+### Task B5: lead 의 dispatch 룰 갱신 (`agents/SKILL.md`)
+
+**Files:**
+- Modify: `agents/SKILL.md` (Phase 2-5 박스 + Anti-patterns 표)
+
+- [ ] **Step 1: 실패 테스트 작성**
+
+```python
+# tests/test_lead_dispatch_uses_pointer.py
+from pathlib import Path
+import re
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+LEAD = REPO_ROOT / "agents/SKILL.md"
+
+
+def test_lead_skill_documents_pointer_only_dispatch():
+    content = LEAD.read_text(encoding="utf-8")
+    assert "fragment: prompts/fragments/required-reading-block.md" in content, \
+        "lead skill must document the pointer-only dispatch form"
+
+
+def test_lead_skill_forbids_inlining_fragment_body():
+    content = LEAD.read_text(encoding="utf-8")
+    # 룰 박스에 inline 금지 라인이 명시되어야 함
+    assert re.search(
+        r"Inlining (the )?\[Required reading\] (or \[Error reporting\] )?fragment body",
+        content,
+    ), "lead skill must forbid inlining fragment body in dispatch prompts"
+```
+
+- [ ] **Step 2: 테스트 실패 확인**
+
+```bash
+python3 -m pytest tests/test_lead_dispatch_uses_pointer.py -v
+```
+
+Expected: 2 FAIL.
+
+- [ ] **Step 3: `agents/SKILL.md` Phase 2-5 박스 갱신**
+
+`agents/SKILL.md` L177-184 부근 ("Phase 2 — Phase 5: Prompt preparation..." 박스) 의 `- The [Required reading] clause (audience-scoped enumeration...)` 와 `- The [Error reporting] clause and the asymmetry...` 두 bullet 을 다음으로 교체:
+
+```markdown
+- The `[Required reading]` clause — for in-process `claude-worker`, the agent definition (`agents/workers/claude-worker.md` "## Required Reading Before Any Analysis") owns the body. For CLI-wrapper workers (`codex-worker` / `gemini-worker`), the lead's dispatch prompt carries ONLY the pointer line `[Required reading] — fragment: prompts/fragments/required-reading-block.md (resolve before CLI launch)`. The wrapper subagent reads the fragment, performs placeholder substitution, and inlines the result into the CLI stdin payload. Lead MUST NOT embed the fragment body itself — the pointer-only form is what keeps lead context flat across runs.
+- The `[Error reporting]` clause — same pointer-only pattern. Lead emits `[Error reporting] — fragment: prompts/fragments/error-reporting-block.md (resolve before CLI launch, substitute <role-slug>)`. Wrapper subagent expands; lead does not.
+- Audience-scoped enumeration (analysis workers vs report-writer vs reverify dispatches) and the asymmetry between in-process vs CLI workers remain as documented in [okstra-team-contract](./skills/okstra-team-contract/SKILL.md).
+```
+
+- [ ] **Step 4: Anti-patterns 표에 새 행 추가**
+
+`agents/SKILL.md` 의 anti-patterns 표 (L340-356 부근) 끝에 두 행 추가:
+
+```markdown
+| Inlining the `[Required reading]` fragment body into the lead's dispatch prompt for codex/gemini workers | Use the pointer-only form per [okstra-team-contract](./skills/okstra-team-contract/SKILL.md) "Required reading clause" — wrapper subagent resolves the fragment, lead does not. Inline form re-enters the lead's context on every cache miss and is the original cause of the lead-context bloat this rule fixes |
+| Inlining the `[Error reporting]` fragment body into the dispatch prompt | Same as above — pointer-only at the lead layer, expansion at the wrapper layer |
+```
+
+- [ ] **Step 5: 테스트 통과 확인**
+
+```bash
+python3 -m pytest tests/test_lead_dispatch_uses_pointer.py -v
+```
+
+Expected: 2 PASS.
+
+- [ ] **Step 6: 커밋**
+
+```bash
+git add agents/SKILL.md tests/test_lead_dispatch_uses_pointer.py
+git commit -m "docs(agents/SKILL): document pointer-only dispatch form for required-reading/error-reporting"
+```
+
+### Task B6: build pipeline 에 `prompts/fragments/` 추가
+
+**Files:**
+- Modify: `tools/build.mjs`
+
+- [ ] **Step 1: 현재 sync 대상 확인**
+
+```bash
+grep -n "prompts\|fragments" tools/build.mjs
+```
+
+`tools/build.mjs` 에서 `prompts/` 디렉토리를 rsync 하는 부분을 찾는다 (이미 sync 됨이면 이 task 는 no-op).
+
+- [ ] **Step 2: 실패 테스트 작성**
+
+```python
+# tests/test_build_includes_fragments.py
+import subprocess
+from pathlib import Path
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+
+
+def test_build_emits_fragments_into_runtime():
+    subprocess.run(["npm", "run", "build"], check=True, cwd=REPO_ROOT, capture_output=True)
+    rr = REPO_ROOT / "runtime/prompts/fragments/required-reading-block.md"
+    er = REPO_ROOT / "runtime/prompts/fragments/error-reporting-block.md"
+    assert rr.is_file(), f"build did not emit {rr}"
+    assert er.is_file(), f"build did not emit {er}"
+```
+
+- [ ] **Step 3: 테스트 실행 — 이미 통과하면 Step 5 로 점프**
+
+```bash
+python3 -m pytest tests/test_build_includes_fragments.py -v
+```
+
+`prompts/**/*` rsync glob 이 이미 fragments 를 잡으면 PASS. 아니면 FAIL.
+
+- [ ] **Step 4: (FAIL 인 경우만) `tools/build.mjs` 에 fragments 경로 추가**
+
+`tools/build.mjs` 의 prompts sync 블록에서 디렉토리 glob 이 fragments 를 포함하도록 수정. 이미 `prompts/**/*` 형태면 skip; `prompts/profiles/*.md` 처럼 특정 서브디렉토리만 잡으면 `prompts/fragments/*.md` 도 추가.
+
+```javascript
+// 예: 기존
+//   await rsync("prompts/profiles/", "runtime/prompts/profiles/");
+// 변경
+await rsync("prompts/profiles/", "runtime/prompts/profiles/");
+await rsync("prompts/fragments/", "runtime/prompts/fragments/");
+```
+
+- [ ] **Step 5: 테스트 통과 확인**
+
+```bash
+python3 -m pytest tests/test_build_includes_fragments.py -v
+```
+
+Expected: PASS.
+
+- [ ] **Step 6: 커밋**
+
+```bash
+git add tools/build.mjs tests/test_build_includes_fragments.py
+git commit -m "build: include prompts/fragments/ in runtime sync"
+```
+
+### Task B7: Track B 회귀 + e2e + CHANGES.md
+
+- [ ] **Step 1: 전체 회귀 + e2e 한 시나리오**
+
+```bash
+python3 -m pytest tests/ -x -q
+bash validators/validate-workflow.sh
+bash tests-e2e/scenario-01-record-start-reconcile.sh
+```
+
+Expected: 모두 PASS.
+
+- [ ] **Step 2: `CHANGES.md` 에 사용자 영향 entry 추가**
+
+`CHANGES.md` 최상단 (가장 최근 entry 위) 에 추가:
+
+```markdown
+### refactor(team-contract,workers): [Required reading]/[Error reporting] 본문을 fragment pointer 로 압축
+
+- **배경**: 매 worker dispatch 마다 lead 가 직접 작성하던 `[Required reading]` (~48 줄) + `[Error reporting]` (~27 줄) verbatim body 가 lead context baseline 의 누적 비용 주범이었다. 3 worker × 다단계 phase × 매 turn cache_read = lead totalTokens 의 큰 비중을 차지.
+- **변경**:
+  - 두 clause body 를 `prompts/fragments/required-reading-block.md` / `prompts/fragments/error-reporting-block.md` SSOT 파일로 추출.
+  - `skills/okstra-team-contract/SKILL.md` 의 본문 verbatim 룰을 pointer 룰로 교체 — lead 의 dispatch prompt 는 `[Required reading] — fragment: <path>` 한 줄만 보낸다.
+  - `agents/workers/codex-worker.md` / `gemini-worker.md` 에 `## Resolve required-reading + error-reporting pointers` 섹션 추가 — wrapper subagent 가 fragment 를 read → placeholder 치환 → CLI stdin 에 inline.
+  - `agents/SKILL.md` 의 Phase 2-5 박스 + Anti-patterns 표 업데이트.
+- **사용자 영향**: 다음 release 후 `npx -y okstra@latest install` 한 번이면 전파. lead 가 codex/gemini dispatch 당 약 75 줄 (~3KB) 의 body 를 더 이상 자체 context 에 담지 않는다. 같은 phase 안에서 dispatch 가 N 회 일어날 때 누적 절감은 N × 75 lines. wrapper subagent 의 context 는 dispatch 당 1회만 fragment 를 흡수하므로 lead-side 와 달리 누적되지 않는다. **호환성 영향**: 기존 prompt-history 파일은 expanded body 그대로 — auditor 가 읽는 형식은 변하지 않는다. lead 의 in-memory prompt 만 pointer-only.
+```
+
+- [ ] **Step 3: 커밋**
+
+```bash
+git add CHANGES.md
+git commit -m "docs(changes): record Required reading/Error reporting pointer compression"
+```
+
+---
+
+## Track D — Stage step 권장값 강화
+
+**Why now:** B 이후. cross-cutting 영향 없음. validator 의 hard cap 은 그대로 두고 권장값(soft) 만 ≤3 으로 강화 → planning 단계 부담은 작고, executor sync block 평균 길이는 절반.
+
+### Task D1: `implementation-planning.md` profile 본문 수정
+
+**Files:**
+- Modify: `prompts/profiles/implementation-planning.md` (L64 + L95)
+
+- [ ] **Step 1: 실패 테스트 작성**
+
+```python
+# tests/test_implementation_planning_step_guidance.py
+from pathlib import Path
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+PROFILE = REPO_ROOT / "prompts/profiles/implementation-planning.md"
+
+
+def test_step_count_recommendation_is_three():
+    content = PROFILE.read_text(encoding="utf-8")
+    # 새 권장값 문구
+    assert "권장 ≤ 3" in content or "recommended ≤ 3" in content, \
+        "implementation-planning profile must recommend ≤3 steps per stage"
+    # hard cap 6 은 유지
+    assert "절대 상한 6" in content or "hard cap 6" in content
+
+
+def test_self_review_step_seven_mentions_three():
+    content = PROFILE.read_text(encoding="utf-8")
+    # Self-review pass step 7 (Stage Map self-check) 안에 ≤3 권장이 들어가야 함
+    self_review = content[content.index("Stage Map self-check"):]
+    assert "≤ 3" in self_review[:1500] or "≤3" in self_review[:1500], \
+        "Stage Map self-check must call out the ≤3 recommendation"
+```
+
+- [ ] **Step 2: 테스트 실패 확인**
+
+```bash
+python3 -m pytest tests/test_implementation_planning_step_guidance.py -v
+```
+
+Expected: 2 FAIL.
+
+- [ ] **Step 3: L64 (Stepwise Execution Order bullet) 수정**
+
+`prompts/profiles/implementation-planning.md` 의 다음 줄을:
+
+```markdown
+    - `### Stepwise Execution Order` — bite-sized table with `step | action | files | command | expected`. **Effective row count ≤ 6** (excluding header / divider / blank). Each step is one action completable in 2–5 minutes; for code steps include actual code or diff sketch; prefer TDD ordering (failing test → implementation → green → commit).
+```
+
+다음으로 교체:
+
+```markdown
+    - `### Stepwise Execution Order` — bite-sized table with `step | action | files | command | expected`. **Effective row count 권장 ≤ 3, 절대 상한 6** (excluding header / divider / blank). 권장값을 초과하면 stage 를 더 잘게 partition 할 수 있는지 먼저 검토하고, partition 이 정말 불가능할 때만 4-6 step 을 유지한다 — executor 1 회 sync block 의 wall-clock 이 stage 길이에 비례하므로 짧은 stage 가 implementation lead 의 single-session 처리 가능성을 높인다. Each step is one action completable in 2–5 minutes; for code steps include actual code or diff sketch; prefer TDD ordering (failing test → implementation → green → commit).
+```
+
+- [ ] **Step 4: L95 (Self-review pass step 7) 수정**
+
+다음 줄을:
+
+```markdown
+  7. **Stage Map self-check** — for every stage, count the effective rows of its `Stepwise Execution Order` table by hand; reject the draft if any stage exceeds 6. Walk the `depends-on` graph and confirm it is a DAG (no cycle, no self-reference). For each `depends-on` link, ask "can this be removed by re-partitioning?" — if yes, re-partition and re-count.
+```
+
+다음으로 교체:
+
+```markdown
+  7. **Stage Map self-check** — for every stage, count the effective rows of its `Stepwise Execution Order` table by hand; reject the draft if any stage exceeds the hard cap 6. **For every stage with 4 step 이상, 명시적으로 "이 stage 를 2 개 이상으로 split 할 수 있는가?" 를 자문하고 그 결정 근거(예: "step 3 과 step 4 의 산출물이 동일 commit 에 묶여야 한다") 를 plan 본문에 한 줄로 기록한다** — 4-6 step stage 는 권장값(≤ 3) 위반이므로 정당화 없이 통과해서는 안 된다. Walk the `depends-on` graph and confirm it is a DAG (no cycle, no self-reference). For each `depends-on` link, ask "can this be removed by re-partitioning?" — if yes, re-partition and re-count.
+```
+
+- [ ] **Step 5: 테스트 통과 확인**
+
+```bash
+python3 -m pytest tests/test_implementation_planning_step_guidance.py -v
+```
+
+Expected: 2 PASS.
+
+- [ ] **Step 6: 커밋**
+
+```bash
+git add prompts/profiles/implementation-planning.md tests/test_implementation_planning_step_guidance.py
+git commit -m "feat(planning): recommend ≤3 steps per stage; require justification when 4-6"
+```
+
+### Task D2: validator 에 step >3 warning 추가
+
+**Files:**
+- Modify: `validators/validate-implementation-plan-stages.py`
+- Test: `tests/test_validate_implementation_plan_stages_warnings.py`
+
+- [ ] **Step 1: 실패 테스트 작성**
+
+```python
+# tests/test_validate_implementation_plan_stages_warnings.py
+"""validate-implementation-plan-stages.py 의 새 warning 동작 검증.
+
+목표:
+- steps ∈ {2, 3} → warning 0건, exit 0
+- steps ∈ {4, 5, 6} → warning 1건 per stage, exit 0 (hard cap 유지)
+- steps == 7 → 기존 S5 error, exit non-zero
+"""
+import subprocess
+import sys
+import textwrap
+from pathlib import Path
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+SCRIPT = REPO_ROOT / "validators/validate-implementation-plan-stages.py"
+
+
+def _plan_with_steps(step_count: int) -> str:
+    """`step_count` 개의 effective row 를 가진 single-stage plan 본문."""
+    rows = "\n".join(
+        f"| {i+1} | action-{i+1} | file.py | cmd | expected |" for i in range(step_count)
+    )
+    return textwrap.dedent(f"""\
+        ## 4.5 Stage Map
+
+        | stage | title | depends-on | step-count | exit-contract-summary |
+        |-------|-------|------------|------------|-----------------------|
+        | 1 | Solo | (none) | {step_count} | exit |
+
+        ## 4.5.1 Stage 1: Solo
+
+        ### Carry-In
+        task-brief only.
+
+        ### Stepwise Execution Order
+        | step | action | files | command | expected |
+        |------|--------|-------|---------|----------|
+        {rows}
+
+        ### Stage Exit Contract
+        exit details.
+
+        ### Stage Validation
+        - pre: noop
+        - post: noop
+    """)
+
+
+def _run(plan_text: str, tmp_path: Path) -> subprocess.CompletedProcess:
+    plan = tmp_path / "plan.md"
+    plan.write_text(plan_text, encoding="utf-8")
+    return subprocess.run(
+        [sys.executable, str(SCRIPT), str(plan)],
+        capture_output=True, text=True,
+    )
+
+
+def test_two_steps_no_warning(tmp_path):
+    r = _run(_plan_with_steps(2), tmp_path)
+    assert r.returncode == 0
+    assert "WARN" not in r.stderr
+
+
+def test_three_steps_no_warning(tmp_path):
+    r = _run(_plan_with_steps(3), tmp_path)
+    assert r.returncode == 0
+    assert "WARN" not in r.stderr
+
+
+def test_four_steps_warning_but_pass(tmp_path):
+    r = _run(_plan_with_steps(4), tmp_path)
+    assert r.returncode == 0, f"unexpected fail: {r.stderr}"
+    assert "WARN" in r.stderr and "step-count=4" in r.stderr
+
+
+def test_six_steps_warning_but_pass(tmp_path):
+    r = _run(_plan_with_steps(6), tmp_path)
+    assert r.returncode == 0
+    assert "WARN" in r.stderr and "step-count=6" in r.stderr
+
+
+def test_seven_steps_hard_fail(tmp_path):
+    r = _run(_plan_with_steps(7), tmp_path)
+    assert r.returncode != 0
+    assert "S5" in (r.stdout + r.stderr)
+```
+
+- [ ] **Step 2: 테스트 실패 확인**
+
+```bash
+python3 -m pytest tests/test_validate_implementation_plan_stages_warnings.py -v
+```
+
+Expected: 5 FAIL (현재 validator 는 warning 미발행).
+
+- [ ] **Step 3: validator 코드 수정**
+
+`validators/validate-implementation-plan-stages.py` L1 부근의 상수에 추가:
+
+```python
+RECOMMENDED_STEP_CAP = 3
+HARD_STEP_CAP = 6
+```
+
+`_check_subsections` 함수 (현재 L131-146 부근) 안의 `if steps > 6:` 블록을 다음으로 교체:
+
+```python
+        # S5: effective step count hard cap
+        steps = _count_effective_steps(section)
+        if steps > HARD_STEP_CAP:
+            errs.append(ValidationError("S5", s.stage_number,
+                f"effective step count {steps} exceeds hard cap {HARD_STEP_CAP}"))
+        elif steps > RECOMMENDED_STEP_CAP:
+            # Warning — exit code 영향 없음. stderr 로 한 줄.
+            import sys as _sys
+            print(
+                f"WARN stage {s.stage_number}: step-count={steps} exceeds "
+                f"recommended cap {RECOMMENDED_STEP_CAP} (hard cap {HARD_STEP_CAP}); "
+                "consider splitting this stage",
+                file=_sys.stderr,
+            )
+```
+
+(`import sys` 가 이미 파일 상단에 있다면 inline import 는 제거하고 모듈-level 만 사용.)
+
+- [ ] **Step 4: 테스트 통과 확인**
+
+```bash
+python3 -m pytest tests/test_validate_implementation_plan_stages_warnings.py -v
+```
+
+Expected: 5 PASS.
+
+- [ ] **Step 5: 기존 validator 테스트 회귀 확인**
+
+```bash
+python3 -m pytest tests/ -x -q -k validate
+```
+
+Expected: 회귀 0건.
+
+- [ ] **Step 6: 커밋**
+
+```bash
+git add validators/validate-implementation-plan-stages.py tests/test_validate_implementation_plan_stages_warnings.py
+git commit -m "feat(validators/plan-stages): warn (no fail) when stage step-count > 3"
+```
+
+### Task D3: template 예시 갱신 + CHANGES.md
+
+**Files:**
+- Modify: `templates/reports/implementation-planning-input.template.md`
+- Modify: `CHANGES.md`
+
+- [ ] **Step 1: 현재 예시 확인**
+
+```bash
+grep -n -A2 "stage | title | depends-on | step-count" templates/reports/implementation-planning-input.template.md
+```
+
+`step-count` 컬럼의 예시 값이 무엇인지 확인.
+
+- [ ] **Step 2: 예시 step-count 값을 ≤3 으로 갱신**
+
+`templates/reports/implementation-planning-input.template.md` 의 두 예시 Stage Map 표 (L111-119 부근) 의 step-count 컬럼 값을 모두 2 또는 3 으로 바꾸고, 표 직전에 다음 한 줄을 삽입:
+
+```markdown
+> 권장: stage 당 effective step count ≤ 3 (hard cap 6). 4 step 이상이면 split 가능 여부를 먼저 검토.
+```
+
+- [ ] **Step 3: `CHANGES.md` 사용자 영향 entry 추가**
+
+```markdown
+### feat(planning): stage 당 step 권장값을 ≤ 3 으로 강화 (hard cap 6 은 유지)
+
+- **배경**: implementation phase 의 single stage 가 5-6 step 으로 partitioned 되면 executor 1 회 sync block 의 wall-clock 이 길어져 lead 의 single-session 처리 한계를 초과하는 패턴이 반복 관측되었다. Stage 가 짧을수록 한 lead 세션 안에서 dispatch → 검증 → persist 가 모두 끝날 가능성이 높다.
+- **변경**:
+  - `prompts/profiles/implementation-planning.md` 의 "Effective row count ≤ 6" 룰을 "권장 ≤ 3, 절대 상한 6" 으로 강화. 4-6 step stage 는 정당화(예: "step 3, 4 의 산출물이 같은 commit 에 묶여야 한다") 한 줄을 plan 본문에 기록해야 함.
+  - `validators/validate-implementation-plan-stages.py` 에 `step > 3` warning 추가 (stderr 한 줄, exit code 영향 없음). `step > 6` hard fail 은 기존대로 유지.
+  - template 예시의 step-count 컬럼 값을 ≤ 3 으로 갱신.
+- **사용자 영향**: 다음 release 후 `npx -y okstra@latest install` 한 번이면 전파. **기존 plan 영향**: 이미 산출된 plan 은 그대로 (validator 가 warning 만 emit). **신규 implementation-planning run 부터**: report-writer 가 partition 을 한 단계 더 미세하게 가져갈 가능성이 높아지고, 따라서 implementation run 의 평균 wall-clock 이 짧아진다. **호환성 영향**: 4-6 step stage 도 여전히 통과하므로 breaking change 아님 — warning 은 다음 partition iteration 의 트리거일 뿐.
+```
+
+- [ ] **Step 4: 회귀 확인**
+
+```bash
+python3 -m pytest tests/ -x -q
+```
+
+- [ ] **Step 5: 커밋**
+
+```bash
+git add templates/reports/implementation-planning-input.template.md CHANGES.md
+git commit -m "docs(template,changes): update Stage Map examples to ≤3 steps"
+```
+
+---
+
+## Track C — implementation profile lazy split
+
+**Why last:** B/D 적용 후 실측을 한 번 보고 진입 — 이미 lead context 가 충분히 슬림해졌다면 C 의 BLOCKING gate 설계 복잡도를 감수할 가치가 작다. 실측 후에도 lead 가 phase 6 안에서 못 끝낸다면 진행.
+
+**Decision gate before C:** 다음 두 측정값이 모두 충족되면 C 진행. 그렇지 않으면 C 를 holdback 으로 분류하고 plan 을 닫음.
+
+1. B/D 적용 후 첫 implementation 실측에서 lead totalTokens 가 baseline 대비 30 % 이상 감소했는가? (못 줄였다면 C 가 효과가 크지 않음)
+2. B/D 만으로도 phase 6 를 한 lead 세션 안에 끝낼 수 있는가? (그렇다면 C 는 over-engineering)
+
+위 측정은 이 plan 의 범위 밖. 사용자에게 결과 보고 후 C 진입 여부 결정.
+
+이하 task 들은 **C 진행이 결정된 후에만** 실행한다.
+
+### Task C1: 3개 sidecar 파일 생성 (executor / verifier / deliverable)
+
+**Files:**
+- Create: `prompts/profiles/_implementation-executor.md`
+- Create: `prompts/profiles/_implementation-verifier.md`
+- Create: `prompts/profiles/_implementation-deliverable.md`
+- Test: `tests/test_implementation_profile_split.py` (1차)
+
+- [ ] **Step 1: 실패 테스트 작성 (sidecar 존재 + content invariant)**
+
+```python
+# tests/test_implementation_profile_split.py
+from pathlib import Path
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+PROFILES = REPO_ROOT / "prompts/profiles"
+MAIN = PROFILES / "implementation.md"
+EXECUTOR = PROFILES / "_implementation-executor.md"
+VERIFIER = PROFILES / "_implementation-verifier.md"
+DELIVERABLE = PROFILES / "_implementation-deliverable.md"
+
+
+def test_three_sidecars_exist():
+    for p in (EXECUTOR, VERIFIER, DELIVERABLE):
+        assert p.is_file(), f"sidecar missing: {p}"
+
+
+def test_executor_sidecar_owns_tdd_loop():
+    content = EXECUTOR.read_text(encoding="utf-8")
+    assert "Mandatory TDD loop" in content
+    assert "red-green-refactor" in content
+    assert "Sidecar evidence writer" in content
+
+
+def test_verifier_sidecar_owns_qa_duties():
+    content = VERIFIER.read_text(encoding="utf-8")
+    assert "Two-tier command lookup" in content
+    assert "deny-list" in content
+    assert "Read-only command log" in content
+
+
+def test_deliverable_sidecar_owns_final_report_shape():
+    content = DELIVERABLE.read_text(encoding="utf-8")
+    assert "Required deliverable shape" in content
+    assert "Self-review pass" in content
+    assert "Lead post-stage persistence" in content
+
+
+def test_sidecars_do_not_use_include_directive():
+    """sidecar 는 lead 가 직접 Read 하므로 INCLUDE 토큰 expand 불필요."""
+    for p in (EXECUTOR, VERIFIER, DELIVERABLE):
+        assert "{{INCLUDE:" not in p.read_text(encoding="utf-8"), \
+            f"{p.name} should not rely on INCLUDE expansion"
+```
+
+- [ ] **Step 2: 테스트 실패 확인**
+
+```bash
+python3 -m pytest tests/test_implementation_profile_split.py -v
+```
+
+Expected: 5 FAIL.
+
+- [ ] **Step 3: `_implementation-executor.md` 작성 — 다음 섹션을 현재 `implementation.md` 에서 복사하여 옮긴다**
+
+다음 섹션 전체 (현재 위치는 `implementation.md` L64-86 + L87-100):
+
+- `Pre-implementation context exploration` (L64-78)
+- `Stage execution contract` (L79-86)
+- `Allowed actions during the run` (L87-100) — 단 verifier-specific 항목은 제외
+
+추가로 파일 최상단에 다음 헤더를 둔다:
+
+```markdown
+<!--
+Implementation profile — executor sidecar. Lead lazy-loads this file at the
+start of Phase 5 (executor dispatch). NOT included via `{{INCLUDE:}}` because
+lead context should NOT carry this body during Phase 1-4. Read once, retain
+until Phase 5 ends, then drop from active context for Phase 6/7.
+-->
+
+# Implementation profile — Executor sidecar
+
+> **When to read**: lead reads this file ONCE at the start of Phase 5 (after Stage Map parse, before issuing the Executor's first `Edit`/`Write`). The body governs ONLY the Executor role's behaviour. Verifier / report-writer behaviour lives in sibling sidecars.
+
+```
+
+이어서 원본 섹션을 그대로 붙여넣되, 헤딩 레벨을 `##` 으로 정규화한다 (`-` bullet 시작이었던 부분은 적절히 `## Pre-implementation context exploration` 등으로 승격).
+
+- [ ] **Step 4: `_implementation-verifier.md` 작성**
+
+다음 섹션을 옮긴다:
+
+- `Verifier QA duties` 블록 (현재 `implementation.md` L20-40 부근)
+- `Forbidden actions` 의 verifier-specific bullet 들 (L113-121)
+- `All-verifier-failure policy` (L43)
+
+헤더:
+
+```markdown
+<!--
+Implementation profile — verifier sidecar. Lead lazy-loads this file ONCE
+at Phase 5, BEFORE constructing the verifier worker dispatch prompts.
+-->
+
+# Implementation profile — Verifier sidecar
+
+> **When to read**: lead reads this file ONCE in Phase 5, between executor stage completion and the first verifier dispatch. Carries the two-tier command lookup, deny-list, discrepancy rule, and verifier-specific forbidden actions.
+
+```
+
+- [ ] **Step 5: `_implementation-deliverable.md` 작성**
+
+다음 섹션을 옮긴다:
+
+- `Required deliverable shape` (L122-143)
+- `Self-review pass` (L144-154)
+- `Lead post-stage persistence` (L155-159)
+
+헤더:
+
+```markdown
+<!--
+Implementation profile — deliverable sidecar. Lead lazy-loads this file ONCE
+at the start of Phase 6 (report-writer dispatch), AFTER all worker results
+are collected and convergence finished. Phase 1-5 do not need it.
+-->
+
+# Implementation profile — Deliverable sidecar
+
+> **When to read**: lead reads this file ONCE at the start of Phase 6 (after Phase 5.5 convergence completes, before constructing the report-writer dispatch prompt). Carries the final-report deliverable shape, lead's post-stage persistence rules, and the self-review checklist.
+
+```
+
+- [ ] **Step 6: 테스트 통과 확인**
+
+```bash
+python3 -m pytest tests/test_implementation_profile_split.py -v
+```
+
+Expected: 5 PASS.
+
+- [ ] **Step 7: 커밋**
+
+```bash
+git add prompts/profiles/_implementation-executor.md prompts/profiles/_implementation-verifier.md prompts/profiles/_implementation-deliverable.md tests/test_implementation_profile_split.py
+git commit -m "feat(profiles): split implementation.md sections into three lazy-load sidecars"
+```
+
+### Task C2: `implementation.md` 본체를 thin core 로 축소
+
+**Files:**
+- Modify: `prompts/profiles/implementation.md`
+- Test: `tests/test_implementation_profile_split.py` (2차 — substring 보존)
+
+- [ ] **Step 1: 실패 테스트 작성 (thin core 사이즈 + substring 보존)**
+
+`tests/test_implementation_profile_split.py` 에 다음을 추가:
+
+```python
+def test_main_profile_is_thin_core():
+    """thin core 는 약 50 줄 이하여야 한다 (baseline 비용 절감 목표)."""
+    lines = MAIN.read_text(encoding="utf-8").splitlines()
+    effective = [ln for ln in lines if ln.strip() and not ln.strip().startswith("<!--")]
+    assert len(effective) <= 65, f"main profile should be ≤65 effective lines, got {len(effective)}"
+
+
+def test_main_profile_keeps_pre_implementation_gate():
+    """Phase 1 진입 시 필요한 gate 룰은 thin core 에 잔류해야 한다."""
+    content = MAIN.read_text(encoding="utf-8")
+    assert "Pre-implementation gate" in content
+    assert "approved: true" in content
+
+
+def test_main_profile_keeps_task_worktree_block():
+    """Phase 1 의 worktree binding 도 thin core 에 잔류."""
+    content = MAIN.read_text(encoding="utf-8")
+    assert "Task worktree" in content
+    assert "EXECUTOR_WORKTREE_PATH" in content
+
+
+def test_main_profile_has_lazy_section_pointers():
+    """thin core 는 3 개 sidecar 의 read 시점을 명시한 박스를 가져야 한다."""
+    content = MAIN.read_text(encoding="utf-8")
+    assert "_implementation-executor.md" in content
+    assert "_implementation-verifier.md" in content
+    assert "_implementation-deliverable.md" in content
+    assert "Lazy section pointers" in content or "lazy section pointers" in content
+
+
+def test_main_plus_sidecars_cover_critical_tokens():
+    """split 전 implementation.md 의 핵심 토큰이 thin core + 3 sidecar 의 합에 모두 살아 있는지."""
+    union = "\n".join(
+        p.read_text(encoding="utf-8") for p in (MAIN, EXECUTOR, VERIFIER, DELIVERABLE)
+    )
+    critical_tokens = [
+        # executor 측
+        "Mandatory TDD loop",
+        "red-green-refactor",
+        "Stage execution contract",
+        "Sidecar evidence writer",
+        "Reverse link",
+        "One-PR-per-stage",
+        "Out-of-plan edits",
+        "Commit message format",
+        # verifier 측
+        "Two-tier command lookup",
+        "Tier 1 — plan validation set",
+        "Tier 2 — project baseline",
+        "deny-list",
+        "Discrepancy rule",
+        "Read-only command log",
+        "All-verifier-failure policy",
+        # deliverable 측
+        "Plan link & approval evidence",
+        "Stage sidecar evidence",
+        "Validation evidence",
+        "TDD evidence",
+        "Verifier results",
+        "Rollback verification",
+        "Routing recommendation for `final-verification`",
+        "Follow-up tasks",
+        "Self-review pass before finalising the report",
+        "Lead post-stage persistence",
+        # thin core 측
+        "Pre-implementation gate",
+        "Task worktree",
+        "EXECUTOR_WORKTREE_PATH",
+    ]
+    missing = [t for t in critical_tokens if t not in union]
+    assert not missing, f"tokens dropped during split: {missing}"
+```
+
+- [ ] **Step 2: 테스트 실패 확인 — `test_main_profile_is_thin_core` 등이 FAIL 이어야 함**
+
+```bash
+python3 -m pytest tests/test_implementation_profile_split.py -v -k "thin_core or lazy_section or critical_tokens"
+```
+
+Expected: 일부 FAIL (현재 implementation.md 가 아직 161 줄).
+
+- [ ] **Step 3: `implementation.md` 본체를 thin core 로 교체**
+
+`prompts/profiles/implementation.md` 전체를 다음으로 교체:
+
+```markdown
+# Implementation Profile
+
+- Purpose: realise the approved `implementation-planning` deliverable as actual source changes, with cross-model verification, while keeping the run reversible
+- Required workers:
+  - claude
+  - codex
+  - report-writer
+- Optional workers (opt-in via `--workers`):
+  - gemini — when added to the roster it joins the verifier set; when omitted only the Claude+Codex verifiers participate (`--executor gemini` is therefore not selectable without explicitly listing `gemini` in `--workers`)
+- **Executor binding (resolved at run-prep time, fixed for this run):**
+  - Executor display name: `{{EXECUTOR_DISPLAY_NAME}}`
+  - Executor provider: `{{EXECUTOR_PROVIDER}}` (one of: `claude` | `codex` | `gemini`; chosen via `--executor` or `OKSTRA_DEFAULT_EXECUTOR`, default `claude`)
+  - Executor subagent for dispatch: `{{EXECUTOR_WORKER_AGENT}}`
+  - Executor model: `{{EXECUTOR_MODEL_DISPLAY}}` (launch value: `{{EXECUTOR_MODEL_EXECUTION_VALUE}}`)
+  - Wherever this profile mentions the `Executor`, it refers to the role bound above. The other two providers in the roster (`claude` / `codex` / `gemini` minus the executor) are dispatched as **verifiers only** for this run and remain strictly read-only.
+{{INCLUDE:_common-contract.md}}
+- Pre-implementation gate (mandatory — refuse to start if any item fails):
+  - the run brief MUST cite `--approved-plan <path>` pointing to a `final-report.md` produced by a prior `implementation-planning` run located under `runs/implementation-planning/.../reports/final-report.md`
+  - that file's YAML frontmatter MUST carry `approved: true`. report-writer emits `approved: false` by default; the user flips it to `true` to authorise this run. Free-form approvals such as "lgtm" / "go ahead" / paraphrased confirmations are NOT accepted; re-edit the plan file's frontmatter to `approved: true` before invoking implementation, or pass `--approve` so the CLI flips it on the user's behalf (`okstra_ctl.run._apply_cli_approval`).
+  - The `--approve` flag is meaningful ONLY with `--task-type implementation` and `--approved-plan <path>`; any other use raises `PrepareError`. Idempotent — re-running with `approved: true` already set appends an audit line but does NOT re-toggle.
+  - the file's `Recommended option` and its bite-sized step list become the authoritative scope for this run; deviations must be justified in the final report and routed back to a new `implementation-planning` run rather than silently expanded.
+- Task worktree (provisioned by `okstra-ctl` at the first phase's run-prep time, reused for every subsequent phase of this task-key):
+  - Status: `{{EXECUTOR_WORKTREE_STATUS}}` (one of: `created` | `reused` | `skipped-in-worktree` | `skipped-not-git`)
+  - Working tree path: `{{EXECUTOR_WORKTREE_PATH}}` — when status is `created` or `reused`, this is the task's `git worktree` rooted at `~/.okstra/worktrees/<project>/<task-group>/<task-id>/`. When skipped, this is the caller's `project_root`.
+  - Branch: `{{EXECUTOR_WORKTREE_BRANCH}}` — empty when status is `skipped-*`. Branch name = `<work-category-prefix>-<task-id-segment>`, globally unique via `~/.okstra/worktrees/registry.json`.
+  - Base ref: `{{EXECUTOR_WORKTREE_BASE_REF}}` — canonical `<base>` for every `git diff` / `git log` in this run.
+  - Provisioning note: `{{EXECUTOR_WORKTREE_NOTE}}`
+  - Treat the working-tree path as `project_root` for the duration of this run. Do NOT mutate the caller's original checkout. cwd-sensitive Bash commands MUST be prefixed `cd {{EXECUTOR_WORKTREE_PATH}} && ` in the same Bash invocation (never `bash -lc "..."` wrappers — see executor sidecar for full rules).
+  - Lifecycle: kept after the run completes; reused by every subsequent phase of the same task-key. Manual cleanup: `git worktree remove <path>` → `git branch -D <branch>` → drop registry entry.
+- Approval gate (phase-specific addendum to shared authority rule):
+  - the pre-implementation gate's recorded user approval marker is the only authorised approval gate at this phase — proceed once it is satisfied without further external coordination.
+- Forbidden actions — universal (any occurrence → terminal status `contract-violated`):
+  - **`git push` of any kind**, including `--dry-run` against a real remote that produces side-effects
+  - publishing or release commands: `npm publish`, `cargo publish`, `pip publish`, `gh release`, `docker push`
+  - real database migrations or schema changes that touch shared environments
+  - production credentials, deploy commands, infra mutation against non-local clusters
+  - external API WRITE calls (POST/PUT/PATCH/DELETE) to third-party services other than localhost test fixtures
+  - dispatching parallel sub-agents beyond the required worker roster
+  - any Edit/Write before the pre-implementation gate has passed
+  - source edits or Bash mutations performed by any verifier role (verifier-specific deny-list lives in the verifier sidecar)
+- In-phase debugging:
+  - isolate root cause before changing the fix direction, but the executor MUST NOT route to a separate `error-analysis` phase mid-run; if a defect blocks plan progress, the executor records findings and routes to a new run after this one ends.
+
+## Lazy section pointers (BLOCKING for lead — load at the listed phase, not at Phase 1)
+
+The bulk of this profile's body is split into three sidecars so the lead's Phase 1 baseline stays under ~50 effective lines. Read each sidecar ONCE, at the phase noted, into the lead's active context — do NOT pre-load them at Phase 1.
+
+| Sidecar | Read at | Purpose |
+|---------|---------|---------|
+| `prompts/profiles/_implementation-executor.md` | Start of Phase 5 (after Stage Map parse, before Executor's first Edit/Write) | Pre-implementation context exploration, TDD loop, Stage execution contract, allowed actions, commit-message format |
+| `prompts/profiles/_implementation-verifier.md` | Phase 5, between Executor stage completion and the first verifier dispatch | Two-tier command lookup, deny-list, discrepancy rule, Read-only command log, verifier-specific forbidden actions |
+| `prompts/profiles/_implementation-deliverable.md` | Start of Phase 6 (after Phase 5.5 convergence completes, before report-writer dispatch prompt construction) | Required deliverable shape, Validation/TDD evidence rules, Verifier results structure, Self-review pass, Lead post-stage persistence |
+
+**Phase 5 / 6 진입 시 해당 sidecar 가 lead context 에 없으면 BLOCKING — phase 진입 거부.** Lead 는 sidecar 를 read 한 후 1 회 turn 안에 phase 의 후속 action 으로 이어가야 한다 (즉 sidecar 의 룰은 read 한 그 turn 부터 효력 발생).
+
+```
+
+- [ ] **Step 4: 테스트 통과 확인**
+
+```bash
+python3 -m pytest tests/test_implementation_profile_split.py -v
+```
+
+Expected: 모든 테스트 PASS.
+
+- [ ] **Step 5: 커밋**
+
+```bash
+git add prompts/profiles/implementation.md tests/test_implementation_profile_split.py
+git commit -m "refactor(profiles/implementation): reduce main profile to thin core + 3 lazy sidecar pointers"
+```
+
+### Task C3: lead 의 lazy reading discipline 룰 추가 (`agents/SKILL.md`)
+
+**Files:**
+- Modify: `agents/SKILL.md` (Phase 1 박스 뒤에 새 박스)
+- Test: `tests/test_lead_lazy_reading_discipline.py`
+
+- [ ] **Step 1: 실패 테스트 작성**
+
+```python
+# tests/test_lead_lazy_reading_discipline.py
+from pathlib import Path
+import re
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+LEAD = REPO_ROOT / "agents/SKILL.md"
+
+
+def test_lead_skill_documents_implementation_lazy_pointers():
+    content = LEAD.read_text(encoding="utf-8")
+    assert "Implementation profile lazy reading discipline" in content
+
+
+def test_lead_skill_names_three_sidecars_with_read_timing():
+    content = LEAD.read_text(encoding="utf-8")
+    box = content[content.index("Implementation profile lazy reading discipline"):]
+    # 3 sidecar 파일명 + 진입 phase 표기
+    for sidecar, phase_marker in [
+        ("_implementation-executor.md", "Phase 5"),
+        ("_implementation-verifier.md", "Phase 5"),
+        ("_implementation-deliverable.md", "Phase 6"),
+    ]:
+        assert sidecar in box[:2000], f"missing sidecar reference: {sidecar}"
+        # phase 표기는 sidecar 라인 인근에 있어야 함
+        idx = box.index(sidecar)
+        nearby = box[max(0, idx - 200):idx + 200]
+        assert phase_marker in nearby, f"{sidecar} not annotated with {phase_marker}"
+
+
+def test_lead_skill_blocks_phase_entry_without_sidecar():
+    content = LEAD.read_text(encoding="utf-8")
+    box = content[content.index("Implementation profile lazy reading discipline"):][:2500]
+    assert re.search(r"BLOCKING", box)
+    assert "phase 진입 거부" in box or "phase entry refused" in box.lower()
+```
+
+- [ ] **Step 2: 테스트 실패 확인**
+
+```bash
+python3 -m pytest tests/test_lead_lazy_reading_discipline.py -v
+```
+
+Expected: 3 FAIL.
+
+- [ ] **Step 3: `agents/SKILL.md` Phase 1 박스 뒤 ("Lazy reading discipline" 섹션 끝) 에 새 박스 추가**
+
+`agents/SKILL.md` 의 `**Lazy reading discipline (do NOT read at Phase 1):**` bullet 리스트 (L163-169) 끝, 다음 빈 줄에 다음을 삽입:
+
+```markdown
+**Implementation profile lazy reading discipline (BLOCKING — applies only when `task_type == "implementation"`):**
+
+The `implementation` profile's thin core (`prompts/profiles/implementation.md`) is intentionally minimal so the Phase 1 baseline stays small. Three sidecar files carry the bulk of the rules and MUST be read at the listed phase — do NOT pre-load them at Phase 1.
+
+| Sidecar | Read at | Owned by |
+|---------|---------|----------|
+| `prompts/profiles/_implementation-executor.md` | **Phase 5**, after Stage Map parse, BEFORE issuing the Executor's first `Edit` / `Write` | Pre-implementation context exploration, TDD loop, Stage execution contract, allowed actions, commit-message format |
+| `prompts/profiles/_implementation-verifier.md` | **Phase 5**, between Executor stage completion and the first verifier dispatch | Two-tier command lookup, deny-list, discrepancy rule, Read-only command log, verifier-specific forbidden actions |
+| `prompts/profiles/_implementation-deliverable.md` | **Phase 6**, after Phase 5.5 convergence completes, BEFORE constructing the report-writer dispatch prompt | Required deliverable shape, Validation / TDD evidence rules, Verifier results structure, Self-review pass, Lead post-stage persistence |
+
+**Entry guard (BLOCKING).** Before transitioning into Phase 5 or Phase 6 for an `implementation` run, lead MUST emit a single Read tool call for the sidecar(s) above whose `Read at` matches the entering phase. If lead enters the phase without that Read on record (verified via lead session jsonl by `tests/` and observable to a human auditor), the phase 진입 거부 — lead writes a `contract-violation` to the run-level errors log with `--message "implementation-sidecar-not-loaded"` and stops. Re-entry requires the sidecar Read first.
+
+The guard is not satisfied by remembering content from a prior run — each implementation run reads the sidecar fresh, because the sidecars are part of the runtime shipped via `okstra install` and may have been updated between runs.
+
+This pattern is implementation-only. Other profiles (`requirements-discovery`, `error-analysis`, `implementation-planning`, `final-verification`, `release-handoff`) load their whole profile body at Phase 1 as before — they are short enough not to benefit from a split.
+```
+
+- [ ] **Step 4: 테스트 통과 확인**
+
+```bash
+python3 -m pytest tests/test_lead_lazy_reading_discipline.py -v
+```
+
+Expected: 3 PASS.
+
+- [ ] **Step 5: 커밋**
+
+```bash
+git add agents/SKILL.md tests/test_lead_lazy_reading_discipline.py
+git commit -m "feat(agents/SKILL): document implementation-profile lazy reading discipline with BLOCKING entry guard"
+```
+
+### Task C4: validator 가 sidecar split 후에도 substring 검사를 통과하도록 갱신
+
+**Files:**
+- Modify: `validators/validate-run.py` (필요 시)
+- Test: `tests/test_validate_run_implementation_substrings.py`
+
+- [ ] **Step 1: 현재 validator 가 implementation 산출 보고서에서 검사하는 substring 들 파악**
+
+```bash
+grep -n "implementation\|TDD evidence\|Validation evidence\|Verifier results\|Out-of-plan edits\|Stage sidecar evidence" validators/validate-run.py
+```
+
+substring 검사가 산출 보고서(final-report.md) 자체를 대상으로 한다면, sidecar split 은 영향 없음 (보고서는 여전히 deliverable 명세를 따라야 하므로). 검사가 profile body 를 대상으로 한다면 (예: profile 안에 특정 토큰이 있는지) 갱신 필요.
+
+- [ ] **Step 2: 실패 테스트 작성**
+
+```python
+# tests/test_validate_run_implementation_substrings.py
+"""validate-run.py 의 implementation profile 검사가 sidecar split 후에도 작동하는지."""
+import subprocess
+import sys
+from pathlib import Path
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+
+
+def test_validator_accepts_split_profile_present():
+    """thin core + 3 sidecar 모두 존재하면 validator 가 'implementation profile incomplete' 류 에러를 발하지 않아야 한다."""
+    # 단순 self-check: validator 가 profile 파일을 inspect 한다면 그 inspect 가 sidecar 도 cover 해야 함
+    # 구체 명령은 validate-run.py 의 실제 호출 형태에 맞춰 조정
+    r = subprocess.run(
+        [sys.executable, str(REPO_ROOT / "validators/validate-run.py"), "--check-profile", "implementation"],
+        capture_output=True, text=True,
+    )
+    # validate-run.py 가 --check-profile 플래그를 지원하지 않으면 이 테스트는 skip
+    if r.returncode == 2 and "unrecognized" in r.stderr.lower():
+        import pytest
+        pytest.skip("validate-run.py does not expose --check-profile; substring check is report-only")
+    assert "implementation profile incomplete" not in r.stderr.lower()
+    assert "sidecar" not in r.stderr.lower() or "missing" not in r.stderr.lower()
+```
+
+- [ ] **Step 3: 테스트 실행 — 현재 validator 형태에 따라 결과 분기**
+
+```bash
+python3 -m pytest tests/test_validate_run_implementation_substrings.py -v
+```
+
+PASS / SKIP 이면 Step 5 로. FAIL 이면 다음 step.
+
+- [ ] **Step 4: (FAIL 인 경우만) validator 갱신**
+
+`validators/validate-run.py` 가 implementation profile 의 특정 substring 을 profile 본체에서 직접 찾는 패턴이면, 검색 대상에 sidecar 3 파일을 추가한다. 코드 패턴 예시:
+
+```python
+# 변경 전:
+profile_text = (REPO_ROOT / "prompts/profiles/implementation.md").read_text()
+for token in REQUIRED_TOKENS:
+    assert token in profile_text, ...
+
+# 변경 후:
+profile_paths = [
+    REPO_ROOT / "prompts/profiles/implementation.md",
+    REPO_ROOT / "prompts/profiles/_implementation-executor.md",
+    REPO_ROOT / "prompts/profiles/_implementation-verifier.md",
+    REPO_ROOT / "prompts/profiles/_implementation-deliverable.md",
+]
+profile_text = "\n".join(p.read_text() for p in profile_paths)
+for token in REQUIRED_TOKENS:
+    assert token in profile_text, ...
+```
+
+(실제 패턴은 Step 1 의 grep 결과에 맞춰 수정.)
+
+- [ ] **Step 5: 회귀 + e2e**
+
+```bash
+python3 -m pytest tests/ -x -q
+bash validators/validate-workflow.sh
+```
+
+- [ ] **Step 6: 커밋**
+
+```bash
+git add validators/validate-run.py tests/test_validate_run_implementation_substrings.py
+git commit -m "fix(validators/validate-run): include implementation sidecars in substring scan"
+```
+
+(코드 변경이 없었다면 test 만 commit:)
+
+```bash
+git add tests/test_validate_run_implementation_substrings.py
+git commit -m "test(validators): pin implementation sidecar discovery"
+```
+
+### Task C5: install 파이프라인 + CHANGES.md + CLAUDE.md
+
+**Files:**
+- Modify: `src/install.mjs` (sidecar 파일들이 user machine 에 sync 되는지 확인)
+- Modify: `CLAUDE.md` "Where to find things"
+- Modify: `CHANGES.md`
+
+- [ ] **Step 1: install 파이프라인 검증**
+
+```bash
+node bin/okstra --version
+# install dry-run 또는 sandbox install
+OKSTRA_HOME=$(mktemp -d) node bin/okstra install --dry-run 2>&1 | grep -E "(executor|verifier|deliverable|fragments)"
+```
+
+`_implementation-*.md` 와 `prompts/fragments/*.md` 가 user machine 의 `~/.okstra/lib/python/prompts/` (또는 동등 위치) 로 sync 되는지 확인.
+
+이미 디렉토리 단위 rsync 라면 자동으로 포함됨. 파일 단위 allowlist 라면 추가 필요.
+
+- [ ] **Step 2: 누락 시 `src/install.mjs` (또는 `tools/build.mjs`) 갱신**
+
+(생략 — Step 1 결과에 따라 조건부)
+
+- [ ] **Step 3: `CLAUDE.md` "Where to find things" 표에 항목 추가**
+
+`CLAUDE.md` 의 표에 두 줄 추가:
+
+```markdown
+| `[Required reading]` / `[Error reporting]` clause SSOT body | [`prompts/fragments/required-reading-block.md`](prompts/fragments/required-reading-block.md), [`prompts/fragments/error-reporting-block.md`](prompts/fragments/error-reporting-block.md) — dispatch prompt 에 inline 되는 본문 |
+| Implementation profile lazy sidecars | [`prompts/profiles/_implementation-executor.md`](prompts/profiles/_implementation-executor.md), [`_implementation-verifier.md`](prompts/profiles/_implementation-verifier.md), [`_implementation-deliverable.md`](prompts/profiles/_implementation-deliverable.md) — lead 가 Phase 5 / 6 에서 lazy read |
+```
+
+- [ ] **Step 4: `CHANGES.md` 사용자 영향 entry 추가**
+
+```markdown
+### refactor(profiles/implementation): 161-line profile 을 thin core (~50 lines) + 3 lazy sidecar 로 split
+
+- **배경**: `implementation.md` 가 161 줄까지 비대해져 lead 의 Phase 1 baseline cost 의 큰 부분을 차지. 모든 룰이 모든 phase 에 필요한 것이 아니므로 (예: Verifier QA duties 는 Phase 5 verifier dispatch 직전에만 필요) lazy load 가 가능했다.
+- **변경**:
+  - `prompts/profiles/_implementation-executor.md` 신규 — Pre-implementation context exploration, TDD loop, Stage execution contract, allowed actions, commit-message format. Phase 5 진입 시점 lazy load.
+  - `prompts/profiles/_implementation-verifier.md` 신규 — Two-tier command lookup, deny-list, discrepancy rule, Read-only command log, verifier-specific forbidden actions. Phase 5 verifier dispatch 직전 lazy load.
+  - `prompts/profiles/_implementation-deliverable.md` 신규 — Required deliverable shape, Validation/TDD evidence rules, Verifier results structure, Self-review pass, Lead post-stage persistence. Phase 6 진입 시점 lazy load.
+  - `prompts/profiles/implementation.md` 본체를 thin core (~50 줄) 로 축소 — Purpose, Required workers, Executor binding, common-contract INCLUDE, Pre-implementation gate, Task worktree, 공통 Forbidden actions, In-phase debugging, Lazy section pointers.
+  - `agents/SKILL.md` 에 "Implementation profile lazy reading discipline" BLOCKING 박스 추가 — Phase 5/6 진입 시 해당 sidecar 의 Read 가 lead session jsonl 에 기록되지 않으면 `contract-violation` 으로 phase 진입 거부.
+- **사용자 영향**: 다음 release 후 `npx -y okstra@latest install` 한 번이면 전파. lead 의 implementation phase Phase 1 baseline 이 161 줄 (profile) → ~50 줄 (thin core) 으로 축소 — 매 turn cache_read 비용 감소. **호환성 영향**: 룰 자체는 모두 살아 있음 (단지 다른 파일로 옮김). `okstra install` 가 sidecar 3 파일을 user machine 에 sync 함. 자체 작성한 implementation profile 변형은 그대로 작동 (thin core 만 비대해질 뿐, 룰 누락은 없음).
+```
+
+- [ ] **Step 5: 회귀 + commit**
+
+```bash
+python3 -m pytest tests/ -x -q
+bash validators/validate-workflow.sh
+git add CLAUDE.md CHANGES.md src/install.mjs tools/build.mjs
+git commit -m "docs(claude-md,changes): document implementation profile lazy split"
+```
+
+(install/build 변경이 없었으면 두 파일 제외.)
+
+---
+
+## Final integration
+
+### Task FINAL: 전체 e2e + token-usage smoke + dogfooding
+
+- [ ] **Step 1: 풀 e2e 시나리오 모두**
+
+```bash
+for s in tests-e2e/scenario-*.sh; do
+  echo "=== $s ==="
+  bash "$s" || { echo "FAIL: $s"; exit 1; }
+done
+```
+
+- [ ] **Step 2: `npm run build` 후 사용자 install 시뮬레이션**
+
+```bash
+npm run build
+OKSTRA_HOME=$(mktemp -d) node bin/okstra install
+node bin/okstra doctor
+```
+
+`doctor` 의 출력에서 fragment 파일 + 3 sidecar 가 모두 보고되어야 함. 보이지 않으면 install/build 누락.
+
+- [ ] **Step 3: dogfooding — 작은 implementation task 로 한 번 돌려본다**
+
+```bash
+# 실제 작은 task 하나를 골라 okstra --task-type implementation 실행
+# (이 plan 의 범위는 변경의 land 까지. 측정은 follow-up.)
+```
+
+token-usage 결과를 비교 baseline (B/D/C 적용 전 한 번 + 적용 후 한 번) 으로 수집해 plan 의 효과 측정. 수집된 수치는 follow-up issue 또는 다음 release note 의 evidence.
+
+- [ ] **Step 4: PR 생성**
+
+```bash
+gh pr create --base main --title "Implementation lead context slimming: B(fragment-pointers) + D(stage-step-cap-3) + C(profile-lazy-split)" --body "$(cat <<'EOF'
+## Summary
+- Track B: `[Required reading]` / `[Error reporting]` clause 본문을 `prompts/fragments/` SSOT 로 분리, lead 의 dispatch prompt 는 pointer 1줄만 emit. codex/gemini wrapper subagent 가 dispatch 직전 fragment 를 resolve 해서 CLI stdin 에 inline.
+- Track D: implementation-planning profile 의 stage step 권장값을 ≤ 3 으로 강화 (hard cap 6 유지). validator 는 step > 3 일 때 stderr warning 만 발행 (exit code 영향 없음).
+- Track C: `prompts/profiles/implementation.md` 161 줄을 thin core (~50 줄) + 3 lazy sidecar (executor / verifier / deliverable) 로 split. lead 는 Phase 5 / 6 진입 시점에 해당 sidecar 만 Read; 미Read 시 BLOCKING.
+
+## Why
+v0.36 implementation phase 의 lead context bloat 으로 phase 6 (worker dispatch) 가 한 lead 세션 안에 끝나지 않고 dispatch 직전 wizard 가 "이 세션 진행 vs prompt persist 후 다음 세션 resume" 양자택일을 자주 띄움. 위 세 변경으로 lead 의 dispatch-당 / phase-당 / Phase 1 baseline context 비용을 모두 절감.
+
+## Test plan
+- [ ] `python3 -m pytest tests/ -x -q` 회귀 0건
+- [ ] `bash validators/validate-workflow.sh` PASS
+- [ ] `bash tests-e2e/scenario-*.sh` 모두 PASS
+- [ ] `node bin/okstra doctor` 가 신규 fragment + sidecar 파일들을 모두 보고
+- [ ] 작은 implementation task 한 건 dogfooding — token-usage 비교 측정 (별도 follow-up 으로 수치 수집)
+
+## Notes
+- Track C 는 `docs/superpowers/plans/2026-05-24-implementation-lead-context-slimming.md` "Decision gate before C" 조건이 충족된 후에만 land — B/D 만으로 phase 6 single-session 진행이 가능해지면 C 는 over-engineering 으로 holdback 처리.
+EOF
+)"
+```
+
+(이 step 은 사용자 승인 필요 — `gh pr create` 는 외부 영향이므로.)
+
+---
+
+## Self-review 체크리스트
+
+이 plan 작성 직후, 작성자(=Claude lead)가 직접 통과시켜야 하는 항목:
+
+1. **Spec coverage**
+   - 사용자 분석의 B → C 의 모든 사항이 plan 의 task 로 매핑되었는가?
+     - B: Task B1–B7 ✓
+     - D: Task D1–D3 ✓
+     - C: Task C1–C5 ✓
+   - "Decision gate before C" 가 plan 안에 명시되었는가? ✓
+
+2. **Placeholder scan**
+   - "TBD" / "implement later" / "TODO" / "fill in details" 가 plan 본문에 존재하는가? — 없음 ✓
+   - "Similar to Task N" 패턴이 있는가? — Task B5 의 gemini-worker 변경이 codex-worker 와 동일하지만, 차이 토큰을 명시적으로 enumerate 함 ✓
+
+3. **Type consistency**
+   - 파일 경로가 trackB / track C 에서 동일하게 쓰이는가? — `prompts/fragments/required-reading-block.md`, `prompts/profiles/_implementation-*.md` 모두 일관 ✓
+   - `RECOMMENDED_STEP_CAP` / `HARD_STEP_CAP` 상수명이 validator code + 테스트에서 일치 ✓
+   - `_FRAGMENT_MISSING` 센티넬 이름이 worker 간 일관 ✓
+
+4. **Test-first 준수**
+   - 모든 코드 변경 task 가 (test 작성 → fail 확인 → 구현 → pass 확인 → commit) 순서 ✓
+
+5. **Track 간 의존성**
+   - B/D/C 의 적용 순서는 명시됨 (B → D → 측정 → C 결정).
+   - 동시 적용 시 충돌 없음 — 서로 다른 파일/룰 영역.
+
+---
+
+## Execution Handoff
+
+Plan 저장 완료: `docs/superpowers/plans/2026-05-24-implementation-lead-context-slimming.md`.
+
+두 실행 옵션이 있다.
+
+**1. Subagent-Driven (권장)** — fresh subagent per task, lead 가 task 간 review. fast iteration. 각 트랙(B/D/C) 별로 독립적으로 dispatch 가능.
+
+**2. Inline Execution** — 같은 세션 안에서 executing-plans 로 batch 처리. checkpoint 단위 review.
+
+어느 쪽으로 진행할지 알려달라. (참고: C 는 "Decision gate before C" 통과 후에만 진입하므로, B 와 D 만 우선 dispatch 하고 측정 후 C 를 별도 trigger 하는 분리 실행도 가능.)