hugh.kim / harness ontology
Planning x Design x Prototype

기획 문서는 개발 화면과 다시 만날 때 운영 자산이 됩니다.

요구사항 분석에서 기획 문서 초안, 검증 리포트, 상세 기획안, 화면정의서, 디자인 시스템, 프로토타입, 개발까지 이어지는 하네스 온톨로지입니다.

Plan초안 / 상세안 / 화면정의서
Design토큰 / 컴포넌트 / 접근성
Prototype클릭 흐름 / 상태 검증
Dev소스 backfeed / drift
Framing

질문은 자동 작성이 아니라 자동 검증과 되먹임입니다.

Question

AI가 문서를 쓰는가보다 중요한 질문은, 그 문서가 실제 근거와 화면 상태, 디자인 규칙, 개발 소스와 계속 맞춰지는가입니다.

Pipeline

요구사항에서 개발까지 이어지는 8단계

각 단계는 다음 단계의 입력이면서, 실패하면 이전 산출물을 보강하는 근거가 됩니다.

01요구사항과 분석

회의록, PDF, 기존 문서, 이슈를 evidence pack으로 묶습니다.

02기획 문서 초안 생성

문제, 목표, 범위, MVP/Later, open question을 초안으로 만듭니다.

03검증 리포트

근거 부족, scope drift, human review blocker를 초안과 분리합니다.

04기획 상세 생성

상태, 예외, 권한, 데이터/API, 운영 정책을 보강합니다.

05화면정의서

화면, 필드, 버튼, empty/loading/error, 권한 분기를 정의합니다.

06디자인 시스템 반영

토큰, 컴포넌트, 밀도, 접근성, 브랜드 톤을 연결합니다.

07프로토타입 생성

핵심 흐름을 클릭 가능한 HTML 또는 앱 화면으로 검증합니다.

08개발

route, component, API, UI state를 구현하고 다시 문서로 되돌립니다.

Ontology

생성 산출물과 검증 산출물을 분리합니다.

LayerPrimary artifactQuality gateBackfeed signal
Planning기획안 초안, 상세 기획안Evidence coverage, scope control요구 변경, 미확정 blocker
Screen Spec화면정의서, 상태 정의, 권한 분기State coverage, screen traceability화면 누락, 버튼/상태 불일치
Design디자인 시스템 반영안, 컴포넌트 규칙Token consistency, accessibility디자인 drift, 컴포넌트 변형
Prototype클릭 가능한 HTML, 주요 시나리오Scenario QA, empty/error path사용 흐름 막힘, 상태 누락
Developmentroute, component, API implementationBuild, browser QA, source driftimplemented-but-undocumented
Backfeed map

개발된 화면은 다시 기획의 증거가 됩니다.

Inputs
회의록 / PDF
기존 기획서 / 이슈
디자인 시스템
화면 소스 / API
Core harness
Planning Validation Loopdraft -> report -> detail -> screen spec -> design -> prototype -> dev -> source backfeed
Repair queue
human review checklist
validator rule
scorecard update
replay fixture
Decision

최종 메시지

자동 생성은 시작점이고, 핵심은 검증 리포트와 사람 검토 기준입니다. 반복 실패는 다음 하네스 규칙으로 승격되어야 합니다.