60-final-recommendations 통합 지식 보고서

주제 통합 결론

60-final-recommendations의 세 원본 문서는 Sanctum LLM 운영 모델의 최종 실행 결론을 하나의 방향으로 수렴시킨다. Sanctum은 Graphify, RAG, Codex App, service worker를 따로 도입하는 것이 아니라 canonical source -> service context -> navigation/retrieval -> runtime enforcement -> handoff/e2e integration 순서로 운영 체계를 세워야 한다.

SSOT는 사람이 읽고 검토할 수 있는 canonical 문서와 contracts/에 둔다.
Graphify는 repo navigation과 context routing을 돕는 derived index이며 source of truth나 write authorization이 아니다.
RAG는 evidence retrieval layer이며 RAG DB나 generated answer는 canonical fact가 아니다.
Codex App workspace separation은 위험 감소 수단이지만 hard write boundary가 아니다.
service worker 안전성은 discord-codex-bot runtime의 write allowlist, diff guard, structured approval scope, handoff rule로 강제해야 한다.
첫 파일럿은 wallet-api 중심 context-only pilot으로 시작하고 kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs, contracts/, root/e2e agent로 점진 확장한다.

확정 원칙

Canonical source가 먼저다

계층	Owner	역할
Product/operation SSOT	reviewed human docs 또는 Notion export 기반 canonical Markdown	제품 구성, component relationship, request flow, deployment/runbook
Engineering contract SSOT	`contracts/`	schema, ABI, endpoint, event, protocol contract의 최종 사실
Service execution context	각 service의 `AGENTS.md`와 `llm-context/`	worker 실행에 필요한 service-local 운영 문맥
Derived navigation	Graphify graph	관련 파일과 dependency 후보 탐색
Derived retrieval	RAG DB	source-backed evidence retrieval
Derived conclusions	generated reports/analysis	conclusion, reasoning, confidence, validation state, stale condition, source links를 가진 검증 가능 결론

Service context pack은 contract를 복제하지 않는다

각 서비스에는 AGENTS.md와 llm-context/가 필요하지만 llm-context/contracts.md는 canonical contracts/ 내용을 복사하지 않는다. 관련 canonical contract path, producer/consumer 관계, endpoint/schema/event 사용 지점, 변경 시 handoff owner, contract 변경 후 필요한 테스트 범위, dependency stub 위치와 stale condition만 기록한다.

Graphify는 context-router다

Graphify는 wallet -> KMS -> HD -> MPC 흐름처럼 여러 서비스와 contracts/를 가로지르는 경로를 찾는 데 유용하다. 그러나 derived index이므로 drift와 extraction failure가 있다. repo 구조 탐색, 관계 후보 찾기, contract 관련 파일 후보 찾기, flow tracing 시작점 제안, context pack 작성 보조에만 사용한다.

Write boundary는 runtime에서 강제한다

AGENTS.md와 문서 규칙은 필요하지만 충분하지 않다. worker별 cwd, read allowlist, write allowlist, propose-only path, forbidden path, post-run diff guard, structured approval record, handoff artifact validation이 실제 안전성을 만든다.

Root/e2e agent는 super-worker가 아니다

root/e2e agent는 전체 repo를 읽고 cross-service flow를 검증할 수 있지만 모든 service-local implementation을 직접 수정하면 service boundary가 무너진다. 기본 역할은 integration analysis, e2e validation, contract impact review, handoff coordination이다.

Sanctum 운영 모델

역할	책임	권한 모델
`wallet-api-worker`	wallet request flow와 service-local context/변경	`wallet-api/` write, dependencies propose-only
`kms-api-worker`	key lifecycle, auth/security boundary, KMS service context	`kms-api/` write, wallet/HD/MPC propose-only
`hd-manager-worker`	derivation flow와 wallet/KMS dependency context	`hd-manager/` write, upstream/MPC propose-only
`mpc-manager-rs-worker`	MPC orchestration과 party coordination	`rust-mpc/mpc-manager-rs/` write
`party-node-rs-worker`	party node participant behavior	`rust-mpc/party-node-rs/` write
`contracts-worker`	canonical contract 변경	`contracts/` write는 승인/owner 기반
root/e2e agent	cross-service flow, integration validation	repo-wide read, 제한 write 또는 propose-only 기본

다른 주제와 연결되는 의존성

이 최종 권고는 앞선 여섯 주제의 결론을 실행 순서로 연결한다. 10-context-management는 SSOT와 derived knowledge 신뢰 등급을, 20-graphify-evaluation은 Graphify drift와 pilot 적합성을, 30-sanctum-knowledge-architecture는 contracts/ SSOT와 service context pack을, 40-worker-agent-operations는 service-scoped worker와 handoff를, 50-codex-app-and-runtime-boundary는 Codex App soft boundary와 runtime hard enforcement의 차이를 제공한다.

충돌 가능성 및 우선순위

빠른 자동화와 안전한 경계가 충돌하면 안전한 경계가 우선이다. context-only pilot을 먼저 수행하고 code change pilot은 Stage 2로 미룬다. contract fact는 contracts/만 소유한다. root graph only로 시작하고 실제 noise가 측정된 뒤 service graph를 추가한다. Codex App은 personal lane, service worker는 runtime lane으로 분리한다. root/e2e는 분석과 handoff coordination을 맡고 service-local 구현은 해당 worker가 맡는다.

실행 로드맵

Stage 0: root LLM operating principle, contracts/ canonical role, Product/operation SSOT와 engineering contract SSOT 분리, Derived Knowledge schema를 확정한다.
Stage 1: wallet-api 중심 flow를 확정하고 wallet-api/AGENTS.md, wallet-api/llm-context/, dependency stub, contracts/ mapping을 작성한다.
Stage 2: root Graphify graph를 생성하고 branch, commit, generatedAt, scan root, ignore policy, stale condition을 기록한다. RAG source registry를 canonical/derived group으로 분리한다.
Stage 3: wallet-api-worker cwd, read/write allowlist, propose-only paths, diff guard, structured approval scope, handoff artifact를 dry-run한다.
Stage 4: context-only pilot을 실행하고 Graphify/RAG source validation, contract mapping, dependency handoff, diff guard 결과를 검토한다.
Stage 5: 성공 후 kms-api, hd-manager로 확장하고 MPC worker는 별도 pilot으로 분리한다. root graph noise가 확인될 때만 service graph와 merged graph를 도입한다.

검증 질문

contracts/가 canonical contract fact owner로 명확히 남아 있는가?
service context가 contract 내용을 복제하지 않고 canonical path로 mapping하는가?
Derived Knowledge에 source, reasoning, confidence, validation state, stale condition이 있는가?
Graphify graph가 현재 branch와 commit 기준으로 생성되었는가?
Graphify가 제안한 파일을 worker가 실제로 읽었는가?
각 worker의 write allowlist가 runtime metadata로 강제되는가?
propose-only path를 수정하려 하면 차단되는가?
diff guard가 allowlist 밖 변경을 잡는가?
Codex App workspace separation을 hard boundary로 표현하지 않았는가?
service-scoped worker 실행은 discord-codex-bot runtime에서 이루어지는가?
wallet-api-worker가 dependency와 contract 변경을 handoff로 처리하는가?

최종 요약

Sanctum의 LLM 운영 모델은 더 많은 context를 LLM에게 주는 방식만으로 안전해지지 않는다. 안전한 운영은 canonical source, service-local context, derived navigation/retrieval, runtime write enforcement, handoff/e2e integration이 순서대로 맞물릴 때 가능하다.