[HAN-390] 11:15 Done → 12:14 In Progress 복구 히스토리

TL;DR

• HAN-390은 2026-06-07 11:15:25Z에 In Progress → Done으로 전환됐다. PR 첨부 없음, 코멘트 없음. 머지·자동화 흔적 zero.
• 동일 시각 ±5분 안에 머지된 PR이 하나도 없다. 가장 가까운 머지(PR #238)는 11:16:51Z — Done 시각 1분 26초 뒤. 즉 PR 머지가 끌어내린 게 아니다.
• 따라서 트리거 후보는 둘로 좁혀진다. (A) 누군가의 수동 close, (B) 부모(HAN-344) Done에 반응한 외부 sub-issue 일괄 정리 자동화. 둘 다 의도된 흐름이 아니다.
• 사용자 의도 확인 후("문제가 남아있다면 HAN-390을 격상하면 될거 같아요") In Progress + Urgent로 되돌렸다 (2026-06-07 12:14:27Z).
• 본 문서는 왜 닫혔는지·왜 되돌렸는지의 기록. 진단·요건·잔여 작업은 별도 status 보고서(HAN-390 dispatcher status)에 있다.

상태 전환 타임라인

이슈 본문 priority는 동시에 Urgent로 격상됐다.

왜 닫혔는가 — 11:15 Done 진단

직접 흔적은 없다

• Linear 코멘트 0건 (list_comments 결과 빈 배열).
• PR 첨부 0건 (이슈 attachments에 PR 객체 없음).
• 가장 가까운 hangseung/pantheon 머지 시각.

PR #238은 Done 처리 뒤에 머지됐다. 인과 방향이 맞지 않는다.

가설 두 개

가설 A — 수동 close. Linear UI에서 사용자가 직접 닫았다.
- 근거: 직전 thread에서 "오래돼서 기억 안나요" (사용자, HAN-344에 대해). 부모 Done이 의도였는지 본인도 기억 못 함 → 같은 무의식 흐름에서 자식까지 닫았을 수 있다.
- 반박: 그러면 1시간 20분의 시차가 어색하다.

가설 B — sub-issue 일괄 정리 자동화. 부모(HAN-344)가 09:56 Done 처리되면서 어떤 외부 스캐너(Jarvis 정리 hook 또는 Linear workspace 자동화)가 "parent Done이면 active child도 정리" 휴리스틱을 돌렸다.
- 근거: HAN-344의 sub-issue는 HAN-390 한 개뿐. 부모-자식 1:1 짝에서 부모만 닫는 건 의미적으로 불완전해 보이는 형태. 자동화가 이를 정합 부족으로 판정하고 자식까지 정렬했을 가능성.
- 반박: 시차가 왜 정확히 1h20m인가는 설명 못 함. 만약 자동화라면 트리거 주기를 봐야 한다. (Jarvis ledger hook이 시간당 또는 사용자 액션 게이트로 도는지 확인 필요.)

어느 쪽이든 의도된 흐름은 아니다. 본인이 11:15에 의식적으로 "이 fan-out 문제 해결됐다"라고 판정한 흔적이 어느 채널에도 없다.

왜 되돌렸는가 — 12:14 In Progress 복구

순서는 이렇다.

1. 사용자가 2026-06-07 사고(같은 출처 독후감 2건 main 동시 게시) 보고서 작성을 요청.
2. jini가 HAN-390 dispatcher status를 작성하면서 티켓이 In Progress라고 가정하고 본문을 썼다.
3. 보고서 작성 뒤 Linear를 다시 조회해 보니 Done. 본문이 사실과 어긋났다 (보고서는 "결정·락·게이트는 비어 있다"고 단언).
4. jini가 사용자에게 "11:15에 Done으로 닫혔는데 의도였느냐"를 묻고, "문제가 남아있다면 HAN-390을 격상하면 될거 같아요" 응답을 받음.
5. 위 응답을 남은 문제 존재 인정 + 격상 승인으로 해석해 In Progress + Urgent로 복구.

복구의 근거가 된 사실은 같은 보고서가 짚은 두 가지.

• side-effect 단일 owner lock이 인입 안 됐다. PR #224에는 routing decision logger만 들어갔다.
• 그래서 오늘 발생한 사고의 정답 슬롯(중복 게시 0 + 침묵 0)은 비어 있다.

즉 문제 자체는 해결되지 않은 채 티켓만 닫혀 있는 상태였다. 사용자 확인 후 되돌리는 게 사실 정합.

함의 — 같은 사고가 반복되지 않으려면

1. 티켓 close 시 출처를 의무화. 코멘트 없이 상태만 바뀌는 close가 11:15처럼 조용히 발생하는 경로가 열려 있다. 자동화든 수동이든, close 사유 한 줄이 강제되면 같은 진단이 30초로 끝난다.
2. parent Done = child 자동 닫기 자동화가 존재한다면 끄거나 확인 게이트 추가. 1:1 부모-자식에서 자식이 의미상 parent의 잔여 실행 단위라면, 부모 close가 자식까지 끌고 가면 안 된다.
3. 부모 Done 처리 시점에 "잔여 child 있는지" 검토를 routine으로 추가. 오늘은 HAN-344가 닫히면서 HAN-390이 고아 In Progress가 됐다. 이 패턴이 발견되면 자동으로 parent re-open 또는 child 격상 둘 중 하나로 정렬.

검증 질문

1. 11:15 close 트리거가 수동인지 자동인지를 결정적으로 가를 신호는? Linear Activity log의 actor 필드(사용자 vs API token vs integration)가 정답을 준다. 현재 MCP list_comments로는 안 보인다 — Linear UI Activity 탭에서 actor 한 번 확인 필요.
2. 부모-자식 close 정합 자동화가 어딘가 존재하는가? Jarvis ledger·workspace automation·SDD pipeline 어디에 들어 있는지 또는 전혀 없는지 확인. 없다면 가설 A(수동)로 좁힌다.
3. 오늘 11:15 close가 처음인가? HAN-300 시리즈에서 child-only In Progress가 parent Done과 시차를 두고 닫힌 다른 사례가 있다면 자동화 패턴 신호. 없다면 일회성 수동 사고.

참고

• HAN-390: https://linear.app/hangman-lab/issue/HAN-390
• HAN-344 (parent, Done 09:56Z): https://linear.app/hangman-lab/issue/HAN-344
• HAN-390 dispatcher status (오늘 사고 진단 본): https://hangman-docs.pages.dev/reports/2026-06-07-HAN-390-dispatcher-status.html
• northstar dispatcher case study (2026-05-28 합의): https://hangman-docs.pages.dev/reports/northstar-dispatcher-case-study-2026-05-28.html
• PR #224 (HAN-344 머지): https://github.com/hangseung/pantheon/pull/224
• PR #238 (11:16:51Z, Done 직후 머지): https://github.com/hangseung/pantheon/pull/238