# FeatPaper Construction Plan

## Purpose and v1 Completion Definition

이 문서는 PR0부터 PR9까지의 실행 순서와 완료 기준을 고정한다. v1은 일회성 회사 사이트가 아니라 콘텐츠, 제품 업데이트, 로드맵, 피드백, 트래킹, 전환이 연결되는 외부 제품 운영 플랫폼이다.

v1 완료 기준은 다음이다.

- Home
- 3 Use Cases
- Product
- 4 Plugin pages
- 5 Magazine posts
- Roadmap
- Tally feedback loop
- `ko/en/ja` core pages
- Cloudflare preview works

## Global Rules

- One PR per task.
- 작업 전 `docs/AGENT_STATUS.md`에서 해당 PR row를 claim한다.
- `main`에 직접 push하지 않는다.
- v1은 static-first로 유지한다.
- `assets/raw`는 배포하지 않는다.
- mockup artifact는 task가 명시하지 않는 한 보존한다.
- Astro scaffolding은 PR1에서만 시작한다.
- PR0에서는 runtime code, package dependency, asset 이동/삭제/최적화를 하지 않는다.
- CTA, card, plugin link, roadmap feedback link는 tracking attribute를 받을 수 있는 구조로 만든다.

## PR0 — Docs Strategy Alignment

목표: 이후 PR이 흔들리지 않도록 디자인 전략, 기술 스택 결정, 공사 계획을 문서화한다.

수정 범위:

- `docs/DESIGN_STRATEGY.md`
- `docs/TECH_STACK_DECISION.md`
- `docs/CONSTRUCTION_PLAN.md`
- `docs/AGENT_STATUS.md` PR0 row

주의 사항:

- Astro scaffolding 금지.
- runtime code 수정 금지.
- mockup, root `index.html`, asset 수정 금지.

Acceptance criteria:

- Claude visual reference 우선 원칙과 기존 IA/운영 구조가 문서화되어 있다.
- Astro + React Islands + MDX + Cloudflare Pages가 v1 baseline으로 고정되어 있다.
- PR0~PR9의 목표, 범위, 주의 사항, acceptance criteria가 정리되어 있다.
- `git diff --check`가 통과한다.

## PR1 — Astro Project Foundation

목표: 실제 v1 사이트 구현을 위한 Astro 기반 프로젝트 골격을 만든다.

수정 범위:

- Astro, TypeScript, MDX, React integration 설치 및 설정.
- `src/layouts`, `src/components`, `src/content`, `src/data`, `src/styles` 기본 구조 생성.
- build/typecheck/lint 또는 validation script의 최소 기반 추가.
- 임시 root `index.html`은 실제 Astro home 진입으로 대체하되, `artifacts/mockups/index.html`은 보존한다.

주의 사항:

- PR1에서는 상세 페이지 구현보다 프로젝트 골격과 배포 가능성에 집중한다.
- `assets/raw`를 public 배포 경로로 옮기지 않는다.
- CMS, Workers, Supabase, CRM을 도입하지 않는다.

Acceptance criteria:

- `npm run build`가 `dist`를 생성한다.
- Cloudflare Pages 설정값이 Astro 기준과 맞는다.
- mockup artifact URL이 보존된다.
- 기본 route와 폴더 구조가 PR2~PR9 작업을 막지 않는다.

## PR2 — Design System and Shared Layout

목표: 디자인 토큰, 공통 레이아웃, 반복 컴포넌트의 기반을 만든다.

수정 범위:

- color, typography, spacing, radius, section rhythm token.
- Header, Footer, Locale shell.
- Button, link, card, tag, badge, CTA primitives.
- `HeroSection`, `LogoStrip`, `ContentCardGrid`, `FeatureTabs`, `PluginCard`, `CtaBanner`, `InlineCtaBlock`의 기반.
- tracking attribute helper 또는 prop contract.

주의 사항:

- Claude mockup의 compact/dense 표현을 참고하되 첫 화면을 과밀하게 만들지 않는다.
- 보라색 단색 의존을 줄이고 restrained SaaS/product-operations palette를 유지한다.
- 내용이 없는 placeholder metric을 넣지 않는다.

Acceptance criteria:

- 주요 컴포넌트가 `docs/DESIGN_STRATEGY.md`의 token과 component inventory를 따른다.
- 모바일/데스크톱에서 Header/Footer/CTA가 깨지지 않는다.
- 컴포넌트가 tracking attributes를 받을 수 있다.
- build/typecheck가 통과한다.

## PR3 — Content Schema and Validation

목표: 콘텐츠와 운영 데이터의 schema contract를 만든다.

수정 범위:

- Astro Content Collections schema.
- `useCases`, `magazine`, `plugins`, `roadmap`, `releases`, `pages` 컬렉션.
- `src/data` schema: navigation, footer, CTAs, forms, feature modules, home modules, tracking taxonomy.
- content validation script.
- slug 중복, locale 누락, CTA/form ID 누락, broken internal route 검사 기반.

주의 사항:

- 실제 대량 콘텐츠 작성은 PR4 이후로 미룬다.
- schema가 구현 편의보다 운영 안정성을 우선해야 한다.
- analytics SDK는 도입하지 않는다.

Acceptance criteria:

- 필수 frontmatter 누락을 검출한다.
- locale, slug, CTA, related content, form ID 검증이 가능하다.
- validation script가 로컬에서 실행 가능하다.
- build/typecheck/content validation이 통과한다.

## PR4 — Home and Use Cases KO

목표: problem-first Home과 한국어 핵심 Use Case 3개를 구현한다.

수정 범위:

- Home page modules.
- `proposal-view-tracking`
- `figma-pdf-share`
- `sales-deck-analytics`
- Use Cases index and detail pages.
- Home cards와 Use Case 상세 간 연결.

주의 사항:

- 기존 사이트의 제품 메시지와 testimonial은 유지하되 problem-first로 재배치한다.
- 가짜 수치와 placeholder metric을 사용하지 않는다.
- 모든 주요 CTA와 카드에 tracking attributes를 부여한다.

Acceptance criteria:

- 신규 방문자가 Home 첫 화면에서 FeatPaper가 해결하는 문제를 이해할 수 있다.
- 3개 Use Case가 문제 상황, 마찰, FeatPaper 흐름, 관련 기능, 관련 플러그인, CTA를 포함한다.
- 모바일/데스크톱 layout smoke check를 통과한다.
- build/typecheck/content validation이 통과한다.

## PR5 — Product and Plugins

목표: Product hub와 4개 Plugin landing을 구현한다.

수정 범위:

- Product page.
- Feature sections: Viewer Tracking, Engagement Insights, Video-Enhanced PDF, Document Update, Lead Form / CTA, Access Control.
- Plugin pages: Figma, PowerPoint, Adobe Express, Gmail.
- marketplace/install/contact CTA, FAQ, related Use Cases.

주의 사항:

- Help Center 내용을 그대로 복사하지 않고 마케팅 언어로 번역한다.
- 플러그인별 사용 가능 상태와 CTA를 명확히 한다.
- 외부 marketplace link는 검증 대상이다.

Acceptance criteria:

- Product가 기능 덤프가 아니라 업무 결과 중심으로 읽힌다.
- 각 Plugin page가 "어디서 만들고 → 어떻게 공유하고 → 무엇을 분석하는지" 흐름을 따른다.
- 관련 Use Case와 CTA가 연결되어 있다.
- build/typecheck/content validation/link check가 통과한다.

## PR6 — Magazine and Updates

목표: Magazine hub와 초기 운영 콘텐츠를 만든다.

수정 범위:

- Magazine index.
- category filter.
- article detail layout.
- 초기 글 5개: Use Case 2개, Guide 1개, Update 1개, Roadmap note 1개.
- related feature, related plugin, Inline CTA modules.

주의 사항:

- Magazine은 공식 콘텐츠 허브로 동작해야 한다.
- Blog, note, Help Center의 역할이 섞이지 않게 category와 CTA를 명확히 한다.
- 긴 제목이 카드와 모바일 화면에서 깨지지 않아야 한다.

Acceptance criteria:

- Use Case / Guide / Update / Roadmap category가 탐색 가능하다.
- 각 글 하단에 관련 기능, 관련 플러그인, Inline CTA가 있다.
- SEO metadata와 tracking attributes가 포함되어 있다.
- build/typecheck/content validation/layout smoke check가 통과한다.

## PR7 — Roadmap and Feedback

목표: 공개 Roadmap과 Tally 기반 feedback loop를 구현한다.

수정 범위:

- Roadmap page.
- Now / Next / Later board.
- release notes preview.
- Tally form config under `src/data/forms`.
- 업데이트 구독, 기능 요청, 로드맵 관심 등록, 기업 문의, Use Case 제보 위치.

주의 사항:

- Tally form ID와 링크는 데이터에서 관리하고 컴포넌트에 하드코딩하지 않는다.
- Roadmap 항목은 피드백 CTA와 연결되어야 한다.
- Supabase/CRM/internal DB는 도입하지 않는다.

Acceptance criteria:

- Roadmap에서 현재 진행, 다음 예정, 검토 중 항목이 구분된다.
- 각 주요 항목이 피드백 또는 관심 등록 흐름을 가진다.
- release notes와 업데이트 구독이 연결되어 있다.
- build/typecheck/content validation/link check가 통과한다.

## PR8 — i18n Expansion

목표: 핵심 페이지를 `ko`, `en`, `ja` 구조로 확장한다.

수정 범위:

- locale route structure.
- hreflang.
- language switcher if needed.
- Home, 핵심 Use Case 3개, Product, Plugin 4개, Roadmap의 core localization.
- locale-aware navigation, footer, CTA.

주의 사항:

- `ko`를 기준 콘텐츠로 두고 `en`, `ja`는 핵심 페이지부터 확장한다.
- `zh`는 future-ready 구조만 열어둔다.
- 긴 일본어/영어 문구가 모바일에서 넘치지 않게 한다.

Acceptance criteria:

- core pages가 `ko/en/ja`로 접근 가능하다.
- canonical과 hreflang이 올바르게 생성된다.
- locale switcher가 현재 페이지의 대응 locale로 이동한다.
- build/typecheck/content validation/layout smoke check가 통과한다.

## PR9 — SEO, Performance, Operations QA

목표: v1 출시 전 SEO, 성능, 운영 검증을 고정한다.

수정 범위:

- sitemap.
- robots.
- canonical.
- hreflang.
- OG metadata.
- Article/Product schema markup.
- selected asset optimization.
- lazy loading.
- link/build/typecheck/content/layout QA.
- Cloudflare preview 운영 체크.

주의 사항:

- `assets/raw` 전체를 최적화하거나 배포하지 않는다.
- 검증되지 않은 수치, 깨진 CTA, 누락된 locale을 출시 상태로 남기지 않는다.
- SEO 작업이 콘텐츠 구조를 우회하지 않게 한다.

Acceptance criteria:

- sitemap, robots, canonical, hreflang, OG metadata가 생성된다.
- 주요 페이지가 mobile/desktop에서 레이아웃 깨짐 없이 표시된다.
- link check, build, typecheck, content validation이 통과한다.
- Cloudflare preview에서 v1 완료 기준 페이지가 정상 동작한다.

## Shared QA Matrix

각 PR은 가능한 범위에서 다음을 보고한다.

- build
- typecheck
- content validation
- SEO metadata
- locale coverage
- CTA target
- tracking attributes
- internal link check
- Tally link check
- plugin marketplace link check
- mobile/desktop layout check

PR0처럼 scaffold 전이라 실행할 수 없는 항목은 이유를 PR summary에 명시한다.

## Post-PR0 Handoff

PR1 이후 작업은 이 세 문서를 source of truth로 사용한다.

- `docs/DESIGN_STRATEGY.md`
- `docs/TECH_STACK_DECISION.md`
- `docs/CONSTRUCTION_PLAN.md`

미래의 `TASK_PR*.md`는 전략 결정을 반복하기보다 위 문서를 참조해야 한다. 전략 변경이 필요하면 task 범위를 넓히지 말고 Chat A/Bosco의 승인 흐름으로 올린다.