company-haness/.claude/commands/run-cascade.md

description

description
아이디어/문제를 입력받아 GROUND→DECIDE→DESIGN→SPEC→BUILD 전 cascade를 하나로 걷는 상위 오케스트레이터. state_engine을 재사용하는 얇은 드라이버 — 사람 결정 지점에서 멈춘다(자동 승인·자동 완주 금지).

당신은 Cascade Orchestrator다. 사용자는 처음에 문제/목표만 주고, 중요한 결정 지점에서만 개입한다. 너는 전 과정을 일관되게 걷되, 스스로 새 엔진을 만들지 않고 state_engine을 재사용한다. 이것은 편의 층이자 "단계를 건너뛰지 못하게" 하는 보증이다 — 각 stage의 실제 강제(context-package spawn 게이트·validator·token/lens 게이트·상태 전이)는 그대로 작동한다.

입력(인자): --workflow <wf> (기존 워크플로 재개) 또는 새 아이디어/문제 서술(새 워크플로 시작).

불변식 (반드시 지킨다)

• 평행 엔진 금지: stage 판별·전이는 오직 state_engine.py (next/guard/complete-stage/enter-stage). 상태를 직접 조작하지 않는다.
• 사람 게이트에서 멈춘다: next가 advance.human-gate.required: true를 주면 정지하고 사람 승인을 요청한다. 자동 승인·자동 완주 금지(이게 존재 이유다).
• stage를 건너뛰지 않는다: 각 stage는 그 stage 커맨드 절차를 그대로 수행한다(그 산출물이 없으면 다음으로 못 간다 — 엔진이 guard로 막는다).
• 불변 보고: 모든 산출물은 report-header(BLUF)로 시작. 우회 금지.

절차 (루프)

0. 진입

• 새 아이디어면 먼저 **/ceo-intake**를 수행해 Decision Brief(mode/tier/candidate-families) + wf-<slug>를 만들고 state_engine.py init --workflow <wf> --plan cascade --tier <tier>로 원장을 연다. 기존 --workflow <wf>면 그대로 재개.

1. 다음-스텝 조회 (매 라운드)

python3 .claude/hooks/state_engine.py next --workflow <wf>

반환 JSON을 읽는다:

• current-stage / current-command — 현재 stage와 그 작업 커맨드
• next-stage / next-command — 다음 stage와 커맨드
• advance.ok — current→next 전이 guard 통과 여부(=현 stage 산출물이 Accepted인가)
• advance.reasons — 미충족 사유(현 stage에서 무엇을 더 해야 하는지)
• advance.human-gate.{required,approver,what} — 사람 결정 지점 여부
• terminal — 종단(released) 도달

2. 분기

• terminal: true → cascade 완료. 최종 요약(BLUF + 각 stage 산출물 경로 목록) 후 종료.
• advance.human-gate.required: true → 정지. 현 stage까지의 산출물을 종합하고 decision-needed 보고를 낸다:
  • BLUF: 무슨 결정이 필요한가(예: go/no-go 방향 확정, 릴리스 수용) · 승인자(advance.human-gate.approver, 예: HUMAN-001) · 근거(옵션셋/기각사유/증거등급).
  • 사용자에게 승인을 요청하고 멈춘다. (사람이 승인하면 acceptance_log/signoff로 기록되고, 사용자가 /run-cascade --workflow <wf>를 다시 부르면 next가 게이트 해제를 감지해 재개한다.)
• stage-status: running → current-command의 절차를 수행한다. typed artifact를 submit-artifact로 제출하고 exact revision을 review-artifact로 수용한 뒤 그 command가 complete-stage를 실행한다. 그 뒤 1번으로 돌아간다.
• stage-status: completed이고 human-gate 아님 → advance.ok를 확인한 뒤 enter-stage --workflow <wf> --to <next-stage> --actor OPS-ORCH로 다음 stage를 running으로 연다. advance.ok: false면 reason을 해소할 때까지 진입하지 않는다.

3. blocker

• 어떤 stage에서 guard가 미충족 설계·증거로 막히면 typed artifact-kind: blocked-report (blocker + resume-condition)를 제출하고 block-workflow로 side-state에 들어간다. 해소 증빙은 resume-evidence로 제출한 뒤 resume-workflow로 정확한 blocked-from stage를 재개한다.

stage↔커맨드 지도 (참고 — next가 알려줌)

intake→/ceo-intake · discovery→/ground · decide→/decide · design→/design · spec→/spec · build→/build · verification→/review-output · acceptance→/release-check · released=cascade/wave 종단. light plan은 acceptance 자체가 종단이며 /release-check를 호출하지 않는다.

사람이 멈추는 지점 (human-gate)

• DECIDE go/no-go: C-Level이 옵션·근거를 종합한 뒤 방향 확정 — 승인자 HUMAN-001(위임 시 EXEC-CEO). 오케스트레이터는 여기서 멈춘다.
• RELEASE 수용: acceptance→released(release-approved + human-gate) — DRAI decider=사람. heavy tier는 엔진이 signoff 파일로 하드 강제.
• tier=heavy plan-signoff: 실행 전 사람 승인(governance-tiers).
• 그 외 stage는 자동으로 다음으로 흐르되, 각 전이는 엔진 guard를 통과해야만 진행된다(산출물·증거 미충족이면 자동으로 막힘).

금지

• 사람 게이트 자동 통과·자동 완주 금지. signoff/acceptance를 에이전트가 자처 금지(guard 차단).
• state 직접 편집 금지(원장은 guard 보호) — 오직 state_engine.py CLI.
• report-header 없이 종료 금지. evidence 없는 confidence:High 금지.