Files
llm-wiki/raw/blog-topics/manifest-driven-agent-harness-policy-engine.md
T

4.0 KiB

title, source_type, status, related_branches, related_projects, tags, created, status_label, target_audience, inspiration_url, archive_url
title source_type status related_branches related_projects tags created status_label target_audience inspiration_url archive_url
blog-topic / manifest-driven-agent-harness-policy-engine blog-topic raw
chore-harness-policy-engine-alignment
ca-skeleton
blog-topic
ca-skeleton
architecture
build-tooling
code-generation
2026-07-20 captured backend-engineer

blog-topic: manifest-driven-agent-harness-policy-engine

부모

트리거

글감

  • 한 문장 요지: 중복 prompt 모음을 module registry, strict evidence, deterministic renderer, risk profile을 가진 실행 가능한 policy engine으로 바꾼 과정.
  • 예상 제목 후보:
    • Clean Architecture Agent Harness를 Manifest-Driven Policy Engine으로 바꾸기
    • Prompt 동기화가 아니라 Mutation Test로 지키는 멀티 플랫폼 개발 하네스

핵심 주장 후보

  • 사실 후보: flat path gate는 실제 nested adapter production 경로를 놓쳤다 — 근거: branch §마주친 문제.
  • 사실 후보: 19개 leaf registry를 Gradle/import/agent consumer가 함께 사용한다 — 근거: branch D1.
  • 경험 후보: 세 차례 architecture review와 spec review에서 revision surface, risk, verdict evidence의 우회를 mutation test로 닫았다 — 근거: branch §검증 결과.
  • 의견/해석 후보: agent prompt를 문서가 아니라 생성·검증 가능한 artifact로 다뤄야 장기 drift를 줄일 수 있다.

Outline seed

  1. 감사에서 드러난 topology drift — legacy flat path가 왜 green test 뒤에 숨었는지.
  2. registry와 immutable task packet — module owner, profile, rule hash를 한 번 resolve하는 방식.
  3. platform renderer와 thin adapter — 공통 의미와 제품별 hook 문법을 분리하는 방식.
  4. fail-closed evidence chain — counts, command rows, revision, upstream artifact를 검증한 이유.
  5. risk-based ceremony — N!·전수 matrix 대신 low/medium/high와 evidence profile을 쓴 이유.
  6. 검증의 경계 — static parity는 external authenticated E2E가 아니며 baseline failure도 별도로 남겨야 한다.

Canonical 전환 후보 / Canonical extraction candidates

  • wiki/projects/ca-tmpl/manifest-driven-agent-harness.md 후보: ca-tmpl 실제 구조·테스트·review 결과.
  • wiki/concepts/agent-harness-policy-engine.md 후보: registry, renderer, evidence identity의 일반 패턴.
  • 필요한 추가 검증: 실제 세 플랫폼 golden run, production full check green, CI에서 physical surface 설치·parity 재현.

근거 후보

미해결

  • 아직 확인해야 할 사실: authenticated products에서 같은 seeded task의 verdict/evidence parity.
  • 과장하면 안 되는 부분: repository-local static parity와 mutation test만 locally-verified다.
  • 블로그 전에 필요한 canonical 정제: code path/command evidence를 wiki/projects 문서로 승격하고 external golden 결과를 추가한다.

처리 결정

  • 액션: keep-as-topic
  • 이유: 구현과 local evidence는 충분하지만 external golden과 production full check가 남아 있다.
  • 다음 단계: 후속 검증 뒤 project/concept canonical로 정제한다.

관련