init: document-haness 하네스 설계

examples/output/retry-policy-demo/inputs/brief.normalized.json

@@ -0,0 +1,58 @@
+{
+  "title": "API 재시도는 횟수가 아니라 부하 예산으로 설계한다",
+  "document_type": "technical_blog",
+  "language": "ko-KR",
+  "audience": {
+    "roles": [
+      "백엔드 개발자",
+      "플랫폼 엔지니어"
+    ],
+    "prior_knowledge": [
+      "HTTP 요청과 타임아웃의 기본 개념",
+      "분산 시스템의 부분 실패 경험"
+    ],
+    "needs": [
+      "재시도 정책을 설계할 때 확인할 판단 기준",
+      "운영 환경에서 검증할 지표"
+    ]
+  },
+  "reader_goal": "재시도가 장애를 증폭하지 않도록 타임아웃, 재시도 횟수, 백오프, 지터, 멱등성을 함께 설계한다",
+  "core_message": "재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.",
+  "scope": [
+    "서비스 간 동기 HTTP 호출의 클라이언트 재시도 정책",
+    "정책을 검증하는 운영 지표와 실패 실험"
+  ],
+  "non_scope": [
+    "메시지 큐의 전달 보장 전체 설계",
+    "특정 클라우드 SDK의 모든 기본값",
+    "정확히 한 번 처리 보장"
+  ],
+  "prerequisites": [
+    "HTTP 상태 코드와 타임아웃을 이해함",
+    "로그와 지표를 조회할 수 있음"
+  ],
+  "required_topics": [
+    "재시도의 부하 증폭",
+    "멱등성",
+    "지수 백오프",
+    "지터",
+    "재시도 한도",
+    "성공 및 중단 기준"
+  ],
+  "constraints": {
+    "target_words": 1200,
+    "tone": "운영 경험이 있는 엔지니어에게 설명하는 직접적이고 검증 가능한 문체",
+    "version_context": "HTTP 의미론은 RFC 9110, 예시는 2026-07-23 기준",
+    "max_heading_depth": 3,
+    "require_citations": true,
+    "allow_external_knowledge": false
+  },
+  "forbidden_claims": [
+    "재시도는 항상 안전하다"
+  ],
+  "metadata": {
+    "owner": "platform-engineering",
+    "risk": "high",
+    "review_cycle": "quarterly"
+  }
+}

examples/output/retry-policy-demo/inputs/pipeline.normalized.json

@@ -0,0 +1,59 @@
+{
+  "planner": {
+    "provider": "mock",
+    "model": "",
+    "timeout_seconds": 300,
+    "options": {}
+  },
+  "writer": {
+    "provider": "mock",
+    "model": "",
+    "timeout_seconds": 300,
+    "options": {}
+  },
+  "reviewers": [
+    {
+      "role": "logic",
+      "provider": "mock",
+      "model": "",
+      "timeout_seconds": 300,
+      "options": {}
+    },
+    {
+      "role": "reader",
+      "provider": "mock",
+      "model": "",
+      "timeout_seconds": 300,
+      "options": {}
+    },
+    {
+      "role": "evidence",
+      "provider": "mock",
+      "model": "",
+      "timeout_seconds": 300,
+      "options": {}
+    },
+    {
+      "role": "operations",
+      "provider": "mock",
+      "model": "",
+      "timeout_seconds": 300,
+      "options": {}
+    }
+  ],
+  "reviser": {
+    "provider": "mock",
+    "model": "",
+    "timeout_seconds": 300,
+    "options": {}
+  },
+  "quality_gate": {
+    "minimum_score": 82.0,
+    "max_blockers": 0,
+    "max_errors": 2,
+    "max_revisions": 2,
+    "deterministic_weight": 0.4,
+    "model_weight": 0.6
+  },
+  "fail_on_reviewer_error": true
+}

examples/output/retry-policy-demo/inputs/sources.normalized.json

@@ -0,0 +1,41 @@
+{
+  "sources": [
+    {
+      "id": "S1",
+      "title": "Timeouts, retries, and backoff with jitter",
+      "url": "https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/",
+      "publisher": "Amazon Web Services Builders’ Library",
+      "accessed": "2026-07-23",
+      "facts": [
+        "Retries can increase load on a dependency that is already failing.",
+        "Exponential backoff limits retry frequency, and jitter spreads retry timing across clients.",
+        "Retry behavior should be bounded rather than continuing indefinitely."
+      ],
+      "notes": "Use for retry-load, backoff, jitter, and bounded-retry claims."
+    },
+    {
+      "id": "S2",
+      "title": "RFC 9110, HTTP Semantics — Idempotent Methods",
+      "url": "https://datatracker.ietf.org/doc/html/rfc9110#section-9.2.2",
+      "publisher": "IETF",
+      "accessed": "2026-07-23",
+      "facts": [
+        "A request method is idempotent when multiple identical requests have the same intended effect as one request.",
+        "A client can automatically retry an idempotent request after a communication failure before reading the response, subject to the specification's conditions."
+      ],
+      "notes": "Use for the definition and retry implications of HTTP method idempotency."
+    },
+    {
+      "id": "S3",
+      "title": "Retry strategy",
+      "url": "https://cloud.google.com/storage/docs/retry-strategy",
+      "publisher": "Google Cloud",
+      "accessed": "2026-07-23",
+      "facts": [
+        "Retry behavior should consider whether the operation is idempotent.",
+        "Exponential backoff increases the delay between retry attempts and should use bounded limits."
+      ],
+      "notes": "Use as a second implementation-oriented source for bounded backoff and idempotency checks."
+    }
+  ]
+}