diff --git a/.serena/memories/orchestrator-subagent-resume-verify-completion-not-assume.md b/.serena/memories/orchestrator-subagent-resume-verify-completion-not-assume.md
new file mode 100644
index 0000000..96590e1
--- /dev/null
+++ b/.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 로 상류 제안됨.