82 lines
4.0 KiB
Markdown
82 lines
4.0 KiB
Markdown
---
|
|
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: 생성 전.
|
|
|