40-worker-agent-operations 통합 지식 보고서

주제 통합 결론

40-worker-agent-operations의 네 문서는 하나의 운영 결론으로 수렴한다. Sanctum의 LLM 운영은 서비스별 bounded worker와 root/e2e orchestrator 조합으로 설계해야 한다. 서비스별 worker는 자기 서비스의 구현, 테스트, context pack을 깊게 다루고 sibling service, canonical contracts/, root e2e, deployment/runtime policy는 기본적으로 propose-only로 둔다.

핵심 원칙은 넓게 읽고 좁게 쓴다이다. wallet-api는 kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs와 연결되고, 중심에는 contracts/가 있다. 워커는 cross-service context를 읽어 문제를 이해하되 실제 diff는 write allowlist 안에서만 만들어야 한다.

Graphify는 repo memory index이자 navigation/context-router이고, RAG는 evidence retrieval layer다. 둘 다 SSOT나 write authorization이 아니다. SSOT는 사람이 검토 가능한 canonical 문서, 코드, contracts/, root/service AGENTS.md, service llm-context/, 테스트 결과에 있다.

Codex App workspace separation은 위험을 줄일 수 있지만 hard write boundary가 아니다. 실제 서비스 스코프는 discord-codex-bot runtime의 write allowlist, diff guard, approval metadata, 필요 시 sparse worktree/container/read-only mount로 강제해야 한다.

확정 원칙

1. 서비스별 worker는 실행 단위이고 root/e2e agent는 통합 단위다

wallet-api, kms-api, hd-manager, mpc-manager-rs, party-node-rs는 독립 worker scope를 갖고 자기 서비스 implementation과 focused test를 처리한다. root/e2e agent는 여러 worker 결과를 모아 contract, e2e, final diff review를 담당한다.

2. cwd는 힌트이고 write allowlist가 경계다

cwd는 명령 실행 시작 위치일 뿐 보안 경계가 아니다. worker metadata에는 cwd와 별도로 worker id, writeAllowlist, readHints, proposeOnly, handoffRequiredOn, approval scope가 필요하며 final 전 diff guard는 실제 변경 파일이 allowlist 안인지 검사해야 한다.

3. contracts/는 contract SSOT이고 service context는 mapping이다

contracts/는 서비스 간 API/schema/protocol contract의 canonical source다. 서비스별 llm-context/contracts.md는 계약 내용을 복제하지 말고 consumer/producer 역할, assumption, stale condition을 mapping해야 한다.

4. Graphify는 context-router이고 authorization source가 아니다

Graphify는 관련 파일 후보와 dependency path를 찾는 데 유용하지만 graph edge가 쓰기 허가를 뜻하지 않는다. graph drift가 생길 수 있으므로 초기 pilot은 root graph로 시작하고 authorization에는 사용하지 않는다.

5. Out-of-scope 발견은 handoff로 완료한다

범위 밖 변경 필요성을 발견한 것은 실패가 아니다. 실패는 조용히 무시하거나 직접 수정하는 것이다. Handoff에는 source worker, current task, current write scope, target worker, routing reason, problem, evidence, proposed change, risk if ignored, suggested validation이 필요하다.

6. root/e2e agent는 super-worker가 아니라 integration controller다

root/e2e agent는 초기에는 review-only로 시작해 service handoff 수집, contract impact 분석, e2e matrix, final diff review를 담당한다. 이후 e2e fixture, root runbook, service llm-context/e2e-role.md, cross-service reference 문서 갱신을 제한적으로 허용할 수 있다.

실행 로드맵

1. Policy-first service packs: root/service AGENTS.md, service llm-context/, canonical contract mapping, dependency stub을 만든다.
2. Runtime write allowlist: cwd와 writeAllowlist를 분리하고 approval scope와 actual diff path를 대조한다.
3. Diff guard and handoff-required: allowlist 밖 diff는 성공 처리하지 않고 blocked paths와 target worker를 기록한다.
4. Root Graphify pilot: wallet signing, key derivation, MPC session flow 후보를 탐색하고 graph 결과는 context-router로만 쓴다.
5. Root/e2e orchestration: handoff를 수집하고 contract impact, e2e matrix, final diff review를 작성한다.
6. High-risk isolation: kms-api, contracts/, MPC crates에는 sparse worktree, container, read-only mount, secret-like artifact 검사를 검토한다.

검증 질문

• worker write allowlist가 실제 path 기준으로 정의되어 있는가?
• cwd 밖 파일 수정 diff가 final 전에 차단되는가?
• contracts/ 변경은 contracts worker 또는 root/e2e agent로 handoff되는가?
• Graphify/RAG가 write authorization으로 사용되지 않는가?
• e2e 미실행이 pass가 아니라 residual risk로 표시되는가?