makdoong2-team 2.2.0 → 2.3.1

package/agents/makdoong2-planner.md

@@ -245,7 +245,9 @@ bash <SCRIPTS_DIR>/state.sh set {ISSUE_KEY} '.stages."1_planning".substages."sco
 - 범주 하향(major→minor) — escalation만 허용.
 - 다음 phase 작업(dev/test) 선행.
 - **outer-world 에이전트(Sisyphus / Explore / Librarian / oh-my-openagent 계열 카테고리 등) 위임 금지.** 본 에이전트에는 `Task` 툴이 프론트매터에서 제거되어 있어 물리적으로 스폰 불가. 조사가 필요하면 반드시 `skill_mcp` 로 `jira-research` / `confluence-research` / `bitbucket-research` / `github-oss-research` 스킬만 사용. 이는 planning phase가 makdoong2 서브에이전트 체계 내에서 봉인되어야 한다는 아키텍처 원칙이다.
-- **bash를 통한 파일 쓰기 리디렉션 일체 금지 (READ-ONLY 원칙).** 예외: `<SCRIPTS_DIR>/state.sh set ...` 을 통한 state.json 마커 기록만 허용.
+- **bash를 통한 파일 쓰기 리디렉션 일체 금지 (READ-ONLY 원칙).** 예외 2가지:
+  - `<SCRIPTS_DIR>/state.sh set ...` 을 통한 state.json 마커 기록.
+  - **planning 산출물(`.makdoong2-team/<이슈키>/` 아래 `*.md`·`*.json` — `requirements-draft.md` 등)은 `write` 툴로 직접 생성·갱신한다.** 이것은 READ-ONLY 위반이 아니라 stage spec(02-requirements.md §2-0b)이 부과한 **의무**이며, 훅도 이 경로의 `write` 를 명시적으로 허용한다. 단 같은 경로라도 bash 리디렉션·`apply_patch` 는 차단되므로 반드시 `write` 툴을 쓴다.
   - **금지 패턴**: `echo >`, `cat > file`, `cat <<EOF > file`, `tee file`, `sed -i`, `awk ... > file`, `printf > file`, `> file`, `>> file`, `python -c "... open(..., 'w') ..."`, `node -e "... fs.writeFileSync(...) ..."`
   - **위반 예시**:
     ```bash
@@ -264,5 +266,7 @@ bash <SCRIPTS_DIR>/state.sh set {ISSUE_KEY} '.stages."1_planning".substages."sco
     # ✅ 허용: state.json 마커 기록 (state.sh 경유)
     bash <SCRIPTS_DIR>/state.sh set PROJ-123 '.stages."1_planning".substages."scope".done' 'true'
     ```
-  - **위반 결과**: verifier가 `git status`로 untracked 파일 감지 → REJECTED 판정 → 워크플로우 중단
-  - **올바른 절차**: 초안 파일 생성이 필요하면 spec을 team-leader에게 반환하여 dev 단계로 위임한다. Planning 단계는 "무엇을 만들지"만 결정하고, "실제로 만드는 것"은 implementation 단계의 책임이다.
+  - **위반 결과**: 훅이 bash 쓰기·`apply_patch` 를 차단하고, 우회에 성공하더라도 verifier가 `git status`로 untracked 파일 감지 → REJECTED 판정 → 워크플로우 중단
+  - **올바른 절차**:
+    - **planning 산출물(요구사항 초안 등 `.makdoong2-team/<이슈키>/*.md|json`)은 본인이 `write` 툴로 직접 생성한다.** team-leader 반환·dev 위임 대상이 아니다 — 그 시점 파이프라인에는 초안을 대신 만들 역할이 없어 워크플로가 정지한다 (issue #8).
+    - **소스 코드** 파일 생성·변경이 필요하면 spec을 team-leader에게 반환하여 dev 단계로 위임한다. Planning 단계는 "무엇을 만들지"만 결정하고, "실제로 만드는 것"은 implementation 단계의 책임이다.

package/agents/makdoong2-team-leader.md

@@ -98,6 +98,28 @@ permission:
 
 `MAX_ATTEMPTS` 는 dispatch_stage **호출 1회 내부**의 예산이므로 재호출하면 리셋된다. `hang_history` 누적 상한은 그 리셋을 무력화하기 위한 **호출 간(cross-call) 차단막**이며, 부장님이 우회하면 무한 루프가 된다.
 
+## 서브에이전트 능력을 frontmatter `tools:` 목록으로 판정하지 말 것 (hardrule)
+
+에이전트 정의 파일의 frontmatter `tools:` 는 **whitelist 가 아니다** — 목록에 없는 툴도 permission 설정이 허용하면 실행된다. 실제로 planner frontmatter 에 `Write` 가 없다는 이유로 "planner 는 구조적으로 파일 생성이 불가능하다" 고 단정하고 워크플로를 중단시킨 오진단이 있었다 — 로그상 planner 는 `write` 를 정상 실행해 왔고 차단 이력이 0건이었다 (GitHub issue #8). 서브에이전트가 파일을 못 만들었다면 원인은 **훅 차단 메시지·permission 프롬프트 대기(PERMISSION_STALL)·프롬프트 지시** 중에 있다. frontmatter 를 근거로 사용자에게 에이전트 정의 수정을 요구하지 말고, 실패한 세션의 실제 차단 로그를 근거로 판단하라.
+
+## verdict 는 셋이다 — REJECTED 와 ERROR 를 절대 섞지 말 것 (hardrule)
+
+`dispatch_verifier` 의 `verdict` 는 `VERIFIED` / `REJECTED` / `ERROR` 세 값이다.
+
+| verdict | 뜻 | 올바른 조치 |
+|---|---|---|
+| `VERIFIED` | 검증했고 통과 | 다음 substage 로 진행 |
+| `REJECTED` | 검증했고 **산출물을 반려** | `.done=false` 로 되돌리고 `dispatch_stage` 재호출 |
+| `ERROR` | **검증이 수행되지 않음** (verifier 세션 인프라 실패) | **`dispatch_verifier` 만 재호출.** stage 재실행 금지 |
+
+`ERROR` 에서 stage 를 재실행하면 **아무 문제 없는 작업을 통째로 다시 시킨다.** 실제로 마커가 전부 정상이던 `1_planning.jira` 가 planner 200초 재가동으로 이어졌고, 재검증 결과는 `VERIFIED` 였다 — 원 작업에는 처음부터 결함이 없었다 (GitHub issue #7).
+
+판정 근거는 `verdict_source` 에, 조치는 `next_action` 에 실려 온다. **`next_action` 을 그대로 따른다** (하드룰 4). `raw` / `parsed` 의 문구를 보고 스스로 해석하지 않는다 — 그 오판이 이 사고의 직접 원인이었다.
+
+- `retryable: true` 는 "같은 인자로 verifier 만 다시 부르면 된다" 는 뜻이다. stage 재실행 신호가 **아니다**.
+- `counts_as_rejection: false` 인 판정은 `rejected_count` / `same_reason_streak` 에 집계되지 않는다.
+- ERROR 는 자체 연속 상한을 갖는다: `verifier_error_streak_exceeded: true` (3회 연속) 이면 재호출을 멈추고 사용자에게 보고한다.
+
 ## REJECTED 재시도 정책 (신규)
 
 `dispatch_verifier` 가 `verdict: "REJECTED"` 를 반환하면 다음 규약을 따른다:
@@ -111,7 +133,18 @@ permission:
 
 ```
 verdict = dispatch_verifier(issue, target_stage, worktree, result.output)
-if verdict.verdict == "REJECTED":
+if verdict.verdict == "ERROR":
+    # 검증이 수행되지 않았다 (인프라 실패). stage 산출물은 멀쩡하다.
+    # state.json 은 건드리지 않는다 — last_verdict_reason 도 기록되지 않았다.
+    if verdict.verifier_error_streak_exceeded == True:
+        # 3회 연속 판정 실패 — 모델·인프라 문제. 자동 재시도로 풀리지 않는다.
+        [사용자에게 verdict.verdict_source + verdict.verifier_error_streak 보고]
+        [세션 종료 후 사용자 결정 대기]
+    else:
+        # verifier 는 idempotent — 같은 인자로 그대로 재호출한다.
+        # .done 을 false 로 되돌리지 않는다. dispatch_stage 를 부르지 않는다.
+        [dispatch_verifier(issue, target_stage, worktree, result.output) 재호출]
+elif verdict.verdict == "REJECTED":
     # (자동) dispatch_verifier 가 state.json 에 사유 기록 완료
     if verdict.same_reason_streak_exceeded == True:
         # 동일 사유 5회 연속 — 무한루프 의심. 사용자 개입 필요.
@@ -214,6 +247,16 @@ loop (max_substage_retries=3 per substage):
   # 2차 검증 (Verifier)
   verdict = dispatch_verifier(issue, next.target_stage, worktree, result.output)
 
+  if verdict.verdict == "ERROR":
+    # 검증 미수행 (인프라 실패). verdict.next_action 이 지시하는 그대로 따른다.
+    # stage 재실행 금지 — 산출물에는 아무 문제가 없다.
+    if verdict.verifier_error_streak_exceeded == true:
+      [verdict.verdict_source + verdict.verifier_error_streak 사용자 보고]
+      [세션 종료 후 사용자 결정 대기]
+      continue
+    [dispatch_verifier 재호출 — 같은 인자, state.json 변경 없음]
+    continue
+
   if verdict.verdict == "REJECTED":
     # dispatch_verifier 가 state.json 에 verdict.raw / hash / streak 자동 기록 완료
     # dispatch_stage 재호출 시 last_verdict_reason 이 자동으로 프롬프트에 주입됨.
@@ -246,6 +289,8 @@ loop (max_substage_retries=3 per substage):
 - 모델 폴백 시: `[fallback] <agent>: <primary> → <fallback> (reason: ...)`
 - `retry_disallowed` 감지 시: `[substage X RETRY DISALLOWED] outcome=timeout, transient_failures=0 — sub-agent hang. <retry_disallowed_reason>`
 - `session_gone` 최종 실패 시: `[substage X SESSION_GONE gone_reason=<message_stall|status_absent>] dispatch_stage 3회 자동 redispatch 후 실패. attempts=<N>, previous_session_ids=[...]`
+- verifier ERROR 시: `[substage X VERIFIER ERROR source=<verdict_source>] 검증 미수행 — verifier 만 재호출 (streak=<N>/3). stage 는 건드리지 않음`
+- verifier ERROR streak 초과 시: `[substage X VERIFIER ERROR STREAK EXCEEDED] 판정 3회 연속 실패. source=<verdict_source>. 사용자 개입 필요.`
 - REJECTED 재시도 시: `[substage X REJECTED retry] streak=<N>, reason_prefix="<40자>" → dispatch_stage 재호출`
 - REJECTED streak 5회 초과 시: `[substage X REJECTED STREAK EXCEEDED] 동일 사유 <streak>회 연속 실패. verdict.raw:\n<verdict.raw 전문>\n\n사용자 개입 필요.`
 - HITL opt-in 커밋 게이트 시: `[3_delivery.commit HUMAN GATE] auto_approve=false — 변경 보고서 작성, 사용자 승인 대기` (기본 흐름에서는 발생하지 않음)

package/agents/makdoong2-verifier.md

@@ -37,7 +37,7 @@ bash 명령은 **실행 후 결과로 판단**한다. 실행 전 permission 을
 <verifier-verdict>REJECTED</verifier-verdict>
 ```
 
-이 태그 없이 종료 시 `dispatch_verifier` 는 `source=session_failed_default` 로 자동 REJECTED 처리하여 team-leader 재작업 loop 를 트리거한다. **작업이 성공적으로 완료되었더라도 태그를 잊으면 REJECTED 로 확정된다.**
+정상 종료했는데 이 태그가 없으면 `dispatch_verifier` 는 `source=malformed_output_default` 로 **REJECTED 를 확정**하고 team-leader 재작업 loop 를 트리거한다. **검증 결과가 통과였더라도 태그를 잊으면 REJECTED 다.** (세션이 아예 죽어 판정 자체를 못 낸 경우는 `source=session_failed_default` / `session_gone_default` 로 `verdict: "ERROR"` 가 되며, 이때 team-leader 는 stage 를 재실행하지 않고 verifier 만 재호출한다 — 그 경로는 이 에이전트가 제어할 수 없다.)
 
 ### 종료 직전 필수 자기 점검 (매 turn 마다)
 

package/bin/cli.js

@@ -20,7 +20,7 @@ import { fileURLToPath } from "node:url";
 import { dirname, join, resolve } from "node:path";
 import { execFileSync } from "node:child_process";
 import { buildPoliciesFromConfig, DEFAULT_ALLOWED_PRIMARIES, } from "../scripts/model-policy.mjs";
-import { install, uninstall, resolveConfigDir, parseJsonc, readCachedVersion, opencodeCacheRoot, } from "../scripts/install-lib.mjs";
+import { install, uninstall, resolveConfigDir, parseJsonc, readCachedVersion, opencodeCacheRoot, computeExternalDirPaths, } from "../scripts/install-lib.mjs";
 const HERE = dirname(fileURLToPath(import.meta.url));
 const PKG_ROOT = resolve(HERE, "..");
 const PKG = JSON.parse(readFileSync(join(PKG_ROOT, "package.json"), "utf8"));
@@ -135,7 +135,14 @@ function doDoctor(flags) {
         check(existsSync(join(PKG_ROOT, d)), `${d}/ in package`, `${d}/ missing in package (reinstall: npm install -g makdoong2-team)`);
     }
     const ocPath = join(DEST, "opencode.json");
-    let pluginOk = false, toolsOk = false, ocParseOk = false, ocParseErr = "";
+    // 설치가 심도록 설계된 external_directory 시드. 에이전트 프롬프트가 서브에이전트
+    // 세션에 워크스페이스 외부 경로(<pkgRoot>/stages/*.md 등) 읽기를 지시하므로,
+    // 이 allow 가 없으면 서브에이전트가 응답 불가한 권한 프롬프트에 걸려
+    // PERMISSION_STALL 로 중단된다 (issue #8). 파일 배포만 성공하고 opencode.json
+    // 패치가 남지 않은 부분 설치를 doctor 가 잡아야 한다.
+    const requiredExtDirPaths = computeExternalDirPaths(PKG_ROOT, DEST);
+    let pluginOk = false, toolsOk = false, extDirOk = false, ocParseOk = false, ocParseErr = "";
+    let extDirMissing = requiredExtDirPaths;
     if (existsSync(ocPath)) {
         try {
             const oc = parseJsonc(readFileSync(ocPath, "utf8"));
@@ -155,14 +162,20 @@ function doDoctor(flags) {
             });
             const ocTools = oc.tools;
             toolsOk = !!ocTools && TOOLS.every((t) => ocTools[t] === true);
+            const extDir = oc.permission?.external_directory;
+            extDirMissing = requiredExtDirPaths.filter((p) => !extDir || typeof extDir !== "object" || extDir[p] !== "allow");
+            extDirOk = extDirMissing.length === 0;
         }
         catch (e) {
             ocParseErr = e instanceof Error ? e.message : String(e);
         }
     }
     check(!existsSync(ocPath) || ocParseOk, "opencode.json parses (JSONC tolerated)", `opencode.json is unparseable — install silently skips patching it: ${ocParseErr}`);
-    check(pluginOk, "opencode.json registers the plugin", "opencode.json missing the plugin entry");
-    check(toolsOk, "opencode.json enables custom tools", "opencode.json missing custom tools");
+    check(pluginOk, "opencode.json registers the plugin", "opencode.json missing the plugin entry (run: npx makdoong2-team install)");
+    check(toolsOk, "opencode.json enables custom tools", "opencode.json missing custom tools (run: npx makdoong2-team install)");
+    check(extDirOk, "opencode.json allows external_directory (pkgRoot + configDir)", `opencode.json missing permission.external_directory allow(s): ${extDirMissing.join(", ")} ` +
+        `— sub-agents will hit unanswerable permission prompts and abort with PERMISSION_STALL ` +
+        `(run: npx makdoong2-team install)`);
     // The plugin opencode actually loads lives in the `<name>@latest` cache dir,
     // not in the globally installed npm module. When those drift the user runs
     // old code while `npm ls -g` reports the new version — invisible without

package/bin/cli.ts

@@ -33,6 +33,7 @@ import {
   parseJsonc,
   readCachedVersion,
   opencodeCacheRoot,
+  computeExternalDirPaths,
 } from "../scripts/install-lib.mts";
 
 const HERE = dirname(fileURLToPath(import.meta.url));
@@ -150,7 +151,14 @@ function doDoctor(flags: Flags): never {
    }
 
     const ocPath = join(DEST, "opencode.json");
-    let pluginOk = false, toolsOk = false, ocParseOk = false, ocParseErr = "";
+    // 설치가 심도록 설계된 external_directory 시드. 에이전트 프롬프트가 서브에이전트
+    // 세션에 워크스페이스 외부 경로(<pkgRoot>/stages/*.md 등) 읽기를 지시하므로,
+    // 이 allow 가 없으면 서브에이전트가 응답 불가한 권한 프롬프트에 걸려
+    // PERMISSION_STALL 로 중단된다 (issue #8). 파일 배포만 성공하고 opencode.json
+    // 패치가 남지 않은 부분 설치를 doctor 가 잡아야 한다.
+    const requiredExtDirPaths = computeExternalDirPaths(PKG_ROOT, DEST);
+    let pluginOk = false, toolsOk = false, extDirOk = false, ocParseOk = false, ocParseErr = "";
+    let extDirMissing: string[] = requiredExtDirPaths;
     if (existsSync(ocPath)) {
       try {
         const oc = parseJsonc(readFileSync(ocPath, "utf8"));
@@ -168,12 +176,23 @@ function doDoctor(flags: Flags): never {
         });
         const ocTools = oc.tools;
         toolsOk = !!ocTools && TOOLS.every((t) => ocTools[t] === true);
+        const extDir = oc.permission?.external_directory;
+        extDirMissing = requiredExtDirPaths.filter(
+          (p: string) => !extDir || typeof extDir !== "object" || extDir[p] !== "allow",
+        );
+        extDirOk = extDirMissing.length === 0;
       } catch (e) { ocParseErr = e instanceof Error ? e.message : String(e); }
     }
    check(!existsSync(ocPath) || ocParseOk, "opencode.json parses (JSONC tolerated)",
          `opencode.json is unparseable — install silently skips patching it: ${ocParseErr}`);
-   check(pluginOk, "opencode.json registers the plugin", "opencode.json missing the plugin entry");
-   check(toolsOk, "opencode.json enables custom tools", "opencode.json missing custom tools");
+   check(pluginOk, "opencode.json registers the plugin",
+         "opencode.json missing the plugin entry (run: npx makdoong2-team install)");
+   check(toolsOk, "opencode.json enables custom tools",
+         "opencode.json missing custom tools (run: npx makdoong2-team install)");
+   check(extDirOk, "opencode.json allows external_directory (pkgRoot + configDir)",
+         `opencode.json missing permission.external_directory allow(s): ${extDirMissing.join(", ")} ` +
+         `— sub-agents will hit unanswerable permission prompts and abort with PERMISSION_STALL ` +
+         `(run: npx makdoong2-team install)`);
 
    // The plugin opencode actually loads lives in the `<name>@latest` cache dir,
    // not in the globally installed npm module. When those drift the user runs

package/dist/opencode-plugin.js

@@ -22,6 +22,7 @@ import { basename as pathBasename, dirname as pathDirname, join, resolve as path
 import { tool } from "@opencode-ai/plugin";
 import { appendSessionIndex, findWorktreeRoot, lookupSessionFromIndex } from "./session-index.js";
 import { computeVerdictHash } from "./verdict-hash.js";
+import { classifyVerifierOutcome, nextVerifierErrorStreak, verifierErrorStreakExceeded, VERIFIER_ERROR_STREAK_LIMIT, } from "./verifier-verdict.js";
 import { nextModel, applyConfigOverrides, POLICIES } from "./model-fallback-policy.js";
 import { agentForStage, STAGE_SPEC_FILES } from "./agent-stage-config.js";
 import { shouldEscalateStall } from "./stall-escalation.js";
@@ -742,6 +743,11 @@ export const Makdoong2TeamPlugin = async ({ $, client, directory, worktree }) =>
             const last = sessionLastToolExecuteAt.get(sessionId);
             return typeof last === "number" && Date.now() - last < TOOL_EXECUTE_ALIVE_WINDOW_MS;
         },
+        // "지금 이 순간 툴이 실행 중인가" — before 훅에서 올리고 after 훅에서 내리는
+        // 활성 카운터 그대로다. isRecentlyActive 의 5분 창과 달리 순간값이라 완료
+        // 판정에 쓸 수 있다. 폴러가 읽는 메시지 스냅샷보다 항상 앞선다 (issue #7:
+        // tool.execute.before 발화 110ms 뒤의 폴이 tool part 를 아직 못 봤다).
+        isToolExecuting: () => (sessionActiveToolCount.get(sessionId) ?? 0) > 0,
     });
     // ── sessionID → agent 매핑. chat.params hook에서 채우고, tool.execute.before
     //    hook에서 조회한다. 이 매핑을 통해 hook input에 없는 agent 식별을 우회한다.
@@ -1157,9 +1163,12 @@ export const Makdoong2TeamPlugin = async ({ $, client, directory, worktree }) =>
                             `${filePath ? `"${filePath}" 에 ` : ""}쓸 수 없다.\n` +
                             (allowed === null
                                 ? `이 에이전트는 파일을 쓰지 않는다 — 조사 결과는 최종 응답 텍스트로 반환하라.\n`
-                                : `허용된 산출물은 .makdoong2-team/<이슈키>/ 아래의 지정된 파일 하나뿐이다 ` +
-                                    `(패턴: ${allowed.source}).\n`) +
-                            `코드 변경이 필요하면 그 사실을 산출물/응답에 적고 engineer 단계로 넘겨라.`);
+                                : `허용된 산출물은 .makdoong2-team/<이슈키>/ 아래의 지정된 파일뿐이다 ` +
+                                    `(패턴: ${allowed.source}).\n` +
+                                    `그 경로에는 지금 즉시 'write' 툴(filePath 인자)로 쓸 수 있다 — ` +
+                                    `bash 리디렉션·apply_patch 우회가 차단된 것이지 산출물 쓰기 자체가 금지된 것이 아니다. ` +
+                                    `산출물이 필요하면 포기하지 말고 write 툴로 재시도하라.\n`) +
+                            `소스 코드 변경이 필요하면 그 사실을 산출물/응답에 적고 engineer 단계로 넘겨라.`);
                     }
                 }
                 // ── Leader hardrule 1: 직접 파일 편집·생성 금지 (write/edit/patch/multiedit) ──
@@ -2020,11 +2029,29 @@ export const Makdoong2TeamPlugin = async ({ $, client, directory, worktree }) =>
                             }
                             promptPromise.catch(() => { });
                             if (success) {
-                                const resetPath = `${stageJqPath(args.target_stage)}.hang_history`;
-                                const resetR = await $ `bash ${SCRIPTS_DIR}/state.sh set ${args.issue} ${resetPath} ${"[]"}`
-                                    .cwd(args.worktree).quiet().nothrow();
-                                logger.debug(`[hang_history] reset issue=${args.issue} stage=${args.target_stage} ` +
-                                    `exit=${resetR.exitCode} — substage succeeded`);
+                                // hang_history 리셋 조건은 "dispatch 정상 반환" 이 아니라 "substage
+                                // 실제 완료(done=true)" 다. 종전에는 세션이 텍스트만 뱉고 done=false
+                                // 로 끝나도 리셋됐고, 재-dispatch 를 반복하는 동안 이력이 매번
+                                // 비워져 stall_escalate_threshold 가 사실상 도달 불가였다 (issue #8).
+                                // cwd 는 effectiveWorktree — 이 substage 의 다른 state.json 접근과
+                                // 같은 파일을 봐야 한다 (args.worktree 를 쓰면 교정 발동 시 갈린다).
+                                const resetDonePath = `${stageJqPath(args.target_stage)}.done`;
+                                const resetDoneR = await $ `bash ${SCRIPTS_DIR}/state.sh get ${args.issue} ${resetDonePath}`
+                                    .cwd(effectiveWorktree).quiet().nothrow();
+                                const resetDoneValue = resetDoneR.exitCode === 0
+                                    ? (resetDoneR.stdout?.toString().trim() ?? null)
+                                    : null;
+                                if (resetDoneValue === "true") {
+                                    const resetPath = `${stageJqPath(args.target_stage)}.hang_history`;
+                                    const resetR = await $ `bash ${SCRIPTS_DIR}/state.sh set ${args.issue} ${resetPath} ${"[]"}`
+                                        .cwd(effectiveWorktree).quiet().nothrow();
+                                    logger.debug(`[hang_history] reset issue=${args.issue} stage=${args.target_stage} ` +
+                                        `exit=${resetR.exitCode} — substage done=true`);
+                                }
+                                else {
+                                    logger.debug(`[hang_history] reset skipped issue=${args.issue} stage=${args.target_stage} ` +
+                                        `done=${resetDoneValue} — dispatch 는 정상 반환했지만 substage 미완료`);
+                                }
                             }
                             const retryDisallowed = finalOutcome.kind === "timeout" &&
                                 finalOutcome.transientFailures === 0;
@@ -2087,10 +2114,17 @@ export const Makdoong2TeamPlugin = async ({ $, client, directory, worktree }) =>
              * just reported done. Read-only sub-agent reads state.json self_check markers,
              * the stage spec, and the dispatcher's output, and emits a structured verdict
              * of `<verifier-verdict>VERIFIED</verifier-verdict>` or `REJECTED`.
+             *
+             * 반환 verdict 는 셋이다. `ERROR` 는 "검증이 수행되지 않았다"(세션 인프라
+             * 실패)로, 콘텐츠 반려인 `REJECTED` 와 조치가 정반대다 — 전자는 verifier 만
+             * 재호출, 후자는 stage 재실행. 판정 근거는 `verdict_source`, 지시는
+             * `next_action` 이 싣는다 (src/verifier-verdict.ts).
              */
             dispatch_verifier: tool({
                 description: "Spawn the makdoong2-verifier sub-agent to second-check a stage's completion. " +
-                    "Returns { ok, verdict: 'VERIFIED' | 'REJECTED', raw, session_id }.",
+                    "Returns { ok, verdict: 'VERIFIED' | 'REJECTED' | 'ERROR', verdict_source, retryable, " +
+                    "next_action, raw, session_id }. verdict='ERROR' means the verifier session failed " +
+                    "before producing a verdict — re-run dispatch_verifier only; do NOT re-run the stage.",
                 args: {
                     issue: tool.schema.string().describe("Jira issue key, e.g. PROJ-12345"),
                     stage: tool.schema.enum(STAGE_ORDER),
@@ -2224,8 +2258,8 @@ export const Makdoong2TeamPlugin = async ({ $, client, directory, worktree }) =>
                                 ? " (message_stall detected)"
                                 : "";
                             logger.warn(`[dispatch_verifier] SESSION_GONE session=${subSessionID} stage=${args.stage}` +
-                                `${stallReason} — defaulting to REJECTED verdict, no retry ` +
-                                `(verifier is idempotent, team-leader can redispatch)`);
+                                `${stallReason} — verdict=ERROR (판정 없음), no retry ` +
+                                `(verifier is idempotent, team-leader can redispatch the verifier alone)`);
                             const vHangEntry = JSON.stringify({
                                 attempt: 1,
                                 at: new Date().toISOString(),
@@ -2268,30 +2302,48 @@ export const Makdoong2TeamPlugin = async ({ $, client, directory, worktree }) =>
                             skipSessionOps: verifierSessionGone,
                         });
                     }
-                    const m = raw.match(/<verifier-verdict>\s*(VERIFIED|REJECTED)\s*<\/verifier-verdict>/i);
-                    const jsonFallback = !m ? raw.match(/"verdict"\s*:\s*"(VERIFIED|REJECTED)"/i) : null;
-                    const verdict = m
-                        ? m[1].toUpperCase()
-                        : jsonFallback
-                            ? jsonFallback[1].toUpperCase()
-                            : "REJECTED";
-                    const verdictSource = verifierSessionGone
-                        ? "session_gone_default"
-                        : m
-                            ? "verdict_tag"
-                            : jsonFallback
-                                ? "json_fallback"
-                                : success
-                                    ? "malformed_output_default"
-                                    : "session_failed_default";
+                    const classification = classifyVerifierOutcome({
+                        raw,
+                        success,
+                        sessionGone: verifierSessionGone,
+                    });
+                    const verdict = classification.verdict;
+                    const verdictSource = classification.source;
                     logger.debug(`[dispatch_verifier] VERDICT ${verdict} — issue=${args.issue} stage=${args.stage} ` +
-                        `session=${subSessionID} source=${verdictSource} success=${success}`);
+                        `session=${subSessionID} source=${verdictSource} success=${success} ` +
+                        `retryable=${classification.retryable} counts_as_rejection=${classification.countsAsRejection}`);
                     const stageBase = stageJqPath(args.stage);
                     let sameReasonStreak = 0;
                     let sameReasonStreakExceeded = false;
                     let rejectedCount = 0;
+                    let verifierErrorStreak = 0;
+                    let verifierErrorStreakHit = false;
                     const SAME_REASON_STREAK_LIMIT = 5;
-                    if (verdict === "REJECTED") {
+                    if (verdict === "ERROR") {
+                        // 검증이 **수행되지 않았다**. 반려 집계에 넣지 않는다.
+                        //
+                        // 여기서 REJECTED 로 집계하면 stage 산출물에 아무 문제가 없는데도
+                        // `rejected_count` 가 오르고 `last_verdict_reason` 에 "verifier session
+                        // failed" 가 박힌다. team-leader 는 그것을 반려로 읽고 stage 를 통째로
+                        // 재실행한다 — 실제로 마커가 전부 정상인 1_planning.jira 가 planner
+                        // 200초 재가동으로 이어졌고 재검증은 VERIFIED 였다 (issue #7).
+                        //
+                        // 대신 ERROR 전용 연속 카운터로 무한 재호출만 막는다.
+                        const prevErrR = await $ `bash ${SCRIPTS_DIR}/state.sh get ${args.issue} ${stageBase + ".verifier_error_streak"}`
+                            .cwd(args.worktree).quiet().nothrow();
+                        const prevErr = prevErrR.exitCode === 0
+                            ? (parseInt(prevErrR.stdout?.toString().trim() || "0", 10) || 0)
+                            : 0;
+                        verifierErrorStreak = nextVerifierErrorStreak(prevErr, classification);
+                        verifierErrorStreakHit = verifierErrorStreakExceeded(verifierErrorStreak);
+                        await $ `bash ${SCRIPTS_DIR}/state.sh set ${args.issue} ${stageBase + ".verifier_error_streak"} ${String(verifierErrorStreak)}`
+                            .cwd(args.worktree).quiet().nothrow();
+                        logger.warn(`[dispatch_verifier] VERIFIER_ERROR — issue=${args.issue} stage=${args.stage} ` +
+                            `source=${verdictSource} streak=${verifierErrorStreak}/${VERIFIER_ERROR_STREAK_LIMIT} ` +
+                            `— 판정 없음. verifier 재호출만이 올바른 조치다 (stage 재실행 금지)` +
+                            (verifierErrorStreakHit ? ` ERROR_STREAK_EXCEEDED` : ``));
+                    }
+                    else if (classification.countsAsRejection) {
                         const reasonText = raw.trim().slice(0, 4000);
                         const reasonHash = computeVerdictHash(raw, args.stage);
                         const prevHashR = await $ `bash ${SCRIPTS_DIR}/state.sh get ${args.issue} ${stageBase + ".last_verdict_reason_hash"}`
@@ -2336,11 +2388,25 @@ export const Makdoong2TeamPlugin = async ({ $, client, directory, worktree }) =>
                         await $ `bash ${SCRIPTS_DIR}/state.sh set ${args.issue} ${stageBase + ".same_reason_streak"} 0`
                             .cwd(args.worktree).quiet().nothrow();
                     }
+                    // 판정을 얻었으면(VERIFIED / REJECTED 무관) ERROR 연속 카운터는 리셋한다.
+                    // 인프라가 회복됐다는 뜻이므로 직전 실패를 계속 들고 갈 이유가 없다.
+                    if (verdict !== "ERROR") {
+                        await $ `bash ${SCRIPTS_DIR}/state.sh set ${args.issue} ${stageBase + ".verifier_error_streak"} 0`
+                            .cwd(args.worktree).quiet().nothrow();
+                    }
                     await $ `bash ${SCRIPTS_DIR}/log-event.sh ${args.issue} verifier_verdict stage=${args.stage} verdict=${verdict} session=${subSessionID}`
                         .cwd(args.worktree).quiet().nothrow();
                     return JSON.stringify({
                         ok: success,
                         verdict,
+                        // 종전에는 이 세 값이 없어서 호출자가 "왜 REJECTED 인지" 를 알 수 없었다.
+                        // verdictSource 는 이미 계산되어 로그에만 남고 있었다 (issue #7).
+                        verdict_source: verdictSource,
+                        // retryable=true 는 "같은 인자로 verifier 만 다시 부르면 된다" 는 뜻이다.
+                        // stage 재실행 신호가 아니다 — next_action 이 그 점을 못 박는다.
+                        retryable: classification.retryable,
+                        counts_as_rejection: classification.countsAsRejection,
+                        next_action: classification.nextAction,
                         stage: args.stage,
                         agent: verifierId,
                         model: modelFull,
@@ -2349,13 +2415,9 @@ export const Makdoong2TeamPlugin = async ({ $, client, directory, worktree }) =>
                         same_reason_streak: sameReasonStreak,
                         same_reason_streak_exceeded: sameReasonStreakExceeded,
                         rejected_count: rejectedCount,
-                        parsed: m
-                            ? "verdict tag found"
-                            : jsonFallback
-                                ? `verdict tag missing — extracted from JSON body (${jsonFallback[1]})`
-                                : success
-                                    ? "verdict tag missing — defaulted to REJECTED (verifier output malformed)"
-                                    : `verifier session failed (${raw.slice(0, 120)})`,
+                        verifier_error_streak: verifierErrorStreak,
+                        verifier_error_streak_exceeded: verifierErrorStreakHit,
+                        parsed: classification.parsed,
                     });
                 },
             }),

package/dist/poll-sub-session.d.ts

@@ -83,6 +83,7 @@ export type PollOutcome = {
     stalledMs: number;
     permissionID?: string;
     permissionType?: string;
+    permissionPatterns?: string[];
 } | {
     kind: "session_gone";
     polls: number;
@@ -106,6 +107,7 @@ export interface PollOptions {
     messageStallThresholdMs?: number;
     statusAbsentGraceMs?: number;
     isRecentlyActive?: () => boolean;
+    isToolExecuting?: () => boolean;
     contentStableCompletionMs?: number;
     preambleOnlyTextThreshold?: number;
     nudgeAtFraction?: number;

package/dist/poll-sub-session.js

@@ -123,6 +123,7 @@ export async function pollSubSession(client, sessionId, options = {}) {
     const contentStableCompletionMs = options.contentStableCompletionMs;
     const preambleOnlyTextThreshold = options.preambleOnlyTextThreshold;
     const isRecentlyActive = options.isRecentlyActive;
+    const isToolExecuting = options.isToolExecuting;
     const permissionCheckIntervalPolls = options.permissionCheckIntervalPolls ?? 5;
     let pollCount = 0;
     let transientFailures = 0;
@@ -133,6 +134,10 @@ export async function pollSubSession(client, sessionId, options = {}) {
     let lastAssistantSig = "";
     let nudged = false;
     let firstGoneObservedAt = null;
+    // finish 단독 완료 신호를 처음 관측한 폴의 content 시그니처. 같은 시그니처를
+    // 연속 두 폴에서 볼 때만 완료로 확정한다 (아래 finishOnlyCompletion 참조).
+    let finishConfirmSig = null;
+    let toolStallExemptLogged = false;
     dbg?.(`[pollSubSession] START session=${sessionId} timeoutMs=${timeoutMs}`);
     while (now() < deadline) {
         await sleep(pollIntervalMs);
@@ -227,6 +232,12 @@ export async function pollSubSession(client, sessionId, options = {}) {
             : Boolean(lastAssistant);
         const hasFinish = lastAssistant?.info?.finish != null;
         const hasPendingToolCall = !!lastAssistant?.parts?.some(isInFlightToolPart);
+        // 메시지 스냅샷(hasPendingToolCall)과 실시간 훅 신호(isToolExecuting)의 합집합.
+        // 둘 중 하나라도 "툴이 떠 있다" 고 하면 완료로 판정하지 않는다 — 스냅샷은
+        // 서버 반영이 늦고(issue #7), 훅 신호는 훅이 안 붙은 환경에서 아예 없다.
+        // OR 로 묶어야 각자의 사각지대를 서로 덮는다.
+        const toolExecuting = isToolExecuting?.() === true;
+        const toolInFlight = hasPendingToolCall || toolExecuting;
         const stalledMs = now() - lastProgressAt;
         // session_gone (status_absent) has two admission paths with different
         // strictness:
@@ -253,7 +264,7 @@ export async function pollSubSession(client, sessionId, options = {}) {
         // wall-clock semantics.
         const activeSignal = isRecentlyActive?.() === true;
         const goneAdmitted = !activeSignal &&
-            !hasPendingToolCall &&
+            !toolInFlight &&
             !messagesChanged &&
             !status &&
             (sessionEverAppeared || (sessionAliveByMessages && hasProducedAssistantMessage));
@@ -261,7 +272,7 @@ export async function pollSubSession(client, sessionId, options = {}) {
             if (firstGoneObservedAt === null) {
                 firstGoneObservedAt = now();
                 dbg?.(`[pollSubSession] GONE_ADMIT session=${sessionId} poll=${pollCount} ` +
-                    `sig="${currentAsstSig}" pending_tool=${hasPendingToolCall} ` +
+                    `sig="${currentAsstSig}" pending_tool=${hasPendingToolCall} tool_exec=${toolExecuting} ` +
                     `session_ever_appeared=${sessionEverAppeared} alive_by_msgs=${sessionAliveByMessages} ` +
                     `messages=${messages.length} grace_ms=${statusAbsentGraceMs} ` +
                     `— gone admission started; will fire in ${statusAbsentGraceMs}ms if condition persists`);
@@ -282,7 +293,7 @@ export async function pollSubSession(client, sessionId, options = {}) {
         else {
             if (firstGoneObservedAt !== null) {
                 dbg?.(`[pollSubSession] GONE_ADMIT_RESET session=${sessionId} poll=${pollCount} ` +
-                    `active_signal=${activeSignal} pending_tool=${hasPendingToolCall} ` +
+                    `active_signal=${activeSignal} pending_tool=${hasPendingToolCall} tool_exec=${toolExecuting} ` +
                     `messages_changed=${messagesChanged} status=${status?.type ?? "absent"} ` +
                     `— gone admission cleared before grace elapsed`);
             }
@@ -317,18 +328,57 @@ export async function pollSubSession(client, sessionId, options = {}) {
                         stalledMs,
                         permissionID: p.id,
                         permissionType: p.permission,
+                        permissionPatterns: p.patterns,
                     };
                 }
             }
         }
-        if (hasPendingToolCall && stalledMs >= toolCallStallThresholdMs) {
-            err(`[pollSubSession] PERMISSION_STALL session=${sessionId} polls=${pollCount} stalledMs=${stalledMs}`);
+        // Tool-call stall — "툴 호출이 떠 있는데 아무 진전이 없다".
+        //
+        // 이 휴리스틱이 잡으려는 것은 **서브에이전트 컨텍스트에서 답할 수 없는 권한
+        // 요청에 막힌** 툴 호출이다. 실행 자체가 오래 걸리는 툴(sbt·docker·gradle
+        // 빌드)은 대상이 아니다 — 그런데 둘은 `stalledMs` 만 보면 구분되지 않는다.
+        // tool part 의 state 변화는 시그니처(`id:partsLen:textLen`)를 바꾸지 않으므로
+        // 5분짜리 빌드도 "진전 없음" 으로 보이고, 기본 임계 60초에서 abort 된다.
+        // `hasPendingToolCall` 이 프로덕션에서 항상 false 였던 동안에는 이 경로가 한
+        // 번도 발화하지 않아 드러나지 않았고, 그 값을 고치는 순간 무장됐다.
+        //
+        // `isToolExecuting()` 이 그 둘을 가른다. before 훅이 발화하고 after 훅이 아직
+        // 안 돈 상태 = 툴이 실제로 **실행 중**이다. 이때는 죽이지 않는다. 진짜 권한
+        // 대기는 매 폴 도는 `permission.list()` 경로가 요청 ID·패턴까지 짚어 정확히
+        // 잡아내고, 그마저 실패해도 절대 타임아웃이 받쳐준다. 이 모듈의 위험 선호와
+        // 같은 방향이다 — 미탐(살아있는 세션을 죽임)이 오탐(타임아웃까지 기다림)보다
+        // 비싸다.
+        if (hasPendingToolCall && toolExecuting && stalledMs >= toolCallStallThresholdMs && !toolStallExemptLogged) {
+            toolStallExemptLogged = true;
+            dbg?.(`[pollSubSession] TOOL_STALL_EXEMPT session=${sessionId} poll=${pollCount} ` +
+                `stalled_ms=${stalledMs} threshold_ms=${toolCallStallThresholdMs} ` +
+                `— 툴이 실행 중이므로 permission_stall 로 판정하지 않는다`);
+        }
+        if (hasPendingToolCall && !toolExecuting && stalledMs >= toolCallStallThresholdMs) {
+            // abort 전에 대기 중인 permission 요청을 1회 조회해 어떤 카테고리·경로가
+            // 대기 중인지 abort 메시지에 남긴다 (issue #8 제안 2). 종전에는 폴러
+            // 로그만으로 대기 대상을 특정할 수 없어 원인 규명에 코드 독해가 필요했다.
+            // best-effort — client.permission 이 없거나(구버전 SDK) 조회가 실패해도
+            // 종전과 동일한 무정보 outcome 으로 진행한다.
+            let stalledPerm;
+            if (client.permission) {
+                const permResult = await client.permission.list().catch(() => null);
+                stalledPerm = (permResult?.data ?? []).find(p => p.sessionID === sessionId);
+            }
+            err(`[pollSubSession] PERMISSION_STALL session=${sessionId} polls=${pollCount} stalledMs=${stalledMs}` +
+                (stalledPerm
+                    ? ` pending permissionID=${stalledPerm.id} type=${stalledPerm.permission} patterns=${JSON.stringify(stalledPerm.patterns)}`
+                    : ` pending permission unknown (permission.list unavailable or empty)`));
             await client.session.abort({ path: { id: sessionId } }).catch(() => undefined);
             return {
                 kind: "permission_stall",
                 polls: pollCount,
                 elapsedMs: now() - startTime,
                 stalledMs,
+                permissionID: stalledPerm?.id,
+                permissionType: stalledPerm?.permission,
+                permissionPatterns: stalledPerm?.patterns,
             };
         }
         // Message stall: sub-agent registered (sessionEverAppeared) and appears
@@ -365,7 +415,7 @@ export async function pollSubSession(client, sessionId, options = {}) {
         if (messageStallThresholdMs !== undefined &&
             (sessionEverAppeared || sessionAliveByMessages) &&
             busyIndicated &&
-            !hasPendingToolCall &&
+            !toolInFlight &&
             stalledFromProgress >= messageStallThresholdMs) {
             const hangMode = lastAssistant ? "mid_stream" : "bootstrap";
             err(`[pollSubSession] MESSAGE_STALL session=${sessionId} polls=${pollCount} ` +
@@ -380,7 +430,7 @@ export async function pollSubSession(client, sessionId, options = {}) {
                 reason: "message_stall",
             };
         }
-        const finishComplete = hasFinish && !hasPendingToolCall && properOrdering;
+        const finishComplete = hasFinish && !toolInFlight && properOrdering;
         // INV-1: `!status` alone is not idle. Require `status.type === "idle"` AND
         // that we saw the session in the status map at least once (or that the
         // messages list already contains an assistant response).
@@ -393,12 +443,46 @@ export async function pollSubSession(client, sessionId, options = {}) {
         // statusIdle nor finishComplete ever fires (worktree-CWD, no finish field).
         const contentStable = contentStableCompletionMs !== undefined &&
             hasProducedAssistantMessage &&
-            !hasPendingToolCall &&
+            !toolInFlight &&
             stalledFromProgress >= contentStableCompletionMs;
-        const looksComplete = statusIdle || finishComplete || contentStable;
+        // finish 단독 완료는 한 폴 더 확인하고 결론낸다.
+        //
+        // `finish` 는 "이번 assistant 메시지의 생성이 끝났다" 는 뜻이지 "세션이 끝났다"
+        // 가 아니다. 모델이 tool call 로 턴을 마치면 그 순간 finish 가 붙고 곧바로 툴이
+        // 실행된다. 그 사이(관측 110ms)에 폴이 끼면 tool part 는 아직 안 보이고 finish
+        // 만 보여 **완료로 오판**한다 (issue #7). statusIdle(서버가 직접 idle 이라고
+        // 말함)이나 contentStable(5분 무변화)이 함께 서 있으면 그런 오판이 아니므로
+        // 즉시 결론내고, finish 뿐일 때만 한 폴(기본 2s) 뒤 재확인한다. 그 시점이면
+        // tool part 가 메시지에 반영돼 있거나 isToolExecuting 이 참이라 판정이 취소된다.
+        //
+        // 재확인의 기준은 **content 시그니처 동일**이다. 시그니처가 바뀌었다는 것은
+        // 이번 폴에서 내용이 움직였다는 뜻이고, 움직이는 중에는 결론내지 않는다.
+        // (관측된 오판 2건 모두 `contentStable=false` — 내용이 아직 안정되지 않은
+        // 상태에서 완료 판정이 내려졌다.)
+        //
+        // 비용은 finish 단독 경로에서 폴 1회다. worktree-CWD 세션(status map 이 CWD
+        // 필터링되어 statusIdle 이 영영 안 뜬다)이 이 경로를 상시로 타지만, substage
+        // 하나가 수 분인 것에 비하면 2초는 무시할 수 있다.
+        const finishOnlyCompletion = finishComplete && !statusIdle && !contentStable;
+        let deferredForConfirm = false;
+        if (finishOnlyCompletion) {
+            if (finishConfirmSig !== currentAsstSig) {
+                finishConfirmSig = currentAsstSig;
+                deferredForConfirm = true;
+            }
+        }
+        else {
+            finishConfirmSig = null;
+        }
+        const looksComplete = !deferredForConfirm && (statusIdle || finishComplete || contentStable);
         dbg?.(`[pollSubSession] POLL session=${sessionId} poll=${pollCount} status=${status?.type ?? "absent"} ` +
             `messages=${messages.length} finishComplete=${finishComplete} statusIdle=${statusIdle} ` +
-            `contentStable=${contentStable} sessionEverAppeared=${sessionEverAppeared}`);
+            `contentStable=${contentStable} sessionEverAppeared=${sessionEverAppeared} ` +
+            `pendingTool=${hasPendingToolCall} toolExec=${toolExecuting} deferredForConfirm=${deferredForConfirm}`);
+        if (deferredForConfirm) {
+            dbg?.(`[pollSubSession] FINISH_CONFIRM_PENDING session=${sessionId} poll=${pollCount} ` +
+                `sig="${currentAsstSig}" — finish 단독 완료 신호. 한 폴 뒤 재확인한다`);
+        }
         if (!nudged && options.nudgeAtFraction != null && options.onNudge) {
             const elapsedMs = now() - startTime;
             if (elapsedMs >= options.nudgeAtFraction * timeoutMs) {
@@ -440,13 +524,24 @@ export async function pollSubSession(client, sessionId, options = {}) {
             .filter(p => p.type === "text" && typeof p.text === "string" && p.text.length > 0)
             .map(p => p.text)
             .join("\n");
-        if (text.length > 0) {
+        // 공백만 있는 text part 는 "짧은 서두" 가 아니라 "아직 텍스트가 없음" 이다.
+        // 종전에는 `text.length > 0` 만 보고 preamble 분기에 들어갔고, trim 길이 0 은
+        // 임계 미만이라 그대로 preamble_only 로 확정됐다 — 로그의 `textLen=0` 이 바로
+        // 이 경로다 (issue #7). 스트리밍 초기 상태를 "서두만 쓰고 끝냈다" 로 읽는
+        // 것이라 오판의 방향이 정반대다. 정상 반환된 서브에이전트 출력들도 모두
+        // `\n\n` 으로 시작한다는 관측이 이 경로가 상시 노출돼 있었음을 말한다.
+        //
+        // 텍스트 없음으로 떨어뜨리면 dispatch_stage 는 "작업을 다시 하라" 는 action
+        // 재프롬프트 대신 요약 재프롬프트를 보내고, `.done=true` override 도 그대로
+        // 걸린다 — 이미 끝난 작업을 되풀이시키지 않는 쪽이다.
+        const trimmedLen = text.trim().length;
+        if (trimmedLen > 0) {
             if (preambleOnlyTextThreshold !== undefined &&
                 preambleOnlyTextThreshold > 0 &&
-                text.trim().length < preambleOnlyTextThreshold &&
-                !hasPendingToolCall) {
+                trimmedLen < preambleOnlyTextThreshold &&
+                !toolInFlight) {
                 dbg?.(`[pollSubSession] preamble-only detected session=${sessionId} ` +
-                    `textLen=${text.trim().length} threshold=${preambleOnlyTextThreshold} — ` +
+                    `textLen=${trimmedLen} threshold=${preambleOnlyTextThreshold} — ` +
                     `reclassifying text outcome as empty`);
                 return {
                     kind: "empty",
@@ -457,6 +552,16 @@ export async function pollSubSession(client, sessionId, options = {}) {
             }
             return { kind: "text", text, polls: pollCount, elapsedMs: now() - startTime };
         }
+        if (text.length > 0) {
+            dbg?.(`[pollSubSession] whitespace-only text session=${sessionId} raw_len=${text.length} — ` +
+                `텍스트 없음으로 처리 (preamble_only 아님)`);
+            return {
+                kind: "empty",
+                reason: "whitespace_only_text",
+                polls: pollCount,
+                elapsedMs: now() - startTime,
+            };
+        }
         return {
             kind: "empty",
             reason: "assistant message has no text parts",
@@ -499,8 +604,12 @@ export function pollOutcomeToLegacy(outcome) {
         case "permission_stall":
             return {
                 text: outcome.permissionType
-                    ? `(permission_stall: sub-agent blocked on ${outcome.permissionType} permission (id=${outcome.permissionID}) — auto-rejected and aborted)`
-                    : `(permission_stall: sub-agent tool call stalled for ${outcome.stalledMs}ms — likely waiting for external_directory permission approval that cannot be answered in subagent context)`,
+                    ? `(permission_stall: sub-agent blocked on ${outcome.permissionType} permission ` +
+                        `(id=${outcome.permissionID}${outcome.permissionPatterns ? `, patterns=${JSON.stringify(outcome.permissionPatterns)}` : ""}) ` +
+                        `— cannot be answered in subagent context; aborted after ${outcome.stalledMs}ms)`
+                    : `(permission_stall: sub-agent tool call stalled for ${outcome.stalledMs}ms — likely waiting for a permission approval ` +
+                        `that cannot be answered in subagent context; pending permission could not be identified (permission.list unavailable or empty). ` +
+                        `점검: opencode.json 의 permission.external_directory 시드 존재 여부 (npx makdoong2-team doctor))`,
                 success: false,
             };
         case "session_gone":

package/dist/verifier-verdict.d.ts

@@ -0,0 +1,62 @@
+/** verdict 가 어떤 경로로 정해졌는지. 종전에도 로그에는 이 값이 남고 있었다. */
+export type VerifierVerdictSource = 
+/** 응답에 `<verifier-verdict>` 태그가 있었다 — 유일하게 권위 있는 경로. */
+"verdict_tag"
+/** 태그는 없지만 본문 JSON 에 `"verdict"` 키가 있었다. */
+ | "json_fallback"
+/** 세션은 정상 종료했는데 판정을 못 읽었다 — verifier 출력 형식 위반. */
+ | "malformed_output_default"
+/** 세션이 실패했다 (abort / empty / timeout). 판정 자체가 없다. */
+ | "session_failed_default"
+/** 세션이 사라졌다 (status_absent / message_stall). 판정 자체가 없다. */
+ | "session_gone_default";
+/**
+ * `ERROR` 는 "검증이 수행되지 않았다" 는 제3의 값이다. `REJECTED`(반려)와
+ * 섞으면 안 된다 — 조치가 정반대다.
+ */
+export type VerifierVerdict = "VERIFIED" | "REJECTED" | "ERROR";
+export interface VerifierOutcomeInput {
+    /** verifier 세션의 최종 텍스트 (pollOutcomeToLegacy 의 text). */
+    raw: string;
+    /** pollOutcomeToLegacy 의 success — 세션이 텍스트를 산출했는가. */
+    success: boolean;
+    /** pollSubSession 이 session_gone 을 반환했는가. */
+    sessionGone: boolean;
+}
+export interface VerifierClassification {
+    verdict: VerifierVerdict;
+    source: VerifierVerdictSource;
+    /** true 면 같은 입력으로 verifier 를 다시 돌리는 것이 올바른 조치다. */
+    retryable: boolean;
+    /** true 일 때만 `rejected_count` / `same_reason_streak` 에 집계한다. */
+    countsAsRejection: boolean;
+    /** 사람이 읽는 한 줄 설명 (툴 반환값의 `parsed`). */
+    parsed: string;
+    /** 호출자가 그대로 따라야 할 조치. 애매하면 여기서 못을 박는다. */
+    nextAction: string;
+}
+/**
+ * verifier 세션 결과 → 판정 분류.
+ *
+ * 판정 태그는 세션 실패보다 우선한다: 태그를 이미 뱉은 뒤 세션 꼬리가 죽었다면
+ * 그 판정은 실제로 산출된 것이므로 존중한다.
+ *
+ * `malformed_output_default`(세션은 살아서 끝났는데 태그가 없음)는 `ERROR` 로
+ * 올리지 않고 종전대로 `REJECTED` 를 유지한다 — 형식 위반은 verifier 가 관측
+ * 가능한 콘텐츠 결함이고, `same_reason_streak` 이 이미 무한루프를 막는다.
+ * 여기서 완화 대상은 판정이 물리적으로 존재하지 않는 두 경로뿐이다.
+ */
+export declare function classifyVerifierOutcome(input: VerifierOutcomeInput): VerifierClassification;
+/**
+ * 인프라 실패로 판정을 못 얻은 횟수의 연속 상한.
+ *
+ * `same_reason_streak`(REJECTED 무한루프 차단)의 ERROR 판 대응물이다. ERROR 는
+ * 집계에서 빠지므로 그쪽 상한이 걸리지 않는다 — 별도 상한이 없으면 verifier 만
+ * 재호출하는 루프가 영원히 돈다. 3회로 잡은 것은 재호출이 저렴하고(단일 read-only
+ * 세션) 3회 연속 실패면 모델·인프라 문제라 자동 재시도로 풀리지 않기 때문이다.
+ */
+export declare const VERIFIER_ERROR_STREAK_LIMIT = 3;
+/** 이번 결과를 반영한 ERROR 연속 횟수. ERROR 가 아니면 0 으로 리셋된다. */
+export declare function nextVerifierErrorStreak(previousStreak: number, classification: Pick<VerifierClassification, "verdict">): number;
+/** 상한 도달 여부. 도달하면 team-leader 는 재호출을 멈추고 사용자에게 보고한다. */
+export declare function verifierErrorStreakExceeded(streak: number, limit?: number): boolean;

package/dist/verifier-verdict.js

@@ -0,0 +1,110 @@
+// verifier-verdict.ts — dispatch_verifier 응답의 순수 분류기.
+//
+// 왜 별도 파일인가: opencode 의 플러그인 로더는 `src/opencode-plugin.ts` 의
+// **모든 named export 를 plugin factory 로 호출**한다. 헬퍼를 거기에 export 하면
+// 로더가 그것을 팩토리로 부르고 downstream `for (S of hooks) { S.auth }` 에서
+// 터진다 (`test/plugin-exports-shape.test.ts` 가 export 집합을 고정한다).
+// 그래서 순수 로직은 항상 별도 모듈에 두고 import 한다.
+//
+// ── 무엇을 고치는가 ────────────────────────────────────────────────────────
+// 종전 dispatch_verifier 는 다섯 갈래의 결과를 `verdictSource` 로 **구분해 로그에
+// 남기면서도** 툴 반환값의 `verdict` 는 전부 `REJECTED` 하나로 눌러 내보냈다.
+// 그래서 호출자(team-leader)는 다음 둘을 구별할 수 없었다:
+//
+//   (가) 콘텐츠 반려 — verifier 가 실제로 검사하고 산출물을 물렸다.
+//        → 올바른 조치: `.done=false` 로 되돌리고 stage 를 재실행한다.
+//   (나) 인프라 실패 — verifier 세션이 판정을 내리지 못하고 죽었다.
+//        → 올바른 조치: **verifier 만 재실행한다.** stage 산출물은 멀쩡하다.
+//
+// 실제로 (나)가 (가)로 보고되어, 마커가 전부 정상인 `1_planning.jira` 를
+// team-leader 가 통째로 재실행했다 (planner 200초 재가동). 재검증 결과는
+// VERIFIED 였다 — 원 작업에는 처음부터 결함이 없었다 (GitHub issue #7).
+//
+// 구분에 필요한 정보는 이미 전부 있었다. 계약에 반영하지 않았을 뿐이다.
+const VERDICT_TAG_RE = /<verifier-verdict>\s*(VERIFIED|REJECTED)\s*<\/verifier-verdict>/i;
+const VERDICT_JSON_RE = /"verdict"\s*:\s*"(VERIFIED|REJECTED)"/i;
+const NEXT_ACTION_VERIFIED = "다음 substage 로 진행한다.";
+const NEXT_ACTION_REJECTED = "검증이 산출물을 반려했다. 해당 substage 의 `.done` 을 false 로 되돌리고 " +
+    "dispatch_stage 를 재호출한다 (이전 실패 사유는 프롬프트에 자동 주입된다).";
+const NEXT_ACTION_ERROR = "검증이 **수행되지 않았다** (verifier 세션 인프라 실패). 같은 인자로 " +
+    "dispatch_verifier 만 재호출한다. stage 를 재실행하지 말고 `.done` 을 false 로 " +
+    "되돌리지도 말 것 — 판정을 못 얻었을 뿐 stage 산출물은 그대로다. " +
+    "verifier 는 idempotent 하므로 재호출이 안전하다.";
+/**
+ * verifier 세션 결과 → 판정 분류.
+ *
+ * 판정 태그는 세션 실패보다 우선한다: 태그를 이미 뱉은 뒤 세션 꼬리가 죽었다면
+ * 그 판정은 실제로 산출된 것이므로 존중한다.
+ *
+ * `malformed_output_default`(세션은 살아서 끝났는데 태그가 없음)는 `ERROR` 로
+ * 올리지 않고 종전대로 `REJECTED` 를 유지한다 — 형식 위반은 verifier 가 관측
+ * 가능한 콘텐츠 결함이고, `same_reason_streak` 이 이미 무한루프를 막는다.
+ * 여기서 완화 대상은 판정이 물리적으로 존재하지 않는 두 경로뿐이다.
+ */
+export function classifyVerifierOutcome(input) {
+    const tag = input.raw.match(VERDICT_TAG_RE);
+    if (tag) {
+        const verdict = tag[1].toUpperCase();
+        return {
+            verdict,
+            source: "verdict_tag",
+            retryable: false,
+            countsAsRejection: verdict === "REJECTED",
+            parsed: "verdict tag found",
+            nextAction: verdict === "VERIFIED" ? NEXT_ACTION_VERIFIED : NEXT_ACTION_REJECTED,
+        };
+    }
+    const json = input.raw.match(VERDICT_JSON_RE);
+    if (json) {
+        const verdict = json[1].toUpperCase();
+        return {
+            verdict,
+            source: "json_fallback",
+            retryable: false,
+            countsAsRejection: verdict === "REJECTED",
+            parsed: `verdict tag missing — extracted from JSON body (${verdict})`,
+            nextAction: verdict === "VERIFIED" ? NEXT_ACTION_VERIFIED : NEXT_ACTION_REJECTED,
+        };
+    }
+    if (input.sessionGone || !input.success) {
+        const source = input.sessionGone
+            ? "session_gone_default"
+            : "session_failed_default";
+        return {
+            verdict: "ERROR",
+            source,
+            retryable: true,
+            countsAsRejection: false,
+            parsed: `verifier session failed — 판정 없음 (${source}): ${input.raw.slice(0, 120)}`,
+            nextAction: NEXT_ACTION_ERROR,
+        };
+    }
+    return {
+        verdict: "REJECTED",
+        source: "malformed_output_default",
+        retryable: false,
+        countsAsRejection: true,
+        parsed: "verdict tag missing — defaulted to REJECTED (verifier output malformed)",
+        nextAction: NEXT_ACTION_REJECTED,
+    };
+}
+/**
+ * 인프라 실패로 판정을 못 얻은 횟수의 연속 상한.
+ *
+ * `same_reason_streak`(REJECTED 무한루프 차단)의 ERROR 판 대응물이다. ERROR 는
+ * 집계에서 빠지므로 그쪽 상한이 걸리지 않는다 — 별도 상한이 없으면 verifier 만
+ * 재호출하는 루프가 영원히 돈다. 3회로 잡은 것은 재호출이 저렴하고(단일 read-only
+ * 세션) 3회 연속 실패면 모델·인프라 문제라 자동 재시도로 풀리지 않기 때문이다.
+ */
+export const VERIFIER_ERROR_STREAK_LIMIT = 3;
+/** 이번 결과를 반영한 ERROR 연속 횟수. ERROR 가 아니면 0 으로 리셋된다. */
+export function nextVerifierErrorStreak(previousStreak, classification) {
+    if (classification.verdict !== "ERROR")
+        return 0;
+    const prev = Number.isFinite(previousStreak) && previousStreak > 0 ? previousStreak : 0;
+    return prev + 1;
+}
+/** 상한 도달 여부. 도달하면 team-leader 는 재호출을 멈추고 사용자에게 보고한다. */
+export function verifierErrorStreakExceeded(streak, limit = VERIFIER_ERROR_STREAK_LIMIT) {
+    return streak >= limit;
+}

package/gates/stage3-scope-verify.sh

@@ -54,8 +54,14 @@ if [ "$SPEC_HASH" != "__MISSING__" ] && [ "$SPEC_HASH" != "null" ] && [ -n "$SPE
     fi
     fail "spec_hash 는 기록됐는데 draft_path 마커도 확정 명세 파일도 없다 — requirements substage 를 재작업하라 (stages/02-requirements.md §2-0, §2-5 9번)"
   fi
+  # "생성된 적 없음" 을 안내에서 빼면 복구 방향을 잘못 잡는다 — 실제로 가장 흔한
+  # 경우인데 종전 메시지는 동기화 누락·삭제만 언급해 리더가 동기화 문제부터
+  # 의심했다 (issue #8).
   [ -f "$ROOT/$DRAFT" ] \
-    || fail "draft_path=${DRAFT} 마커는 있으나 파일이 없다 (기준 경로 ${ROOT}) — worktree 동기화 누락이거나 파일이 삭제됐다"
+    || fail "draft_path=${DRAFT} 마커는 있으나 파일이 없다 (기준 경로 ${ROOT}). 가능한 원인 순서대로:
+  (1) 애초에 생성된 적 없음 — planner 가 마커만 기록하고 파일 생성에 실패한 경우. requirements substage 를 재작업해 write 툴로 초안부터 생성하라 (stages/02-requirements.md §2-0b),
+  (2) worktree 동기화 누락 — 다른 cwd(main repo/worktree)의 같은 상대경로에 파일이 있는지 확인,
+  (3) 파일이 삭제됨 — 삭제 경위 확인 후 requirements 재작업"
   ACTUAL="$(sha256sum "$ROOT/$DRAFT" | cut -d' ' -f1)"
   [ "$ACTUAL" = "$SPEC_HASH" ] \
     || fail "확정 명세 무단 변경 감지 (spec drift) — 동결 후 변경은 사용자 재승인 + spec_hash 재기록 절차만 허용 (stages/02-requirements.md §2-4a)"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "makdoong2-team",
-  "version": "2.2.0",
+  "version": "2.3.1",
   "publishConfig": {
     "access": "public"
   },

package/references/pr-template.md

@@ -83,7 +83,8 @@
 ## 4. PR 생성 규칙
 
 1. 반드시 **Draft 로 생성**한다 → `bitbucket_createPullRequest(..., draft=true)`.
-2. **리뷰어를 추가하지 않는다** → `reviewers` 파라미터 자체를 생략한다 (`[]` 도 아니라 미전달).
+2. **토큰 소유자를 리뷰어로 추가한다** → §4-1 로 식별한 username 을 `reviewers` 에 전달한다. 자기 자신이 PR 작성자여서 Bitbucket DC 가 거부하면 `reviewer_self_skipped=true` 로 기록한다 (`stages/08-pr.md` §7-5).
+   > 종전 이 항목은 "리뷰어를 추가하지 않는다 (`reviewers` 파라미터 자체를 생략)" 였다. 같은 문서의 §4-1·§4-2 와도, `stages/08-pr.md` 와도, `gates/stage7-post-pr-verify.sh` 의 reviewer 마커 검사(`reviewer_added` XOR `reviewer_self_skipped`, 미기록 시 fail)와도 정면으로 어긋나 있었다. 게이트가 마커를 요구하는 이상 리뷰어는 추가하는 것이 맞다.
 3. 생성 후 각 커밋별 diff 를 분석하여 **인라인 코멘트** 를 **개별 live 코멘트** 로 작성한다 (아래 §5–6).
 
 ### 4-1. 토큰 소유자 식별 (리뷰어 추가용)

package/scripts/run-tests.mts

@@ -50,6 +50,7 @@ const STEPS = [
   "node --test test/doctor-phantom-scan.test.ts",
   "node --test test/mcp-secret-injector.test.ts",
   "node --test test/poll-sub-session.test.ts",
+  "node --test test/verifier-verdict.test.ts",
   "node --test test/tmux-monitor.test.ts",
   "node --test test/gate-already-done-block.test.ts",
   "node --test test/gate-hybrid-first-entry.test.ts",

package/stages/01-planning.md

@@ -89,6 +89,8 @@ mkdir -p .makdoong2-team/<이슈키>
 
 파일 (repo/worktree root 기준 상대경로): `.makdoong2-team/<이슈키>/requirements-draft.md`
 
+**초안 파일은 반드시 `write` 툴(filePath 인자)로 생성·갱신한다.** bash 리디렉션(`cat > …`, `printf > …` 등)과 `apply_patch` 는 같은 경로라도 훅이 차단한다 — planner 의 유일한 파일 쓰기 수단은 `write` 다. 이 경로의 `write` 는 planner READ-ONLY 원칙의 명시적 예외이며 훅이 허용한다 (issue #8).
+
 초안 구조:
 ```markdown
 # 요구사항 초안 — <이슈키>

package/stages/02-requirements.md

@@ -62,6 +62,8 @@ mkdir -p .makdoong2-team/<ISSUE_KEY>
 
 파일 경로 (repo/worktree root 기준 상대경로): `.makdoong2-team/<ISSUE_KEY>/requirements-draft.md`
 
+**초안 파일은 반드시 `write` 툴(filePath 인자)로 생성·갱신한다.** bash 리디렉션(`cat > …`, `printf > …` 등)과 `apply_patch` 는 같은 경로라도 훅이 차단한다 — planner 의 유일한 파일 쓰기 수단은 `write` 다. 이 경로의 `write` 는 planner READ-ONLY 원칙의 명시적 예외이며 훅이 허용한다 (issue #8).
+
 초안 초기 구조:
 ```markdown
 # 요구사항 초안 — <ISSUE_KEY>

package/stages/08-pr.md

@@ -175,3 +175,30 @@ post-verify 실패 시:
 
 
 
+
+## 7-7. publisher 세션이 반복 실패할 때 (대체 경로)
+
+`dispatch_stage(3_delivery.pr)` 가 **연속 3회 이상** 실패 반환하면 (empty / session_gone / timeout — 즉 산출물 문제가 아니라 세션 자체가 결과를 못 낸 경우), 부장님(team-leader)은 아래 조건을 **모두** 확인한 뒤 남은 작업을 직접 완결할 수 있다.
+
+> 근거: 실제로 이 단계가 4회 연속 empty 반환했고, 그 사이 `git push` 는 실제로 수행됐는데 PR 생성과 마커 기록만 미완으로 남았다. 재-dispatch 를 반복해도 같은 지점에서 멈춘다 — 남은 일에 git 명령이 없기 때문이다 (GitHub issue #7).
+
+**진입 조건 (하나라도 false 면 진입 금지 — 사용자에게 보고하고 지시를 기다린다)**
+
+| 항목 | 확인 방법 |
+|---|---|
+| 1 | `dispatch_stage(3_delivery.pr)` 가 3회 이상 `ok:false` 로 반환됐다 |
+| 2 | `origin/<브랜치>` 가 이미 존재한다 (**push 가 끝나 있다**) — `git ls-remote` 는 부장님 권한 밖이므로 직전 publisher 세션 로그 또는 `hang_history` 로 확인 |
+| 3 | 남은 작업에 **git 명령이 하나도 없다** — PR 생성(MCP)·마커 기록(`state.sh`)뿐이다 |
+| 4 | `escalate: true` 를 받지 않았다 (받았으면 재디스패치·대체 실행 모두 금지, 사용자 에스컬레이션만) |
+
+**허용 범위 (이것만 한다)**
+
+- `bitbucket_createPullRequest` / `bitbucket_getPullRequest` / `bitbucket_updatePullRequest` — MCP 호출이며 git 명령이 아니다.
+- `state.sh set` 으로 §완료 기록의 마커 기록.
+- `gates/stage7-post-pr-verify.sh` 실행.
+
+**금지 (조건 2 가 거짓이면 그냥 막힌다)**
+
+- `git push` 를 비롯한 모든 git 명령. 부장님은 permission 이 deny 이고, 우회하지 않는다. push 가 남아 있으면 이 대체 경로를 쓸 수 없다 — 사용자에게 보고한다.
+
+**보고**: `[3_delivery.pr PUBLISHER FALLBACK] publisher <N>회 실패 → 남은 작업(PR 생성·마커)에 git 없음을 확인하고 부장님이 직접 완결. push 는 <세션 ID> 에서 이미 완료됨`