@walwal-harness/cli 6.1.6 → 7.1.0

package/skills/dispatcher/references/convention-flow.md

@@ -1,111 +0,0 @@
----
-docmeta:
-  id: convention-flow
-  title: Convention Flow — Positive Guide Classifier
-  type: output
-  createdAt: 2026-04-22T00:00:00Z
-  updatedAt: 2026-04-22T00:00:00Z
-  source:
-    producer: agent
-    skillId: harness-dispatcher
-  inputs:
-    - documentId: harness-dispatcher-skill
-      uri: ../SKILL.md
-      relation: output-from
-      sections:
-        - sourceRange:
-            startLine: 45
-            endLine: 100
-          targetRange:
-            startLine: 30
-            endLine: 140
-  tags:
-    - dispatcher
-    - convention
-    - positive-guidance
----
-
-# Convention Flow — Positive Guide Classifier
-
-긍정 가이드("~해야 해", "항상 ~", "이렇게 해줘")를 감지하면
-해당 스코프의 `.harness/conventions/<scope>.md` 에 `[C-NNN]` 엔트리로 append.
-
-## 1. 긍정 시그널 감지
-
-다음 패턴 중 하나라도 포함되면 Convention 후보:
-
-- 명령형: "해야 해", "~로 해줘", "이렇게 만들어", "~를 사용해"
-- 원칙 선언: "항상 ~", "모든 ~ 는", "우리는 ~ 방식", "표준은 ~"
-- 하우스 스타일: "이 프로젝트에서는 ~", "컨벤션상 ~", "규칙은 ~"
-- 영어: "always", "must", "should", "we use", "prefer", "standard is"
-
-**부정 시그널과 충돌 시 부정 우선** (Gotcha 로 라우팅). 예: "~ 하지 말고 ~ 해줘" 는 Gotcha.
-
-## 2. Scope 판별
-
-엔트리의 적용 범위를 다음 순서로 판별:
-
-1. **특정 에이전트 명시** → 해당 에이전트 파일
-   - 사용자가 명시적으로 이름 언급 ("Generator-BE 는 ~") 또는 문맥상 확실한 키워드
-2. **도메인 키워드 매칭** → 대응 에이전트
-   | 키워드 | 스코프 |
-   |--------|-------|
-   | backend, API, controller, service, DTO, NestJS, MSA | `generator-backend` |
-   | frontend, React, Next.js, UI, component, hook, Tailwind | `generator-frontend` |
-   | plan, sprint, feature-list, api-contract, roadmap | `planner` |
-   | Playwright, E2E, browser, functional test | `evaluator-functional` |
-   | layout, screenshot, a11y, responsive, viewport, AI slop | `evaluator-visual` |
-   | code quality, lint, tsc, architecture, type safety | `evaluator-code-quality` |
-3. **매칭 실패 + 여전히 에이전트 국한** → `shared.md`
-4. **프로젝트 전체 철학/원칙** (예: "우리는 TDD 한다", "보안 우선") → 루트 `CONVENTIONS.md` 에 사용자 권고 (Dispatcher 직접 수정 금지)
-
-## 3. 중복 감지
-
-대상 파일에서 기존 `[C-NNN]` 엔트리를 읽어:
-- **완전 중복** (같은 rule) → append 하지 않고 기존 엔트리의 Date 를 갱신
-- **부분 중복** (관련 주제) → 새 엔트리로 추가하되 기존 엔트리 ID 를 `Related:` 필드로 참조
-
-## 4. 엔트리 포맷
-
-```markdown
-### [C-NNN] 간결한 제목 (긍정형, 70자 이내)
-- **Date**: YYYY-MM-DD
-- **Scope**: <agent> | shared
-- **Rule**: 사용자가 말한 내용을 긍정 규칙으로 정제. 명령형 문장.
-- **Rationale**: 사용자가 설명한 이유 (없으면 "미지정" 표기, 추정 금지)
-- **Applies to**: 적용 대상 상세 (특정 파일 경로, 특정 상황, 엔드포인트 등)
-- **Added from**: 사용자 프롬프트 (YYYY-MM-DD HH:MM) | migration | manual
-- **Related**: C-XXX, C-YYY (선택)
-```
-
-### ID 할당
-
-대상 파일의 기존 `[C-NNN]` 최댓값 + 1 을 3자리 zero-pad. 예: 기존에 C-001, C-003 이 있으면 다음은 C-004 (비어있는 번호는 재사용하지 않음).
-
-## 5. 루트 CONVENTIONS.md 처리
-
-루트 `CONVENTIONS.md` 는 **사용자가 자유 기술하는 최상위 원칙 파일**. Dispatcher 가 직접 수정하지 않고, 사용자에게 안내:
-
-```
-이 규칙은 프로젝트 전체 철학에 가까워 보여서 CONVENTIONS.md(루트) 에
-직접 추가하시는 게 좋겠습니다. 추가 후 모든 에이전트가 세션 시작 시 읽습니다.
-```
-
-## 6. 사용자 확인 메시지 포맷
-
-```
-Convention 등록 완료:
-- ID: [C-004]
-- Scope: generator-backend
-- Rule: API 응답 필드는 snake_case
-- 저장 위치: .harness/conventions/generator-backend.md
-
-Generator-Backend 는 다음 세션 시작 시 이 규칙을 읽고 적용합니다.
-```
-
-## 7. 금지 사항
-
-- Convention 파일의 기존 엔트리 삭제/수정 (사용자만 가능)
-- `CONVENTIONS.md` (루트) 직접 수정
-- 추정성 rationale 작성 (근거 없으면 "미지정")
-- 에이전트 SKILL.md 자체 수정 (구조적 변경은 사용자 권고)

package/skills/dispatcher/references/gotcha-flow.md

@@ -1,79 +0,0 @@
-# Gotcha Flow — 상세 가이드
-
-## 교정 시그널 감지
-
-| 시그널 패턴 | 예시 | 확신도 |
-|------------|------|--------|
-| 명시적 부정 | "아니", "틀렸어", "no" | HIGH |
-| 행동 교정 | "그렇게 하면 안 돼", "X 하지 마" | HIGH |
-| 올바른 방법 제시 | "X는 Y로 해야 해" | HIGH |
-| 반복 불만 | "왜 또 이래", "또 같은 실수" | HIGH |
-| 암시적 교정 | "그게 아니라", "다시 해봐" | MEDIUM |
-| 질문형 | "이게 맞아?" | LOW (확인 후 판단) |
-
-**HIGH/MEDIUM만 Gotcha로 기록.**
-
-## 대상 에이전트 판별
-
-| 도메인 키워드 | 대상 |
-|-------------|------|
-| API, 엔드포인트, DB, 스키마, NestJS, Gateway, 서비스 | `generator-backend` |
-| 컴포넌트, UI, 스타일, 반응형, React, CSS, 상태 | `generator-frontend` |
-| 테스트, 검증, 통과, 기준, 채점, PASS/FAIL | `evaluator-functional` |
-| 디자인, 접근성, 색상, 레이아웃, 반응형 심사 | `evaluator-visual` |
-| 설계, 아키텍처, 기획, 기능 목록, IA, 서비스 분할 | `planner` |
-| 불명확 | 사용자에게 질문 |
-
-## 스택별 파일 네이밍 규칙 (v5.2 — 적응형 하네스)
-
-에이전트별로 **공통 파일 + 스택별 파일** 2트랙:
-
-| 파일 | 용도 |
-|------|------|
-| `.harness/gotchas/<agent>.md` | 스택 무관 공통 실수 (예: "PASS 남발", "Evidence 없는 Score") |
-| `.harness/gotchas/<agent>-<stack>.md` | 특정 스택에서만 적용되는 실수 (예: `generator-frontend-swift.md` — force unwrap 금지) |
-
-### 라우팅 규칙
-
-교정 시그널을 기록할 때:
-1. `scan-result.json.tech_stack.fe_stack` / `be_stack` 조회
-2. 시그널 내용이 스택 특정 기술(import, API, 프레임워크 함수명 등)을 언급 → `<agent>-<stack>.md`
-3. 스택 무관 일반 규칙(문서화, 테스트 태도, 평가 기준) → `<agent>.md` (공통)
-4. 판단 애매 → **공통 파일 우선** (후속 발생 시 스택별로 이관)
-
-### 에이전트 On Start 로딩
-
-적응형 에이전트는 세션 시작 시 **두 파일을 모두 로드**:
-```
-.harness/gotchas/<agent>.md              # 공통
-.harness/gotchas/<agent>-<current_stack>.md   # 스택별 (없으면 skip)
-```
-
----
-
-## Gotcha 항목 형식
-
-`.harness/gotchas/[agent-name].md` 또는 `<agent-name>-<stack>.md` 에 추가:
-
-```markdown
-### [G-NNN] 간결한 제목
-- **Date**: 2026-04-07
-- **Trigger**: "사용자 원문 요약"
-- **Wrong**: 에이전트가 했던 잘못된 행동
-- **Right**: 사용자가 지시한 올바른 행동
-- **Why**: 왜 잘못인지 근거
-- **Scope**: 항상 / 특정 조건에서만
-- **Occurrences**: 1
-```
-
-## 중복 처리
-
-1. 기존 gotchas 파일 읽기
-2. 동일/유사 항목 존재 → `Occurrences` 증가 + 날짜 업데이트
-3. 신규 → 다음 G-NNN 번호로 추가
-
-## 관리 규칙
-
-- Dispatcher만 gotchas 파일 쓰기 가능
-- 해결된 항목: `[RESOLVED]` 태그 (삭제하지 않음)
-- 20개 초과 시 가장 오래된 RESOLVED부터 정리

package/skills/dispatcher/references/initialization.md

@@ -1,53 +0,0 @@
-# Initialization Guide — Phase 0
-
-## Phase 0a: 전체 초기화 (빈 프로젝트 / 하네스 미설치)
-
-```bash
-bash scripts/scan-project.sh .
-bash scripts/init-agents-md.sh .
-```
-
-## Phase 0b: AGENTS.md 없음 (하네스는 있으나 문서 누락)
-
-```bash
-bash scripts/scan-project.sh .
-bash scripts/init-agents-md.sh .
-```
-
-## Phase 0c: 기존 CLAUDE.md 보존 + 리빌드 (브라운필드)
-
-```bash
-# 1. 스캔 — 기존 CLAUDE.md 내용을 scan-result.json에 보존
-bash scripts/scan-project.sh .
-
-# 2. 리빌드 — 기존 규칙을 "Preserved Rules" 섹션으로 이관
-#    원본은 .harness/archive/pre-harness-backup/ 에 백업
-bash scripts/init-agents-md.sh .
-```
-
-## Phase 0 이후 사용자 확인
-
-```
-AGENTS.md가 생성/리빌드되었습니다.
-
-스캔 결과:
-- 프로젝트 타입: [fullstack / backend-only / frontend-only / empty]
-- 감지된 스택: [BE] / [FE] / [DB]
-- 미분류 경로: [N]개 ([?] 태그)
-- 기존 규칙 이관: [Y/N]
-
-[?] 태그 경로를 확인해 주세요. 확인 후 요청사항을 말씀해 주시면 파이프라인을 선택합니다.
-```
-
-## scan-project.sh 감지 항목
-
-| 항목 | 감지 방법 |
-|------|----------|
-| NestJS | nest-cli.json |
-| FastAPI | requirements.txt + "fastapi" |
-| Next.js | next.config.* |
-| React/Vite | vite.config.* |
-| 모노레포 | turbo.json, nx.json, pnpm-workspace.yaml |
-| DB | package.json 내 typeorm/prisma/mongoose |
-| OpenAPI | openapi.json/yaml, swagger.json/yaml |
-| Git | .git/ 존재, 커밋 수, 브랜치 |

package/skills/dispatcher/references/pipeline-definitions.md

@@ -1,151 +0,0 @@
----
-docmeta:
-  id: pipeline-definitions
-  title: Pipeline Definitions
-  type: output
-  createdAt: 2026-04-09T00:00:00Z
-  updatedAt: 2026-04-09T00:00:00Z
-  source:
-    producer: agent
-    skillId: harness-dispatcher
-  inputs:
-    - documentId: harness-dispatcher-skill
-      uri: ../SKILL.md
-      relation: output-from
-      sections:
-        - sourceRange:
-            startLine: 58
-            endLine: 70
-          targetRange:
-            startLine: 30
-            endLine: 95
-  tags:
-    - dispatcher
-    - pipeline
-    - fe-stack
-    - flutter
----
-
-# Pipeline Definitions
-
-> **FE Stack 차원**: 모든 FE 관련 파이프라인은 `fe_stack` 필드로 스택을 기록한다.
-> Planner가 scan-result.json(`tech_stack.fe_stack`) 또는 사용자 질문으로 확정한다.
-
-## 단일 에이전트 체인 (v5.6.5+)
-
-**에이전트 이름 치환은 하지 않는다**. 모든 FE 스택(React, Next.js, Vue, Svelte, Flutter, Swift, 기타) 은 공통 `generator-frontend` / `evaluator-functional` / `evaluator-visual` 을 사용하며, 스택 특성(runner, paths, API, validation) 은 **adaptive ref-docs** (`.harness/ref/fe-<stack>.md`) 에서 로드한다.
-
-| 스택별 스킵/우회 | 방법 |
-|------------------|------|
-| Visual 렌더 검증이 불가능한 네이티브 모바일/데스크톱 | ref-docs 의 `validation.visual.enabled = false` — `evaluator-visual` 이 MANUAL_REQUIRED 로 우아하게 우회 |
-| Playwright 대신 스택 네이티브 E2E (예: XCUITest, Flutter `flutter_driver`) | ref-docs 의 `validation.functional_tests` 에 해당 명령 나열 — `evaluator-functional` 이 로드 실행 |
-
-Dispatcher 는 `fe_stack` 을 `pipeline.json` 에 기록만 하고, 에이전트 이름은 변경하지 않는다. Generator/Evaluator 는 세션 시작 시 스스로 ref-docs 를 로드해 스택에 맞는 동작을 한다.
-
-## Evaluator Chain (공통)
-
-모든 파이프라인의 Generator 이후 단계는 **평가자 체인**으로 처리한다. 직렬 실행 + 조기 종료:
-
-```
-Generator → evaluator-code-quality → evaluator-functional → evaluator-visual → archive
-                    │                        │                      │
-                    └─ FAIL ─ reroute ────────┴──────────────────────┘
-                              → Generator (failure.retry_target)
-```
-
-- **code-quality** (정적, 저비용, 브라우저 없음): BE/FE/libs 공통 코드 품질
-- **functional** (동작, 중비용): API·E2E 행동 검증
-- **visual** (렌더, 고비용): 레이아웃/접근성
-
-앞단 FAIL 시 뒷단은 실행하지 않는다. 구조가 깨진 코드에 동작 테스트 낭비 방지.
-
-## FE-ONLY
-
-```yaml
-trigger: 외부 API 존재 + FE 작업 요청
-agents:
-  - planner (light):
-      skip: MSA 서비스 설계, BE 기능 목록
-      do: OpenAPI → api-contract.json 변환, FE 컴포넌트 설계, feature-list (layer: frontend만), fe_stack 확정
-  - generator-frontend                                 # 모든 스택 공통 (ref-docs 로드)
-  - evaluator-code-quality                             # 공통 — 브라우저 없음
-  - evaluator-functional                               # 모든 스택 공통
-  - evaluator-visual                                   # ref.validation.visual.enabled=false 면 MANUAL_REQUIRED 로 우회
-evaluator_chain:
-  - evaluator-code-quality
-  - evaluator-functional
-  - evaluator-visual
-skip:
-  - generator-backend
-notes:
-  - api-contract.json은 OpenAPI에서 파생 (Planner가 변환)
-  - Eval-Func 의 API Health Check는 외부 서버 대상 (ref.api.base_url)
-  - AGENTS.md IA-MAP에 BE 경로 없음 (외부 서버)
-  - 네이티브 모바일/데스크톱 스택은 ref-docs 에서 visual.enabled=false 로 설정
-```
-
-## BE-ONLY
-
-```yaml
-trigger: 기존 서버 + BE 기능 추가 요청
-agents:
-  - planner:
-      skip: FE 컴포넌트 설계, 비주얼 요구사항
-      do: 기존 코드 분석, 신규 API 설계, api-contract.json 확장
-  - generator-backend
-  - evaluator-code-quality                  # 공통
-  - evaluator-functional:
-      mode: api-only
-      skip: browser 테스트
-      do: curl/httpie로 API 엔드포인트 직접 검증
-evaluator_chain:
-  - evaluator-code-quality
-  - evaluator-functional
-skip:
-  - generator-frontend
-  - evaluator-visual
-notes:
-  - Eval-Func는 Playwright 대신 CLI 기반 API 테스트
-  - Code-Quality 는 BE 코드의 레이어/DI/DTO/에러 전파/테스트 품질 감사
-```
-
-## FULLSTACK
-
-```yaml
-trigger: 신규 PRD / 제품 설명
-agents:
-  - planner (full)
-  - generator-backend
-  - generator-frontend
-  - evaluator-code-quality
-  - evaluator-functional
-  - evaluator-visual
-evaluator_chain:
-  - evaluator-code-quality
-  - evaluator-functional
-  - evaluator-visual
-skip: none
-```
-
-## pipeline.json Output Format
-
-```json
-{
-  "decided_at": "ISO 8601",
-  "user_request_summary": "요약",
-  "detected_signals": ["시그널1", "시그널2"],
-  "pipeline": "FE-ONLY | BE-ONLY | FULLSTACK",
-  "agents_active": ["agent1", "agent2"],
-  "agents_skipped": ["agent3"],
-  "planner_mode": "light | full",
-  "evaluator_mode": "browser | api-only",
-  "api_source": { "type": "openapi | internal", "location": "URL or path" },
-  "notes": "추가 컨텍스트"
-}
-```
-
-## Disambiguation (불명확 시 질문)
-
-1. "백엔드 API가 이미 존재합니까? (OpenAPI/Swagger 문서 있음?)"
-2. "프론트엔드 UI가 필요합니까?"
-3. "신규 프로젝트입니까, 기존 프로젝트에 추가입니까?"

package/skills/documentationer/SKILL.md

@@ -1,92 +0,0 @@
----
-name: harness-documentationer
-description: "COO 직속 Documentationer. 웹 리서치, 실험 로그 정리, 보고서 작성, 가설 유효/무효 판정을 담당한다. 운영 문서보다는 의사결정 문서에 초점을 둔다. 트리거: 'report', 'documentation', 'research brief', 'hypothesis verdict'."
-disable-model-invocation: false
----
-
-# Documentationer
-
-> 리서치와 실험을 문장으로 묶어 COO가 즉시 판단할 수 있는 보고서로 바꾼다.
-
-## 1. 책임
-
-- 웹 리서치 기반 가설 보강
-- `coo-developer` 실험 결과 정리
-- 가설 검증 보고서 작성
-- 가설의 유효/무효/보류 판정 및 근거 명시
-
-## 2. 입력
-
-- Planner의 가설 브리프
-- Service-Ops의 드리프트 신호 또는 신규 기획 방향
-- `coo-developer`의 실험 결과
-- 필요 시 외부 리서치 소스
-
-## 3. 출력 (산출물 경로 표준)
-
-- `.harness/actions/hypothesis/<id>/brief.md` — `hypothesis-brief` (사전 리서치)
-- `.harness/actions/hypothesis/<id>/report.md` — `validation-report` (실험 후 통합)
-- `.harness/actions/hypothesis/<id>/evidence/` — 출처 스냅샷·캡처
-- `.harness/actions/hypothesis/<id>/verdict.json` — 기계 판독 판정
-
-`verdict.json` 스키마 (필수 필드):
-
-```json
-{
-  "id": "H-...",
-  "hypothesis": "한 줄 가설",
-  "verdict": "supported | refuted | inconclusive",
-  "confidence": 0.0,
-  "key_evidence": [
-    {"source": "actions/hypothesis/<id>/spike/run.log", "kind": "experiment"},
-    {"source": "https://...", "kind": "external-research"}
-  ],
-  "next_action": "promote-to-sprint | additional-experiment | discard",
-  "rationale": "왜 이 판정인가 — evidence 와 직접 연결",
-  "open_questions": ["..."],
-  "limitations": ["..."]
-}
-```
-
-`progress.json` 업데이트 (완료 시):
-
-```bash
-bash scripts/harness-progress-set.sh . \
-  '.documentationer.last_report = "actions/hypothesis/<id>/report.md" |
-   .documentationer.last_verdict = "actions/hypothesis/<id>/verdict.json"'
-```
-
-## 4. 보고서 규칙
-
-- 결론 먼저, 근거 다음
-- 주장마다 evidence 출처 명시 (URI 또는 artifact path)
-- 운영팀/CTO/CQO가 바로 이어받을 수 있게 열린 질문을 분리
-- "왜 아직 확실하지 않은가"도 반드시 적을 것
-- `verdict` 는 supported / refuted / inconclusive 셋 중 하나로만 — 모호한 표현 금지
-
-## 5. 금지
-
-- evidence 없는 유효 판정
-- CTO/CQO 검증을 대신했다고 표현
-- 실험 로그를 정제 없이 그대로 보고서로 제출
-
-## 6. Parallel-Tracks 컨텍스트 (v6.2)
-
-`validation-report` 는 followup-review 회의에서 **track deliverable** 로 사용된다.
-
-- followup-review 의 Meeting-Manager 는 `prior_tracks[].deliverable_path` 를 통해 이 보고서를 읽는다.
-- `verdict.json` 의 `next_action` 이 `promote-to-sprint` 면 followup 결정은 보통 `apply-now`, `additional-experiment` 면 `more-validation`, `discard` 면 `backlog` 또는 종결.
-- 형제 트랙 (예: `track-1: cto/bugfix`) 의 결과는 별도 deliverable. 둘을 함께 보고 결정자(CTO 또는 CEO) 가 통합한다 — Documentationer 가 직접 통합 결정을 내리지 않는다.
-
-## 7. Session Boundary
-
-### On Start
-1. `.harness/progress.json` 읽기 — `planner.last_brief` 확인 (`hypothesis:research` 또는 `hypothesis:report`)
-2. brief=research 면 `brief.md` 작성, brief=report 면 `coo-developer` 의 spike 결과를 `report.md` 로 통합
-3. `.harness/conventions/documentationer.md`, `.harness/gotchas/documentationer.md` 읽기
-4. (v6.2) parallel 모드면 형제 트랙 owner 의 gotcha 도 한 번 훑기
-
-### On Complete
-1. `report.md` + `verdict.json` 작성 완료
-2. partial update: `documentationer.last_report`, `documentationer.last_verdict`, `agent_status = "completed"`
-3. `next_agent = "planner"` (hypothesis-verdict 종합)

package/skills/evaluator-architecture/SKILL.md

@@ -1,173 +0,0 @@
----
-name: harness-evaluator-architecture
-description: "아키텍처 축 평가자. CQO 산하 4번째 Eval 축. IA-MAP 준수·결합도/응집도·계층 위반·의존 그래프·api-contract 일치·DB 설계·서비스 경계·확장성 검증. Default-to-FAIL, 권한·계층 위반 1건 = FAIL. 트리거: 'eval architecture', '아키텍처 검증', 'arch audit'."
-disable-model-invocation: false
----
-
-<!--
-Source: https://github.com/msitarzewski/agency-agents (MIT)
-재해석 출처:
-- engineering/engineering-software-architect.md
-- engineering/engineering-backend-architect.md
-- engineering/engineering-database-optimizer.md
-- engineering/engineering-minimal-change-engineer.md
-- specialized/specialized-workflow-architect.md
--->
-
-# Evaluator-Architecture — 아키텍처 축 평가자
-
-> "코드는 동작하지만 아키텍처가 무너졌다면 그것은 부채다. 부채는 기술적이 아니라 구조적이다."
-> CQO 산하, Eval 5축 중 아키텍처.
-
-## 1. 정체성
-
-- **위치**: CQO 산하, Eval-Functional/Visual/CodeQuality/Security와 평행
-- **책임**: 변경된 코드가 IA-MAP·api-contract·서비스 경계·결합/응집 원칙을 준수하는지 적대적 검증
-- **금지**: Generator 작업 지시, 점수 임의 부여, 구현 디테일에 매몰(코드 한 줄이 아니라 흐름·경계·의존이 평가 대상)
-
-## 2. 검증 축 (sub-axis)
-
-| Sub-axis | 측정 도구·방법 | 통과 기준 |
-|---|---|---|
-| IA-MAP 준수 | git diff vs AGENTS.md 권한 매트릭스 | 권한 위반 0건 |
-| 의존 그래프 | madge / dependency-cruiser / pydeps / phpstan | 순환 0건, 신규 cross-layer 0건 |
-| 결합도 | 모듈 간 import 다양성·인터페이스 안정성 | 신규 fan-out > 5 alarm |
-| 응집도 | 동일 모듈 내 책임 단일성 | "유틸 dump" 안티패턴 0건 |
-| api-contract 일치 | 구현 vs `.harness/actions/api-contract.json` | 100% 일치 |
-| DB 설계 | 스키마 diff·인덱스·정규화·N+1 | N+1 0건, 누락 인덱스 0건 |
-| 서비스 경계 | 마이크로서비스 직접 DB 접근 / 메시지 패턴 | 직접 접근 0건 |
-| 확장성 | 알려진 부하 시나리오 추정 | 명시적 한계 표기 |
-
-## 3. 평가 절차
-
-```
-1. 사전조건:
-   - sprint-contract.md 변경 영역 식별
-   - AGENTS.md IA-MAP 로드
-   - api-contract.json 로드
-   - 직전 baseline 의존 그래프 로드 (없으면 생성)
-2. 자동 분석:
-   - madge·dependency-cruiser 등으로 그래프 산출
-   - 순환 의존 / 계층 위반 / 신규 cross-layer 검출
-   - DB 마이그레이션·쿼리 분석 (eager/lazy, 인덱스, N+1)
-3. 수동 분석:
-   - api-contract vs 실제 라우트·DTO 1:1 매핑
-   - 새 모듈의 책임 단일성 (1줄 정의 가능 여부)
-   - 변경이 IA-MAP 권한 매트릭스를 위반하는지
-4. 점수 산출 (0~3, rubric 5절)
-5. 평가서 작성 + Cross-Validation 큐잉
-```
-
-## 4. Evidence 카탈로그 (필수)
-
-`evaluation-architecture-<feature>.md` 에 다음 모두 포함:
-
-- 의존 그래프 이미지 (또는 텍스트 출력) — before/after diff 강조
-- 권한 위반 표: `file | owner_required | actual_change_by | severity`
-- api-contract 매핑표: `endpoint | dto | implementation_path | match`
-- DB 변경 표: `migration | indexes | N+1_risk | est_query_count`
-- 신규 모듈별 책임 1줄 설명
-- 결합도/응집도 측정값 + baseline 대비 delta
-- 명시적 한계·확장 시나리오
-
-증거 0건 + 점수 ≥ 2.80 → CQO가 rubber-stamping 적발 → 자체 FAIL.
-
-## 5. Rubric
-
-| 점수 | 의미 | 조건 |
-|---|---|---|
-| 3.00 | Excellent | 위반 0 + 결합도 개선 + 의존 그래프 단순화 |
-| 2.85 | Strong PASS | 위반 0 + 신규 부채 0 |
-| 2.80 | Threshold PASS | 위반 0 (개선은 미미) |
-| 2.50 | Borderline FAIL | 결합도 ↑ + 새 cross-layer 1건 |
-| 2.00 | FAIL | api-contract 불일치 1건 또는 권한 위반 1건 |
-| 1.00 | Strong FAIL | 순환 의존 신규 / 직접 DB 접근 / N+1 신규 |
-| 0.00 | Reject | IA-MAP 권한 위반 / Evidence-zero / api-contract 메이저 변경 무허가 |
-
-## 6. Cross-Validation 트리거
-
-| 발견 | Alert 대상 | 사유 |
-|---|---|---|
-| api-contract 불일치 | Eval-Functional | AC가 잘못 작성됐을 가능성 |
-| 권한 매트릭스 위반 | Eval-Security | 보안 가드 우회 가능성 |
-| N+1 / 인덱스 누락 | Eval-CodeQuality | 성능 베이스라인 위반 |
-| 직접 DB 접근 | Eval-Functional | 메시지 패턴 미사용 → AC 재정의 필요 |
-
-## 7. Regression Checkpoint
-
-매 Sprint 종료 시:
-- 직전 baseline 의존 그래프 vs 현재 비교
-- 신규 순환·신규 cross-layer 1건이라도 회귀 → Sprint 전체 FAIL
-
-## 8. 도구 통합 (스택별)
-
-| 스택 | 의존 그래프 | DB 분석 |
-|---|---|---|
-| Node/TS | madge, dependency-cruiser | prisma-er-diagram, eslint-plugin-prisma |
-| Python | pydeps, snakefood | sqlalchemy schema introspection |
-| PHP/Laravel | phpstan, deptrac | EloquentDumper, telescope query log |
-| Go | go mod graph + custom | gorm query logger |
-
-도구 미설치 → cqo-audit에 install 권고 첨부.
-
-## 9. 흔한 안티패턴 (자동 검출 룰)
-
-| 안티패턴 | 룰 | Severity |
-|---|---|---|
-| God Object / God Service | 한 모듈의 의존 fan-out > 12 | High |
-| Circular dependency | 그래프 cycle 검출 | High |
-| Direct DB cross-service | service-A 가 service-B의 ORM 호출 | Critical |
-| Anemic domain | DTO만 있고 도메인 행동 없음 (선택적) | Medium |
-| Magic config bypass | 환경변수 없이 하드코드 | Medium |
-| API leakage | 내부 모델이 그대로 외부 응답 | High |
-| N+1 in hot path | feature가 list 응답인데 개별 fetch 패턴 | High |
-
-## 10. progress.json 추가
-
-```json
-"eval_architecture": {
-  "last_audit": "<iso>",
-  "open_violations": 0,
-  "new_cycles": 0,
-  "api_contract_mismatches": 0,
-  "graph_baseline_path": ".harness/baselines/dep-graph-*.json",
-  "audit_path": ".harness/actions/evaluation-architecture-*.md"
-}
-```
-
-## 11. 권한 매트릭스
-
-| 파일 | 읽기 | 쓰기 |
-|---|---|---|
-| 코드 (apps/, libs/) | ✅ | ❌ |
-| evaluation-architecture-*.md | ✅ | ✅ |
-| api-contract.json | ✅ | Change Request 첨부만 |
-| AGENTS.md (IA-MAP) | ✅ | Change Request 첨부만 (Planner 전용) |
-| feature-list.json | ✅ | passes 필드 confirm만 |
-| .harness/baselines/ | ✅ | ✅ (의존 그래프 baseline 저장) |
-
-## 12. Session Boundary Protocol
-
-### On Start
-1. progress.json 읽기 → 평가 대상 feature·diff 식별
-2. partial update: `current_agent = "evaluator-architecture"`, `agent_status = "running"`
-3. 직전 baseline 로드, 없으면 생성하고 baseline_only 모드로 표시(점수 X)
-
-### On Complete
-1. evaluation-architecture-<feature>.md finalize
-2. baseline 갱신
-3. partial update:
-   - `eval_architecture.*` 필드
-   - feature-list.json passes.architecture
-   - `agent_status = "completed"`, `next_agent` 결정
-4. CQO에 cross-validation 큐잉
-5. High 이상 위반 발견 시 즉시 Conductor에 alert (Spec Review 검토)
-
-## 13. 출처 (Attribution)
-
-agency-agents (MIT) 흡수:
-- `engineering-software-architect`: 트레이드오프·결합/응집 원칙
-- `engineering-backend-architect`: BE 경계·메시지 패턴
-- `engineering-database-optimizer`: DB 설계·N+1·인덱스
-- `engineering-minimal-change-engineer`: 변경 최소화 검증
-- `specialized-workflow-architect`: 시스템 워크플로 평가