Opord

---
name: opord
description: Use when writing an operation order (작전명령) for a single-PR issue or one DP in this project — kickoff A-3 전환, `/opord` 명시 호출, superpowers:writing-plans 를 invoke 하려는 그 자리(brainstorming 종점 포함) 전부. Triggers on "작전명령 세워", "계획 세워", "opord", writing-plans 발동 시점. Does NOT trigger on 캠페인·전략 작성(campaign), 실행(implement·orchestrate), 이슈 분해(kickoff).
---

# Opord — 작전명령 작성

## 1. 개요

**작전명령이 이 프로젝트의 플랜이다.** superpowers:writing-plans 를 **대체한다** — 문서 구조는 `docs/operations/templates/opord.md` 가 이끌고, writing-plans 에서 남는 건 부록 A 의 태스크 스텝 규격(`### Task N:` 헤딩 · Files · Interfaces · 체크박스 Step)과 No Placeholders 원칙뿐이다. writing-plans 의 헤더·Execution Handoff·저장 경로는 쓰지 않는다.

작전명령은 **다른 세션 에이전트가 이 문서만 보고 착수 가능한 인수인계 문서**다. 실행자는 이 세션의 대화·탐색 기억 없이, 문서에 적힌 것만 갖고 시작한다.

템플릿 공통 규칙 — 항목 밖 서술 금지 / 해당 없는 항목은 "없음" 으로 채운다 / **간결하게 쓴다**: 항목마다 핵심만 남기고 반복·배경 늘어놓기·수식을 걷어낸다 — 줄이는 대상은 문장이지 담을 결정·정보가 아니다 / 문장 규범은 CLAUDE.md §1 **글 규범**이 정본이다 — 간결은 그 요건 안에서다. 용어(DP·LOE·FRAGO·MOP/MOE·PIR/FFIR)는 템플릿 머리의 용어 줄이 정본이다.

## 2. 진입

- 단위는 **M 이슈 하나 또는 DP 하나** = PR 하나. S(구두지시)·L(캠페인)·XL(전략)은 이 스킬 밖이다.
- kickoff 가 안 돌았으면 먼저 invoke 한다 — 정찰(1-가)은 kickoff 탐색을 재사용한다.
- 입력: **M** 이면 kickoff 정찰 브리프(미정 결정 목록 포함). **L 의 DP** 면 DP ID + `campaign.md` 인용(1-다).
- **범위 명확성 전제** — 작전명령은 후속 이슈 분리가 필요 없을 정도로 확실한 영역에서 쓴다. 작성 중 태스크를 확정할 수 없거나, 경계가 안 그어지거나, "일단 해보고 판단" 스텝이 필요해지면 **계속 쓰지 말고 §3-5 질문 라운드로 되돌아가 미정을 확정한다.** 확정하고도 경계가 안 그어지면 사이즈 오판이다 — kickoff 재판정(승격)으로 되돌린다. 범위가 흐린 명령을 실행자에게 넘기면 우발상황 반문이 빈발한다.

## 3. 절차

1. **입력 확인** — DP ID + campaign.md 인용, M 이면 kickoff 정찰 브리프.
2. **착수 자격 확인 (DP 만)** — 작전계획 재가 + 선행 DP 머지 + 소유 범위 확보. 하나라도 빠지면 시작하지 않는다. 예외는 유저가 stacked 를 명시 허용한 의존 DP 뿐 — "선행 DP 머지"가 "선행 DP PR 존재 + 인터페이스 계약 확정"으로 완화된다 (orchestrate §2). **선행 DP 가 원장에서 `회귀` 면 머지 이력이 있어도 "선행 DP 머지"는 충족되지 않는다** — 재실행을 기다리거나 유저 결정을 받는다.
3. **정찰** — kickoff 탐색 재사용, 부족하면 code-analyzer.
4. **과업 도출** — 명시 과업(DP: campaign.md 9항 내용 + 8항 통제수단의 인터페이스 계약 / M: 이슈 본문·정찰 브리프)과 추정 과업(명시 안 됐지만 rules·아키텍처가 딸려 붙이는 것 — 짝지어진 두 위치, 테스트 스킴, localization 키 등)을 도출하고, 필수 과업(누락 시 최종상태 미달로 직결되는 것)으로 2 임무문을 세운다. 추정 과업이 소유 범위·위임을 넘으면 질문 라운드에 싣는다. **추정 과업을 딸려 붙일 근거 교리가 rules·선례 어디에도 없으면 doctrine 스킬로 룰 구축을 요구한다** — 계획은 멈추지 않고, 요구를 §3-5 질문 라운드에 실어 보낸다.
5. **질문** — **정찰 브리프의 "유저만 답 가능" 미정 목록이 첫 입력이다** (확정 자리는 kickoff 가 아니라 여기다) + 목적 뉘앙스 · 최종상태 세부 · 건드리면 안 되는 것 · 위임 좁힘 · 수용 위험 · 즉시보고 조건. 기본안을 붙여 **일괄** AskUserQuestion — 설계가 갈리는 미정 결정엔 단일 기본안이 아니라 **옵션 2개 이상 + 트레이드오프**를 붙인다 (권장안을 첫 옵션으로).
6. **초안** — 템플릿 하단 사용 노트가 정본이다: 쓰는 순서·3-가 ≥ 3-다·정찰로 아는 건 묻지 않음·못 물은 건 1-라 가정. 부록 A~C 는 §4·§5 규정.
7. **드라이런** — 재가 **전**에 돈다: 결정지점 D-n → 우발계획 → 대안 경로 전환 조건 순으로 걸어본다. 즉시보고 조건마다 결정지점이 있는지, 제한마다 이유가 있는지, 유저 부재 시 행동(5)이 있는지 확인한다. 구멍이 나오면 초안을 보강하고 다시 걸어본다 — 재가받은 명령을 드라이런으로 고치면 재가가 무효가 된다.
8. **확인보고 → 재가** — **재가 전 1차 리뷰를 맡은 세션이 지정돼 있으면**(유저 지시) 드라이런 뒤 그 세션에 먼저 보내 plan-review 통과를 받고 확인보고로 간다. 서두 `■ 확인보고`(`report-confirmation.md`: 임무 내 말로 / 의도 / 자율로 정할 것 / 묻는 것)를 채워 유저에게 **응답 본문에 재가 요약(아래 서식)과 전문을** 보인다 — **재가 전 전문이 사는 자리는 응답 본문과 로컬 `opord.md` 뿐이다.** 이슈 본문엔 핵심 블록만 가고(§7), 확인보고 봇 코멘트는 `report-confirmation.md` 머리 게시 줄대로 **4항목만** 싣는다 (`mcp__github-reviewer__add_issue_comment` + `@sudopark` 멘션 — 재가 대기). 그 코멘트에 전문을 욱여넣지 않는다 — 템플릿이 "게시물은 4항목이 전부"로 못박은 알림용 요약이고, 전문이 GitHub 에 남는 자리는 재가 후의 원문 코멘트다(§7). 재가에서 유저가 고칠 범위도 템플릿 사용 노트대로. 재가되면 진행 파일의 명령 상태를 `재가` 로 올리고 §7 미러.
9. **dispatch 전이** — 서브에이전트에 넘기면 브리프 = 작전명령이고, 첫 보고에 백브리프(`report-backbrief.md` 7항)를 요구한다. 인라인 실행이면 implement 로 전이.

### 재가 요약 — 응답 본문 서식

**유저에게 재가를 청하는 응답은 전문 앞에 세 블록을 먼저 낸다.** 전문은 그 뒤에 그대로 싣는다. campaign·strategy 의 재가 요청도 이 서식을 쓴다 (campaign §2-7).

```
■ 재가 요약
1. 결심 안건 — <이번 재가로 확정되는 유저 결정을 하나씩. 없으면 "없음">
2. 임무·최종상태 — <무엇을 어디까지 하는가, 한 단락>
3. 규모·유저 시간 — <태스크·커밋 수(campaign 은 DP 수) · 유저 시간이 어디에 몇 번 드는가>
```

**계획 개정이 딸려 있으면 1 에 싣는다** — 상위 campaign·strategy 의 어느 항이 어떻게 바뀌는지를 적는다. 명령만 보고 재가하면 그 개정이 함께 확정된다는 사실을 유저가 모르고 지나간다. 1 은 `묻는 것`(확인보고 4항목)과 다르다 — 그쪽은 아직 답을 못 받은 질문이고, 이쪽은 재가가 곧 확정인 항목이다. 둘이 겹치면 겹친 채로 둔다.

세 블록은 전문을 읽어 직접 쓴다. 블록이 없으면 유저는 재가 판단에 전문을 다 읽어야 한다. 계획 개정이 딸린 재가에서는 무엇이 함께 확정되는지가 특히 안 보인다.

## 4. 부록 A — 태스크 상세 규정

### 해상도 — 결정은 정확하게, 구현은 넘긴다

작전명령은 **결정을 담는 문서지 구현체를 담는 문서가 아니다.** 실행자가 못 채우는 건 함수 몸통이 아니라 어느 타입을 쓸지·어느 레이어에 둘지·기존 동형 구현이 뭔지·엣지 케이스가 뭔지다. 그건 전부 구현체 없이 적을 수 있다.

**정확히 박을 것:**

- 타입·메서드 시그니처
- 파일 경로 + 참고할 기존 동형 구현의 `file:line`
- 엣지 케이스와 그때의 기대 동작
- 테스트 케이스 이름 목록
- 커밋 시퀀스 (부록 B)

**실행에 넘길 것**: 함수 몸통, 보일러플레이트, 뻔한 매핑, 에러 핸들링 관용구.

수도코드는 분기·순서가 비자명할 때만 서너 줄. 수도코드가 구현체를 다른 표기로 옮긴 게 되면 코드 통째 기입과 같은 문제이고, 컴파일 검증조차 안 받아 더 나쁘다.

**writing-plans 의 No Placeholders 와의 관계** — 그 원칙이 막는 건 결정 회피(`TBD`, `add appropriate error handling`, `write tests for the above`)다. 그 요구는 그대로 유지되고, 위 "정확히 박을 것"이 그걸 충족한다. 이 조항이 뒤집는 건 `Steps that describe what to do without showing how (code blocks required for code steps)` 한 줄뿐 — **code block 의무는 이 프로젝트에서 면제된다.** 상충으로 읽고 임의 판단하지 말 것.

### 헤딩·구조 — SDD 호환

- 태스크 헤딩은 `### Task N: <제목>` — SDD task-brief 스크립트가 `^#+[ \t]+Task[ \t]+N` 으로 자른다. 본문 3-다 의 `T-n` 과 번호를 맞춘다.
- 각 태스크에 **Files**(Create/Modify/Test 경로) · **Interfaces**(Consumes/Produces — 인접 태스크가 쓰는 이름·타입) · 체크박스 `- [ ] Step k` 를 둔다.
- 커밋 스텝은 `feat:` 메시지를 쓰지 않고 부록 B 의 해당 항목을 참조한다.

### 작업 유형별 결정 포인트 게이트

**신규 설정·선택 UI** — 새 설정 화면·선택/편집 UI(위젯 편집 시트·AppIntents 파라미터 UI 포함)를 만드는 태스크가 있으면, 아래 넷이 스펙·명령에 결정돼 있는지 확인한다. 하나라도 미정이면 작성을 멈추고 §3-5 질문 라운드로 되돌아가 확정한다 — 넷 다 구현 분기를 바꾼다:

- 목록의 **정렬 기준·포함/제외 범위** (예: 다가오는 순, 공휴일 포함 여부)
- 라벨·문구 **로컬라이즈**
- 항목·파라미터의 **노출·활성 조건** (예: 반복 일정일 때만 회차 노출)
- **아이콘이 기존 아이콘과 혼동되지 않는지**

**코드 이동·모듈 분리의 계층 판별** — 타입·파일을 다른 모듈로 옮기는 명령은 이동 대상마다 계층(usecase / service / engine)을 판별해 목록에 명시한다. "SDK import가 있다" 같은 표면 신호로 일괄 분류 금지 — usecase는 Domain 잔류(service 프로토콜 소비), service 구현체만 내려간다. 동형 선례(예: PlaceSuggest 분리 구조)를 찾아 대조하고 그 결과를 적는다.

**신설 요소 최소 판정** — 명령이 신설하는 타입·프로토콜·래퍼·중간층마다 **"기존 객체에 의존을 직접 주입해 풀 수 없나"를 먼저 묻는다.** 신설은 직접 연결이 불가한 구체 근거가 있거나 현재 소비자가 둘 이상일 때만 — 근거를 태스크 본문에 적고, 못 적으면 신설하지 않는다. implement 리팩터 게이트의 Speculative Generality는 코드가 된 뒤에만 걸린다 — 간접층은 명령에서 막는 게 싸다.

### 자족성 체크 — 저장 전

저장 전 아래를 자문한다. 하나라도 "이 세션 기억에만 있다"면 문서에 옮겨 적는다:

- **목표가 뭐고 뭐를 해야 하는지** — 2 임무 + 3-다 과업 목록으로 답해지는가
- **어디를 수정하고 어디까지가 범위인지** — 부록 A Files + 3-라 제한·위임 범위로 답해지는가
- **어떤 과정으로 수행하고 어디서 커밋하는지** — 부록 A 스텝 + 부록 B 로 답해지는가
- **탐색으로 알아낸 전제**(현재 동작 file:line, 함정, 오탐 알려진 것)가 1-가 정찰 결과나 태스크 본문에 적혀 있는가
- **실행자가 따라야 할 rules 조항**(테스트 작성이 있으면 testability.md의 더블·wait API 규칙 등)이 태스크 본문에 발췌돼 있는가 — 실행 서브에이전트는 path 매칭 자동 로드를 받지 못한다
- **신설 타입·간접층마다 필요 근거(직접 주입 불가 사유 또는 소비자 둘 이상)가 적혀 있는가** — 없으면 §신설 요소 최소 판정으로 되돌아간다
- **§해상도의 "정확히 박을 것" 다섯이 태스크마다 채워졌는가** — 시그니처·경로와 동형 구현 `file:line`·엣지 케이스·테스트 이름·커밋 시퀀스. 하나라도 비면 실행자가 추측하거나 갭 보고로 되돌아온다

## 5. 부록 B·C

### 부록 B — 커밋 시퀀스

- 최종 커밋 목록을 사전 계획한다: **논리 단위 묶음 + `[#이슈] 동작 변화 요약` 메시지 초안** (CLAUDE.md §5 컨벤션).
- **태스크 경계 ≠ 커밋 경계.** 여러 태스크가 한 커밋으로 묶일 수 있고, 그 대응을 시퀀스에 명시한다 (예: "커밋 2 = Task 2+3").
- 커밋은 결과 위주 — TDD 중간 상태(RED/GREEN 과정)를 커밋에 싣지 않는다.
- 시퀀스 변경은 사후보고(종결보고 7항) — 사전승인 대상이 아니다.

### 부록 C — 태스크별 모델 티어

실행 세션이 재판단 없이 그대로 dispatch할 수 있게, 태스크마다 모델 티어를 판정해 표로 명시한다:

- **기계적 transcription** — 결정이 시그니처·경로 수준까지 확정됐고 1-2 파일: **하위 모델 (haiku급)**
- **통합·판단** — 멀티 파일 조율, 기존 패턴 매칭, 프로즈 스펙에서 코드 도출: **표준 모델 (sonnet급)**
- **설계 판단** — 아키텍처 결정·광범위 코드베이스 이해 필요: **최상위 모델** (이런 태스크가 있다면 명령이 덜 여문 신호 — 범위 명확성 전제 재점검)

**태스크별 리뷰 판정은 이 표에 넣지 않는다.** 이 프로젝트는 태스크 단위 리뷰어 dispatch를 돌리지 않는다 — 에이전트 리뷰는 PR 직전 최종 whole-branch 1회다 (implement 스킬 §착수). 판정할 대상 자체가 없다.

## 6. 상태 전이

명령 상태는 진행 파일(§8)의 `명령 상태:` 줄에 산다 — 본문 층(opord.md)엔 상태 칸이 없다. 값은 여섯이고, 바꾸는 주체가 다르다:

| 상태 | 전이 시점 | 주체 |
|---|---|---|
| 정찰 | 킥오프 보드 착수 표시 — 진행 파일 씨앗 생성 | kickoff |
| 초안 | 초안 저장 → §7 미러 | 이 스킬 |
| 재가 | 확인보고에 유저가 승인 → §7 미러 | 이 스킬 |
| 실행 | 첫 태스크 착수 | implement |
| 검토 | PR 생성 · 종결보고(`report-debrief.md`) | pr |
| 종결 | PR 머지 — **머지까지가 명령 달성이다** | pr (머지·정리 단계) |

**S(작전명령 없는 런)는 `초안`·`재가` 를 건너뛴다** — `정찰`(kickoff §0) → `실행`(implement) → `검토`(pr) → `종결`(pr). 진행 파일만 있고 이슈 본문 미러는 없다(핵심 블록의 출처인 본문 층이 없다) — 그 진행 파일은 상황판 전용이다. 전이 주체가 이 표와 같으니 S 도 각 단계에서 상태를 올린다. 안 올리면 상황판이 구현·리뷰 내내 `정찰` 로 보인다.

전이마다 이슈 본문 미러를 재조립한다(§7). 실행 중 변경은 부록 D 단편명령(`frago.md`)으로 누적한다 — 바뀐 항목만 적고 나머지는 "변경 없음". **검토 단계도 같다** — 머지 전엔 리뷰로 작업이 폐기되거나 방향·계획이 바뀔 수 있고, 리뷰 반영이 본문 층(범위·구조·산출물)을 바꾸면 부록 D 에 단편명령으로 누적한다.

**단편명령 발부는 세 짝이 한 묶음이다** (하나라도 빠지면 이탈): ① 부록 D 누적 + 그 전문을 이슈 봇 코멘트로 기록(`frago.md` 머리 게시 줄 — 히스토리 층) ② 본문 층(`opord.md`)에 변경을 반영하고 진행 파일 `핵심:` 줄(§8)을 최신 확정 상태로 갱신한 뒤 이슈 본문 미러를 재조립(§7) — 이슈 본문 핵심 블록은 항상 원문 대비 변경이 반영된 **최종 상태**다. 변경이 핵심 블록 항목(임무·최종상태·범위·과업 목록)에 닿지 않아도 재조립은 한다 — `핵심:` 줄과 단편명령 링크가 바뀐다 ③ board-sync. 단편명령·즉시보고 누적은 **초기 계획과 다르게 진행됐다는 이탈 신호**다 — 상황판이 ⚑ 로 집계해 드러내고, 빈발은 계획 단계 부실 신호로 유저에게 함께 보고한다(implement 플랜 갭 루프).

**인접 DP 소유 범위 침범** — 인지 경로는 delegation 결정 권한표의 `스코프 밖 파일 수정 = 사전승인`이다. 자기 스코프(부록 A Files + 3-라 제한) 밖 파일을 건드려야 해서 멈춘 자리에서, **그 파일이 campaign.md 9항 `소유 범위` 칸의 다른 DP 에 걸리는지 대조한다** — 걸리면 침범이고 아래를 탄다. 9항이 없는 단독 M 은 1-마 인접 작업 기재분과 열린 PR·워크트리로 대조한다. 대조를 안 하면 스코프 밖 승인만 받고 지나가, 상대는 자기 범위가 깎인 걸 끝까지 모른다. 침범이면 침범하는 쪽이 통보를 남긴다. ① 상대 DP 이슈에 `report-immediate.md` 서식 봇 코멘트로 침범 범위·사유를 게시하고 `@sudopark` 를 멘션한 뒤 승인까지 중단한다 — 상대의 `opord.md` 는 그 세션 워크트리에 있고 gitignore 대상이라 이 세션이 쓸 수 없고, 양쪽이 공유하는 층은 이슈뿐이다. **승인을 받을 때 상대 세션에 전달을 함께 요청한다** — 상대 세션은 실행 중이라 자기 이슈 코멘트를 다시 읽는 조항이 없고, 유저가 유일한 전달 경로다. **승인이 떨어지면 침범한 쪽도 자기 부록 D 에 단편명령을 남긴다** — 부록 A Files·3-라 제한이 넓어진 것이라 양쪽 명령이 같이 바뀌어야 한다. 뺏은 쪽을 안 고치면 그 명령만 보고 들어오는 다음 세션이 그 파일을 자기 범위로 읽는다. ② 전달받은 세션은 그 내용을 자기 부록 D 에 단편명령으로 흡수한다(사유 `인접 DP 침범 통보 접수`, 위 세 짝 그대로) — 통보만 있고 흡수가 없으면 상대 명령은 침범 전 소유 범위를 계속 전제한다. **받을 세션이 없으면 통보 코멘트로 끝난다** — 인접 DP 가 아직 `미착수` 면 opord 도 부록 D 도 없고, 그 DP 킥오프가 이슈 코멘트를 읽어 받는다. 이미 `머지` 면 고칠 명령이 없다. ③ 통보 대상의 1차 목록은 작전명령 1-마 인접 작업·3-라 인접 협조다. **거기 없는 DP 를 실행 중 새로 발견하면 통보 전에 1-마를 단편명령으로 먼저 갱신한다** — 계획 시점에 못 본 인접 관계가 드러나는 것이 이 절차의 주된 발동 사유라, 목록을 정적으로 두면 정작 필요한 케이스에서 대상이 빈다.

**재작성 경계** — 의도(3-가)가 바뀌면 단편명령이 아니라 재작성이다. **유저 지시가 계획 변경을 의도하면**(단편명령이 커버 가능한 범위를 이미 넘어선 케이스) 상위 계획이 있는 런(L 의 DP)은 그 변경·부분 개정을 우선하고(campaign §4 계획 개정), 이어서 명령 재작성을 유도한다 — 명령부터 고치고 계획을 뒤따라 맞추는 순서가 아니다. 상위 계획 없는 단독 M 은 곧바로 명령 재작성이다.

## 7. 저장·미러

- 경로: `docs/operations/<이슈번호>/opord.md`. DP 면 `opord-<DP>.md`. gitignore 대상 — 다른 세션·워크트리는 **재가 원문 코멘트 + 부록 D 단편명령 코멘트를 순서대로 적용해** 복원한다 (또는 상황판 스풀). 이슈 본문은 핵심만 싣게 되어 여기서 전문을 복원할 수 없다 — 본문만 읽고 실행에 들어가지 않는다.
- 본문 층과 진행 층을 가른다 — **본문 층**(1~5절·부록 A~D)은 초안 확정과 단편명령(부록 D) 반영 때 갱신한다. **진행**(명령 상태·태스크 진행)은 진행 파일(§8)에 자유 갱신한다. 둘 다 git 에 커밋하지 않는다 (2026-09-09 미커밋 전환 — 본문 층의 정본 공유는 재가 원문 코멘트, 진행 층은 이슈 본문 미러·상황판 스풀이고, 커밋하면 워크트리·develop 싱크 비용이 든다. #1043 상태 전용 커밋 금지도 여기 흡수된다).
- **이슈 본문 = 명령 핵심 블록 + `<!-- progress -->` 블록.** 본문 층 전문은 싣지 않는다 — 전문은 재가 원문 코멘트가 갖는다. 같은 전문을 본문과 코멘트에 이중으로 실으면 이슈가 부풀어 무엇이 최신인지 읽는 사람이 가려내야 한다. 핵심 블록 서식은 고정이다:

  ```markdown
  ## 작업 지침 — #<이슈> <명칭>
  상위: <campaign #n / LOE-x / y단계 / DP-x.y / 선행 DP, M 이면 "단독">
  핵심: <진행 파일 `핵심:` 줄(§8) 그대로 — 원문 대비 변경이 반영된 최신 요지>
  임무: <2 임무 한 문장>
  최종상태: <3-가 최종상태 — 동작·코드·구조·검증·외부 중 해당 항목만 한 줄씩>
  범위: 건드릴 것 <부록 A Files 합집합> / 안 건드릴 것 <3-라 제한>
  과업: <3-다 T-n 한 줄씩 — 부록 A~C 상세는 싣지 않는다>
  원문: <재가 원문 코멘트 링크 — 재가 전엔 "재가 대기"> · 단편명령: <FRAGO-n 코멘트 링크 …>
  ```

  본문이 답할 질문은 "이 이슈가 뭘 하는 작업이고 지금 어디까지 왔나"지 "어떻게 짜나"가 아니다 — 실행 지시서가 본문에 오지 않는 이유가 그거다. 재조립 시점은 초안 저장 직후·재가 직후와 태스크 완료·단편명령 반영·§6 상태 전이 갱신마다다 — 태스크 착수 표기·활동 로그는 board-sync 만 타고 미러 재조립 대상이 아니다(§8·implement §착수). `gh issue edit <N> --body-file <합본>` 로 핵심 블록과 progress.md 를 이어 붙인다. 별도 요약 코멘트는 없다(kickoff A-4 갈음). 마커 코멘트도 없다 — 본문 자체가 최신 확정 상태다. 보고 봇 코멘트(확인보고·종결보고 등 게시 줄이 ○인 것)는 이 금지의 대상이 아니다 — 그건 히스토리 층이다(issue 스킬).
- **재가 직후엔 확정 원문 전문을 이슈 봇 코멘트로 게시하고 `@sudopark` 를 멘션한 뒤, 그 코멘트 URL 을 핵심 블록 `원문:` 줄에 넣어 미러를 재조립한다** (순서가 뒤집히면 링크 자리가 빈 채로 본문이 올라간다) — 본문이 핵심만 싣는 이상 **GitHub 에 전문이 남는 자리는 이 코멘트뿐이다.** 재가 시점 스냅샷이라 이후 고치지 않는다 — 변경은 부록 D 단편명령 코멘트가 누적으로 담고, 둘을 이어 적용한 것이 최신 전문이다. 이 코멘트를 빠뜨리면 전문이 로컬 워크트리 밖 어디에도 없다. 확인보고·종결보고와 같은 히스토리 층 게시라 위 마커 코멘트 금지의 대상이 아니다.
- 상황판 동기화는 미러보다 잦다 — 미러 재조립 때만이 아니라 **진행 파일·활동 로그(§8)를 쓸 때마다** `.claude/scripts/campaign-board-sync.sh <이슈번호>` 를 짝으로 호출한다 (스크립트가 스풀 복사와 정적 렌더까지 한다, 실패 비차단). Artifact 재게시는 자동으로 하지 않는다 — 유저가 상황판 원격 미러를 요청할 때만 그 세션이 `~/.claude/campaign-board/board.html` 을 `~/.claude/campaign-board/artifact-url.txt` 의 URL 로 수동 재게시한다.

## 8. 진행 파일 ↔ SDD ledger

둘 다 쓴다 — 층이 다르다:

- **진행 파일 `.operations/<이슈번호>/progress.md`** = 계획 층의 진행 정본 (옛 부록 E 대체). 서식: `<!-- progress -->` 헤딩 + `명령 상태:` 줄 + **`핵심:` 줄**(명령의 요지 한두 문장을 **줄바꿈 없이 한 줄로** — 상황판 파서가 첫 줄만 읽어 둘째 줄부터는 소리 없이 잘린다. 킥오프 씨앗 시점엔 이슈 제목이 들어가 있고, **초안 저장 시점에 명령 요지로 갈아 쓴다** — 그때 이미 미러가 재조립돼(§7) 본문에 노출되므로, 재가까지 미루면 임무·최종상태만 초안이고 `핵심:` 줄만 이슈 제목인 본문이 올라간다. 재가에서 유저가 고치면 그 시점에 다시, 이후로는 단편명령이 임무·범위를 바꿀 때마다 최신 확정 상태로 갱신한다. 이슈 본문 머리와 상황판이 이 줄을 읽는다) + 태스크 표 `| 태스크 | 상태 | 커밋 | 보고 |` (정기보고 근거 — 부록 A 가 확정되는 초안 저장 시점에 채운다. 씨앗 단계엔 없다). gitignore 대상이지만 이슈 본문 미러로 GitHub 에 남는다 — 다른 세션·워크트리는 이슈 본문에서 복원한다. **파일을 만드는 주체는 kickoff §0 다**(상태 `정찰`) — 이 스킬은 그 씨앗을 이어받아 `초안` 으로 올린다. 킥오프 없이 직접 호출돼 씨앗이 없으면 이 스킬이 만든다.
- **활동 로그 `.operations/<이슈번호>/activity.md`** = 실행 층의 실시간 피드 — 상황판 드릴다운이 읽는다. 태스크 착수·GREEN·커밋·보고·블로커처럼 유의미한 활동마다 `- MM-DD HH:MM 내용` 한 줄을 append 한다 (갱신 주체는 implement). **PR 공개 후 리뷰 라운드도 같은 대상이다** — 리뷰 접수·반영 push·스레드 회신·재리뷰 대기 전환마다 한 줄. `검토` 상태 동안에도 실행 층은 살아 있다(종결은 머지다 — §6) — 여기가 끊기면 상황판엔 마지막 태스크 이후가 무활동으로 보인다(갱신 주체는 그 반영을 수행하는 스킬 — implement §리뷰 지시 게이트). gitignore 대상이고 이슈 미러엔 싣지 않는다 — 미러는 확정 상태, 활동 로그는 흐름이다.
- **SDD `.superpowers/sdd/<plan-basename>/progress.md`** = superpowers 플러그인의 실행 층 장부. ruling·복구·재개용 — 플러그인 소관이라 그대로 둔다.

진행 파일 갱신은 태스크 상태 전이(착수 시 `실행` 표기 포함)·완료·커밋 시점 + §6 상태 전이 시점, ledger 갱신은 SDD 절차대로.

## 9. 종료 기록 — skill_end

작전명령이 저장·재가돼 절차가 끝나면 skill_end를 기록한다 (명령·compliance 규칙은 CLAUDE.md §1). 이때 superpowers:writing-plans가 이 런에 실제 발동(invoke)됐으면 같은 시점에 함께 기록한다 — 발동 레코드와 동일한 `superpowers:` prefix 포함 이름으로. 플러그인 스킬은 자체 종료 조항이 없어 여기가 기록 주체다.

**superpowers:brainstorming도 같은 규칙으로 함께 기록한다** — 발산이 끝나고 방향이 작전명령으로 확정된 시점이 그 종료다. 작전명령을 안 거치고 바로 구현으로 간 런은 implement 스킬이 기록 주체다.