워크플로우 가이드

Generate IDEAS.md from this conversation.

Purpose: a document the author reads to decide "do we build this or not", and to recall months later what the idea is and why it came up. The human decides; this document provides the material. Write concise Korean, using the author's own terms. It does not need to be exhaustive or formally precise.

Rules:
- Use only what was said in this conversation. Do not fill gaps.
- The idea is what the user stated or accepted. AI suggestions the user did not accept are not part of the idea.
- Do not add your own evaluation of the idea or a go/no-go recommendation. Evidence, objections, and scores that appeared in the conversation are copied as they appeared, with their tags ([출처]/[추론]/[의견]) if they had one. Do not invent numbers.
- Keep existence evidence (someone is doing it) separate from demand evidence (someone is dissatisfied or pays).

Top of the document:
- 한 줄 요약
- 결정 준비도: "판단 가능" or "더 논의 필요", with a one-line reason. This assesses whether the conversation covers enough to decide, not whether the idea is good.

Sections (omit any that were not discussed):
1. 발단: what triggered the idea, what was seen or experienced, by whom
2. 문제와 대상 사용자
3. 아이디어: what it does, as stated
4. 기존 대안
5. 증거: 존재 증거 / 수요 증거 / 반증
6. 반론과 의문, and whether each was resolved
7. 성공 조건(가정)과 한국 조건, if discussed. Put "fatal + unverified" items first.
8. 검증 결과: only if a score or table was made in the conversation, copied as is. Otherwise "검증 미실시".
9. 논의 중 바뀐 점 / 기각된 방향
10. 빠진 것과 미해결 질문: using this checklist as a guide, list which items are missing or only thinly discussed: 발단, 문제, 대상 사용자, 기존 대안, 수요 증거, 반증, 첫 사용자 확보, 누가 돈을 내는가, 한국 조건, 플랫폼·법규 의존, 단위 경제, 비어 있는 이유, 가장 그럴듯한 실패 이유. For each, one question to discuss next. Questions only, no answers.

Generate PRODUCT_SPEC.md.

INPUT
- The product information provided with this request.
  Product discovery and idea validation are complete and final.
  It is the only source of product information.
- If wireframes or mockups are provided, translate their structure into text.
  MUST NOT reference or embed image files.
- MUST NOT create any other document.
- Output the contents of PRODUCT_SPEC.md only.

STOP CONDITIONS
If information required for any section is missing, ambiguous, or contradictory:
output ONLY a numbered list of questions. Nothing else.
After I answer, treat my answers as final input and continue.
MUST NOT invent information to fill a gap.

PURPOSE
The purpose of PRODUCT_SPEC.md is to define:

What the product is.
What the product does.
How it works from the end user's perspective, including its UI and UX.
What the user can do.

SCOPE BOUNDARY
- Specify only what the end user can observe and do.
- Specify only what is to be built now. Features that were discussed but
  deferred to later MUST NOT appear in the document, except as
  Non-Goals if explicitly excluded.
- UI and UX are product behavior. MUST specify them (see USER INTERFACE RULES).
- How the product works internally (mechanism) belongs to ARCHITECTURE.md.
  MUST NOT describe implementation, architecture, technologies, tech stacks,
  programming languages, databases, internal APIs, internal components,
  or directory structures.
- Persistence is specified as observable behavior (what is kept across sessions),
  never as storage technology.
- Human-owned. MUST NOT specify:
  wording, copy, translations, images,
  visual styling (colors, typography, spacing, visual polish).
  Specify which content slots exist and what each is for, not their content.
- Business outcomes (revenue, user counts, conversion, growth, market targets)
  are out of scope. MUST NOT include them anywhere in the document.
- MUST NOT propose improvements.
- MUST NOT add features that were not discussed.
- MUST NOT expand the scope.

USER INTERFACE RULES
For every surface the user interacts with:
- Screens: give each a stable ID (SCR-001, ...), its purpose, and the elements on it.
- Elements: for each, its purpose and what the user can do with it.
- Arrangement: relative placement, grouping, and hierarchy only.
  MUST NOT specify exact sizes, spacing, or visual styling.
- States: every state that applies (initial, empty, loading, populated, error,
  disabled) and what is shown in each.
- Navigation: for each trigger, the destination.
- Interactions: for each user action, the observable result.
- Platform or window-size differences, only if stated in the input.
For non-graphical products (e.g. command-line):
- Every command, option, input, and the structure of output that users
  or other programs rely on, and exit behavior.
  MUST NOT specify exact output wording unless programs depend on it.

REQUIREMENT RULES
- Give every Functional Requirement a stable ID (FR-001, FR-002, ...).
- Each requirement is one externally observable behavior that can be
  verified pass/fail. If it cannot be written objectively, ask.
- Product Goals: only what the product enables the end user to do.
  MUST NOT include business outcomes.
- Error Conditions specify the observable behavior for each condition.
- Acceptance Criteria reference requirement and screen IDs and are pass/fail verifiable.
- Non-Goals: only what the input explicitly excludes.
- External Systems: list each external system the product depends on
  and the behavior relied on.
  Mark with [UNVERIFIED] the heading of any section whose behavior depends on
  an external system whose behavior has not been observed.
- Constraints: only observable non-functional requirements stated in the input
  (supported platforms or environments, performance, offline behavior,
  data retention, accessibility). If none are stated, write "None stated."

The document must include, in this order:

- Purpose
- Problem
- Product Goals
- Users
- Inputs
- Outputs
- Constraints
- External Systems
- User Interface
- Functional Requirements
- User Flows
- Error Conditions
- Non-Goals
- Acceptance Criteria

FORMAT
LANGUAGE
- Write the entire document in English, regardless of the input language.
  Translate all input content into English.
- Exception: proper nouns and identifiers stay as given.
- Content slots are specified by purpose only (see SCOPE BOUNDARY),
  so this rule never requires writing product copy.

READER
- The only reader is a coding AI agent. There is no human reader.
- Optimize for unambiguous, direct implementation and test derivation.
- Every line MUST be an actionable, verifiable statement or a defined fact.

STYLE
- MUST NOT include background, rationale, motivation, narrative,
  introductions, summaries, transitions, or commentary.
- One behavior or fact per bullet. MUST NOT combine multiple behaviors
  in one bullet.
- Use only "MUST" and "MUST NOT" for requirements.
  MUST NOT use "should", "may", "can", "ideally", "preferably".
- MUST NOT use vague terms: "etc.", "and so on", "appropriate", "as needed",
  "fast", "user-friendly", "properly", "similar".
  Enumerate every item explicitly. If it cannot be enumerated, ask.
- Use one term per concept. Define it once in the section where it
  first appears and reuse it exactly. MUST NOT use synonyms.
- Reference other items by ID only (FR-xxx, SCR-xxx, EL-xxx, ERR-xxx).
  MUST NOT refer to them by description.

STRUCTURE
- Flat bullets. Maximum nesting depth: 2.
- Per screen, use this fixed schema in this order:
  ID / Purpose / Elements (EL-xxx: purpose, user actions) /
  States / Navigation (trigger -> destination) /
  Interactions (action -> observable result)
- Use "trigger -> result" lines for navigation and interactions.
- Give IDs to every element (EL-), error condition (ERR-),
  and acceptance criterion (AC-).
- No emphasis styling, no emoji, no ASCII art, no images.
- Output the document only.