Root/E2E Orchestrator Role 향상 보고서
보고서 목적
이 보고서는 Sanctum LLM 운영 모델에서 root/e2e agent가 맡아야 할 역할을 실행 관점으로 재정리한다. 서비스별 워커가 자기 서비스 안에서 좁게 쓰도록 제한되면 cross-service 변경과 contract alignment를 닫을 책임자가 필요하다.
핵심 결론
root/e2e agent는 통합 구현자가 아니라 통합 검증자이자 orchestration controller다. 서비스별 worker는 자기 서비스 내부 구현과 local test를 담당하고, root/e2e agent는 서비스 간 요청 흐름과 contract alignment 검증, contracts/ 변경 파급 범위 조정, service worker handoff 수집, e2e/integration test matrix, final diff review, release 전 승인 권고를 담당한다.
Graphify와 RAG는 관련 파일, consumer, producer, flow 후보를 찾는 데 유용하지만 최종 판단은 실제 파일, canonical contracts/, root/service AGENTS.md, service llm-context/, 테스트 결과, handoff evidence에 근거해야 한다.
권장 boundary
권장 write boundary는 root-level orchestration docs, e2e test files, integration fixtures, 명시적 contract-change task 또는 worker handoff가 있는 contracts/, service llm-context/e2e-role.md, cross-service reference 문서다. 서비스 내부 대규모 구현 변경이나 보안 민감 로직 변경은 금지 또는 propose-only다.
read boundary는 넓다. root/service AGENTS.md, contracts/, service llm-context/, handoff, tests, fixtures, deployment/runbook docs, Graphify graph, RAG results를 읽을 수 있다.
Sanctum 적용 해석
wallet-api signing request payload가 바뀌면 root/e2e agent는 contracts/ signing request contract, kms-api handler, mpc-manager-rs session parameter 변환, party-node-rs 영향, error response와 e2e fixture 갱신 여부를 확인해야 한다.
kms-api key authorization 또는 signing delegation 변경은 wallet caller contract, HD derivation dependency, MPC flow request shape, secret-safe review 상태를 확인해야 한다. hd-manager 변경은 derivation output과 consumer interpretation을, MPC 변경은 manager-party protocol boundary, session lifecycle, full cluster test 필요 여부를 확인해야 한다.
운영 판단
- 초기 root/e2e agent는 review-only로 시작한다.
- 운영이 안정되면 e2e test, integration fixture, root runbook, service
llm-context/e2e-role.md, contract mapping 문서 갱신을 허용한다. - canonical contract semantics 변경은 명시 task와 affected consumer validation이 있을 때만 허용한다.
- final diff review는 변경 목적, 서비스별 변경, contract 변경 여부, test result, 미검증 영역, write boundary 위반 여부, approval recommendation을 포함하는 engineering artifact여야 한다.
- e2e 미실행은 pass가 아니라 residual risk와 release 전 follow-up 조건으로 기록한다.
리스크와 가드레일
- root agent가 super-worker가 되지 않도록 service-internal large implementation patch는 해당 service worker에게 되돌린다.
- Graphify, RAG, generated summary를 contract authority로 쓰지 않고
contracts/와 사람이 관리하는 canonical 문서를 우선한다. - Graph drift를 고려해 초기에는 root graph pilot으로 freshness rule을 단순화한다.
- service graph는 noise를 줄이지만 cross-service flow를 놓칠 수 있으므로 root graph noise가 실측될 때 도입한다.
- approval metadata와 실제 diff path를 대조해 approval scope 우회를 막는다.
실행 체크리스트
- 작업 범위, 참여 service worker, contract 변경 여부, 직접 수정 필요 여부를 확인한다.
- 변경 파일, 테스트 결과, 미검증 영역, cross-service 영향, 요청된 e2e scenario가 포함된 handoff를 수집한다.
contracts/, root/serviceAGENTS.md, servicellm-context/, 실제 diff를 확인한다.- Graphify/RAG는 관련 파일 후보와 producer/consumer 탐색에만 사용한다.
- service-local, contract compatibility, e2e smoke, full cluster/distributed test 필요 여부를 포함한 matrix를 만든다.
- 실행한 명령, 결과, 실행하지 못한 이유, residual risk를 기록한다.
- write allowlist 위반, service boundary 침범, root/e2e 직접 구현 정당성을 diff guard로 확인한다.
- 승인 가능, 조건부 승인, service worker 재작업, contract owner 확인, release 전 e2e 필요 중 하나로 final review를 작성한다.