# /ideate

Read `contracts/authoring-delivery.md` before discovery. Establish the bootstrap receipt and inspect advertised/native tag agreement before generating repeated records. Emit the formal discovery artifact even when a narrative usage report is also included. This command does not combine with `/preview` in one first-message slash string.

When SiteGraph supplies `dynamicBindings` (`kiwe.dynamic-bindings.v1`), use it as the field vocabulary. Native WordPress/WooCommerce tags take priority; Kiwe supplies only the missing public bindings. Every occurrence of owner-managed data that should update after launch must have an inert `data-seam-anchor` and `data-seam-field="EXACT.CATALOGUE.PATH"` on its preview element. Keep real preview text, image URLs and links so the client can see the design. The matching closed field stitch declares `binding`, the catalogue's exact `dynamicTag`, `slot` and the existing source guard. Optional `data-seam-slot` disambiguates text/image/link. The markers and map must agree; markers alone do not authorize a guessed conversion.

Example: `<img data-seam-anchor="brand-logo" data-seam-field="identity.logo" data-seam-slot="image" src="VERIFIED_PREVIEW_URL" alt="Verified business name">` pairs with a field stitch whose `binding` is `identity.logo` and whose `dynamicTag` is the actual catalogue tag, usually `{kiwe_site_logo}`. Never replace preview copy with visible curly-brace placeholders.

Use the catalogue's native collection declarations for pages, products, selected Team, Services, media and testimonials. Stable group/offer IDs retain their meaning after renaming. In a loop bind every changing text, image, accessible label and link to the current record. Declared planning-only or private records must not become public queries or tags. An unknown future field, unsupported tag or incomplete catalogue is an explicit review item, never a hardcoded production substitute. Business activities may overlap: an online store can also publish news. Optional square/round brand assets reuse the owner's WordPress media references; do not invent a logo or Google resource.

Start with discovery, not a fixed questionnaire. Inspect every supplied file by its contents before asking anything. Treat the attachments themselves as the source brief; do not ask the user to describe files that can be inspected.

For any supplied existing design, establish its **source authority before choosing a creative lane**. Resolve exactly one of: `approved-final`, `enhancement-authorized`, or `redesign-authorized`. Only an explicit user statement can authorize enhancement or redesign; `/ideate`, the presence of source files, visual defects, stale navigation, missing content, or the AI's preference never grants that authority. If the conversation does not prove the answer, ask exactly one question: **“Is this design final/approved, should I enhance it without changing its art direction, or are you asking for a redesign?”** Then stop. Do not select a direction, propose an art style, request SiteGraph, emit a usage brief, or create files until the user answers. If the user says only “final” or “approved,” treat that as `approved-final`.

After source authority is resolved, determine the proven lane: a new website, preservation of an approved existing design, enhancement/expansion without changing its accepted art direction, or an explicitly authorized redesign. State the detected lane and ask only for another missing decision when it materially changes the result. Never ask again for facts already supplied by the project, SiteGraph or its embedded Design Context.

Once source authority is resolved, classify SiteGraph as `required`, `beneficial`, or `not-needed` and explain the evidence. SiteGraph is required when the requested result must use or preserve real site identity, owner decisions, media, products, posts, services, menus, taxonomies, custom fields, commerce data, or future dynamic-binding intent that the supplied files do not prove completely. It is beneficial but optional for an ungrounded concept that may use honest placeholders. It is not needed when the approved supplied project is self-contained and the requested work neither introduces nor changes site-owned facts. If required evidence is absent, stop before recreation and request exactly one safe SiteGraph handoff.

Choose the safest SiteGraph connection the participating AI can actually use. Prefer an already connected read-only SiteGraph tool or MCP resource; otherwise use a scoped, expiring task-capsule/API connection; otherwise request an attached current SiteGraph export. Do not pretend an unavailable connector worked, ask the user to choose technical transport, request a broad permanent key, or paste secrets into project output. Explain the one action required only when no safe connection is available.

Inventory approved source pages, assets, references and existing-site evidence before proposing work. Existing Design Context is authoritative for business facts and owner-locked brand values; SiteGraph design content supplies real media, products, posts, taxonomies, custom content and public identity. Distinguish read-only owner facts from AI-writable suggestions.

When SiteGraph is present, report **Design Context coverage before changing any file**. Use `seamDesignContext.scores.designContextStrength` as the authoritative percentage when supplied. Otherwise calculate coverage—not subjective design quality—using this evidence rubric: identity 15%, audience and goal 10%, brand preferences 15%, public contact and localization 10%, about/founder/team 15%, pages/services/content plan 10%, commerce and product context 15%, and approved resources/media 10%. Exclude a genuinely irrelevant section and redistribute its weight proportionally; never award points for guessed values or placeholders. Show the percentage, covered sections, material gaps, locked owner facts, preserved owner preferences, AI-writable gaps, and the SiteGraph/context hash when available. If SiteGraph is not needed, record coverage as `not-applicable` rather than fabricating a number.

Next share a concise **usage brief** before changing any file. Under Design Context, list only the verified owner facts and preferences that will materially affect this requested page or project. Under Design Content, shortlist only the real products, posts, services, menus and media that have a clear intended role in the proposed result. Select media by semantic metadata, intended resource role, orientation/aspect ratio and the actual section need; do not enumerate, download or force every SiteGraph media item into the design. State what will remain dynamic, what is preview evidence only, and any ambiguity requiring review.

Perform a **production-content readiness preflight** as part of that brief. When the user requests a final, production-ready or approved project and SiteGraph or the supplied self-contained source proves sufficient business context, every visible content region must contain grounded, page-appropriate final copy, a proven dynamic-binding intent, or an explicit human-review item. Do not leave lorem ipsum, “sample”, “dummy”, “placeholder”, TODO text, repeated generic filler, invented testimonials, fake statistics, guessed prices, unproven certifications, unsupported claims or fabricated contact/legal/compliance facts. Use verified SiteGraph facts and the page's purpose to complete the copy without changing an approved composition, hierarchy or art direction. Do not keyword-stuff. Preview placeholders are allowed only for an explicitly ungrounded concept where SiteGraph is not required; identify every such region in the discovery artifact and never represent that artifact as production-ready. If required facts are unavailable, mark the affected region blocked rather than guessing.

Then stop and ask the user to say `proceed`. Providing, attaching, replacing, reconnecting or updating SiteGraph, Design Context, source files, references or assets only satisfies an input request; it is never approval, never means `proceed`, and never authorizes file generation. After receiving any requested SiteGraph or other evidence, read it, emit the coverage report, usage brief and content-readiness preflight, and stop again. Do not create or modify output files before that explicit response. The explicit response must occur after the usage brief. Emit `ideate/kiwe-ideate-discovery.json` using schema `kiwe.ideate-discovery.v5` with approval status `awaiting-user` during this pause. After `proceed`, set it to `approved`, preserve the approved source authority and usage brief as the implementation boundary, and produce the project without another generic questionnaire. A later material change to either boundary requires a new approval; small conversational corrections do not.

Do not apply Seam Framework, Bricks structures or a SEAM house style. Do not flatten unusual but intentional art direction into a component library. Keep corrections conversational until the user accepts the result.

Return a complete browser-runnable HTML/CSS/JS project appropriate to the detected lane: create a coherent new project, preserve an approved existing design, enhance it within its accepted art direction, or redesign it only when explicitly authorized. For `approved-final`, visual composition, palette, typography, spacing system, responsive behavior, content hierarchy, page boundaries and JavaScript are immutable except for explicit user corrections; SiteGraph may ground content, media and functional intent and may add non-visual semantic/dynamic markers. Never collapse multiple supplied pages into one JavaScript-switched document unless the user explicitly requests a single-file application. When a single-file application is supplied or explicitly requested, give each page view a stable unique `data-view`, `data-page`, or `data-route-view` marker so `seam.kiwe` can partition shared header/footer and page bodies deterministically. Include every required local asset and `assets/asset-manifest.json`, recording provenance and intended WordPress Media use. Preserve semantic regions and `data-seam-role` only where they help people or the running page; do not use a role label as conversion authority. Never invent IDs, fields, products or site facts.

## Strict Semantic Seam handoff

Every project created or materially updated after `proceed` must also carry a closed **SEAM Map**. The visible HTML/CSS/JS remains the creative canvas. Add only inert, unique `data-seam-anchor="stable-token"` attributes to nodes whose WordPress meaning affects conversion; these attributes must not add CSS, alter layout, become JavaScript dependencies or influence art direction. Write the matching sidecar to `seam/seam-map.json` using `kiwe.seam-map.v1`, `mode: "strict"` and `sourcePolicy: "marker-only"`. This is a builder-neutral semantic handoff, not Bricks JSON and not Seam Framework.

The map must make each conversion-sensitive decision explicit: WordPress template type and template conditions; commerce ownership (`preserve` or `woocommerce`); editorial ownership (`static` or `posts`); full or partial dynamic text, link and image fields; repeated collections and their one retained prototype; Kiwe launchers; specialized native builder elements; native interactions; element conditions; and an explicit `static` stitch for a marked lookalike that must remain authored content. When one source document contains several WordPress outputs, add one `template-boundary` stitch per Page, Header, Footer, Popup or Archive root with an exact `outputPath`, title, full WordPress contract and `runtime: "include"|"exclude"`; at most one boundary in that document may own the authored runtime. Unmarked content has one deterministic meaning: preserve it as static source content. The compiler must never infer dynamic, commerce, editorial, template-boundary, interaction or conditional meaning in strict mode.

Use exactly one unique anchor per marked DOM node. Every anchor in HTML must be declared by one stitch, every declared anchor must exist exactly once, every stitch needs `key`, `semantic`, and explicit `authority` (`sitegraph`, `owner`, `approved-source`, or `wordpress-contract`), and each document closure must declare its unique anchor count with `status: "complete"` and `unresolved: []`. Root `requiresHumanReview` must also be empty. If a decision cannot be proven, stop and resolve it conversationally; never issue a nominally strict map with guesses, uncertainty, invented values or an outstanding review item.

For mid-sentence data, anchor the existing text host without introducing a wrapper and declare a `textRange` with the exact child-node path, complete original text and one exact match. For a collection, mark its container and exactly one representative preview item, declare the exact item selector and preview count, and prove that all preview copies are structurally equivalent after bound field differences are normalized. Do not delete preview cards in the source; seam.kiwe collapses only the conversion copy after validation. For native elements, interactions and conditions, provide declarative registered settings only; executable PHP, JavaScript, fetches or eval-like payloads are forbidden.

If any stitch uses SiteGraph authority, include the exact unchanged evidence used for ideation as `seam/site-graph.json`. Record that path, its revision and the SHA-256 of its exact bytes in the map. Every SiteGraph authority pointer must be an RFC 6901 JSON pointer that resolves inside that attachment. Every dynamic tag, query object type and Kiwe module must be present in the attached graph. If no stitch uses SiteGraph, declare the map's SiteGraph schema, path, revision and hash as `null` and do not include unused evidence. Compute every source SHA-256 only after all inert anchors are final. The source fingerprints, evidence hash, exact guards, marker closure and registered capability checks form the Proof Ledger; a mismatch must fail closed before Bricks JSON is emitted.

Before delivery, run `seam validate-seam-map <project>` and load every entry page at its intended desktop and mobile viewport. Fail closed on any validator finding, uncaught JavaScript error, missing-selector initialization, empty required region, broken local link, missing required asset or unintended document overflow. Bind scripts only to elements that exist. Record the runtime result in `contentReadiness.runtimeSmokeTest`; an artifact that fails either proof is not production-ready.


### Complete record bindings

Use native WordPress/WooCommerce tags for each record. Read `dynamicBindings` for exact commerce, configured pair and stable tag-group fields. A product card must bind its image, image description, visible price, accessible price and each link to the same current record; do not retain the sample label. For several slots on one node, use an inert JSON marker such as `data-seam-fields='{"image":"commerce.product.image","alt":"commerce.product.imageAlt"}'`. It replaces the single `data-seam-field` form on that node. Allowed slots are `text`, `image`, `link`, `alt`, `aria-label`, `title`; every slot has its own closed field stitch and exact original guard. Labels accept declared text/number fields only. Arbitrary attributes, private paths and executable tags are forbidden. Preview text, URLs and labels remain real values.

Native product query loops can use `kiweProductRelation` (`upsells`, `cross_sells`, `grouped`, `companion`, `configured_offers`) and optional `kiweRelationSource` in their query stitch. The compiler places these in the original Bricks element controls. Leave source empty for current product. Source relationships and pair configuration stay in Woo/Kiwe product editing. Stable pair selectors use the trigger product ID; renames retain tags and deleted/private targets become empty. The chooser/handoff enumerates at most 100 configured source products per request; current-record and exact stable selectors do not scan and remain valid beyond that sampled catalogue. Use the returned catalogue; never invent a final pair total. Woo owns quantities, chosen variations, coupons, tax, shipping and checkout totals.

## Command-only continuation

After the usage brief, `/preview` is explicit approval to generate that preview (the original `proceed` remains valid). Once the identified preview is accepted, `/seam` prepares a separate Framework source copy under contexts/seam.md. `/library` reads the complete public reference. None grants production deployment or redesign authority.