LAXworkspace
알림 · 보고서
오프라인입력 0 (캐시 0%) · 출력 0
새 대화
세션 목록
⚠ 로컬 데몬이 오프라인입니다 — 메시지는 큐에 쌓였다가 데몬이 켜지면 처리됩니다.
박보검의 요청: [에이전트 슬러그 일괄 변경 — daemon 측 의존성 확인 요청] Jason 결정: 전 에이전트 슬러그를 이름기반(bogum/gyohwan/wooseok/ria/sukgu)에서 생성순번 'agent-N'(id 기준: bogum→agent-1, gyohwan→agent-2, wooseok→agent-3, ria→agent-4, sukgu→agent-5)으로 **기존 포함 일괄 변경**하려 해. DB(worker) 쪽은 내가 처리한다: agents.slug + artifacts.agent_slug + agent_conversations.from_slug/to_slug + agent_activity.agent_slug 마이그레이션, 코드 하드코드(DRAFTER_SLUG, brain chief) 수정. 내가 daemon 쪽에서 슬러그가 키로 쓰이는 걸 발견했어 — 예: agent-skills 폴더가 `daemon/agent-skills/<slug>/.claude/skills` 처럼 슬러그 경로야. DB만 바꾸면 스킬 로딩이 깨질 것 같아. 그래서 묻는다: 1. daemon이 **슬러그를 키로 쓰는 모든 곳**을 알려줘 — 파일시스템 경로(agent-skills/<slug>, 작업폴더, 로그, 캐시), 환경설정, KV/시크릿 키, 메모리 파일 등 전부. 2. 슬러그가 바뀌면 daemon이 깨지는 지점과, 깨지지 않게 같이 옮겨야 할 것(폴더 rename 등)의 정확한 목록. 3. daemon은 에이전트를 slug로 식별해 task를 처리해? 아니면 agent_id 기준이야? 슬러그 변경이 진행 중 task/폴링에 주는 영향은? 4. 안전한 실행 순서 제안 — DB 변경과 daemon 폴더/상태 변경을 어떤 순서로, daemon 재시작이 필요한지. 진행상황: worker 코드/마이그레이션은 내가 준비 중이고, 너 답 받아서 daemon 측까지 lockstep으로 같이 반영한 뒤 Jason에게 최종 GO 받고 실행하려 해. 실제 폴더 rename이 필요하면 그 명령/위치도 알려줘.

조사 끝. 결론부터.

[결론] daemon은 슬러그를 DB에서 받아쓰기만 한다 — 하드코딩 0건. 진짜 위험은 단 하나: 파일시스템 스킬 폴더. DB만 바꾸고 폴더를 안 옮기면 크래시가 아니라 조용한 스킬 전손(특히 변우석 도메인 스킬 15개)이 난다.


1. daemon이 슬러그를 키로 쓰는 곳 (전수)

# 위치 슬러그 용도 슬러그 출처 변경 시 영향
A daemon/agent-skills/<slug>/.claude/skills/ (agentSkillsRoot, L543·872·875) 에이전트별 자가생성 스킬 폴더 (FS 경로) task.agent_slug 🔴 핵심 파괴점. 폴더 안 옮기면 빈 새 폴더 생성→누적 스킬 전부 미로드
B MASTER_SKILLS_ROOT/<slug>/.claude/skills (L573) 도메인 매칭 마스터 스킬 시드 slug 🟢 무해. _master_common만 존재(slug별 폴더 없음) → 이미 no-op
C delete-skill:<slug>:<name> 제어 (L1601~1614) 스킬 삭제 경로 제어 메시지의 slug 🟡 A 폴더 옮기면 자동 정합
D WIKICOMU_FROM_SLUG env → mcp-agents (L850) ask_agent 발신자 식별 task.agent_slug 🟢 런타임 주입 → DB 바뀌면 자동 따라감
E a2a 룸 링크 /chat/a2a/room/<slug:slug> (L487) 표시용 딥링크 task.agent_slug 🟢 표시값일 뿐
F STORE_WIKI 충돌 인박스 파일명 …__<slug>.md (L702) 파일 내용(작성자 표기) slug 🟢 키 아님
G pushAgentSkillsPOST /bridge/agent-skills {agent_slug} (L628·1829) worker로 스킬 역동기화 slug 🟡 worker가 새 slug 받을 준비돼야 함(네 쪽)
seededSlugs Set (L562) 중복 시드 방지 slug 🟢 인메모리. 재시작 시 리셋, .seeded 마커로 멱등

daemon FS에 슬러그로 키된 메모리 파일은 없다. 메모리는 memoryWritePOST /bridge/memory {task_id} 로 worker가 보관(L1394). 로그/캐시/KV/시크릿 중 슬러그 키 없음. 결국 daemon에서 옮겨야 할 것은 agent-skills/<slug> 폴더 하나뿐.

2. 같이 옮겨야 할 것 (lockstep rename)

실제 디스크에 존재하는 대상 폴더 (git mv로 이력 보존):

git mv daemon/agent-skills/bogum    daemon/agent-skills/agent-1
git mv daemon/agent-skills/gyohwan  daemon/agent-skills/agent-2
git mv daemon/agent-skills/wooseok  daemon/agent-skills/agent-3   # ← 도메인 스킬 15개, 최우선
git mv daemon/agent-skills/ria      daemon/agent-skills/agent-4
# sukgu(agent-5): 폴더 미존재 → 첫 실행 시 자동 생성, rename 불필요

.seeded 마커는 폴더 안에 있어 같이 따라간다(재시드 안 됨, OK).

⚠️ 확인 필요(중요): 디스크엔 위 4개 외에 슬러그 폴더가 ~12개 더 있다 — alex, ara, daon, dodam, hangyeol, jarvis, kkomkkom, mira, onyu, ruda, seoyeon, bonwoo. Jason 매핑은 5명만 명시했는데 "전 에이전트 일괄"이라 했다. 이들도 agent-N으로 바꾸는지, 바꾼다면 각자 id→N 매핑을 받아야 한다. 이 폴더들은 DB만 바뀌고 rename 누락되면 동일하게 스킬 전손. GO 전에 범위 확정 요청.

3. 식별 방식 / 진행 중 task 영향

  • daemon은 task_id(리스)로 식별한다. agent_slug는 /bridge/poll이 돌려주는 task 페이로드의 한 속성일 뿐(L1535~1628). agent_id 기준 식별 아님, slug 하드코딩 없음. → worker DB가 slug를 바꾸면 다음 폴부터 새 slug가 자동 유입된다.
  • 진행 중 task가 유일한 레이스: 이미 리스된 task는 옛 slug를 메모리에 스냅샷으로 들고 끝까지 가고, 종료 시 pushAgentSkills(task.agent_slug)(L1829)로 옛 slug 경로에 스킬을 역기록한다. → 컷오버 시 in-flight를 반드시 드레인.

4. 안전 실행 순서

1. [롤백점] daemon 현재 상태 git 커밋 고정 (네 worker 마이그레이션도 동일)
2. [드레인] daemon 폴링 중단 + activeRuns 빌 때까지 대기 (in-flight task 0 확인)
3. [락스텝] daemon 정지 상태에서 동시 반영:
     - worker: DB 마이그레이션(agents.slug + artifacts.agent_slug + 
               agent_conversations.from/to_slug + agent_activity.agent_slug)
     - daemon: 위 git mv 4건 (+범위 확정 시 나머지 폴더)
4. [재시작] daemon 재기동. 폴더 경로는 task마다 재계산 → 새 slug로 새 폴더 인식.
            seededSlugs는 인메모리라 재시작이 깔끔. (정지 중 rename이 핵심이라 재시작 권장)
5. [라이브 검증·자가DONE 금지] agent-3(변우석)으로 실제 task 1건 실행 →
     daemon 로그 `skillsRoot=…/agent-3` + 도메인 스킬 로드 확인 + /activity 노출 눈으로 확인.

daemon 재시작은 필요하다 — 엄밀히는 경로가 task별 재계산이라 무중단도 가능하지만, "정지 중 rename"으로 in-flight 역기록 레이스를 원천 차단하는 게 안전하다.

롤백: worker DB revert + git mv 역방향 1회. 양쪽 모두 단일 revert로 원복 가능.


네 worker 준비되면 위 rename은 내가 락스텝으로 같이 친다. GO 전에 (a) 5명 외 ~12개 폴더 범위, (b) 드레인 윈도우 타이밍 두 개만 확정해줘. 나머지 daemon 측은 위가 전부다 — 추가 깨질 지점 없음(하드코딩 0 확인됨).