schema-version: 1
project-profile:
  primary: generic
  secondary:
    - 여러 종류의 콘텐츠를 만드는 작업 흐름
    - 파일 계약으로 연결된 Python 시스템
audiences:
  primary:
    - 콘텐츠 하네스가 만드는 결과와 실행 방법을 확인하려는 개발자
    - 문서 작성, 기술 시각화, 이미지 생성 기능을 수정하려는 개발자
  secondary:
    - 산출물의 근거와 검토 절차를 확인하려는 기술 책임자
reader-outcomes:
  - 검토를 통과한 문서, 이미지, 기술 시각화 결과를 바로 확인한다.
  - 예제 요청을 검사하고 전체 테스트를 실행할 수 있다.
  - 네 기능의 책임과 서로 직접 호출하지 않는 경계를 설명할 수 있다.
  - 변경하려는 기능의 정본 경로를 찾을 수 있다.
  - 실행 기록, 버전 관리되는 예시, 아직 끝나지 않은 검증을 구분한다.
project-story:
  value-proposition: 자연어 요청을 문서, 기술 그림, 이미지로 만들고 검토가 끝난 결과만 게시 파일로 묶는다.
  problem: 결과 종류마다 생성 방법과 검토 기준이 다르므로, 한 작업 흐름으로 연결하되 각 기능의 책임은 섞이지 않아야 한다.
  target-reader: 저장소를 평가하거나 기능을 수정하려는 개발자
  notable-traits:
    - text: 문서 작성, 기술 시각화, 이미지 생성은 서로 직접 호출하지 않으며 작업 실행기가 분기와 결과 조립을 맡는다.
      fact-ids: [F-SIBLING-HARNESSES, F-ROUTING]
    - text: 검토를 통과한 대표 산출물 세 개를 영구 문서 경로에서 바로 볼 수 있다.
      fact-ids: [F-README-SHOWCASE]
    - text: 요청부터 게시 파일까지 단계마다 별도 계약을 사용한다.
      fact-ids: [F-CONTRACT-CHAIN, F-INTEGRATIONS]
    - text: 새 실행은 기존 결과를 덮어쓰지 않고 별도 작업공간을 만든다.
      fact-ids: [F-RUN-WORKSPACE]
  maturity: 핵심 계약과 네 기능, 통합 어댑터, 300개 테스트가 구현돼 있다. 일부 평가 자료와 혼합 합성기의 사람 검토는 아직 끝나지 않았다.
  limitations:
    - 의존성 버전과 설치 절차를 고정하는 패키지 설정 파일이 없다.
    - 외부 자료와 별도 전문가 검토가 필요한 종단 간 실행이 있다.
    - runs 아래 파일은 실행 기록이며 재사용할 예시는 docs 또는 examples로 옮겨야 한다.
    - d2-svg-layer-compositor는 자동 검사를 통과했지만 사람 검토가 남았다.
narrative-variant: product
reader-journey:
  - reader-question: 이 저장소로 만든 결과를 먼저 볼 수 있는가?
    section-id: showcase
  - reader-question: 가장 짧게 동작을 확인하려면 무엇을 실행하는가?
    section-id: quick-start
  - reader-question: 각 기능은 무엇을 맡고 어디까지 책임지는가?
    section-id: capabilities
  - reader-question: 요청은 어떤 단계를 거쳐 게시 파일이 되는가?
    section-id: execution-model
  - reader-question: 기능을 고치려면 어느 디렉터리부터 봐야 하는가?
    section-id: architecture
  - reader-question: 현재 통과한 검사와 남아 있는 한계는 무엇인가?
    section-id: verification