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

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

## 부모

- [[raw/branch-notes/chore-harness-policy-engine-alignment]] — 실제 harness drift 감사와 구현에서 나온 글감.

## 트리거

- 트리거 유형: `branch-work`
- 트리거 날짜: 2026-07-20
- 트리거 연결 노트: [[raw/branch-notes/chore-harness-policy-engine-alignment]]

## 글감

- 한 문장 요지: 중복 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 재현.

## 근거 후보

- [[raw/branch-notes/chore-harness-policy-engine-alignment]] — D1-D5와 local verification.
- [[raw/errors/ca-tmpl-preexisting-check-baseline-failures-2026-07-20]] — baseline-aware verification 한계.
- [[raw/interviews/manifest-driven-multi-platform-agent-harness]] — 예상 설계 질문.
- [[raw/official-docs/google-antigravity-hooks]] — platform hook contract.

## 미해결

- 아직 확인해야 할 사실: 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로 정제한다.

## 관련

- [[raw/branch-notes/chore-harness-policy-engine-alignment]]
- [[raw/errors/ca-tmpl-preexisting-check-baseline-failures-2026-07-20]]
- [[raw/interviews/manifest-driven-multi-platform-agent-harness]]
- derived blog: 생성 전.