Compose Landing Page
user_config_info.json 구성을 비즈니스 요구사항에 맞고 시각적으로 독특하며 브라우저에서 바로 실행 가능한 교육용 랜딩 페이지 단일 파일 HTML로 변환합니다. 프로세스는 자체 포함되어 있으며 외부 시스템에 의존하지 않습니다.
구성 규약 버전 3.0, 핵심: conversionFlow는 변환 흐름의 유일한 사실 공급원입니다.
입력
| 파일 | 역할 |
|---|---|
user_config_info.json | 현재 프로젝트의 실제 구성 (사용자 제공) |
references/user-config-spec.md | 필드 설명서: 필드 의미, 유형, 허용 값, 기본값 |
references/business-rules.md | 비즈니스 가드레일: 전환, 예약, 다자녀/다과목 등 불변 규칙 |
references/frontend-design.md | 시각적 방향: 주제 소재, 폰트, 레이아웃, 반패턴 판단 |
references/engineering-conventions.md | 엔지니어링 가드레일: CJK 지원, i18n 렌더링 모드, 네이밍 격리, 초기 로딩 |
references/question-bank.json | 표준 문제 은행: 문제 본문, 선택지, 과목 분류 매핑 |
참조 파일은 내장되어 있습니다. 사용자는 user_config_info.json만 제공하면 됩니다.
우선순위
유효한 구성 → 비즈니스 불변성 → 사용자 명시적 요청 → 엔지니어링 규칙 → 디자인 방향
구성은 읽기 전용 사실이며, 생성, 보완, 검증하지 않습니다. conversionFlow의 단계 순서와 노드 순서는 조정할 수 없습니다. 충돌 시 특정 필드와 규칙을 명시하고, 자동으로 추측하지 않습니다.
Workflow
1단계: 구성 획득
user_config_info.json을 읽습니다. 제공되지 않으면 중단하고, 구문 분석 실패 시 오류 위치를 지적합니다. project.notes가 비어 있지 않으면 구조, 어조 및 시각적 스타일에 대한 사용자의 추가 선호도로 간주되어 5단계 디자인 방향에 직접 영향을 미치지만, 구조화된 필드와 기능 스위치를 덮어쓰지는 않습니다.
2단계: 필드 설명서 읽기
user-config-spec.md를 완전히 읽고 각 필드의 의미를 이해합니다. conversionFlow의 두 가지 순서(단계 순서 + 노드 순서)와 5가지 항목 유형(field / question / verification / booking / calendarSync)을 중점적으로 이해합니다. 스키마 검증은 수행하지 않습니다.
3단계: 읽기 전용 비즈니스 모델 구축
구성 및 필드 설명서를 기반으로 현재 프로젝트의 비즈니스 모델을 추출합니다:
- 과목: 진입 과목(
project.subject) + 추가 과목(extraSubjects) - 전환 흐름:
conversionFlow의 단계 순서와 노드 순서,verification노드가 있는 단계가 인증 코드 위치 - 필드: 활성화된 필드, 필수 필드, 소속(학부모/자녀), 과목 조건 필드
- 스위치:
booking/multiChild/multiSubject/syncCalendar/contactMode/flowMode - 사전 요구사항 유닛:
lead단계의 모든 field 및 question 노드(items 순서대로) - 문제 은행 매칭:
kind=question노드의questionId를question-bank.json과 매칭,project.language에 따라 한국어/영어 문구 선택, 제출 데이터는optionId사용
4단계: 비즈니스 규칙 읽기
business-rules.md를 완전히 읽고 충족해야 할 비즈니스 불변성을 추출합니다. 비즈니스 규칙은 결과에 대한 제약 조건이지 모듈 목록이 아닙니다. AI는 이러한 제약 조건에 따라 정보 아키텍처를 자율적으로 결정합니다.
5단계: 디자인 방향 수립
frontend-design.md를 완전히 읽고 요구사항에 따라 2단계 디자인 계획을 수행합니다:
- brainstorm: 색상(4-6 hex), 서체(2+ 가지 서체 역할), 레이아웃(한 문장 + ASCII 와이어프레임), 시그니처(단일 독특한 요소)
- critique:
project.theme,project.adScene,project.notes와 대조하여 자기 비판 – 어떤 부분이 일반적인 기본값처럼 읽히면 수정, 독특함을 확인한 후에만 코드 작성
6단계: 페이지 코드 생성
먼저 engineering-conventions.md를 읽고 현재 구성에 의해 트리거되는 엔지니어링 제약 조건(CJK 단위, i18n 렌더링 모드, 네이밍 격리, 초기 로딩)을 이해합니다. 이러한 제약은 코드 품질 가드레일이며 비즈니스 결과를 변경하지 않습니다.
완전한 단일 파일 HTML을 출력합니다:
<head>에 meta, title, Google Fonts CDN 포함, 인라인<style>포함;<body>에 인라인<script>포함- 외부 빌드 도구, npm 패키지 또는 로컬 파일에 의존하지 않음
- CSS 인라인, 선택자 특이성 주의; JS 인라인, 구성이 요구하는 모든 비즈니스 프로세스 구현
- 모든 상호작용은 브라우저에서 완료 가능(양식 제출은 mock 가능, 단 명확히 표시)
- 장식 요소는 우선 인라인 SVG 사용; 사진 수준 자료는 무료 CDN 이미지 라이브러리 직접 링크, 크기 제약 추가
- 모바일까지 반응형, 키보드 포커스 가시화,
prefers-reduced-motion준수
비즈니스 동작은 business-rules.md 섹션 5-11에 따라 구현, 코딩 계층 추가 요구사항:
- 인증 코드 컨테이너는
data-verification-stage속성으로 단계 표시 - 실제 시간 데이터가 없으면 명확히 표시된 프로토타입 데이터 사용, 재고를 위장하지 않음
- 숨겨진 필드, 활성화되지 않은 기능, 선택되지 않은 분기의 데이터는 제출 결과에 포함되지 않음
7단계: 자체 점검
제공 전 체크리스트로 자체 점검:
- 비즈니스 정확성:
business-rules.md의 인수 목록을 항목별로 확인 - 디자인 품질: 계획이 자기 비판을 통과, 폰트/색상이 계획에서 파생, Signature 독특, 반응형, 키보드 포커스,
prefers-reduced-motion, CSS 선택자 상쇄 없음 - 엔지니어링 안정성:
engineering-conventions.md의 자체 점검 목록을 항목별로 확인(CJK 단위, i18n 렌더링 모드, 네이밍 접두사, 스코프 격리, 초기 로딩) - 코드 실행 가능성: 단일 파일을 직접 열어 실행 가능, 외부 의존성 없음, 폰트는 CDN
8단계: 제공
파일을 사용자 작업 디렉토리에 저장하며, 파일 이름은 project.name을 기반으로 합니다. 간단한 자연어 설명으로: 어떤 구성을 기반으로 했는지, 어떤 핵심 기능을 구현했는지, Signature 요소, 어떤 데이터가 프로토타입으로 교체가 필요한지
실패 모드
| 상황 | 처리 |
|---|---|
user_config_info.json 미제공 | 중단, 구성 파일 필요 안내 |
| JSON 구문 분석 실패 | 오류 위치 지적, 수정 추측 안 함 |
| 구성이 비즈니스 규칙과 충돌 | 특정 필드와 규칙 지적, 사용자 확인 요청 |
conversionFlow에서 알 수 없는 kind 발생 | 특정 노드 지적, 묵시적으로 건너뛰지 않음 |
| 실제 데이터가 필요하지만 없음 | 명확히 표시된 프로토타입 데이터 사용, 실제 데이터인 척하지 않음 |
| 사용자 요청이 구성과 충돌 | 우선순위 체계에 따라 처리하고 사용자에게 설명 |