@walwal-harness/cli 6.1.5 → 7.1.0

package/skills/planner/references/api-contract-schema.md

@@ -1,34 +0,0 @@
-# API Contract Schema
-
-```json
-{
-  "version": "1.0.0",
-  "gateway_base_url": "/api/v1",
-  "services": {
-    "gateway": { "port": 3000, "description": "API Gateway" },
-    "service-a": { "port": 3001, "transport": "TCP", "description": "..." }
-  },
-  "endpoints": [
-    {
-      "id": "EP-001",
-      "method": "POST",
-      "path": "/api/v1/items",
-      "gateway_route": true,
-      "target_service": "service-a",
-      "message_pattern": "create_item",
-      "description": "...",
-      "request_body": { "name": "string (required)" },
-      "response_200": { "id": "number", "name": "string", "created_at": "string (ISO 8601)" },
-      "response_errors": [
-        { "status": 400, "when": "유효성 검증 실패" }
-      ],
-      "related_features": ["F-001"]
-    }
-  ]
-}
-```
-
-## 규칙
-- Gateway가 외부 진입점, 내부 서비스는 message pattern으로 통신
-- request/response 스키마는 Pydantic/class-validator로 직접 변환 가능한 수준
-- 이 계약서가 Frontend ↔ Gateway ↔ Services 간 유일한 진실의 원천

package/skills/planner/references/fe-stack-detection.md

@@ -1,164 +0,0 @@
----
-docmeta:
-  id: fe-stack-detection
-  title: FE Stack Detection — Planner Responsibility
-  type: output
-  createdAt: 2026-04-09T00:00:00Z
-  updatedAt: 2026-04-09T00:00:00Z
-  source:
-    producer: agent
-    skillId: harness-planner
-  inputs:
-    - documentId: clue-fe-flutter-skill
-      uri: ../../../../../moon_web/clue-fe-flutter.skill
-      relation: output-from
-      sections:
-        - sourceRange:
-            startLine: 1
-            endLine: 103
-          targetRange:
-            startLine: 79
-            endLine: 94
-    - documentId: harness-planner-skill
-      uri: ../SKILL.md
-      relation: output-from
-      sections:
-        - sourceRange:
-            startLine: 26
-            endLine: 56
-          targetRange:
-            startLine: 27
-            endLine: 78
-  tags:
-    - planner
-    - fe-stack
-    - flutter
-    - pipeline
----
-
-# FE Stack Detection — Planner Responsibility
-
-Planner는 Sprint 1 착수 전 반드시 `fe_stack`을 확정하고 `pipeline.json`에 기록해야 한다.
-
-## 1. 감지 순서 (자동)
-
-```
-1. .harness/actions/scan-result.json 의 tech_stack.fe_stack 읽기
-2. 값이 "flutter" 또는 "react" 면 → 그대로 사용
-3. 값이 없거나 "unknown" 이면 → 아래 추가 감지
-```
-
-### 추가 감지 (fallback)
-
-| 시그널 | 판정 |
-|--------|------|
-| 루트 `pubspec.yaml` + `flutter:` 키 존재 | `flutter` |
-| 하위 경로(예: `mobile/`, `apps/mobile/`, `clue_mobile_app/`)에 pubspec.yaml | `flutter` |
-| `package.json` 에 `react`, `next`, `vite` 등 | `react` |
-| `lib/` + `.dart` 파일 다수 | `flutter` |
-| 둘 다 존재 (Flutter + Web 혼재) | **사용자 질문 필수** |
-
-## 2. 사용자 질문 (불명확 시 단 한 번)
-
-```
-프론트엔드 스택을 확인합니다:
-
-(A) React / Next.js / Vite 기반 Web
-(B) Flutter (Dart, 모바일/데스크톱)
-
-현재 감지된 시그널:
-- pubspec.yaml: [있음/없음]
-- package.json: [있음/없음]
-- Next.js config: [있음/없음]
-
-어떤 스택으로 진행하시겠습니까? (A/B)
-```
-
-혼재 프로젝트(Web + Flutter mobile)라면 사용자에게 **현 스프린트의 타깃**을 묻는다 — 파이프라인은 한 번에 하나의 `fe_stack`만 취급한다.
-
-## 2.5 fe_target 확정 (Flutter 전용)
-
-`fe_stack == "flutter"` 인 경우, **반드시** `fe_target` 도 함께 확정해야 한다 (`web` | `mobile` | `desktop`).
-이는 Flutter Web vs Mobile/Desktop 에서 사용 가능한 API, 빌드 명령, evaluator 가 달라지기 때문이다.
-
-### 자동 감지 (scan-result.json 의 `tech_stack.fe_target`)
-
-| 시그널 | fe_target |
-|--------|-----------|
-| `<flutter_root>/web/index.html` 존재 | `web` |
-| `<flutter_root>/android/` 또는 `ios/` 존재, web/ 없음 | `mobile` |
-| `<flutter_root>/macos/`, `windows/`, `linux/` 존재 (mobile/web 없음) | `desktop` |
-| 없음 | `unknown` |
-
-### 사용자 질문 (불명확하거나 multi-target)
-
-```
-Flutter 프로젝트의 타깃을 확인합니다:
-
-(A) Web — 브라우저 (Chrome/Safari/Firefox), 컴파일 결과는 HTML+JS+CSS
-(B) Mobile — Android / iOS 네이티브 빌드
-(C) Desktop — macOS / Windows / Linux 네이티브 빌드
-
-감지된 시그널:
-- web/index.html: [있음/없음]
-- android|ios/: [있음/없음]
-- macos|windows|linux/: [있음/없음]
-
-이번 스프린트의 타깃은? (A/B/C)
-```
-
-### fe_target 과 Eval 흐름 (v5.6.5+)
-
-에이전트 이름 치환은 하지 않는다. 모든 스택이 공통 `generator-frontend` / `evaluator-functional` / `evaluator-visual` 을 사용하고, 스택 특성은 `.harness/ref/fe-<stack>.md` (adaptive ref-docs) 의 `validation` 블록으로 조절된다.
-
-| fe_target | 전략 | 방법 |
-|-----------|------|------|
-| `web` (Flutter Web, Next.js 등) | 일반 Playwright 평가 | ref.validation.visual.enabled = true |
-| `mobile` (iOS/Android 네이티브) | Visual 은 MANUAL_REQUIRED | ref.validation.visual.enabled = false + functional_tests 에 스택 네이티브 명령 |
-| `desktop` (macOS/Windows/Linux 네이티브) | Visual MANUAL_REQUIRED | 동일 |
-
-Generator 는 `ref.runner.dev_command` / `ref.paths.*` 를 로드해 스택별 빌드·테스트·구조를 따른다.
-
-## 3. pipeline.json 갱신
-
-`fe_stack` + `fe_target` 확정 후 `pipeline.json` 에 기록:
-
-```json
-{
-  "pipeline": "FULLSTACK",
-  "planner_mode": "full",
-  "fe_stack": "flutter",
-  "fe_target": "mobile",
-  "agents_active": [
-    "planner",
-    "generator-backend",
-    "generator-frontend",
-    "evaluator-code-quality",
-    "evaluator-functional"
-  ],
-  "agents_skipped": [],
-  "evaluator_mode": "native",
-  "notes": "Flutter mobile — ref.validation.visual.enabled=false, evaluator-visual 은 MANUAL_REQUIRED 로 우회."
-}
-```
-
-### fe_stack + fe_target → 파이프라인 매핑
-
-| pipeline | 에이전트 체인 (스택 무관) | ref-docs 로 조절되는 부분 |
-|----------|--------------------------|---------------------------|
-| FULLSTACK | planner → gen-be → gen-fe → eval-code-quality → eval-func → eval-visual | Gen/Eval 모두 ref.* 로드 |
-| FE-ONLY | planner(light) → gen-fe → eval-code-quality → eval-func → eval-visual | 동일 |
-| BE-ONLY | planner → gen-be → eval-code-quality → eval-func | visual 체인 없음 |
-
-## 4. Flutter 등 네이티브 스택 선택 시 추가 작업
-
-1. **AGENTS.md IA-MAP** 의 `[FE]` 섹션에 해당 스택 구조 반영 (예: Flutter 면 `lib/ui/pages/`, `integrated_data_layer/` 등).
-2. **api-contract.json** 은 언어 중립 스키마 JSON — Generator 가 스택 타입으로 변환.
-3. **feature-list.json** 의 `layer: "frontend"` feature 에 `fe_stack` 태그 유지 (필터링 용도).
-4. **`.harness/ref/fe-<stack>.md`** 의 `validation` 블록을 스택에 맞게 채워 두기 — 이게 실제 동작을 바꾸는 유일한 지점.
-
-## 5. 금지
-
-- 파이프라인 실행 도중 `fe_stack` 변경 금지 — 스프린트 경계에서만 가능
-- 서로 다른 스택 코드 혼재 생성 금지 — Generator 는 하나의 stack만 담당
-- 사용자가 명시적으로 한 스택을 지시했는데 감지 결과로 다른 스택을 강제하지 말 것

package/skills/planner/references/ia-map-guide.md

@@ -1,31 +0,0 @@
-# IA-MAP Guide
-
-## 형식
-
-```
-├── path/to/dir/    # [TAG] 한줄 설명    → 소유 에이전트
-```
-
-## 태그
-
-| 태그 | 의미 | 소유 |
-|------|------|------|
-| `[BE]` | Backend | Generator-Backend |
-| `[FE]` | Frontend | Generator-Frontend |
-| `[HARNESS]` | 하네스 시스템 | Planner / Evaluator |
-| `[META]` | 프로젝트 메타 | Planner |
-| `[INFRA]` | 인프라/배포 | Planner |
-| `[TEST]` | 테스트 코드 | Evaluator / Generator |
-| `[?]` | 미분류 | TBD (Planner가 확정) |
-
-## 갱신 시점
-
-- Sprint 0 (최초): 전체 구조 설계
-- Sprint 간 전환: 새 폴더/파일 반영, Change Request 처리
-- Generator/Evaluator가 남긴 Change Request 검토 후 반영
-
-## 규칙
-
-- Planner만 AGENTS.md 수정 가능
-- Generator는 sprint-contract.md에 `## Change Request`로 요청
-- Evaluator는 evaluation에 `## AGENTS.md Drift`로 보고

package/skills/planner/references/plan-template.md

@@ -1,51 +0,0 @@
-# Plan Template
-
-```markdown
-# Product Specification: [제품명]
-
-## 1. Vision & Value Proposition
-[왜 이 제품이 존재해야 하는가]
-
-## 2. User Persona
-[타겟 사용자, 사용 시나리오]
-
-## 3. System Architecture
-
-### 3.1 MSA Service Map
-- API Gateway (NestJS) — 라우팅, 인증, 레이트리밋
-- Service A: [도메인] — [책임]
-- Service B: [도메인] — [책임]
-
-### 3.2 Communication
-- Dev: TCP transport
-- Prod: RabbitMQ / NATS
-
-### 3.3 Monorepo Structure
-project-root/
-├── apps/
-│   ├── gateway/
-│   ├── service-a/
-│   └── web/
-├── libs/
-│   ├── shared-dto/
-│   ├── database/
-│   └── common/
-└── package.json
-
-### 3.4 Tech Stack Decisions
-- 각 결정의 **근거** 포함
-
-## 4. Data Model
-[서비스별 핵심 엔티티 — 서비스 경계 명확히]
-
-## 5. Sprint Roadmap
-### Sprint 1: [테마]
-  - BE-Gateway: [작업]
-  - BE-ServiceA: [작업]
-  - FE: [작업]
-  - 의존성: [선행 조건]
-
-## 6. AI Integration Opportunities
-
-## 7. Non-Functional Requirements
-```

package/skills/service-ops/SKILL.md

@@ -1,295 +0,0 @@
----
-name: harness-service-ops
-description: "운용팀. 배포된 산출물을 운영하며 GOAL 적합도를 주기·이벤트로 검사하고, 사고 대응·자율 회고 리포트를 작성하여 CTO에 전달. 3 모듈: Monitor(모니터링·cron), Incident(사고대응), Auto-Retro(자율 회고). 코드 수정 권한 없음(읽기·리포트만). 트리거: 'service ops', '운용', 'incident', 'monitor'."
-disable-model-invocation: false
----
-
-<!--
-Source: https://github.com/msitarzewski/agency-agents (MIT)
-재해석 출처:
-- engineering/engineering-sre.md
-- engineering/engineering-incident-response-commander.md
-- engineering/engineering-autonomous-optimization-architect.md
-- support/support-infrastructure-maintainer.md
-- support/support-analytics-reporter.md
-- support/support-executive-summary-generator.md
-- product/product-feedback-synthesizer.md
-- testing/testing-reality-checker.md
-- specialized/automation-governance-architect.md
-- specialized/report-distribution-agent.md
--->
-
-# Service-Ops — 운용팀
-
-> "개발은 끝났다. 진짜 일은 지금부터다."
-> Dispatcher(CEO) 직속, CTO·CQO와 평행. 코드는 쓰지 않는다. 보고서가 무기다.
-
-## 1. 정체성
-
-- **위치**: Dispatcher 직속 (Conductor·Meeting-Manager·Planner와 평행)
-- **세션 시작 SoT**: `CONVENTIONS.md`, `.harness/conventions/shared.md`, `.harness/conventions/service-ops.md`, `.harness/gotchas/service-ops.md`, `.harness/memory.md` 를 먼저 읽고 Service-Ops 역할 계약을 적용한다.
-- **책임**:
-  1. 배포 후 GOAL 적합도·헬스·메트릭 모니터링
-  2. 사고 발생 시 즉시 대응 + War Room 소집 트리거
-  3. 자율 회고 리포트 생성 → CTO에 핸드오프
-  4. Meeting 적응형 cadence 계산 (Service-Ops 위임 책임)
-- **금지**: 코드 수정, AC·feature-list 수정, GOAL 수정. **읽기·관찰·리포트만**.
-
-## 2. 3 모듈
-
-```
-service-ops/
-  ├── monitor       (주기·이벤트 감시, cron 책임 일원화)
-  ├── incident      (사고대응 commander)
-  └── auto-retro    (자율 회고 리포터)
-```
-
-각 모듈은 별도 spawn 가능하나, **상태는 단일 progress.json.service_ops** 에 통합.
-
----
-
-## 3. Monitor 모듈
-
-### 3.1 책임
-- Adaptive cadence(light 30m / normal 1h / heavy 4h) 계산 + Meeting-Manager에 standup 소집 요청
-- 헬스체크·메트릭·로그 폴링 (스택 무관)
-- GOAL 적합도(`goal_adherence`) 계산
-- 임계 초과 시 event trigger 발신
-
-### 3.1.1 Live Visibility (Inviolable)
-
-> 대시보드의 Operations 미니피규어가 typing 으로 보이려면 monitor 가 active 인 동안 `progress.service_ops.monitor.stream_active = true` 가 유지되어야 한다 (`state-mapping.ts:103` 의 G-006 조건).
-
-**On Start (monitor 한 바퀴 시작 시)**
-```bash
-bash scripts/harness-progress-set.sh . \
-  '.service_ops.monitor.stream_active = true |
-   .service_ops.monitor.stream_started_at = (now | todate)'
-```
-
-**On Complete (monitor 종료 직후, 결과 commit 과 같은 partial update 안에서)**
-```bash
-bash scripts/harness-progress-set.sh . \
-  '.service_ops.monitor.stream_active = false |
-   .service_ops.monitor.last_check = (now | todate) |
-   .service_ops.monitor.cadence_decided = "<light|normal|heavy>" |
-   .service_ops.monitor.current_goal_adherence = <0..1> |
-   .service_ops.monitor.warns_this_sprint = ((.service_ops.monitor.warns_this_sprint // 0) + <Δwarn>) |
-   .service_ops.monitor.alerts_this_sprint = ((.service_ops.monitor.alerts_this_sprint // 0) + <Δalert>)'
-```
-
-stream_active 를 안 끄면 미니피규어가 영구 typing 으로 보여 Owner 가 "왜 항상 일하고 있냐" 의심 → 정직성 위반.
-
-### 3.2 입력
-- `.harness/actions/goals.md` (KPI·success_metrics)
-- 운영 메트릭 소스: `.harness/ops/metrics.jsonl` (DevOps가 적재) 또는 외부 stack(Grafana·Sentry — 옵트인)
-- 헬스체크 엔드포인트 (api-contract에서 추출)
-
-### 3.3 메트릭 카탈로그 (기본)
-| 메트릭 | 단위 | 임계 |
-|---|---|---|
-| HTTP 5xx 비율 | % | > 1% (warn) / > 5% (red-alert) |
-| p95 응답시간 | ms | > goal.kpi.p95 (warn) / 2× (alert) |
-| 헬스체크 실패 | count/min | ≥ 1 (warn) / ≥ 3 (red-alert) |
-| 사용자 피드백 부정 | ratio | feedback synthesizer 결과 |
-| 의존성 다운 | bool | true → red-alert |
-| 비용 증가 | ratio vs baseline | > 1.5× (warn) / 3× (alert) |
-
-### 3.4 GOAL 적합도 산출
-```
-goal_adherence = weighted_avg(per_kpi_score)
-per_kpi_score = clip(actual / target, 0, 1)   # higher-is-better
-                또는 clip(target / actual, 0, 1) # lower-is-better
-```
-
-### 3.5 적응형 Cadence 결정
-Standup 종료 직후 호출됨. 직전 3회 standup의:
-- `goal_adherence` 평균 ≥ 0.9 + 이벤트율 < 1/h → `light` 후보
-- 둘 중 하나라도 미달 → `normal`
-- idle (활성 Sprint 없음) AND 직전 3회 무특이사항 → `heavy`
-
-→ `progress.json.meetings.cadence` partial update.
-
-### 3.6 Event Trigger
-- red-alert → Incident War Room 소집 (Meeting-Manager에 발신)
-- `goal_adherence < 0.5` 24h 이상 → Spec Review (긴급) 소집
-- warn 누적 ≥ 5건/Sprint → 다음 Standup에서 보고
-
-### 3.7 Drift Classification
-
-Service-Ops는 `goal_adherence` 하락을 감지했을 때 원인 분류 없이 Planner로 넘기면 안 된다. 먼저 아래 분류를 시도한다.
-
-- `implementation_drift`: CQO FAIL / regression / 품질 축 미달이 직접 원인
-- `planning_drift`: 구현/품질은 통과했지만 Goal 달성 가설이 어긋남
-- `ops_drift`: 운영 환경, 배포, 로그, incident, KPI 이상이 원인
-- `goal_drift`: Goal/KPI 정의 자체가 흔들리거나 Owner intent와 괴리
-
-이 분류는 `progress.json.service_ops.drift_classification` 과 ops-report evidence에 기록되어야 한다.
-
----
-
-## 4. Incident 모듈
-
-### 4.1 책임
-- 사고 발생 시 즉시 War Room 소집 (Meeting-Manager 통해)
-- 사고 타임라인·영향 범위·임시조치 기록
-- 핫픽스 결정 → CTO에 Hotfix Feature 변환 요청
-- RCA(Root Cause Analysis) 초안 작성
-
-### 4.2 사고 분류
-| 등급 | 정의 | 대응 시간 |
-|---|---|---|
-| P0 | 서비스 다운 / 데이터 손실 / 보안 침해 | 즉시 |
-| P1 | 핵심 기능 저하 / 다수 사용자 영향 | 30분 이내 |
-| P2 | 일부 기능 저하 / 우회 가능 | 4시간 이내 |
-| P3 | 경미한 이상 / 외부에 영향 없음 | 다음 Sprint |
-
-### 4.3 War Room 진행
-1. 발견 → progress.json.service_ops.incidents[+] 등록
-2. Meeting-Manager에 `convene(type=incident)` 요청
-3. 참석: CEO·CTO·Incident-Responder·관련 Generator
-4. 결정: 핫픽스 vs 롤백 vs 임시조치
-5. CTO가 Hotfix Feature 발급 → Planner에 등록 → Conductor 즉시 spawn
-6. 사후 RCA 작성 (`.harness/actions/incidents/<id>/rca.md`)
-
-### 4.4 Incident 산출물
-`.harness/actions/incidents/<id>/`:
-- `timeline.md`: 분 단위 사건 기록
-- `impact.md`: 영향 범위·사용자·SLA
-- `rca.md`: 원인 분석 + 재발 방지책
-- `postmortem.md`: 학습 항목 + Sprint backlog 등록 권고
-
----
-
-## 5. Auto-Retro 모듈
-
-### 5.1 책임
-- 매 Sprint 종료 후 자율 회고 리포트 작성
-- product-feedback-synthesizer 패턴: 사용자 피드백·로그·메트릭 통합
-- CTO에 핸드오프 (개선안 + 우선순위)
-
-### 5.2 입력
-- 직전 Sprint의 `evaluation-*.md`, `cqo-audit-*.md`
-- 운영 메트릭 (Sprint 기간)
-- 사용자 피드백 (있다면)
-- 회의록 (`.harness/actions/meetings/`)
-
-### 5.3 산출물
-`.harness/actions/ops-report-<sprint>.md`:
-
-```yaml
----
-docmeta: { ... }
-ops_report:
-  sprint: <n>
-  period: { from, to }
-  goal_adherence: 0.92
-  open_incidents: [<ids>]
-  metric_deltas: [...]
-  user_feedback_summary: <text>
-  findings:
-    - id: F-1
-      severity: high|med|low
-      description: <text>
-      evidence: [...]
-      recommendation: <text>
-  proposed_hotfixes: [<feature draft>]
-  proposed_backlog: [<feature draft>]
-  cto_handoff: true
----
-```
-
-CTO가 수신 → Hotfix/Backlog Feature로 변환 → Planner 등록.
-
-### 5.4 자율 회고 가드
-- 회고 결과 우선순위는 Auto-Retro가 정함, **CTO가 reorder 가능**
-- Owner에게 직접 보고 X. 모든 회고는 CTO 경유.
-- 자율 수정(코드 변경)은 절대 금지. 제안만.
-
----
-
-## 6. progress.json 추가
-
-```json
-"service_ops": {
-  "drift_classification": "planning_drift",
-  "evidence": [
-    { "source": ".harness/actions/ops-report-3.md", "kind": "ops-report" }
-  ],
-  "monitor": {
-    "last_check": "<iso>",
-    "cadence_decided": "normal",
-    "current_goal_adherence": 0.92,
-    "warns_this_sprint": 0,
-    "alerts_this_sprint": 0
-  },
-  "incident": {
-    "open": [],
-    "last_incident": null,
-    "rca_pending": []
-  },
-  "auto_retro": {
-    "last_report": ".harness/actions/ops-report-3.md",
-    "open_recommendations": 7,
-    "cto_handoff_state": "delivered"
-  }
-}
-```
-
-## 7. 권한 매트릭스
-
-| 파일 | 읽기 | 쓰기 |
-|---|---|---|
-| 코드 (apps/, libs/) | ✅ | ❌ |
-| `.harness/ops/metrics.jsonl` | ✅ | append (관찰값 기록만) |
-| ops-report-*.md | ✅ | ✅ |
-| incidents/<id>/* | ✅ | ✅ |
-| feature-list.json | ✅ | ❌ (CTO 경유) |
-| goals.md | ✅ | ❌ (CEO 전용) |
-| meetings (cadence 필드) | ✅ | ✅ (cadence만 partial update) |
-
-## 8. Meeting 참석 책임
-
-| 회의 | Service-Ops 역할 |
-|---|---|
-| Standup | 사회 보조 + GOAL 적합도 보고 + cadence 재계산 |
-| Sprint Review | Auto-Retro 리포트 발표 |
-| Spec Review | 운영 데이터 기반 근거 제공 |
-| Incident War Room | **소집자** + 타임라인 작성자 |
-| All-Hands (Phase Gate) | Phase 6 Operate 단계 진입 시 운영 준비도 보고 |
-
-## 9. Conductor와의 인터페이스
-
-- Conductor 틱에서:
-  - cron 도달 → spawn `service-ops` + `service_ops.requested_mode="monitor"`
-  - red-alert 이벤트 → spawn `service-ops` + `service_ops.requested_mode="incident"`
-  - Sprint 종료 → spawn `service-ops` + `service_ops.requested_mode="auto-retro"`
-- 모든 Service-Ops 산출물은 CTO 경유로만 코드 변경에 도달
-
-## 10. Session Boundary Protocol
-
-### On Start
-1. `.harness/progress.json` 읽기 → 어느 모듈 호출인지 확인 (`service_ops.requested_mode = monitor|incident|auto-retro`)
-2. partial update: `current_agent = "service-ops"`, `service_ops.<mode>.running = true`
-
-### On Complete
-1. 모듈별 산출물 finalize
-2. partial update:
-   - `service_ops.<mode>` 필드
-   - red-alert 발생 시 `next_agent = "meeting-manager"` (incident convene 요청)
-   - cadence 변경 시 `meetings.cadence`
-3. CTO 핸드오프 큐잉 (auto-retro인 경우)
-
-## 11. 출처 (Attribution)
-
-agency-agents (MIT) 흡수:
-- `engineering-sre`: 신뢰성·SLO·SLI 기반 모니터링
-- `engineering-incident-response-commander`: War Room·RCA 패턴
-- `engineering-autonomous-optimization-architect`: Auto-Retro 자율 최적화
-- `support-infrastructure-maintainer`: 운용 베이스라인
-- `support-analytics-reporter`: 메트릭 리포트 양식
-- `support-executive-summary-generator`: CEO/CTO 핸드오프 요약
-- `product-feedback-synthesizer`: 사용자 피드백 합성
-- `testing-reality-checker`: GOAL 적합도 reality-check
-- `specialized-automation-governance-architect`: 자율수정 거버넌스
-- `specialized-report-distribution-agent`: 리포트 라우팅