chore(memory): subagent 재개 시 worker 완료 검증 교훈 기록

회고(sid 20260629-151216) memory_candidate 수용. orchestrator 가 재개 시
선행 worker 완료를 추정 단정하지 말고 관측으로 확인 후 dispatch 기술.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K3FeMrbtxfTScjrwUukyHD

.serena/memories/orchestrator-subagent-resume-verify-completion-not-assume.md

@@ -0,0 +1,22 @@
+# subagent 재개 시 선행 worker 완료를 추정 단정하지 말 것
+
+orchestrator 가 advisor/worker 를 재개(resume·재호출)·취합할 때, 선행 worker 들의 완료 상태를
+"이쯤이면 다 됐을 것" 식으로 추정해 재개 프롬프트(dispatch)에 사실로 주입하면,
+미검증 상태가 입력방향 오염(`mem:` agent-team-protocol §2.9)으로 산출 파이프라인에 전파된다.
+
+## 적용
+1. 재개·취합 직전 완료 상태를 관측으로 확정: 각 worker 의 산출물 append(files-owners.md/change-log.md),
+   `git status -s`, 완료 신호(task 알림) 확인.
+2. 미확인 worker 는 "완료" 아니라 "미확인 — 알림 대기" 로 기술. dispatch 에 추정 완료수 금지.
+3. 부분 완료면 partial-recovery 절차로 잔여만 좁혀 재호출.
+4. 재개 프롬프트 첫 줄: "확정 완료(관측됨): N / 미확인: M" 등급 구분.
+
+## 왜
+세션 20260629-151216(bibimbap 좋아요 영속화)에서 orchestrator 가 research-advisor 재개 시
+"worker 4개 완료됐을 것"이라 단정 추정했으나 당시 2개만 완료. advisor 가 거부하고 나머지 알림 후
+취합해 결함 0 으로 막았지만, advisor 방어가 없었다면 절반만 취합된 근거로 근본원인 판단이 갈렸을 수 있다.
+방어는 우연이므로 orchestrator 측 가드 필요.
+
+기존 `runtime-selfreport-not-ui-evidence` / git-tracking-claim 류가 "주장 전 검증" 일반론이라면,
+본 항목은 "subagent 재개 시 선행 worker 완료 검증" 의 구체 케이스로 구분된다.
+프로토콜 명문화는 atp 번들 권위본 대상이라 report.md protocol_feedback 로 상류 제안됨.