@tienne/gestalt 0.84.1 → 0.85.0

package/dist/plugin/skills/dispatch/SKILL.md

@@ -119,7 +119,7 @@ Orca 런타임이 붙지 않아 워커 디스패치는 못 합니다.
 - 게슈탈트 실행 세션 ID(UUID 원문 — 워커는 다른 프로세스라 `active`가 다르게 해석될 수 있다)
 - 이 워커가 맡은 게슈탈트 taskId
 - `taskContext.taskPrompt` 내용
-- 완료 후 `ges_execute action=execute_task`로 결과를 제출하라는 지시
+- 완료 후 `ges_execute action=execute_task`로 결과를 제출하라는 지시. 바꾼 파일은 전부 `artifacts`에 적고 파일을 안 바꾸는 태스크면 `noCodeChange: true`를 같이 낸다. `verification_failed`가 오면 고쳐서 다시 제출하고 끝내지 못했으면 `status: "failed"`로 낸다. `serverError: true`가 함께 오면 고치지 말고 잠시 뒤 같은 결과를 다시 내고 계속 실패하면 `status: "failed"`로 낸다
 - **다른 태스크는 건드리지 말라는 경계** — 워커가 ready 집합을 보고 남의 태스크까지 하려 들면 충돌한다
 
 동시 워커 수는 `maxConcurrent`로 제한한다. 지정이 없으면 ready 집합 크기와 4 중 작은 값을 쓴다. 워커마다 에이전트 프로세스와 게슈탈트 MCP 서버가 하나씩 뜨므로 무제한으로 띄우지 않는다.
@@ -149,7 +149,7 @@ Orca 런타임이 붙지 않아 워커 디스패치는 못 합니다.
 
 ## 6단계: 막힌 것은 사람에게 올린다
 
-게슈탈트가 human escalation으로 세션을 끝냈으면(`terminationReason: 'human_escalation'`) 그 사실을 `orchestration gate-create`로 올려 사람 눈에 보이게 한다.
+lateral persona를 다 써서 게슈탈트 세션이 `awaiting_human`으로 멈췄으면 그 사실을 `orchestration gate-create`로 올려 사람 눈에 보이게 한다. evolve 응답의 `status: 'awaiting_human'`으로 알 수 있다. `status` 조회에 `openGate`가 실려 있어도 같은 뜻이다. 질문에는 `gate.question`과 `gate.options`의 `id`, `label`을 그대로 옮긴다.
 
 ```bash
 <실행파일> orchestration gate-create --task <task_id> --question "<막힌 지점과 필요한 판단>" --json
@@ -158,6 +158,18 @@ Orca 런타임이 붙지 않아 워커 디스패치는 못 합니다.
 
 카드 코멘트를 남기면 터미널을 열지 않고도 `worktree ps`나 모바일에서 상태가 보인다. 의미 있는 체크포인트마다 코멘트를 갱신한다.
 
+Orca 쪽에서 사람이 답해 해소되면(`gate-resolve`) 그 답을 게슈탈트에 넘겨야 세션이 움직인다. Orca 쪽 해소만으로는 게슈탈트 세션이 `awaiting_human`에 그대로 남는다. 그동안 `ges_execute`는 `status`, `resume`, `gate_resolve`, `evolution_viz` 말고는 다 거절한다.
+
+```json
+{
+  "action": "gate_resolve",
+  "sessionId": "<UUID>",
+  "gateResolution": { "gateId": "<gate.gateId>", "optionId": "<사람이 고른 id>", "decision": "<사람의 결정>", "rationale": "<그 이유>" }
+}
+```
+
+`decision`과 `rationale`은 사람이 적은 말을 쓴다. 비어 있으면 서버가 거절한다. 코디네이터가 지어 채우면 지어낸 판단이 Memory에 남는다. 응답의 `nextAction`이 `evolve_patch`나 `evaluate`면 execute 스킬로 돌려보낸다. `terminated`가 오면(`restart`, `abort`) 세션이 종료된 것이니 디스패치를 멈춘다.
+
 ## Do-NOT
 
 - **execute 스킬을 대체하지 않는다.** 계획 수립(Planning), 평가(Evaluate), 개선(Evolve)은 execute가 한다. 이 스킬은 Phase 2 실행을 다른 백엔드로 돌리는 것뿐이다.

package/dist/plugin/skills/execute/SKILL.md

@@ -1,16 +1,16 @@
 ---
 name: execute
-version: "1.3.0"
-description: "Gestalt-driven execution planner that transforms a Spec into a validated ExecutionPlan. Requires a Spec that already exists. Given only a problem statement, use solve instead — it drives interview → spec → execute as one loop."
+version: '1.3.0'
+description: 'Gestalt-driven execution planner that transforms a Spec into a validated ExecutionPlan. Requires a Spec that already exists. Given only a problem statement, use solve instead — it drives interview → spec → execute as one loop.'
 triggers:
-  - "execute"
-  - "plan execution"
-  - "create execution plan"
+  - 'execute'
+  - 'plan execution'
+  - 'create execution plan'
 inputs:
   spec:
     type: object
     required: true
-    description: "A validated Spec specification from the spec generation step"
+    description: 'A validated Spec specification from the spec generation step'
 outputs:
   - executionPlan
 ---
@@ -61,6 +61,7 @@ Success condition: `score ≥ 0.85` AND `goalAlignment ≥ 0.80`
 - **Flow A — Structural Fix**: fix lint/build/test failures → re-evaluate
 - **Flow B — Contextual Evolution**: patch Spec ACs/constraints → re-execute impacted tasks → re-evaluate
 - **Flow C — Lateral Thinking**: when stagnation detected, rotate through Multistability / Simplicity / Reification / Invariance personas
+- **Flow D — Human Decision**: when all four personas are exhausted, the session pauses as `awaiting_human` — ask the human, then `gate_resolve` and follow `nextAction`
 
 ## Phase 0 — 규칙 확보 (필수 — 스킵 불가)
 
@@ -109,16 +110,15 @@ ges_status()  →  {
 
 **`ruleSourceErrors`가 비어 있지 않으면 멈춘다.** 판정과 사용자에게 알릴 문구는 [`../_shared/rule-sources.md`](../_shared/rule-sources.md)의 "선언이 깨졌을 때" 절이 원본이다. **`ruleSources`가 비어 있지 않아도 일부가 빠진 상태일 수 있으니 배열 길이로 판정하지 않는다.**
 
-
 `scope`가 비어 있지 않으면 **이번 Spec에 해당하는 소스만** 읽는다. 백엔드 태스크만 있는 Spec에서 디자인 토큰을 물어볼 이유가 없다. 여기는 건드릴 파일이 정해진 자리라 태그를 그 파일에서 뽑는다.
 
 **`solve`로 들어와 소스 읽기를 건너뛰는 경우에도 이 판정은 한다.** 건너뛰는 건 읽기지 판정이 아니다. 앞 스킬은 파일을 모른 채 넘겼으므로 여기서 세 가지가 정해진다.
 
-| 앞에서 넘어온 것 | 여기서 |
-|---|---|
+| 앞에서 넘어온 것                                               | 여기서                                                                                             |
+| -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
 | 넓게 잡아 읽어둔 `convention` 소스 중 파일을 보니 안 걸리는 것 | `repoRules.sources`에서 뺀다. 거기서 빠지면 서브에이전트 프롬프트와 완료 보고 양쪽에서 함께 빠진다 |
-| 판정을 미뤄둔 `stop`과 `delegate` 소스 | 여기서 판정한다. 걸리면 읽거나 멈추거나 넘긴다 |
-| 새로 걸리는 소스 | 그것만 더 읽는다 |
+| 판정을 미뤄둔 `stop`과 `delegate` 소스                         | 여기서 판정한다. 걸리면 읽거나 멈추거나 넘긴다                                                     |
+| 새로 걸리는 소스                                               | 그것만 더 읽는다                                                                                   |
 
 `trust: "delegate"`인 소스가 이번 작업 범위에 걸리면 그 부분은 게슈탈트가 직접 만들지 않고 넘긴다. 어디까지 넘기는지 사용자에게 알리고 진행한다.
 
@@ -145,41 +145,52 @@ API 키 없이 MCP 서버 실행 시 자동 활성화. LLM 작업을 caller가
 ### Action별 사용법
 
 **`start`** — 실행 계획 세션 시작
+
 ```json
 { "action": "start", "spec": { ... } }
 ```
+
 → `{ status, sessionId, specId, executeContext, message }`
 
 **`plan_step`** — 각 계획 단계 결과 제출
+
 ```json
 { "action": "plan_step", "sessionId": "...", "stepResult": { "principle": "figure_ground", "classifiedACs": [...] } }
 ```
+
 → `{ status, sessionId, stepsCompleted, isLastStep, executeContext?, message }`
 
+continuity에서 DAG가 무효면 `error`가 함께 실린 `status: "plan_rewound"` 응답이 온다. [DAG가 무효일 때](#dag가-무효일-때--closure로-되감기)를 본다.
+
 **`plan_complete`** — 최종 실행 계획 조립
+
 ```json
 { "action": "plan_complete", "sessionId": "..." }
 ```
+
 → `{ status, sessionId, executionPlan, message }`
 
+저장된 계획의 DAG가 무효면 확정하지 않고 같은 `plan_rewound` 응답을 돌려준다.
+
 **`status`** — 세션 상태 확인
+
 ```json
 { "action": "status", "sessionId": "..." }
 ```
 
 ### ExecuteContext 필드
 
-| 필드 | 타입 | 설명 |
-|------|------|------|
-| `systemPrompt` | string | 실행 계획 시스템 프롬프트 |
-| `planningPrompt` | string | 현재 단계의 계획 프롬프트 |
-| `currentPrinciple` | string | 현재 적용 중인 게슈탈트 원리 |
-| `principleStrategy` | string | 해당 원리의 전략 설명 |
-| `phase` | string | 현재 단계 (`planning`) |
-| `stepNumber` | number | 현재 스텝 번호 (1-4) |
-| `totalSteps` | number | 전체 스텝 수 (4) |
-| `spec` | Spec | 원본 Spec 스펙 |
-| `previousSteps` | array | 이전 단계 결과들 |
+| 필드                | 타입   | 설명                                                                                            |
+| ------------------- | ------ | ----------------------------------------------------------------------------------------------- |
+| `systemPrompt`      | string | 실행 계획 시스템 프롬프트                                                                       |
+| `planningPrompt`    | string | 현재 단계의 계획 프롬프트                                                                       |
+| `currentStage`      | string | 현재 단계를 풀어 쓴 문구 (예: `빠진 요구사항 채우기`). 서버 내부의 원리 이름 대신 응답에 실린다 |
+| `principleStrategy` | string | 해당 원리의 전략 설명                                                                           |
+| `phase`             | string | 현재 단계 (`planning`)                                                                          |
+| `stepNumber`        | number | 현재 스텝 번호 (1-4)                                                                            |
+| `totalSteps`        | number | 전체 스텝 수 (4)                                                                                |
+| `spec`              | Spec   | 원본 Spec 스펙                                                                                  |
+| `previousSteps`     | array  | 이전 단계 결과들                                                                                |
 
 ### Planning Principle 순서
 
@@ -195,6 +206,31 @@ API 키 없이 MCP 서버 실행 시 자동 활성화. LLM 작업을 caller가
 - Continuity 단계에서는 서버 측 DAG 검증이 추가로 수행됨
 - 모든 AC가 분류되어야 하고 모든 Task가 그룹에 포함되어야 함
 
+### DAG가 무효일 때 — closure로 되감기
+
+순환은 closure 단계 `atomicTasks`의 `dependsOn`에서 생긴다. continuity만 다시 내서는 못 고친다. 그래서 `dagValidation.isValid: false`를 보고하거나 서버가 순환이나 충돌을 찾으면 `plan_step`(continuity)과 `plan_complete` 둘 다 계획을 확정하지 않는다. 대신 세션을 figure_ground까지만 남기고 되감은 뒤 이렇게 돌려준다.
+
+```json
+{
+  "error": "Dependency DAG is invalid (...)",
+  "status": "plan_rewound",
+  "sessionId": "...",
+  "rewoundToStep": 2,
+  "hasCycles": true,
+  "cycleDetails": ["Cycle detected involving tasks: task-0 → task-1"],
+  "conflictDetails": [],
+  "executeContext": { "currentStage": "빠진 요구사항 채우기", "stepNumber": 2, "...": "..." },
+  "nextAction": "plan_step"
+}
+```
+
+- `cycleDetails`와 `conflictDetails`를 보고 문제가 된 태스크의 `dependsOn`을 고친다.
+- 응답의 `executeContext`로 closure부터 다시 낸다. 그다음 proximity와 continuity를 차례로 다시 제출한다.
+- `isValid: false`를 그대로 두고 continuity만 다시 내면 또 되감긴다. 호출자 보고가 무효여도 막는다.
+- 이 응답에는 `error` 필드가 함께 실린다. `plan_complete`나 `execute_start`로 넘어가지 않는다.
+- 되감은 뒤의 closure 프롬프트에는 순환 정보도 직전 `atomicTasks`도 없다. 서브에이전트로 다시 낼 때는 응답의 `cycleDetails`와 `conflictDetails`, 직전에 제출한 `atomicTasks`를 함께 넘기고 순환을 만든 `dependsOn`을 고치라고 적는다.
+- 같은 세션에서 `plan_rewound`를 연속 두 번 받으면 closure를 다시 제출하지 않는다. `cycleDetails`를 사용자에게 보여주고 어떻게 할지 묻는다. 서버는 횟수를 세지 않으므로 스킬이 센다.
+
 ### Reasoning Model 서브에이전트로 플래닝 추론
 
 Phase 1 플래닝(`plan_step` 4단계 + `plan_complete`)은 Spec을 태스크 DAG로 분해하는 깊은 one-shot 추론이라, 게슈탈트에서 상위 추론 모델이 진짜 값을 하는 지점이다. 각 `plan_step`의 `stepResult`(classifiedACs / atomicTasks / taskGroups / dagValidation)를 만드는 추론은 현재 세션이 직접 하지 말고 별도 Agent 서브에이전트로 스폰한다.
@@ -207,7 +243,7 @@ Phase 1 플래닝(`plan_step` 4단계 + `plan_complete`)은 Spec을 태스크 DA
 ges_status()  →  { reasoningModel: "fable", reasoningModelFallback: "opus", ... }
 ```
 
-**스폰.** 각 `plan_step`(그리고 `plan_complete` 조립을 위한 추론이 필요하면 그 단계)에서 Agent 도구로 서브에이전트를 띄우되 `model` 파라미터에 `reasoningModel` 값을 넘긴다. 서브에이전트에는 해당 단계의 `executeContext`(`systemPrompt`, `planningPrompt`, `currentPrinciple`, `spec`, `previousSteps`)를 전달하고 그 단계의 `stepResult`를 산출하게 한다. 결과를 `plan_step`으로 제출한다.
+**스폰.** 각 `plan_step`(그리고 `plan_complete` 조립을 위한 추론이 필요하면 그 단계)에서 Agent 도구로 서브에이전트를 띄우되 `model` 파라미터에 `reasoningModel` 값을 넘긴다. 서브에이전트에는 해당 단계의 `executeContext`(`systemPrompt`, `planningPrompt`, `currentStage`, `spec`, `previousSteps`)를 전달하고 그 단계의 `stepResult`를 산출하게 한다. 결과를 `plan_step`으로 제출한다.
 
 **폴백은 스킬 런타임에서 발동한다.** 서버는 폴백 대상(`reasoningModelFallback`)만 알려줄 뿐, 모델 가용성을 감지하거나 재시도하지 않는다. Agent 도구가 `reasoningModel`(예: `fable`)을 지원하지 않아 스폰이 거부/실패하면, 그때 스킬이 직접 `model`을 `reasoningModelFallback`(예: `opus`)로 바꿔 1회 재시도한다. 폴백 판단과 재시도는 전적으로 이 스킬 런타임의 책임이다.
 
@@ -220,9 +256,18 @@ ges_status()  →  { reasoningModel: "fable", reasoningModelFallback: "opus", ..
 `plan_complete` 이후 호출. 태스크 목록을 받아 실행 준비.
 
 ```json
-{ "action": "execute_start", "sessionId": "..." }
+{ "action": "execute_start", "sessionId": "...", "cwd": "/path/to/project" }
 ```
-→ `{ status, sessionId, executionPlan, message }`
+
+→ `{ status, sessionId, executionPlan, artifactCheck, message }`
+
+`cwd`에는 프로젝트 루트를 넘긴다. 서버가 이 디렉토리에서 git 작업 트리가 실행 시작 시점에 어떤 상태였는지 잡아 두고 나중에 `completed` 보고의 `artifacts`를 그 상태와 대조한다. `cwd`를 비우면 세션의 `codeGraphRepoRoot`를 쓰고 그것도 없으면 서버 프로세스의 cwd를 쓴다. git 레포가 아니면 대조 없이 진행한다. 대조 중에는 그 레포의 `filter.*.clean` 설정이 실행되므로 믿지 않는 레포를 `cwd`로 넘기지 않는다.
+
+응답에는 `artifactCheck: { repoRoot, baseline, error? }`가 붙는다. `repoRoot`는 실제로 대조에 쓸 디렉토리다. `baseline`은 아래 셋 중 하나다. `execute_task` 응답의 `artifactCheck`는 `verified` 같은 문자열 하나라 꼴이 다르다.
+
+- `captured`: 시작 시점 상태를 잡았다. 이후 `completed` 보고를 대조한다
+- `no_baseline`: git 레포가 아니라 대조하지 않는다
+- `baseline_failed`: git 호출이 실패해 대조하지 않는다. 실패 내용은 `error`에 담긴다
 
 ---
 
@@ -236,6 +281,7 @@ ges_status()  →  { reasoningModel: "fable", reasoningModelFallback: "opus", ..
 // Call 1: 매칭 컨텍스트 요청
 { "action": "role_match", "sessionId": "..." }
 ```
+
 → `{ matchContext }` — 어떤 에이전트가 적합한지 판단하기 위한 프롬프트
 
 `matchContext.tierHint`는 `"frugal"`이다. `matchContext.availableAgents`에는 에이전트 20여 개의 description이 통째로 들어 있다. 그걸 세션 컨텍스트에 들이는 대신 **서브에이전트에 넘겨 1차 후보를 좁힌다.**
@@ -259,11 +305,22 @@ Agent {
   "action": "role_match",
   "sessionId": "...",
   "matchResult": [
-    { "agentName": "technical-writer", "domain": ["documentation"], "relevanceScore": 0.9, "reasoning": "..." },
-    { "agentName": "architect", "domain": ["architecture"], "relevanceScore": 0.7, "reasoning": "..." }
+    {
+      "agentName": "technical-writer",
+      "domain": ["documentation"],
+      "relevanceScore": 0.9,
+      "reasoning": "..."
+    },
+    {
+      "agentName": "architect",
+      "domain": ["architecture"],
+      "relevanceScore": 0.7,
+      "reasoning": "..."
+    }
   ]
 }
 ```
+
 → `{ perspectivePrompts }` — 각 에이전트별 관점 생성 프롬프트
 
 **`role_consensus` — 다중 관점 합의 (2-Call)**
@@ -279,6 +336,7 @@ Agent {
   ]
 }
 ```
+
 → `{ synthesisContext }` — 관점 통합 프롬프트
 
 ```json
@@ -293,6 +351,7 @@ Agent {
   }
 }
 ```
+
 → `{ roleGuidance }` — execute_task 시 참조할 최종 guidance
 
 ---
@@ -320,13 +379,13 @@ Agent {
 
 ```
 // 같은 메시지에서 동시 호출 — Agent 1
-Agent(task: "task-0 실행: {task-0 title}\n컨텍스트: {taskContext}\n완료 후 execute_task로 결과 제출")
+Agent(task: "task-0 실행: {task-0 title}\n컨텍스트: {taskContext}\n완료 후 execute_task로 결과 제출. 바꾼 파일은 전부 artifacts에 적는다. 파일을 안 바꾸는 태스크면 noCodeChange: true를 같이 낸다. verification_failed가 오면 고쳐서 다시 제출하고 끝내지 못했으면 status: \"failed\"로 낸다. serverError: true가 함께 오면 고치지 말고 잠시 뒤 같은 결과를 다시 내고 계속 실패하면 status: \"failed\"로 낸다")
 
 // 같은 메시지에서 동시 호출 — Agent 2
-Agent(task: "task-1 실행: {task-1 title}\n컨텍스트: {taskContext}\n완료 후 execute_task로 결과 제출")
+Agent(task: "task-1 실행: {task-1 title}\n컨텍스트: {taskContext}\n완료 후 execute_task로 결과 제출. 바꾼 파일은 전부 artifacts에 적는다. 파일을 안 바꾸는 태스크면 noCodeChange: true를 같이 낸다. verification_failed가 오면 고쳐서 다시 제출하고 끝내지 못했으면 status: \"failed\"로 낸다. serverError: true가 함께 오면 고치지 말고 잠시 뒤 같은 결과를 다시 내고 계속 실패하면 status: \"failed\"로 낸다")
 
 // 같은 메시지에서 동시 호출 — Agent 3
-Agent(task: "task-2 실행: {task-2 title}\n컨텍스트: {taskContext}\n완료 후 execute_task로 결과 제출")
+Agent(task: "task-2 실행: {task-2 title}\n컨텍스트: {taskContext}\n완료 후 execute_task로 결과 제출. 바꾼 파일은 전부 artifacts에 적는다. 파일을 안 바꾸는 태스크면 noCodeChange: true를 같이 낸다. verification_failed가 오면 고쳐서 다시 제출하고 끝내지 못했으면 status: \"failed\"로 낸다. serverError: true가 함께 오면 고치지 말고 잠시 뒤 같은 결과를 다시 내고 계속 실패하면 status: \"failed\"로 낸다")
 ```
 
 **각 Agent의 execute_task 제출:**
@@ -345,6 +404,7 @@ Agent(task: "task-2 실행: {task-2 title}\n컨텍스트: {taskContext}\n완료
 ```
 
 실패 시:
+
 ```json
 {
   "action": "execute_task",
@@ -379,10 +439,54 @@ role_match/role_consensus로 얻은 `roleGuidance`를 참조해 태스크를 수
   }
 }
 ```
-→ `{ status, nextTaskId?, allTasksCompleted, driftResult? }`
+
+→ `{ status, nextTaskId?, allTasksCompleted, artifactCheck?, driftResult? }`
 
 `driftResult`가 반환되면 Spec과의 drift 경고 — 계속 진행하되 다음 태스크에서 방향 보정.
 
+**artifacts 대조.** `status: "completed"`로 보고하면 서버가 `artifacts`의 파일이 실행 시작 뒤로 실제로 바뀌었는지 확인한다. 수정하거나 새로 만들거나 커밋하거나 지운 파일은 모두 바뀐 것으로 친다. 상대 경로는 `execute_start`의 `cwd` 기준이다. 디렉토리나 gitignore에 걸린 경로는 확인할 수 없으니 바꾼 소스 파일을 하나씩 적는다. `failed`와 `skipped`는 대조하지 않는다. 대조는 `execute_task`에만 있고 `evolve_re_execute`와 `evolve_fix`로 낸 결과는 대조하지 않는다.
+
+`artifacts`가 빈 `completed`는 거절된다. 조사나 판단처럼 원래 파일을 안 바꾸는 태스크는 `noCodeChange: true`를 같이 낸다. `artifacts`가 하나라도 있으면 `noCodeChange`와 상관없이 대조한다.
+
+```json
+{
+  "action": "execute_task",
+  "sessionId": "...",
+  "taskResult": {
+    "taskId": "task-1",
+    "status": "completed",
+    "output": "기존 인증 흐름 조사 결과 요약",
+    "artifacts": [],
+    "noCodeChange": true
+  }
+}
+```
+
+통과하면 응답에 `artifactCheck`가 붙는다.
+
+- `verified`: 대조를 통과한 경우
+- `no_code_change`: `noCodeChange: true`로 대조를 건너뛴 경우
+- `no_baseline`: git 레포가 아니라 시작 시점 상태가 없는 경우
+- `baseline_failed`: `execute_start` 때 git 호출이 실패해 시작 시점 상태를 못 잡은 경우
+- `baseline_truncated`: 시작 시점에 커밋 안 된 파일이 2000개를 넘어 이벤트에 해시를 다 못 남겼고 이 세션을 다른 서버 프로세스가 이벤트에서 불러와 대조하지 못한 경우. 해시는 실행을 시작한 프로세스 메모리에만 있고 이벤트에는 사유만 남는다. 그래서 서버가 재시작됐거나 MCP 서버를 따로 띄우는 dispatch 워커가 보고하면 대조 없이 통과한다. 시작한 프로세스는 상태를 잡았으므로 `execute_start` 응답의 `artifactCheck.baseline`은 이때도 `captured`로 나간다. dispatch를 쓸 땐 시작 전에 커밋 안 된 파일을 줄여 둔다
+
+**`verification_failed`를 받으면.** 바뀌지 않은 파일이 하나라도 있으면 서버는 결과를 기록하지 않고 이렇게 돌려준다.
+
+```json
+{
+  "status": "verification_failed",
+  "recorded": false,
+  "problems": [{ "path": "src/auth.ts", "status": "unchanged", "hint": "실행 시작 뒤로 내용이 그대로입니다" }],
+  "nextAction": "execute_task"
+}
+```
+
+`problems[].status`는 `unchanged`, `missing`, `outside_repo`, `ignored`, `directory`, `invalid_path`(경로에 개행이나 NUL 문자), `not_regular_file`(FIFO나 소켓처럼 일반 파일이 아님) 중 하나다. 태스크는 아직 끝나지 않은 상태로 남는다. 파일을 실제로 고쳤는지 확인하고 수정을 마치거나 `artifacts` 목록을 바로잡아 같은 태스크를 다시 제출한다. 끝내지 못했으면 `status: "failed"`로 낸다.
+
+응답에 `serverError: true`가 있으면 보고 내용 문제가 아니라 서버 쪽 git 호출이 실패한 것이다. 이때는 고칠 것이 없으니 잠시 뒤 같은 결과를 그대로 다시 낸다. 계속 실패하면 `status: "failed"`로 내고 `output`에 오류 내용을 적는다.
+
+> 기준점은 태스크마다가 아니라 `execute_start` 때 한 번 잡는다. 앞선 태스크가 바꾼 파일을 뒤 태스크가 `artifacts`에 적어도 통과한다.
+
 ---
 
 ## Phase 3 — Evaluate
@@ -390,12 +494,19 @@ role_match/role_consensus로 얻은 `roleGuidance`를 참조해 태스크를 수
 모든 태스크 완료 후 3-Call 평가 진행.
 
 **Call 1 — Structural 단계 시작**
+
 ```json
 { "action": "evaluate", "sessionId": "..." }
 ```
+
 → `{ stage: "structural", structuralContext }` — lint/build/test 실행 지시
 
+`structuralContext.commands`의 `command` 문자열을 고치지 말고 그대로 실행한다. 패키지 매니저는 서버가 package.json의 `packageManager` 필드나 lockfile로 골라뒀다. scripts에 없는 lint, build는 목록에서 빠지고 test는 항상 남는다. 제출할 때도 같은 문자열을 그대로 싣는다 — 명령이 다르거나 빠지면 서버가 거부한다. 종료 코드가 0이 아닌 명령이 있으면 `allPassed`를 `true`로 보내도 실패로 처리된다.
+
+거부 메시지가 `Submitted commands do not match`로 시작하면 `structuralContext.commands`의 명령을 그대로 다시 실행해서 그 실행의 종료 코드와 출력으로 다시 제출한다. 이전 실행 결과에 명령 문자열만 바꿔 싣지 않는다. 다른 거부 메시지면 다시 제출하지 말고 Call 1부터 다시 시작한다.
+
 **Call 2 — Structural 결과 제출**
+
 ```json
 {
   "action": "evaluate",
@@ -410,24 +521,25 @@ role_match/role_consensus로 얻은 `roleGuidance`를 참조해 태스크를 수
   }
 }
 ```
-→ structural 실패 시 `{ stage: "structural_failed", evolveContext }` → Evolve Flow A 진입
-→ structural 통과 시 `{ stage: "contextual", evaluationContext }` — AC별 LLM 검증 지시
+
+→ structural 실패 시 `{ stage: "complete", shortCircuited: true, nextAction: "evolve_fix" }` → Evolve Flow A 진입
+→ structural 통과 시 `{ stage: "contextual", contextualContext }` — AC별 LLM 검증 지시
 
 **Call 3 — Contextual 결과 제출**
+
 ```json
 {
   "action": "evaluate",
   "sessionId": "...",
   "evaluationResult": {
-    "verifications": [
-      { "acIndex": 0, "satisfied": true, "evidence": "...", "gaps": [] }
-    ],
+    "verifications": [{ "acIndex": 0, "satisfied": true, "evidence": "...", "gaps": [] }],
     "overallScore": 0.92,
     "goalAlignment": 0.88,
     "recommendations": []
   }
 }
 ```
+
 → `{ status: "completed" }` (score ≥ 0.85, goalAlignment ≥ 0.80)
 → 미달 시 `{ evolveContext }` → Evolve Flow B 진입
 
@@ -477,7 +589,7 @@ role_match/role_consensus로 얻은 `roleGuidance`를 참조해 태스크를 수
 {
   "action": "evolve_re_execute",
   "sessionId": "...",
-  "reExecuteTaskResult": { "taskId": "task-3", "status": "completed", "output": "...", "artifacts": [] }
+  "reExecuteTaskResult": { "taskId": "task-3", "status": "completed", "output": "...", "artifacts": ["src/auth/oauth.ts"] }
 }
 
 // 4. Re-evaluate
@@ -510,25 +622,64 @@ role_match/role_consensus로 얻은 `roleGuidance`를 참조해 태스크를 수
 { "action": "evolve_lateral", "sessionId": "..." }
 ```
 
-| Stagnation 패턴 | Persona | 전략 |
+| Stagnation 패턴     | Persona        | 전략             |
+| ------------------- | -------------- | ---------------- |
+| hard_cap            | Multistability | 다른 각도로 보기 |
+| oscillation         | Simplicity     | 단순하게 줄이기  |
+| no_drift            | Reification    | 빠진 조각 채우기 |
+| diminishing_returns | Invariance     | 성공 패턴 복제   |
+
+4개 persona를 다 써도 점수가 안 오르면 세션은 끝나지 않고 `awaiting_human`으로 멈춘다. 응답에 `gate`가 실려 온다.
+
+```json
+→ { status: "awaiting_human", gate: { gateId, question, options: [...], context }, escalationContext, nextAction: "gate_resolve", nextActionParams: { sessionId, gateResolution: { gateId } } }
+```
+
+### Flow D — 사람 판단 대기 (`awaiting_human`)
+
+여기서 스킬은 스스로 고르지 않는다. **반드시 사람에게 묻고 답을 기다린다.**
+
+1. `gate.question`과 `gate.context`(막힌 태스크, 시도한 persona, 최고 점수, 남은 문제)를 보여준다.
+2. `gate.options`를 선택지로 띄운다. 호스트에 선택형 질문 도구가 있으면(AskUserQuestion 등) 그걸 쓴다. 없으면 번호 목록으로 보여주고 답을 받는다. `restart`와 `abort`는 세션이 종료된다는 점을 함께 알린다.
+3. 고른 선택지에 더해 **결정(`decision`)과 이유(`rationale`)를 한 줄씩** 받는다. 둘 다 비면 서버가 거절한다. 사람이 이유를 안 적었으면 다시 묻는다. 대신 지어내지 않는다 — 이 두 줄이 그대로 Memory에 남는다.
+4. `gate_resolve`를 부른다.
+
+```json
+{
+  "action": "gate_resolve",
+  "sessionId": "...",
+  "gateResolution": {
+    "gateId": "gate-...",
+    "optionId": "patch_spec",
+    "decision": "사람이 내린 결정",
+    "rationale": "그렇게 정한 이유"
+  }
+}
+```
+
+5. 응답의 `nextAction`을 따른다.
+
+| `optionId` | 응답 | 다음 |
 |---|---|---|
-| hard_cap | Multistability | 다른 각도로 보기 |
-| oscillation | Simplicity | 단순하게 줄이기 |
-| no_drift | Reification | 빠진 조각 채우기 |
-| diminishing_returns | Invariance | 성공 패턴 복제 |
+| `patch_spec` | `gate_resolved`, 세션 `executing` | 사람이 말한 대로 AC나 제약을 고쳐 `evolve_patch` (Flow B) |
+| `manual_task` | `gate_resolved`, 세션 `executing` | 사람이 태스크를 처리했는지 확인한 뒤 `evaluate` |
+| `restart` | `terminated` | 세션 종료. 태스크를 더 잘게 쪼갠 새 스펙으로 `start`를 안내 |
+| `abort` | `terminated` | 세션 종료. 막힌 지점과 시도한 접근을 보고 |
+
+이어간 뒤 다음 평가가 한 번만 성공 기준에 못 미쳐도 persona를 되풀이하지 않고 곧바로 새 `awaiting_human` 응답이 온다. 진화 이력과 이미 써본 persona 기록이 남아 있어서다. 그때도 1번부터 다시 한다.
 
-4개 persona 소진 → `human_escalation` 반환으로 세션 종료.
+`awaiting_human`인 동안에는 `status`, `resume`, `gate_resolve`, `evolution_viz` 말고는 전부 에러로 거절된다. 세션을 이어받았는데 `resume`이 `awaiting_human`을 돌려주면 1번부터 다시 한다.
 
 ### 종료 조건
 
-| 조건 | 트리거 |
-|------|--------|
-| `success` | score ≥ 0.85 AND goalAlignment ≥ 0.80 |
-| `stagnation` | 2회 연속 delta < 0.05 |
-| `oscillation` | 2회 연속 점수 역전 |
-| `hard_cap` | structural 3회 + contextual 3회 실패 |
-| `caller` | `{ action: "evolve", terminateReason: "caller" }` |
-| `human_escalation` | 4개 lateral persona 소진 |
+| 조건               | 트리거                                                        |
+| ------------------ | ------------------------------------------------------------- |
+| `success`          | score ≥ 0.85 AND goalAlignment ≥ 0.80                         |
+| `stagnation`       | 2회 연속 delta < 0.05                                         |
+| `oscillation`      | 2회 연속 점수 역전                                            |
+| `hard_cap`         | structural 3회 + contextual 3회 실패                          |
+| `caller`           | `{ action: "evolve", terminateReason: "caller" }`             |
+| `human_escalation` | 4개 lateral persona 소진 후 사람이 `restart`나 `abort`를 고름 |
 
 ---
 
@@ -551,7 +702,13 @@ activeForm: "실행 계획 수립 중"
 `TaskUpdate`로 현재 Planning 단계를 업데이트한다.
 
 ```
-description: "Planning 중 | 단계 {stepsCompleted}/4 | {currentPrinciple}"
+description: "Planning 중 | 단계 {stepsCompleted}/4 | {executeContext.currentStage}"
+```
+
+`plan_rewound`를 받으면 `stepsCompleted`가 없으므로 이렇게 바꾼다.
+
+```
+description: "Planning 되감김 | 단계 {rewoundToStep - 1}/4 | {executeContext.currentStage}"
 ```
 
 ### Execution 시작 후 (`execute_start` 응답 수신 후)
@@ -584,12 +741,14 @@ activeForm: "병렬 실행 중: 그룹 {groupIndex}/{totalGroups} — {agentCoun
 `TaskUpdate`로 진행 상황과 현재 실행 태스크명을 업데이트한다.
 
 순차 실행 중:
+
 ```
 description: "{completedCount}/{totalTasks} 완료 | 실패: {failedCount}개 | 그룹 {groupIndex}/{totalGroups}"
 activeForm: "실행 중: {taskContext.currentTask.title}"
 ```
 
 병렬 그룹 실행 중 (각 Agent의 execute_task 완료 시):
+
 ```
 description: "{completedCount}/{totalTasks} 완료 | 실패: {failedCount}개 | 그룹 {groupIndex}/{totalGroups}"
 activeForm: "병렬 실행 중: 그룹 {groupIndex}/{totalGroups} — {agentCount}개 Agent 실행 중"
@@ -609,6 +768,14 @@ activeForm: "병렬 실행 중: 그룹 {groupIndex}/{totalGroups} — {agentCoun
 - 평가 완료(success): `TaskUpdate({ status: "completed", description: "완료 | score: {overallScore} | alignment: {goalAlignment}" })`
 - Evolve 진입: description에 "개선 중 (generation {N})" 추가
 
+### 사람 판단 대기 시 (`awaiting_human`)
+
+```
+description: "사람 판단 대기 | 최고 점수: {gate.context.bestScore}"
+```
+
+`gate_resolve`가 `gate_resolved`를 돌려주면 진화 단계 표시로 돌아간다.
+
 ### 오류/에스컬레이션 시
 
 ```

package/dist/plugin/skills/interview/SKILL.md

@@ -128,7 +128,15 @@ The interview only has value if the human's actual intent is captured. A self-an
 1. **Start**: Create a session, detect project type (greenfield/brownfield), ask the first question
 2. **Iterate**: Present each generated question to the user → wait for answer → submit answer to Gestalt
 3. **Score**: Continuously assess resolution across multiple dimensions
-4. **Complete**: When resolution score ≥ 0.8, the interview is ready for spec generation
+4. **Complete**: Call `complete` only after `resolutionScore.isReady === true` (overall ≥ 0.8). The server rejects `complete` on a session that has no score or is below threshold
+
+### 0.8 미만에서 끝내기
+
+사용자가 0.8 미만에서 넘어가겠다고 직접 답한 경우에만 `force: true`로 `complete`를 부른다. 15라운드를 다 채워 `respond`가 더 받지 않으면 그 마지막 답의 점수는 반영되지 않은 상태다. 먼저 `score`로 그 점수를 넣고 `isReady`를 확인한다. 그래도 0.8 미만이면 에이전트가 현재 점수와 덜 채워진 차원을 보여주고 넘어갈지 묻는다. 라운드 수만으로 `force`를 넘기지 않는다. 사용자가 먼저 "그냥 넘어가자"고 했을 때도 같은 내용을 보여주고 한 번 더 확인한 뒤에 부른다.
+
+사용자가 넘어가지 않겠다고 하면 세션을 `in_progress`로 둔다. 15라운드 전이면 같은 세션에서 덜 채워진 차원을 다시 묻는다. 15라운드를 다 채웠으면 덜 채워진 차원을 사용자와 함께 정리해 새 인터뷰로 이어가거나 거기서 멈춘다.
+
+에이전트가 스스로 `force`를 판단하지 않는다. 거절 메시지에 "force=true로 넘기세요"가 나와도 그건 사용자에게 물어볼 근거이지 바로 넘길 근거가 아니다. 이렇게 끝낸 세션에는 `forcedComplete`가 기록된다. Spec을 뽑을 때도 `ges_generate_spec`에 `force`를 따로 넘겨야 한다.
 
 ## Gestalt Principles Applied
 
@@ -154,9 +162,12 @@ API 키 없이 MCP 서버 실행 시 자동 활성화. LLM 작업을 caller가
 | `resolutionScore.priorityClarity` | number (0-1) | 필수* | 우선순위 명확도 |
 | `resolutionScore.contextClarity` | number (0-1) | 선택 | 컨텍스트 명확도 |
 | `resolutionScore.contradictions` | string[] | 선택 | 발견된 모순 목록 |
+| `force` | boolean | 선택 (기본 `false`) | `complete` 전용. 0.8 미만이어도 완료한다. 사용자가 직접 정했을 때만 넘긴다 |
 
 \* resolutionScore 객체를 제공할 경우 필수
 
+답변 라운드가 0인 세션에 기준을 넘는 resolutionScore를 넣으면 `score`와 `respond`가 거절한다. 공백만 보낸 답은 답변으로 세지 않는다. 기준 미만 점수는 받는다.
+
 ### Action별 응답 구조 (Passthrough)
 
 **`start`** → `{ status, sessionId, projectType, detectedFiles, gestaltContext, roundNumber, message }`
@@ -166,7 +177,9 @@ API 키 없이 MCP 서버 실행 시 자동 활성화. LLM 작업을 caller가
 **`score`** (점수 미제공 시) → `{ status, resolutionScore, scoringPrompt, message }`
 **`score`** (점수 제공 시) → `{ status, resolutionScore }`
 
-**`complete`** → `{ status, sessionId, totalRounds, finalResolutionScore, message }`
+**`complete`** → `{ status, sessionId, totalRounds, finalResolutionScore, forced, message }`
+
+`forced`는 기준 미만 세션을 `force`로 끝냈을 때만 `true`다. 이미 준비된 세션에 `force`를 넘겨도 `false`로 남는다.
 
 ### GestaltContext 필드