10-context-management 통합 지식 보고서

주제 통합 결론

10-context-management의 세 문서는 하나의 결론으로 수렴한다. Sanctum의 LLM 운영은 지식 도구를 많이 붙이는 문제가 아니라 신뢰 계층, 탐색 계층, 근거 계층, 실행 권한 계층을 분리하는 문제다.

SSOT는 사람이 검토 가능한 canonical source에 둔다. contracts/, service AGENTS.md, service llm-context/, approved runbook, current source code가 여기에 해당한다. Graphify는 navigation/context-router이고, RAG는 evidence retrieval이며, LLM Wiki와 generated summary는 derived knowledge다. 실제 write boundary는 runtime write allowlist, diff guard, approval/handoff record, sparse worktree/container/read-only mount 같은 집행 장치가 담당한다.

Codex App workspace separation은 개인 탐색과 리뷰의 risk-reduction measure로 볼 수 있지만, out-of-workspace edit이 가능하다면 hard write boundary가 아니다.

이 주제의 보고서

Context Router Model

Graphify, RAG, SSOT, LLM Wiki를 worker 실행 흐름 안에 배치하는 모델.

LLM Wiki vs Graphify vs RAG

각 지식 도구의 책임과 신뢰 수준, 사용 금지 범위를 비교한다.

SSOT와 Derived Knowledge

canonical source와 derived layer를 분리하는 저장 규칙과 metadata.

확정된 원칙

Graphify는 router이지 권한자가 아니다. wallet-api에서 kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs, contracts/로 이어지는 후보 관계를 찾을 수 있지만, 관련 있음은 수정 가능함이 아니다.
RAG는 evidence cache이지 SSOT가 아니다. retrieval은 selection이고 ranking은 correctness가 아니다.
SSOT는 사람이 검토 가능한 source여야 한다. 자동 요약, graph, embedding DB는 파생물이다.
llm-context/contracts.md는 contract field 복제본이 아니라 canonical contracts/ path, service impact, propose-only rule, validation command를 연결하는 mapping 문서다.
Derived Knowledge는 conclusion, reasoning, source_truth, source_observations, confidence, validation_state, stale_when, allowed_use, not_allowed_use를 가져야 한다.
초기 Graphify pilot은 root graph로 시작한다. root graph가 noisy하다는 실측 증거가 생기면 service scan-root graph와 merged graph로 확장한다.
service-scoped worker 운영은 runtime write allowlist와 diff guard에 의존해야 한다.

Sanctum 운영 모델

<service>/
  AGENTS.md
  llm-context/
    service.md
    commands.md
    test-scope.md
    e2e-role.md
    contracts.md
    dependency-stubs.md

적용 대상은 wallet-api, kms-api, hd-manager, rust-mpc/mpc-manager-rs, rust-mpc/party-node-rs다. wallet-api worker는 wallet-facing flow를 수정하되 kms-api, hd-manager, rust-mpc, contracts/ 변경은 기본적으로 propose-only로 둔다. kms-api worker는 key operation과 security-sensitive flow 때문에 canonical runbook과 current source 확인이 우선이다. hd-manager worker는 derivation이나 lifecycle 변경 시 root/e2e validation을 요구한다. mpc-manager-rs와 party-node-rs는 orchestration과 protocol compatibility가 얽혀 있으므로 cross-crate 변경은 handoff를 기본값으로 둔다.

root/e2e agent는 cross-service flow, contract migration, e2e test orchestration을 담당한다. 그러나 root/e2e agent도 무제한 수정자가 아니며 approval, diff guard, test scope를 따라야 한다.

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

연결 주제	의존 내용
`20-graphify-evaluation`	root graph pilot, cwd-specific graph, drift, CI clean build 정책 검증
`30-sanctum-knowledge-architecture`	service `AGENTS.md`, `llm-context/`, `contracts.md` mapping, derived storage 설계
`40-worker-agent-operations`	service-scoped worker, handoff, root/e2e orchestration 실행
`50-codex-app-and-runtime-boundary`	Codex App limit correction, runtime sandbox/write allowlist/diff guard
`60-final-recommendations`	SSOT 정리, context pack, root Graphify, RAG metadata, runtime enforcement 순서

충돌 가능성 및 우선순위

Graphify 결과와 current source가 다르면 current source와 canonical SSOT를 우선한다. RAG snippet과 contracts/가 다르면 contracts/를 우선하고 RAG re-index 필요성을 기록한다. LLM Wiki 결론과 service AGENTS.md가 다르면 service AGENTS.md를 우선하고 wiki를 stale 또는 requires-review로 표시한다. Notion human SSOT와 worker context가 다르면 product fact는 Notion/approved docs를 우선하되 worker write boundary와 test command는 repo AGENTS.md와 llm-context/를 우선한다. Codex App workspace와 runtime policy가 다르면 enforced worker 작업은 runtime policy를 우선한다.

실행 로드맵

Canonical baseline: contracts/를 contract SSOT로 명시하고 root/service AGENTS.md에 worker 모델과 boundary를 기록한다.
Service context pack: 주요 서비스에 llm-context/ pack을 작성한다.
Derived Knowledge template: wallet creation, key operation, HD derivation, MPC session lifecycle, party-node compatibility note를 metadata와 함께 작성한다.
Root Graphify pilot: generated_at, commit, branch, scan root, ignore policy를 기록하고 대표 flow precision/recall을 샘플링한다.
RAG evidence layer: source type을 ssot, worker-context, derived, transient로 구분하고 revision/indexed_at/validation state를 포함한다.
Runtime enforcement: worker별 write allowlist와 diff guard를 적용하고 propose-only path 변경은 handoff report로 생성한다.
Service graph 확장: root graph가 noisy할 때만 service scan-root graph와 merged graph를 도입한다.

검증 질문

contracts/와 service llm-context/contracts.md 사이에 contract detail 복제가 없는가?
각 service worker의 boundary가 AGENTS.md와 runtime allowlist 양쪽에 존재하는가?
Graphify graph에 branch, commit, generated_at, scan root, ignore policy가 기록되는가?
Graphify 결과가 write authorization으로 쓰이지 않는가?
RAG 결과에 source type, revision, indexed_at, validation state가 포함되는가?
LLM Wiki/derived note에 confidence, validation_state, stale_when, not_allowed_use가 있는가?
wallet-api가 kms-api 또는 hd-manager 변경을 필요로 할 때 handoff가 생성되는가?
mpc-manager-rs와 party-node-rs protocol change가 root/e2e validation으로 연결되는가?
Codex App 발견 사항이 runtime-enforced workflow로 승격되는 절차가 있는가?
diff guard가 boundary 밖 파일 변경을 실제로 차단하는가?

최종 요약

10-context-management의 최종 결정은 SSOT, Graphify, RAG, LLM Wiki, runtime guard를 한 시스템 안에 두되 같은 권한으로 취급하지 않는 것이다. Graphify는 빠르게 찾게 하고, RAG는 근거를 붙이게 하고, LLM Wiki는 검증된 판단을 기억하게 한다. 하지만 canonical fact는 contracts/, AGENTS.md, llm-context/, runbook, current source에 있고 write 권한은 runtime allowlist와 diff guard에 있다.