60 lines
4.4 KiB
YAML
60 lines
4.4 KiB
YAML
schema-version: 1
|
|
project-profile:
|
|
primary: generic
|
|
secondary:
|
|
- multi-capability content workflow
|
|
- contract-driven Python system
|
|
audiences:
|
|
primary:
|
|
- 콘텐츠 하네스의 적용 범위와 실행 방법을 평가하는 개발자
|
|
- document-writing, technical-visualization, image-generation 흐름에 기여하는 개발자
|
|
secondary:
|
|
- 생성 문서와 시각 산출물의 계약·검증 방식을 검토하는 기술 리더
|
|
reader-outcomes:
|
|
- 네 capability의 책임과 서로 호출하지 않는 경계를 설명할 수 있다.
|
|
- 체크인된 Clean Architecture 예제를 검증하고 계획 결과를 확인할 수 있다.
|
|
- 버전 관리되는 fixture와 무시되는 로컬 생성 산출물을 혼동하지 않는다.
|
|
- 변경하려는 계약·하네스·런타임·통합 어댑터의 소유 경로를 찾을 수 있다.
|
|
- 현재 의존성, 검증 수준, qualification 한계를 확인할 수 있다.
|
|
project-story:
|
|
value-proposition: 자연어 콘텐츠 요청을 문서 계획, 기술 시각화, 유기적 이미지, 검토된 publication output으로 연결하되 capability별 책임과 증거 경계를 파일 계약으로 유지한다.
|
|
problem: 문서 작성과 정확한 기술 도형, 유기적 이미지 생성, 최종 통합을 한 흐름에서 다루면서도 sibling capability 사이의 의미·검토·실행 책임이 섞이지 않아야 한다.
|
|
target-reader: 저장소를 평가·실행하거나 capability와 contract에 기여하는 개발자
|
|
notable-traits:
|
|
- text: document-writing, technical-visualization, image-generation은 sibling이며 workflow-runtime만 라우팅과 DAG 실행을 소유한다.
|
|
fact-ids: [F-SIBLING-HARNESSES, F-ROUTING]
|
|
- text: ContentJobRequest에서 ArtifactSet과 publication projection까지 단계별 계약이 분리돼 있다.
|
|
fact-ids: [F-CONTRACT-CHAIN, F-INTEGRATIONS]
|
|
- text: technical visualization은 의미 모델과 target별 rendition을 묶고, image generation은 exact technical geometry를 의도적으로 거부한다.
|
|
fact-ids: [F-CAPABILITY-TECHNICAL, F-CAPABILITY-IMAGE]
|
|
- text: 새 실행은 이전 결과를 검색하거나 재사용하지 않고 목적별 immutable run workspace를 할당한다.
|
|
fact-ids: [F-RUN-WORKSPACE]
|
|
- text: 로컬 테스트에는 문서·PNG·SVG가 함께 생성된 사례가 있지만 runs 경로는 무시되는 운영 데이터다.
|
|
fact-ids: [F-LOCAL-CROSS-HARNESS-OUTPUT, F-LOCAL-DOCUMENT-VISUALIZATION, F-LOCAL-IMAGE-OUTPUT, F-RUNS-NONCANONICAL]
|
|
maturity: 핵심 계약, 세 capability handler, runtime routing, 통합 adapter, 테스트와 로컬 실행 산출물이 구현돼 있다. 다만 일부 benchmark 결과와 d2-svg-layer-compositor의 사람 qualification은 완료되지 않았다.
|
|
limitations:
|
|
- 저장소에는 의존성 버전과 설치를 고정하는 packaging manifest가 없다.
|
|
- 전체 end-to-end 경로에는 외부 evidence repository와 별도 expert review 파일이 필요하다.
|
|
- runs 아래 실제 생성 결과는 로컬·ignored 데이터이므로 GitHub README의 영구 이미지 링크로 사용할 수 없다.
|
|
- d2-svg-layer-compositor는 자동 증거가 PASS지만 사람 Gate 3가 PENDING인 qualification candidate다.
|
|
narrative-variant: product
|
|
reader-journey:
|
|
- reader-question: 이 저장소는 무엇을 만들며 누구를 위한 것인가?
|
|
section-id: overview
|
|
- reader-question: 각 capability는 무엇을 소유하고 어디서 경계가 갈리는가?
|
|
section-id: capabilities
|
|
- reader-question: 가장 짧은 검증 경로로 구현 상태를 어떻게 확인하는가?
|
|
section-id: quick-start
|
|
- reader-question: 요청이 계획·생성·검토·publication으로 어떻게 이동하는가?
|
|
section-id: execution-model
|
|
- reader-question: 생성된 이미지·문서·기술 시각화는 어디서 어떻게 확인하는가?
|
|
section-id: artifacts
|
|
- reader-question: 기능을 수정하려면 어느 디렉터리와 계약을 봐야 하는가?
|
|
section-id: architecture
|
|
- reader-question: 명령의 실제 검증 수준과 전체 테스트 진입점은 무엇인가?
|
|
section-id: verification
|
|
- reader-question: 현재 과장 없이 밝혀야 할 제약과 qualification 상태는 무엇인가?
|
|
section-id: limitations
|
|
- reader-question: 더 깊은 설계·운영·benchmark 문서는 어디에 있는가?
|
|
section-id: documentation
|