agent-1 ↔ 손석구

확인 끝났습니다. 아래는 추측이 아니라 daemon.js·run.bat 코드와 실제 프로세스 상태로 검증한 사실입니다.

결론 먼저: 중복 daemon 정리함

Jason이 수동으로 살리는 과정에서 daemon이 2개 겹쳐 돌고 있었습니다(double-poll = 같은 태스크 2번 실행 위험). 오래된 쪽이 idle인 걸 확인하고 방금 정리했습니다. 지금은 단일 인스턴스 정상입니다.

제거한 건 11:05 쌍(supervisor 17560 → node 17852). 자식 claude 프로세스가 없어 in-flight 태스크 0건이라 무손실 정리. 롤백: 문제 시 daemon\run.bat 더블클릭 한 번으로 원복.

1. 왜 '재시작' 버튼이 죽은 daemon을 못 살리나

버튼이 두 가지 이유로 죽은 daemon에 무력합니다:

• 버튼은 재시작이 아니라 "graceful 종료"만 합니다. /settings/bridge/restart-graceful은 bridge에 커맨드를 큐잉할 뿐, 실제 동작은 살아있는 daemon이 폴링으로 그 커맨드를 받아서 .shutdown 플래그 파일을 쓰는 것입니다(daemon.js 1572~1590). daemon은 in-flight 태스크를 다 비운 뒤 process.exit(0)으로 스스로 종료합니다.
• 재기동은 전적으로 supervisor(run.bat 루프)가 합니다. run.bat은 :loop … node daemon.js … goto loop 구조라, node가 exit하면 3초 뒤 다시 띄웁니다. 즉 버튼은 "node를 깨끗이 죽이는" 역할이고, 다시 살리는 건 supervisor입니다.

→ 그래서 supervisor까지 죽으면 버튼은 회생 불가가 맞습니다. 이중으로 불가능합니다: ① 죽은 node는 커맨드를 받을 폴링 루프가 없고, ② 설령 받아 exit해도 재기동할 supervisor가 없습니다. 이번 컷오버에서 supervisor(cmd 29524)를 죽인 게 정확히 이 상황을 만들었습니다.

2. supervisor까지 죽었을 때 회생 방법

C:\Users\user\LAX-site\daemon\run.bat 를 실행하면 됩니다.

1. 탐색기에서 C:\Users\user\LAX-site\daemon\run.bat 더블클릭 (가장 단순·확실).
   • 정상 부팅 진입점은 start-hidden.vbs(창 숨김으로 run.bat 실행)지만, 회생 목적이면 run.bat 직접 실행으로 충분합니다.
2. run.bat이 node daemon.js를 띄우고, 부팅 시 stale 락(.daemon.lock)과 stale .shutdown 플래그를 자동 정리(daemon.js 1849~1855)하므로 죽은 PID가 남긴 찌꺼기 락은 알아서 풀립니다.
3. 중복 실행 걱정은 안 해도 됩니다 — 싱글톤 락이 살아있는 owner를 감지하면 새 인스턴스가 스스로 exit(0)합니다.

3. 앞으로 daemon 안 죽이는 안전한 방법

컷오버 같은 코드 반영 시엔 supervisor를 절대 죽이지 말고, '재시작' 버튼(restart-graceful)만 쓰세요. 그게 바로 "supervisor는 살려둔 채 node만 graceful restart" 경로입니다:

• 버튼 → daemon이 .shutdown 작성 → 진행 중 태스크 드레인 후 node만 exit → supervisor가 3초 뒤 새 코드로 자동 재기동. 셀프 회생됩니다.
• 슬러그 폴더 rename 같은 파일시스템 변경도, supervisor를 건드리지 않는 한 버튼 한 번으로 새 코드/새 폴더 구조를 그대로 물고 올라옵니다.

이번에 문제가 된 건 node .shutdown 수동 조작 + supervisor 강제 종료를 같이 한 것입니다. supervisor를 죽이는 순간 셀프 회생 안전망이 사라집니다 — 앞으로 컷오버 절차에서 supervisor 종료는 빼겠습니다.

4. 현재 상태

정상 동작 중입니다. Jason이 살린 node 36256이 활성 태스크(자식 claude.exe 35908)를 돌리고 있고, 락도 정상 소유, .shutdown 플래그 없음(운영 모드). 이 답변도 그 daemon이 돌리는 중입니다.

슬러그 rename도 정상 반영됨: agent-skills\agent-1 ~ agent-4 폴더와 각 .claude\skills 구조 모두 확인. agent-N 체계로 잘 붙었습니다.

남은 권고 한 가지: 이번처럼 supervisor가 2개로 늘어나는 일을 원천 차단하려면, run.bat 진입 시 기존 supervisor 중복 여부를 체크하는 가드를 넣는 게 좋습니다. 비가역 변경이라 daemon.js 커밋 고정 후 별도로 제안드리겠습니다 — 지금 당장은 단일 인스턴스로 안정 상태입니다.

완료했습니다. 결론부터 보고합니다.

[무엇을 바꿨나]

핵심 발견: 기존 WikicomuDaemon 작업은 LAX가 아니라 다른 프로젝트(Wikicomu-site)를 가리키고 있었습니다. 즉 LAX daemon을 보호하는 OS 회생은 아예 없었습니다. 이번에 LAX 전용으로 새로 만들었습니다.

[왜 — 3계층 회생 모델]

• L1 프로세스 크래시 → run.bat 내부 루프가 3~15초 내 재시작 (기존, 그대로).
• L2 로그온/재부팅 → LAXDaemon의 LogonTrigger가 즉시 시작.
• L3 supervisor(run.bat)까지 사망 → LAXDaemon의 1분 주기 reconciler가 감지·재기동. ← 이전엔 비어 있던 "죽은 채 방치" 구멍.
• reconciler는 멱등 + 유예마커: 죽은 걸 처음 보면 마커만 남겨 run.bat에게 살릴 시간을 주고, 다음 틱(≥60초)에도 죽어 있을 때만(=supervisor 진짜 사망) 재기동 → 정상 크래시와의 중복 supervisor 충돌 방지. daemon의 원자적 단일 인스턴스 락이 최종 안전망.
• LAX 식별은 lock PID로 정밀 판별(Wikicomu daemon도 node daemon.js라 명령줄만으론 구분 불가).

[검증 결과 — 자가 DONE 아님, 라이브/격리 실측]

검증 중 버그 2개를 잡아 고쳤습니다(그래서 검증이 의미 있었습니다):

1. 락 PID 파싱 버그(Get-Content가 단일 라인을 스칼라로 반환 → 첫 문자만 읽힘) → 항상 "DOWN" 오판. -Raw + TryParse로 수정.
2. 그 오판이 일시적으로 띄운 orphan run.bat(PID 19300)을 탐지·정리 완료(원본 supervisor 19500·daemon 36256 무손상).

수정 후 실측:

• healthy 경로(실제 스케줄러 실행 ×3): LastTaskResult=0, 로그 0줄 추가(오판 없음), 마커 없음, daemon PID 36256 불변, 새 orphan 없음.
• DOWN→relaunch 상태머신(격리 샌드박스, 라이브 무영향): run1=마커 생성·재기동 안 함 / run2=재기동 분기 실행·마커 해제 / run3(alive)=무동작. 로그로 결정적 확인.
• 최종: LAXDaemon State=Ready, NextRunTime=13:17(1분 주기 가동 중), 단일 daemon 유지. 작업 중 daemon 안 죽였습니다.

Jason 동작 확인법 (택1): 작업 스케줄러에서 LAXDaemon 우클릭→실행 후 daemon 온라인 유지 확인 / 또는 daemon\ensure-daemon.log가 정상 시 조용한지 확인. 진짜 회생 테스트는 run.bat 콘솔을 강제 종료해 보면 ~1~2분 내 자동 부활합니다.

⚠️ [비가역/위험 — Jason 최종확인 요청]

• LAXDaemon 로그온 자동시작 등록: 이 PC가 로그인될 때마다 LAX daemon이 자동 기동됩니다(부팅 동작 변경). 안전하게 설계했고(락 가드+유예마커로 중복 없음) 라이브 검증했지만, 자동시작 자체를 원치 않으시면 알려주세요. 완전 가역입니다.

[롤백 방법]

# 작업 제거 (자동 회생 해제)
Unregister-ScheduledTask -TaskName 'LAXDaemon' -Confirm:$false
# 파일 제거
Remove-Item 'C:\Users\user\LAX-site\daemon\ensure-daemon.ps1','C:\Users\user\LAX-site\daemon\LAXDaemon.task.xml' -Force
Remove-Item 'C:\Users\user\Desktop\LAX 데몬 켜기 (비상).lnk' -Force

→ 롤백해도 기존 run.bat 루프는 그대로라 현 daemon은 계속 동작합니다(이번 변경은 daemon.js·런타임 코드 무수정, 순수 추가물).

[남은 것 / 참고]

• 신규 파일 2개는 git untracked 상태로 뒀습니다(daemon/ensure-daemon.ps1, daemon/LAXDaemon.task.xml). 정본화 원하시면 커밋하겠습니다.
• (불요 수정 안 함, 보고만) 기존 RUNBOOK-emergency-recovery.md는 복구 경로로 WikicomuDaemon을 언급하는데 그건 다른 프로젝트 작업입니다 — LAX는 이제 LAXDaemon. 원하시면 런북을 LAX 기준으로 갱신하겠습니다.

완료. 결론부터 보고한다.

보고: daemon 자가회생 인프라 정본화

[무엇을 바꿨나]

런북 갱신 항목

• 복구작업명 WikicomuDaemon → LAXDaemon (잔존 참조 0건 검증)
• 3계층 회생모델 표 추가: L1 run.bat 루프(3~15초) / L2 로그온 / L3 1분 감시 reconciler
• 콜드스타트(7번) 섹션 신설: 바탕화면 LAX 데몬 켜기 (비상) 아이콘 / run.bat 더블클릭 + LAXDaemon 작업 재등록 절차
• run.bat 실제 주기(graceful 3초 / crash 15초 백오프)로 outdated "30초" 표기 정정, 부록 표 갱신

[왜] Jason이 로그온 자동시작(LAXDaemon) 유지로 확정 → 자가회생 인프라를 git 정본으로 고정하고 런북을 현 구조와 일치시킴.

[검증 결과]

• 커밋 해시: 8f875ba (full 8f875baa700271090fff9d6070897daccc28d95c), 브랜치 feat/jigeup-workbench
• 변경: 3 files, +109 / −10. 스테이징을 세 파일로 한정 — 작업트리의 다른 수정/untracked는 미포함(서지컬).
• push: 불가. 이 저장소에 원격(remote)이 설정돼 있지 않음 → 로컬 커밋만 존재.
• daemon 안 죽임 확인: 파일 정본화·git만 수행. lock PID(36256)와 실행 중 node daemon.js PID(36256) 일치 → 현 LAX 인스턴스 정상 가동 중.

[롤백 방법] git revert 8f875ba 한 번으로 원복(신규 2파일 삭제 + 런북 원상). 실행 중 daemon에는 영향 없음(런타임 미변경).

참고: push가 필요하면 원격 등록(git remote add origin <URL>) 후 알려주면 즉시 진행 가능. 현재는 등록된 원격이 없어 보류한다.

확인 완료. 결론부터 보고합니다.

[무엇을 바꿨나]

/bridge/agent-config 리졸버에 이름 폴백 추가 — slug 정확매칭 우선 → 없으면 lower(name) 매칭.

• 파일: src/app/bridge/routes.ts (L922~, /agent-config 핸들러)
• 쿼리: WHERE status='active' AND (slug=? OR lower(name)=lower(?)) ORDER BY CASE WHEN slug=? THEN 0 ELSE 1 END LIMIT 1 — .bind(slug,slug,slug)
• LAX bridge의 /bridge/enqueue·chat ask_agent와 동일 정책. exact slug 우선.
• 커밋: d066c58 (fix(bridge): add name fallback to /bridge/agent-config resolver)

[왜]

ask_agent/ask_team(mcp-agents.mjs)은 DB 접근이 없습니다 — to를 /bridge/agent-config에 위임해 해석합니다. 그런데 이 엔드포인트만 slug-only로 남아 있었습니다(WHERE slug=?). 그래서 'to: 손석구'가 not-found. 폴백은 mcp-agents가 아니라 여기가 정답이고, 한 곳 고치면 ask_agent·ask_team 양쪽 다 해결됩니다.

[검증 결과]

• 코드: 적용·커밋 완료. 변경은 컴파일 중인 enqueue 훅과 구조 동일(문자열 리터럴 + string bind 3개)이라 TS 안전.
• 라이브 진단 확정 (production lax-dtb.pages.dev에 서명 read-only 프로브):

  입력	현재 production 결과
  slug agent-1	found ✅ (박보검)
  name 손석구	found:false ❌
  name 변우석	found:false ❌

  • 즉 버그 재현 확인 + 엔드포인트/서명 정상.

[반영 — 아직 미배포 / 단독배포 안 함] ⚠️비가역·대외영향

라이브 효과는 Pages 앱 재배포 후에만 납니다(mcp-agents는 원격 bridge에 위임하므로). 그런데 제가 단독 배포하지 않은 이유 — 둘 다 비가역:

1. 워킹트리에 무관한 WIP 10개 파일이 떠 있습니다(form.tsx, chat, complaint, draft, brain 등 — feat/jigeup-workbench 진행분). npm run deploy는 npm run build로 워킹트리를 그대로 빌드해 production에 올립니다. 이름폴백 하나 때문에 미완성 WIP를 prod에 밀어넣는 건 위험.
2. 배포 스크립트는 --project-name lax --branch=main(production)인데 데몬 bridge는 lax-dtb.pages.dev — 매핑이 코드상 100% 확인 안 됨.

권장 안전 배포 경로(트리가 준비됐을 때):

git stash push -k -- $(git diff --name-only)   # 커밋 안 된 WIP만 잠시 제외
npm run deploy                                   # 커밋된 상태(=내 fix 포함)만 빌드·배포
git stash pop

이러면 production에 커밋분 + 이름폴백만 반영되고 WIP는 안 나갑니다.

[라이브 검증 — 배포 후 가능]

지금은 production이 slug-only라 'to: 손석구'는 여전히 not-found입니다. 배포 완료 시점부터 검증 가능합니다. 검증 명령(위 프로브 재실행)으로 name 손석구 → found:true가 뜨면 OK이고, 그 뒤 직접 ask_agent(to:"손석구", ...) 호출이 통합니다.

[롤백]

• 코드: git revert d066c58 (단일 커밋, 1회 revert로 원복).
• 배포했다면: CF Pages 이전 deployment로 롤백(또는 revert 후 재배포).

daemon은 건드리지 않았습니다. mcp-agents.mjs도 무변경(폴백은 bridge쪽 단일 지점). 배포를 제가 실행해도 될지 — WIP 동반 배포 위험 때문에 트리 상태 확인/확정만 주시면 위 안전경로로 바로 반영하겠습니다.