Planning To Prototype Harness Case
아이디어가 story, scene, production prompt, service workflow로 확장될 때 이를 화면 구조, AI contract, JSON/Markdown export, eval fixture로 고정한 사례.
기획 의도, 화면 정의, AI 입출력 계약
PROMOTE, RETRY, HUMAN_REVIEW, ROLLBACK 검증
fixture verdict와 missing criteria가 모두 일치
사용 가능, 재시도, 사람 검토, 롤백을 분리
eval-backed prototype brief · portfolio detail
01작업 요약
아이디어가 story, scene, production prompt, service workflow로 확장될 때 이를 화면 구조, AI contract, JSON/Markdown export, eval fixture로 고정한 사례.
이 기준이 흐려지면 페이지가 설명 자료로만 남고, 독자는 어떤 근거와 산출물을 확인해야 하는지 다시 물어봐야 합니다.
02입력 의존성
- Artifacts: Intent / Screen / Contractready
기획 의도, 화면 정의, AI 입출력 계약
- Golden cases: 5ready
PROMOTE, RETRY, HUMAN_REVIEW, ROLLBACK 검증
- Eval pass: 5/5ready
fixture verdict와 missing criteria가 모두 일치
- Verdicts: 4 statesready
사용 가능, 재시도, 사람 검토, 롤백을 분리
03리스크 신호
| Signal | Severity | Meaning | First response |
|---|---|---|---|
01_문제 | high | 문제 | 아이디어가 긴 프롬프트 하나로 합쳐져 story, scene, metadata가 분리되지 않음 |
02_접근 | medium | 접근 | Input schema: service name, target user, brief, output type, version, non-goals, tone |
03_결과 | low | 결과 | Intent: target user, V0 scope, non-goals, success criteria 고정 |
04_증거 | low | 증거 | case-001: 모든 contract section이 있어 PROMOTE |
04반복 절차
문제
이 페이지를 처음 읽을 때창의적 아이디어는 빠르게 story, scene, production prompt, 이미지/영상/PPT 생성, 서비스 워크플로우로 번진다. 하네스가 없으면 AI는 보기 좋은 답을 만들지만 구현, 검토, 재사용, 상품화에 필요한 구조를 남기지 못한다.
아이디어가 긴 프롬프트 하나로 합쳐져 story, scene, metadata가 분리되지 않음디자이너가 화면 계층과 콘텐츠 그룹을 다시 해석해야 함개발자가 schema, API, state 정의를 새로 만들어야 함운영자가 결과를 promote/retry/review/rollback 중 무엇으로 볼지 판단하기 어려움접근
세부 기준을 검토할 때V0는 실제 생성 서비스 전체가 아니라 한 개 workflow만 증명한다. 사용자가 서비스 아이디어나 creative brief를 입력하면 story summary, scene breakdown, production prompt, generation metadata, implementation notes로 분리하고 JSON/Markdown 산출물로 내보낸다.
Input schema: service name, target user, brief, output type, version, non-goals, toneOutput schema: story, scene, prompt, metadata, implementation notes, non-goals, verdict candidatePrompt rule: out-of-scope 생산 능력을 invent하지 않고 planner/designer/developer가 쓸 수 있게 반환Screen spec: 입력 editor, structured output panel, verdict panel, export modal을 분리결과
세부 기준을 검토할 때결과물은 단일 문서가 아니라 intent, screen spec, AI contract, project adapter, golden eval set으로 나뉜다. 따라서 기획자는 범위를 보고, 디자이너는 화면을 그리고, 개발자는 계약을 구현하고, QA는 fixture로 회귀를 확인할 수 있다.
Intent: target user, V0 scope, non-goals, success criteria 고정Screen spec: workspace, structured output, eval panel, export modal 정의AI contract: input/output schema, prompt template, retry/human review/rollback rule 정의Project adapter: eval, universal runner, rollback command의 연결점을 설명증거
세부 기준을 검토할 때eval fixture는 좋은 결과만 통과시키는 장치가 아니라 사용 가능, 수정 가능, 위험, 손상된 출력을 구분하는 증거다. 다섯 golden case가 각 verdict를 안정적으로 재현하도록 설계되어 있고, 로컬 검증에서 5개 case가 모두 통과했다.
case-001: 모든 contract section이 있어 PROMOTEcase-002: non-goals 누락으로 RETRYcase-003: story/scene/prompt 분리가 약해 RETRYcase-004: target user가 모호해 HUMAN_REVIEWHTML에서 Astro로
세부 기준을 검토할 때이 사례의 원천은 HTML이 아니라 Markdown 계약서와 eval fixture다. 따라서 원본 화면을 snapshot으로 공개하지 않고, 포트폴리오에서는 data-driven Astro 상세 페이지로 재작성한다. 추후 실제 데모 UI가 생기면 static snapshot이 아니라 case evidence로만 연결한다.
HTML에서 Astro로ArtifactsCase StudiesProvenance
세부 기준을 검토할 때이 사례는 Keystone-native 작업으로 분류한다. 다만 원천에는 내부 demo path와 eval runner path가 포함되므로 공개 페이지에서는 구조와 판단만 설명하고 실제 source path는 private candidate matrix에 보관한다.
provenance_label: keystone-nativesource_path: docs/demos/planning-to-prototype-harness/**public_output: /planning-to-prototype-harness-caseprivate_evidence: docs/internal/viewer-md-candidate-matrix.md05역할 분담
| Role | Primary work | Handoff |
|---|---|---|
| Owner | 기준과 공개 범위 유지 | Decision / Boundary notes |
| Builder | 문서, 화면, 실행 산출물 반영 | Implementation notes |
| Reviewer | 누락, 과장, 공개 리스크 검토 | Review findings |
| Maintainer | 변경 후 다음 버전 동기화 | Update queue |
06완료 체크리스트
한 문장으로 설명 가능
이 페이지가 어떤 판단을 돕는지 제목, 요약, 첫 절차에서 바로 읽혀야 합니다.
근거와 산출물 연결
설명만 남기지 않고 기준, 결과물, 다음 페이지가 같은 맥락으로 이어져야 합니다.
공개 가능한 범위 확인
내부 경로, 계정, 고객 정보, 미검증 아이디어가 섞이지 않아야 합니다.
다음 행동이 남음
읽은 사람이 어디를 보고 무엇을 검토하면 되는지 링크와 체크 항목으로 남아야 합니다.