feat: 하네스 control plane을 구조화된 SDD 런타임으로 고도화

.codex/skills/README.md

@@ -1,66 +1,36 @@
 # Skills
 
-이 디렉터리는 `git-ranker-workflow`에서만 쓰는 project-local skill을 관리한다.
-
-## 목적
-
-- 병렬 에이전트가 같은 품질 기준으로 작업하게 한다.
-- 반복 작업을 매번 자연어로 다시 설명하지 않게 한다.
-- 문서, spec, evidence 규칙을 실행 절차와 연결한다.
+이 디렉터리는 `git-ranker-workflow`에서만 쓰는 최소 workflow skill만 유지한다.
 
 ## Canonical Ownership
 
-- 정책, vocabulary, 상태 전이, 종료 조건, evidence minimum은 `docs/operations/`, `docs/architecture/`, `docs/specs/`가 관리한다.
-- route 결정은 `docs/operations/request-routing-policy.md`, Socratic 질문 contract와 approval gate는 `docs/operations/sdd-spec-policy.md`, runtime order와 artifact rule은 `docs/operations/workflow-governance.md`가 각각 canonical owner다.
-- skill은 그 정책을 대체하지 않고, 한 단계의 반복 실행 절차와 handoff만 다룬다.
-- policy와 skill이 충돌하면 skill에 새 규칙을 더하지 말고 canonical policy를 먼저 수정한 뒤 skill을 맞춘다.
-
-## Thin-Layer Rule
-
-- workflow-local skill은 하나의 harness stage, 필요한 handoff, 다음에 읽을 canonical source만 설명한다.
-- workflow-local skill은 route 정의, approval gate, state machine, question catalog를 policy 문서처럼 길게 다시 쓰지 않는다.
-- workflow-local skill은 backend/frontend file map, repo-local command inventory, bootstrap guide, implementation heuristic의 stable home이 되면 안 된다.
-- thin-layer migration은 workflow skill에서 repo-specific detail을 걷어내도 target repo entry doc과 코드/테스트만으로 onboarding이 유지될 때 완료로 본다.
-
-## Registry Status
+- 프로젝트 헌법은 `AGENTS.md`가 가진다.
+- artifact model, runtime, hook rule, runbook은 `docs/`가 가진다.
+- current task state와 evidence는 `workflows/tasks/<task-id>/`가 가진다.
+- 전역 guard 정책은 `workflows/system/hooks.json`이 가진다.
+- 내부 런타임 구현은 `scripts/workflow_runtime/`이 가진다.
+- skill은 위 규칙을 복제하지 않고, 한 단계의 handoff와 CLI 진입점만 안내한다.
 
-- `skill-creator`: 새 skill 생성, 기존 skill 리팩터링
-- `request-intake`: 새 요청을 `대화`, `모호한 요청`, `즉시 실행 가능한 작업`으로 분류하고 spec authoring stage로 handoff
-- `ambiguity-interview`: `모호한 요청`을 single spec 후보, `Blocked`, `Rejected`로 수렴
-- `socratic-spec-authoring`: 소크라테스 질문으로 spec을 세부화하고 질문 루프 종료 뒤 사용자 명시적 승인을 거쳐 승인 상태까지 고정
-- `context-pack-selection`: approved spec 뒤에 primary context pack과 required docs를 고정
-- `boundary-check`: 구현 전에 read/write/network/escalation 경계를 다시 확인
-- `parallel-work-split`: 여러 agent를 투입하기 전에 ownership과 disjoint write set을 고정
-- `api-contract-sync`: backend API 계약 변화가 client consumer와 workflow evidence에 미치는 영향을 맞춤
-- `verification-contract-runner`: selected verification contract profile을 실행하고 latest verification evidence를 남김
-- `repair-loop-triage`: verification 실패나 review 수리 요청 뒤 rerun, `Blocked`, split 중 하나를 정함
-- `reviewer-handoff`: review가 실제로 필요할 때 reviewer minimum context를 넘김
-- `publish-after-review`: legacy 이름이지만 current policy에서는 latest verification 뒤 open PR을 publish
-- `guardrail-ledger-update`: feedback close-out에서 guardrail ledger entry 작성
-- `failure-to-policy`: normalized failure를 가장 작은 guardrail asset으로 연결
-- `quality-sweep-triage`: quality sweep signal을 cleanup candidate, guardrail follow-up, repair-now, no-action으로 분류
+## Active Skill Set
 
-## Recommended Use
+- `request-intake`
+- `socratic-spec-authoring`
+- `phase-planner`
+- `boundary-check`
+- `phase-executor`
+- `verification-runner`
+- `review-closeout`
+- `repair-reopen`
 
-새 요청을 처음 받을 때의 기본 순서는 아래와 같다.
+## Recommended Order
 
 1. `request-intake`
-2. `ambiguity-interview` if route is `모호한 요청`
-3. `socratic-spec-authoring`
-4. `context-pack-selection`
-5. `boundary-check`
-6. `parallel-work-split` if more than one agent will work on the same spec
-
-`request-intake`는 route와 handoff까지만 담당한다. 현재 spec 초안에 대한 승인 요청과 `Approved` 고정은 `socratic-spec-authoring` 단계에서, 질문 루프가 닫힌 뒤 사용자 명시적 동의를 받아야만 가능하다.
-
-구현 뒤 close-out 순서는 아래 hook을 따른다.
-
-1. `verification-contract-runner`
-2. `publish-after-review` once latest verification evidence is `passed`
-3. `reviewer-handoff` if independent review is required after publish
-4. `repair-loop-triage` if verification failed or review requested changes
-5. `guardrail-ledger-update` once feedback close-out is triggered
-6. `failure-to-policy` when feedback close-out must choose a guardrail promotion target
-7. `quality-sweep-triage` when periodic or targeted quality scan is in scope
-
-`api-contract-sync`의 canonical backend contract는 `git-ranker/docs/openapi/openapi.json`이다. workflow는 canonical spec을 복제해 소유하지 않고, sync 절차와 evidence를 관리한다.
+2. `socratic-spec-authoring`
+3. `phase-planner`
+4. `boundary-check`
+5. `phase-executor`
+6. `verification-runner`
+7. `review-closeout`
+8. `repair-reopen`
+
+새 workflow에서는 markdown spec과 JSON state를 분리한다. `spec.md`는 사람용 요구사항 초안이고, `approve`가 이를 `task.json.intake`로 잠근다. `task.json`/`phases.json`/`runs/*.json`은 자동화용 canonical source다.

.codex/skills/boundary-check/SKILL.md

@@ -1,37 +1,31 @@
 ---
 name: boundary-check
-description: context pack selection 뒤에 task type별 read/write/network/escalation 경계와 approved spec의 write scope completeness를 다시 잠가야 할 때 사용한다.
+description: active phase의 allowed_write_paths 경계를 먼저 확인하고 범위를 벗어나면 phase를 수정하거나 재계획한다.
 ---
 
 # Boundary Check
 
-이 skill의 목적은 더 넓은 접근을 정당화하는 것이 아니라, 현재 subtask가 이미 허용한 경계 안에서만 움직이도록 다시 확인하는 것이다.
-
 ## 언제 사용하나
 
-- primary context pack이 정해졌고 구현 직전이다.
-- approved spec에 write scope와 verification contract profile이 적혀 있다.
+- 구현 전에 수정 대상 파일이 현재 phase 경계 안에 들어가는지 확인해야 한다.
 
 ## 먼저 확인할 것
 
-- approved spec
-- `docs/operations/tool-boundary-matrix.md`
-- `docs/operations/workflow-governance.md`
-- 필요하면 `docs/operations/verification-contract-registry.md`
+- `AGENTS.md`
+- `docs/artifact-model.md`
+- `docs/hooks.md`
+- `workflows/tasks/<task-id>/task.json`
+- `workflows/tasks/<task-id>/phases.json`
+- `workflows/system/hooks.json`
 
 ## 작업 방식
 
-1. primary repo와 active subtask가 여전히 하나인지 확인한다.
-2. 현재 읽으려는 문서와 파일이 selected context pack과 spec named input 안에 있는지 점검한다.
-3. allowed write paths, control-plane artifacts, explicitly forbidden path가 spec에 모두 적혀 있는지 확인한다.
-4. network와 escalation trigger를 최소 범위로 좁힌다.
+1. active phase의 `allowed_write_paths`를 읽는다.
+2. 수정하려는 파일 목록이 범위 안에 있는지 먼저 대조한다.
+3. 범위를 벗어나면 임의로 수정하지 말고 `phases.json`을 다시 계획하거나 승인 범위를 갱신한다.
+4. phase를 닫을 때는 `python3 scripts/workflow.py run <task-id> --complete --changed-path ...`로 write scope를 다시 검증한다.
 
 ## 결과
 
-- task type
-- read boundary
-- write boundary
-- control-plane artifact
-- explicitly forbidden path
-- network 필요 여부
-- escalation trigger
+- 범위 안이면 구현 진행
+- 범위 밖이면 phase 재계획 또는 승인 범위 수정