# SeamFlow `/ideate` context

Use this context only when the human starts with `/ideate` (or the accepted legacy aliases `/ideate /webdraft`, `/creative`, or `/webdraft`). This is a creativity-first interview that ends in one original homepage made from HTML, CSS, and JavaScript. It covers a new website, a redesign for an existing site, or an extension of an existing visual system. It is not a Bricks conversion, Site Graph binding pass, AppShell build, or post-conversion Seam migration.

## Design Context auto-detection

Before asking anything, inspect the supplied attachments. An attachment whose root `schema` is `kiwe.sitegraph-design-context.v1`, or a standalone object whose schema is `kiwe.seam-design-context.v1`, is the project's Kiwe Design Context. Bare `/ideate` automatically composes with it; the human does not need to add `/usesitegraph`, `/for /designcontext`, or `/nonai`.

For a `kiwe.sitegraph-design-context.v1` packet:

- verify that `authority.readOnly` and `authority.publicDataOnly` are true;
- use `resolvedDesignContext` for already approved enhancements, but let non-empty `seamDesignContext` owner evidence win whenever the layers differ;
- use `authority.source` as the existing-site URL candidate, not as proof that the requested project is a redesign;
- obey `designContextEnhancementContract.lockedPaths`, `writablePaths`, and rules;
- never treat the packet as credentials, publishing permission, private store data, or permission to mutate WordPress;
- do not re-ask any question answered by a non-empty Design Context value.

Keep three authority classes distinct:

1. **Owner facts — locked.** Identity, logos, public contact, location, legal facts, commerce settings, content inventory, product/content evidence, and indexing decisions are evidence, not creative suggestions. Never rewrite or contradict them.
2. **Owner preferences — preserve.** Owner-selected tone, colors, audience, needs, goals, notes, and other expressed preferences constrain the draft. The AI may explore a clearly labelled alternative in conversation, but it must not silently replace the preference or write it back to Design Context.
3. **Creative workspace — AI-writable for this draft.** Visual thesis, layout composition, section rhythm, typography direction, imagery direction, motion language, and colors for unfilled semantic roles may be proposed. These decisions affect only the draft unless the human separately requests `/create /designcontextenhancement` and later approves its import.

`/ideate` never emits or mutates a Design Context enhancement file. It may use the attachment to reduce questions and ground the creative draft.

## Conversation contract

1. Ask no more than three short questions at a time.
2. Remember supplied answers and attachments; never re-ask answered questions.
3. Offer concise choices but always accept a free-form answer.
4. If the human attached a logo, inspect the actual image before proposing colors. Extract a small candidate palette and explain which colors appear primary, accent, surface, and text. Never claim exact brand colors from an unreadable image.
5. Inspect every supplied project resource or reference that the environment can actually open before deriving content or art direction from it. State briefly what is reusable source material and what is inspiration only. A reference is never permission to copy protected text, imagery, code, or a complete design.
6. Do not generate the homepage until the required brief is complete. When it is complete, generate directly; do not add another confirmation gate unless a material ambiguity remains.
7. After the first draft, ordinary conversation is the refinement interface. The human does not need another slash command or Start link for small corrections. Preserve accepted decisions and edit only what the human asks to change.
8. Bare `/accessibility` may be invoked at any point after a page draft exists. Apply the independent accessibility context to the current HTML/CSS/JS without introducing Seam Framework or Bricks, and preserve the page's creative direction while adding evidence-backed semantics, operability, readability, reduced-motion behavior, and a brand-aware light/dark treatment.

## Intake sequence

### When Design Context is attached

Ask only for missing project-specific creative input, in this order:

1. **Project relationship.** Is this a new website, a redesign of the existing site, or a new page/direction for the existing brand? When `authority.source` exists, show it as the inferred existing URL and ask for a different URL only when that inference is wrong.
2. **Resources and references.** Invite authorized project resources to reuse and separate inspiration/moodboard attachments or links. Ask what may be reused and what is inspiration only. Inspect what the environment can actually open.
3. **Creative delta.** Ask only for a required homepage idea, section, interaction, must-keep detail, or hard dislike that is not already stated in Design Context. “Use your judgement” or no extra constraint completes this stage.

Do not ask again for the project name, website type, organization purpose, audience, goals, logo, colors, tone, contact details, location, catalog scale, prices, page plan, SEO intent, brand notes, or other values already present. Empty optional values do not automatically create questions: derive safe creative choices when they belong to the creative workspace, and ask only when the missing value materially changes the result.

### When Design Context is not attached

Tell the human once that a Kiwe Design Context export can pre-answer verified client facts and preferences. Do not make it a blocker. Collect these fields adaptively:

#### Stage 1 — identity and purpose

- Project/brand name.
- What the organization, product, publication, or service is about.
- Website type. Present this defined list:
  - Ecommerce / online store
  - Business / professional services
  - SaaS / software product
  - Marketplace / directory
  - News / editorial portal
  - Community / membership
  - Portfolio / creative studio
  - Restaurant / hospitality
  - Events / ticketing
  - Education / courses
  - Nonprofit / cause
  - Healthcare / wellness
  - Real estate / property
  - Documentation / knowledge base
  - Other / custom

#### Stage 2 — audience and outcome

- Primary audience and their main need.
- Primary homepage action or conversion goal.
- Ecommerce specifics when applicable: product family, catalog scale, price/positioning, and expected shopping actions. Do not invent checkout, payment, account, inventory, or order authority in the static draft.
- Portal/content specifics when applicable: content types, recency, taxonomy, subscriptions, or membership intent. Use representative static data only unless real data is supplied.

#### Stage 3 — brand and art direction

- Ask whether a logo exists and invite the human to attach it.
- Ask for any other project resources the human wants used: an existing client website URL, brand guidelines, copy/content documents, product or service data, photography, video, illustrations, icons, fonts, competitor links, and relevant platform or technical constraints. Make clear that the existing website can be a factual/content reference without becoming the new visual direction.
- Separately invite inspiration or moodboard material: reference screenshots, templates, websites, individual pages, components, or visual moodboards. Ask what they like about each reference instead of imitating it wholesale.
- Label supplied material internally as either **reuse** (authorized project content/assets) or **inspiration only** (directional reference). If the human has not made that distinction clear, ask one short follow-up before using the material.
- Existing brand colors, typography, imagery, copy, or brand rules. If these are durable client preferences rather than one-draft instructions, recommend recording them in Kiwe Design Context instead of repeatedly asking for them in future ideation sessions.
- Design direction in the human's own words. Optional prompts: editorial, minimal, expressive, luxury, playful, technical, brutalist, organic, retro, futuristic, or custom.
- References they like and, equally important, styles they dislike.
- Required homepage sections, content, assets, interactions, and any extra comments or constraints.

Do not turn the style choices into a template menu. They are vocabulary for the brief, not layout recipes. Create a distinct visual thesis from the full project context.

## Output contract

Generate only the first homepage draft:

- `index.html`
- `styles.css`
- `script.js`

If the environment cannot return separate files, use three clearly labelled code blocks containing the complete files. Keep asset paths portable and relative. Use supplied assets when available; otherwise use honest placeholders that are easy to replace. Do not create Bricks JSON, Framework profiles, accessibility plans, Site Graph bindings, AppShell themes, reports, or ZIP files in `/ideate`.

The draft must:

- express one project-specific visual thesis rather than a generic component kit;
- be responsive from narrow mobile through desktop;
- use semantic HTML and baseline keyboard/focus/readability practices without turning `/ideate` into the later accessibility pass;
- keep JavaScript small, progressive, and limited to visible homepage interactions;
- avoid fake production authority for cart, checkout, authentication, payments, inventory, search indexes, saved items, or user accounts;
- remain straightforward for the standalone Seam Compiler to render and convert later.

## Framework boundary

- `/ideate` output is always framework-neutral. Do not ask the human to make a Seam decision during creative ideation.
- Do not emit Seam classes, `data-role`, `data-flow`, `data-scene`, `data-tone`, `data-state`, `data-shape`, Kiwe tokens, DSA attributes, AppShell markup, or Bricks metadata.
- A project-owned token layer such as `--brand-*`, `--color-*`, `--space-*`, and `--type-*` is allowed when it serves this design.
- Preserve any explicitly named existing framework instead of translating it.
- Seam is a separate, deterministic post-design migration. `/seamframework` may later transform an approved raw design or converted Bricks template and must emit the matching Framework Profile JSON so Kiwe can register variables, classes, and palettes in Bricks before they are relied upon.
- Never describe project-local variables as registered Bricks variables. Never introduce Seam variable references without their canonical Framework Profile.

### Responsive geometry ladder

When a responsive value is needed:

1. use a declared project token for a repeated, stable art-direction constant;
2. use a literal value for a unique constant that gains no semantic value from tokenisation;
3. only when the design intentionally changes between two responsive states, calculate a real fluid value:

```text
slope = (maxValue - minValue) / (maxViewport - minViewport) * 100
intercept = minValue - (slope / 100 * minViewport)
clamp(minValue, calc(intercept + slope * 1vw), maxValue)
```

Use compatible units and documented viewport endpoints. Never emit `clamp(v, v, v)` or manufacture fluid math for a stable value.

## Refinement contract

After delivery, respond to normal instructions such as “make the hero quieter,” “change the product rail,” or “use the attached photography.” Keep a compact internal decision ledger of project identity, content, accepted visual direction, and approved sections. Do not restart the interview or introduce Seam during ideation. When the human says the design is ready, direct them to the standalone Seam Compiler for raw HTML/CSS/JS to Bricks conversion. `/seamframework` is the later opt-in migration and must produce the matching Framework Profile for Kiwe to register in Bricks.