dev-bouncelisted

# dev-bounce 작업을 **스테이지 체인**으로 진행한다. 각 단계에서 무엇을 하고 무엇이 금지되는지는 프로젝트의 `workflow.yaml`에 정의돼 있고, 엔진이 단계마다 지시를 주입한다. 이 문서에 워크플로우 내용은 없다. **시작 절차만 있다.** 시작한 뒤에는 주입되는 지시를 따르면 된다. ## 물어야 하는데 물을 수단이 없을 때 이 문서는 몇 군데에서 AskUserQuestion으로 사용자에게 물으라고 한다. 그 도구가 없는 컨텍스트도 있다(서브에이전트, 위임 실행 등). 그럴 때는 **추측해서 진행하지 말고 멈춘다.** 선택지를 텍스트로 그대로 제시하고 사용자 답을 기다린다. 도구가 없다는 건 "알아서 하라"는 뜻이 아니다. 물어야 하는 것들은 전부 **사용자만 답할 수 있는 것**이기 때문이다 — 어느 모드로 갈지, 남의 작업과 병렬로 갈지, 이 규칙을 앞으로도 적용할지. 문구가 명확해 보여도(예: "앞으로 항상") 추측으로 진행하면 사용자가 원한 적 없는 영구 변경이 남는다. 되돌리는 비용이 묻는 비용보다 훨씬 크다. ### plan mode를 쓸 수 없는 세션 `blocking: plan_approved`는 **ExitPlanMode가 실제로 승인된 것**만 인정한다. 그런데 비대화 세션(`claude -p` 등)에는 `EnterPlanMode` / `ExitPlanMode`가 아예 없다. 그 세션에서 `plan` 워크플로우를 시작하면 **충족할 방법이 없는 조건에 갇힌다.** 도구가 없다는 걸 확인했으면 조용히 멈춰 있지 말고 **막힌 이유와 빠져나갈 길을 알려라**: - `plan` 대신 `simple` 워크플로우로 시작한다 (계획 단계가 없다), 또는 - 대화형 세션에서 다시 실행한다 승인을 위조하거나 `bouncer done`으로 우회하지 않는다 — 그러면 게이트가 있으나 마나다. 아직 시작하지 않았다면 `bouncer start`를 하지 말고, 이미 시작했다면 `bouncer cancel`로 정리한 뒤 안내한다. 갇힌 작업을 그대로 두면 다음 세션까지 잠금이 남는다. --- ## Step 1 — 상태 확인 ```bash bouncer scan ``` 항상 부른다. 0.01초짜리고, 세션 시작 때 주입된 정보는 그 사이 다른 세션이 작업을 시작했으면 이미 낡았을 수 있다. ``` STATE MINE <경로> <워크플로우> <단계> 이 세션이 이어서 할 작업 STATE OTHER <경로> <단계> <나이> 다른 세션이 잡고 있는 작업 STATE NONE 아무것도 없음 ORPHAN <task-id> <워크플로우> <단계> 잠금이 풀린 미완 작업 (이어받을 수 있다) ERROR <메시지> 설정을 읽을 수 없다 — 사용자에게 그대로 알린다 WORKFLOW <이름> <설명> 모