Sanctum LLM operations reports · Stage 2 Topic HTML
Root/E2E Orchestrator Role
40-worker-agent-operations / 보고서

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 우회를 막는다.

실행 체크리스트

  1. 작업 범위, 참여 service worker, contract 변경 여부, 직접 수정 필요 여부를 확인한다.
  2. 변경 파일, 테스트 결과, 미검증 영역, cross-service 영향, 요청된 e2e scenario가 포함된 handoff를 수집한다.
  3. contracts/, root/service AGENTS.md, service llm-context/, 실제 diff를 확인한다.
  4. Graphify/RAG는 관련 파일 후보와 producer/consumer 탐색에만 사용한다.
  5. service-local, contract compatibility, e2e smoke, full cluster/distributed test 필요 여부를 포함한 matrix를 만든다.
  6. 실행한 명령, 결과, 실행하지 못한 이유, residual risk를 기록한다.
  7. write allowlist 위반, service boundary 침범, root/e2e 직접 구현 정당성을 diff guard로 확인한다.
  8. 승인 가능, 조건부 승인, service worker 재작업, contract owner 확인, release 전 e2e 필요 중 하나로 final review를 작성한다.