5.3 KiB
Architecture
1. 목표
ClariDoc은 문장 생성 능력보다 다음 제어 계층을 우선한다.
- 독자 과업과 문서 유형 계약
- 프로젝트 근거의 수집과 source hierarchy
- 기술 선택의 rationale completeness
- 독자용 prose와 내부 provenance의 격리
- 결정적 검사와 독립 reviewer
- 재현 가능한 artifact와 hash manifest
2. 구성요소
models.py brief/source/outline/review/pipeline 계약
corpus.py 로컬 문서 탐색, heading chunk, ranking, source-pack 생성
structures.py 문서 유형별 필수 section intent와 decision requirements
prompts.py planner/writer/reviewer/reviser 경계와 출력 계약
providers/ Codex, Claude, Antigravity, Mock adapter
lint.py 구조, 메타 누출, rationale, 안전성의 결정적 검사
provenance.py evidence-map.json과 provenance.md 생성
pipeline.py 단계 실행, 리뷰, 수정 루프, quality gate, manifest
report.py 사람이 읽는 품질 보고서
cli.py init/collect/validate/outline/lint/run/doctor
3. 입력 계층
3.1 Brief
Brief는 주제보다 독자 과업과 판단 경계를 먼저 고정한다.
- audience / prior knowledge / needs
- reader goal / core message
- scope / non-scope
- prerequisites / required topics
- citation style / date policy / style profile
- forbidden claims
3.2 SourcePack
Source는 단순 URL이 아니라 다음 metadata를 가질 수 있다.
{
"id": "L1234abcd",
"title": "...",
"url": "repo:///raw/branch-notes/example.md",
"facts": ["heading chunk text"],
"source_type": "branch-note",
"status": "verified",
"path": "raw/branch-notes/example.md",
"heading": "결정 사항",
"line_start": 120,
"line_end": 150,
"claim_ids": ["TX-C1"],
"decision_ids": ["D13"],
"priority": 21.7
}
이 metadata는 내부 reasoning과 audit에 사용된다. citation_style=hidden에서는 독자용 문서로 출력되지 않는다.
4. Local corpus retrieval
corpus.py는 다음 순서로 동작한다.
- configured include directory를 순회한다.
- Markdown frontmatter에서 title/status를 읽는다.
- heading 단위로 chunk를 만든다.
- query와 각 chunk를 BM25 계열 점수로 비교한다.
- source type, status, decision/rationale 용어에 가중한다.
- 파일별 최대 chunk 수와 전체 top-k를 적용한다.
- repository-relative provenance를 포함한 SourcePack으로 변환한다.
Source precedence:
canonical-project
> canonical-concept
> branch-note
> official-doc
> company-tech-blog
> local-document
이 순서는 절대적인 진실 순위가 아니다. 현재 프로젝트 상태에는 canonical project가 우선이고, 선택 배경에는 branch note가 더 유용할 수 있다. Planner와 reviewer가 claim 종류에 맞게 사용해야 한다.
5. Outline contract
각 section은 다음 속성을 가진다.
{
"id": "04-decision-rationale",
"intent": "decision_rationale",
"title": "선택의 이유와 지킨 경계",
"reader_question": "왜 이 선택을 했고 무엇을 포기했는가?",
"purpose": "선택을 이유, 대안, 비용, 가드레일과 함께 설명한다.",
"must_include": ["선택", "이유", "대안", "수용한 비용", "가드레일"],
"evidence_ids": ["L..."],
"decision_requirements": [
"context_or_constraint",
"choice",
"why",
"alternative",
"accepted_cost",
"guardrail"
],
"transition_to_next": "코드와 흐름으로 연결한다."
}
Planner는 제목·질문·근거 배치를 정교화할 수 있지만 intent의 삭제, 추가, 재배열은 할 수 없다.
6. Reader/provenance split
Reader-facing surface
final/document.md- 선택 이유와 기술 설명
- 공개 citation policy에 따른 citation만 포함
Internal surface
final/provenance.mdfinal/evidence-map.json- normalized source pack
- raw provider responses
- review JSON과 lint report
- provider event log
Hidden mode에서 internal source ID, repository path, access date가 document.md에 보이면 quality gate error다.
7. Review topology
- logic: 전제, 인과, 결론
- decision: context, why, alternative, cost, guardrail
- reader: orientation, cognitive load, natural prose
- evidence: claim/source fit, hierarchy, status
- operations: prerequisites, safety, verification, rollback
- editor: 문장 흐름과 표현, 질문-답 연결, 정보 구조가 반복 문장 틀로 노출되는지 검사
Writer와 logic·decision·reader·editor·evidence·operations reviewer를 분리해 self-review 편향을 줄이지만, 여러 모델의 일치는 사실 검증을 대신하지 않는다.
8. Quality gate
composite = deterministic_lint × deterministic_weight
+ model_review_mean × model_weight
통과 조건은 점수와 함께 blocker/error 개수를 검사한다. revision loop가 최대 횟수에 도달하면 실패 상태와 artifact를 그대로 보존한다.
9. Failure behavior
- invalid input contract: 실행 전 실패
- planner invalid JSON/contract: deterministic base outline으로 안전 폴백
- writer/provider failure: 숨기지 않고 pipeline failure
- reviewer failure: config에 따라 failure 또는 blocker review
- revision no-op: warning 기록
- output path traversal in reviewer role: slug sanitize
- final artifact: manifest로 크기와 SHA-256 기록