--url … --key …` walks a whole local directory (`.liquid` → template, everything else → static, relative paths preserved). Either way the Liquid content never gets JSON-escaped. ### Step 7 — Dry-run checkpoint (flows) Every flow assembled above gets a dry run BEFORE it is saved and published (flows-guide.md "Dry run"): `dryRunFlow(flow, context)` executes the UNSAVED document against a mocked request — emails/webhooks are suppressed (recorded, never sent), graphql nodes answer from `context.graphqlResults` and `result_key` http_post nodes from `context.httpResults`, and the step trace shows condition branches including `field_not_resolved` diagnostics. Run 3–4 scenarios per flow: happy path, empty body, member vs anonymous, invalid signature. Fix, then save (`saveFlowDoc`). Fetch the `flowctl` CLI binary, one-time download: ``` curl -fsSL https://dynapi.ru/cms/agent-skill/cli/flowctl-linux-amd64 -o flowctl && chmod +x flowctl ``` (Windows: `.../flowctl-windows-amd64.exe`; macOS: `.../flowctl-darwin-arm64` Apple Silicon, `.../flowctl-darwin-amd64` Intel.) Run `./flowctl validate ` FIRST as the local pre-check — it parses the document, runs the save-time validator and Liquid-syntax-checks every config string offline, and lists the `secret://` references the flow depends on. The same binary carries the staging steps, so the whole pipeline is one tool: `validate` → `dryrun` → `save` (draft; NEVER publishes) → `publish` — and `apply --publish` replays a full export (flow + templates + routes) in one call. No wrapper script needed. ### Step 8 — Publish What goes live when: - ROUTE-LEVEL settings (path, methods, cache, sitemapQuery, flow bindings, member gate) go live on SAVE in the ADMIN UI — the UI runs `saveSiteRoute(draft: true)` immediately followed by `publishSiteRoute(path)`. When driving the raw API, run the same pair. - QUERY-LIBRARY and FILE writes (templates, statics) are DRAFT-FIRST: the preview host executes drafts; promote per item with `publishSiteQuery` / `publishSiteTemplate` / `publishSiteStatic`, or in bulk with `publishSite`. - FLOW BODIES stage and need `publishFlowDoc(slug)` EACH — `publishSite` never promotes flow drafts (below). Bulk promotion of query-library and file drafts: ```graphql mutation { publishSite { templatesCopied routesPromoted queriesPromoted sitemapUrls publishedAt } } ``` Publish validates first (corrupt draft JSON and routes with no flow bindings are rejected). Validation failure returns `SITE_PUBLISH_VALIDATION_FAILED` with a `details: [String!]` **extension** listing each violation (the message stays the bare code). On success: draft templates are copied to main, routes and queries are merged **item-by-item** into live by `updatedAt` recency (a live write newer than the draft copy survives and is reported in `routesConflicts`/`queriesConflicts` — see `conventions.md`), the sitemap is regenerated and `robots.txt` gets a `Sitemap:` line. Check state any time with `sitePublishStatus { lastPublishedAt sitemapUrls }`. Per-flow promotion (the flow BODY is the only artifact `publishSite` skips): ```graphql mutation { publishFlowDoc(slug: "home") { slug published } } ``` `published: false` means the staging copy matched live already. The flow's state is visible on `flows { slug flow_live flow_has_draft }`. ### Step 9 — Verify the public URL The public URL shape is `https://.`: ```graphql query { siteSubdomain { subdomain baseDomain } } ``` With `subdomain: "acme"`, `baseDomain: "dynapi.ru"` → `https://acme.dynapi.ru`. `GET` it and expect a 200 HTML page. **Preview URL — the real mechanism.** There is no draft-namespace query param and no separate preview app: the preview is a **host label prefix** on the tenant subdomain (single-label `preview-_{`).
The render service's resolver (`internal/render/tenant_resolver.go` (extractSubdomain),
default prefix from `RENDER_PREVIEW_HOST_PREFIX`, which defaults to `preview-`)
parses `preview-_{.` (single label) and flags the request as
preview. So the preview URL for the example above is
**`https://preview-acme.dynapi.ru`**. A preview request reads:

- routes from `routes.draft.json`, **falling back** to published `routes.json`
when no draft file exists (nothing pending);
- queries from `queries.draft.json`, **falling back** to `queries.json`;
- templates from `templates/_draft/` **with a per-file fallback** to the
published body: a file the reviewer edited renders its
draft, one without a staged copy renders live — and the same draft-first
overlay covers static assets (`static/_draft/` → `static/`).

Practical consequence: to preview a coherent site you must have at least one
draft routes document (any `saveSiteRoute(draft: true)` seeds the draft from the
live routes as a complete working copy) and a draft copy of every template the
flows render. The preview host exists only on the platform subdomain —
custom domains never serve drafts. `POST`/`PUT`/`DELETE` form submissions and
flow mutations run on the preview host against draft routes and staged flow
copies — forms, member login and registration are testable on preview before
publishing; submissions persist for real and rate limits apply.

---

## 2. add-a-page

Add one static page to a published site using the seeded `page` entity.

### Step 1 — Create the page entry

The `page` entity is seeded per tenant (`internal/bootstrap/content_entities.go`,
slug `"page"`) with properties: `title` (string, required, localized), `slug`
(string, required, unique), `status` (select: draft/published), `seo` (entity →
`page-seo`), `blocks` (entity array). Entries are created with the **typed
mutation** the schema generator derives from the slug — `page` → PascalCase
`Page` → `createPage(input: PageInput!)` (same convention the admin SPA uses,
`admin/src/services/graphql-service.ts:172-185`):

```graphql
mutation {
createPage(input: {
title: "About us"
slug: "about"
status: "published"
}) {
id
}
}
```

`blocks` is optional — a page with no blocks is fine for simple content. Note
the seeded `page` has no plain `body` field; free-form content goes into
`blocks` (entity refs to block types like `hero-section`) or you use a custom
entity. Editing later: `updatePage(id: ..., input: PageUpdateInput!)` — the
update input is all-nullable (partial update, merge semantics).

### Step 2 — Save the query (draft)

```graphql
mutation {
saveSiteQuery(
entry: {
name: "about_page"
query: "{ pages(where:{slug:{eq:\"about\"}}){ id title slug } }"
}
) {
status
}
}
```

`name` is the library key a flow's graphql node references (`library_name`).
The query is a full GraphQL document (string). Static queries need no
variables; parameterized ones use `$var` GraphQL variables the node binds in
its `variables` map — Liquid-rendered against the flow context (see
workflow 3).

**Checkpoint — dry-run every saved query with EMPTY variables before preview.**
`saveSiteQuery` checks syntax only; a query that declares `$price_min: Int`
against a Float filter position (or hits any other runtime validation error)
surfaces NOT at save time but as an all-or-nothing preflight failure at
render: the page comes back blank with no error visible. One extra call per
query catches it in seconds — run the query text as-is against
`/cms/graphql` with `"variables": {}` and fix anything that returns
`errors[]`:

```json
{"query": "", "variables": {}}
```

### Step 3 — Save the route (draft)

Routes bind FLOWS, not templates or query refs. The page flow's graphql node
(`result_key: "about_page"`) fetches the data and feeds the template;
`results.` is ALSO lifted into the render context as ``, so
`about_page.data.` in the template still works.

```graphql
mutation {
saveSiteRoute(
route: {
path: "/about"
methods: ["GET"]
cache: { defaultTtl: 300 }
flows: [{ handle: "about_page_flow", methods: ["GET"] }]
}
) {
status
}
}
```

`originalPath` (optional) is the route's current path when **renaming/moving** —
omit it to append. On the first draft write the draft document is seeded from
the live `routes.json` (complete-working-copy), so existing routes are carried
over. `methods` defaults to `["GET"]` when omitted. Every route needs ≥1 flow
binding.

A route saved with path exactly `/404` is special: it becomes the site-wide
custom not-found page, served automatically with HTTP 404 for every unmatched
path (the preview host uses the draft `/404` route; its template must not
depend on `:params` — there are none). Details in `liquid-guide.md`
("404 and error pages").

### Step 4 — Save the template (draft)

```graphql
mutation {
saveSiteTemplate(
path: "about.liquid"
content: "{{ about_page.data.pages[0].title }}"
) {
status
}
}
```

Each graphql node's result is exposed in Liquid under its `result_key` as the
full GraphQL response envelope (`about_page`) — access data via
`about_page.data.` (here `about_page.data.pages[0].title`, since the
query selects `pages`).

### Step 5 — Preview check

Open `https://preview-_{./about`. The draft route + draft
template + (draft-or-live) query library must all be in place — see the preview
rules in workflow 1, step 9. If the page renders the generic fallback, the
draft template is missing; if it 404s, the draft routes document is missing.

### Step 6 — Publish

Promote the template draft per file, or in bulk:

```graphql
mutation { publishSiteTemplate(path: "about.liquid") { status } }
```

```graphql
mutation {
publishSite {
templatesCopied
routesPromoted
queriesPromoted
sitemapUrls
}
}
```

The route's flow binding went live at save time (workflow 1, step 8). Then
verify `https://_{./about` returns 200.

---

## 3. blog-with-dynamic-routes

A blog section with an index page and per-post URLs (`/blog` + `/blog/:slug`).

### Step 1 — Create the BlogPost entity definition

```graphql
mutation {
createEntity(input: {
name: "Blog Post"
slug: "blog-post"
description: "Blog articles rendered by the public site"
properties: [
{ name: "title", type: "string", required: true }
{ name: "slug", type: "string", required: true, unique: true }
{ name: "content", type: "text" }
{ name: "published", type: "bool" }
]
}) {
id
slug
}
}
```

`PropertyInput` fields (`internal/graphql/type_builder.go:985-1005`): `name`!,
`type`!, `required`, `unique`, `is_array`, `localized`, `entity_ref`,
`config` (object or JSON string), `conditions`, `validation`. Common `type`
values: `string`, `text`, `select`, `number`, `int`, `bool`, `datetime`,
`entity`. There is no `markdown` type — markdown content is `text` (the
`text` editor is markdown by default).
Requires the admin/owner role (`ADMIN_ROLE_REQUIRED` otherwise).

Slug-to-name mapping for everything this entity generates (kebab → PascalCase →
naive English plural): `blog-post` → type `BlogPost` → input `BlogPostInput` /
`BlogPostUpdateInput`, singular field `blogPost`, plural field `blogPosts`,
mutations `createBlogPost` / `updateBlogPost` / `deleteBlogPost`.

**The schema rebuild is asynchronous.** The definition row is committed before
the mutation returns, but `createBlogPost`/`blogPosts` appear only after the
rebuild lands (goroutine in single-tenant mode; per-tenant cache invalidation in
MT mode — `internal/graphql/rebuilder.go`). Poll introspection until the field
shows up (typically seconds):

```graphql
query {
__type(name: "Mutation") {
fields {
name
}
}
}
```

`config` (used by `select` options) is a loose JSON scalar — send either an
inline object (`config: {options: [{label: "Draft", value: "draft"}]}`) or a
JSON-encoded string; both persist. Select options set through
`createEntity` work — no need to avoid config-carrying property types when
defining entities via GraphQL.

### Step 2 — Create sample entries

After the rebuild lands (introspection shows `createBlogPost`):

```graphql
mutation {
first: createBlogPost(input: {
title: "Hello world"
slug: "hello-world"
content: "# Hello\n\nFirst post."
published: true
}) {
id
}
second: createBlogPost(input: {
title: "Second post"
slug: "second-post"
content: "# Second\n\nMore text."
published: true
}) {
id
}
}
```

### Step 3 — Query library entries with limit/offset and the `$slug` variable

How params flow into queries: a flow's graphql node carries a `variables` map
whose values are Liquid-rendered against the flow context before the
preflight call:

- `"slug": "{{ params.slug }}"` — a **path param** captured from the route
pattern (`/blog/:slug` + `/blog/hello` → `slug = "hello"`);
- `"tag": "{{ query.tag }}"` — a **URL query param** (`?tag=foo`). An ABSENT
or EMPTY string leaf is OMITTED from the variables, so the variable
resolves to `null`, and a null filter operator (`eq: $tag` etc.) is
skipped — so `where: {genre: {eq: $tag}}` is a safe OPTIONAL filter: the
default page shows everything, `?tag=rock` filters. No `contains`
workaround needed. (`search: ""` is likewise a no-op.)
- `"limit": "10"` — any other value passes through as a **literal
constant**. Variables are typed-coerced per their DECLARATION in the
query: a literal `"10"` bound to `$limit: Int` (or `"true"` to
`$flag: Boolean`) is converted to a proper JSON number/bool before the
preflight call — GraphQL itself never coerces a string into Int.
- Required-Boolean pattern: `"v": "{{ query.v }}"` with
`query($v: Boolean!)` — an absent param executes with `false`.

Rendered values (truncated to 256 runes) are sent as GraphQL **`variables`**
on the preflight request — never string-interpolated into the query. The
library query declares the variable and uses it: `$slug` with
`where: {slug: {eq: $slug}}`.

```graphql
mutation {
saveSiteQuery(
entry: {
name: "blog_index"
query: "{ blogPosts(limit: 10, offset: 0, where: {published: {eq: true}}, orderBy: [{field: CREATED_AT, direction: DESC}]) { id title slug } }"
}
) {
status
}
}
```

```graphql
mutation {
saveSiteQuery(
entry: {
name: "blog_post_by_slug"
query: "query($slug: String) { blogPosts(where: {slug: {eq: $slug}}, limit: 1) { id title slug content } }"
}
) {
status
}
}
```

Notes: plural fields accept `where`, `orderBy: [{field, direction}]`, `limit`
(default 10), `offset`, `search`. **`orderBy.field` is the ENUM value, not the
property name** — `CREATED_AT`, `TITLE`, never `"created_at"`: a quoted string
saves into the query library without complaint but fails the query at
preflight/render time (and one failing ref drops ALL of the route's bindings —
see `liquid-guide.md`). `Where` nests one operator input per
filterable property (`slug: {eq: $slug}`), plus `AND`/`OR`/`NOT`. A unique
top-level `slug` property also enables a singular field `blogPost(slug: "...")`
if you prefer. Filtering uses eq/neq/gt/gte/lt/lte/contains/startsWith/endsWith
per property type.

### Step 4 — Flows + routes

The listing page is a GET flow: a graphql node (`library_name: "blog_index"`)
fetches the posts, a render node draws the listing template. The detail page
is the same shape, with the graphql node's variables binding the path param:
`"variables": {"slug": "{{ params.slug }}"}` (step 3). The library queries
from step 3 stay valid as-is. Bind each flow to its route:

```graphql
mutation {
blogIndex: saveSiteRoute(
route: {
path: "/blog"
methods: ["GET"]
cache: { defaultTtl: 300 }
flows: [{ handle: "blog_index_flow", methods: ["GET"] }]
}
) {
status
}
blogPost: saveSiteRoute(
route: {
path: "/blog/:slug"
methods: ["GET"]
cache: { defaultTtl: 300 }
flows: [{ handle: "blog_post_flow", methods: ["GET"] }]
}
) {
status
}
}
```

Both writes are draft (default). Path patterns use Gin-style `:param` segments;
matching prefers STATIC over `:param` at each position regardless of pattern
length — a static segment always beats a param segment, so a catch-all
`/:section` can never shadow `/about`.

### Step 5 — Templates

```graphql
mutation {
indexTpl: saveSiteTemplate(
path: "blog/index.liquid"
content: "{% for post in blog_index.data.blogPosts %}{{ post.title }}
{% endfor %}"
) {
status
}
postTpl: saveSiteTemplate(
path: "blog/post.liquid"
content: "{{ blog_post_by_slug.data.blogPosts[0].title }}
{{ blog_post_by_slug.data.blogPosts[0].content }}"
) {
status
}
}
```

Template addressing is unchanged: the flow's `results.` envelope is
lifted as `.data` in the render context, so `blog_index.data.blogPosts`
and `blog_post_by_slug.data.blogPosts[0]` resolve exactly as before.

### Step 6 — Preview, then publish

Preview `https://preview-_{./blog` and `/blog/hello-world`
(remember: preview needs the draft routes document and draft copies of both
templates — the step-4 `saveSiteRoute` calls created the draft routes; the
step-5 template saves created the draft templates). Then:

```graphql
mutation {
publishSite {
templatesCopied
routesPromoted
queriesPromoted
sitemapUrls
}
}
```

Dynamic routes are also expanded in the sitemap at publish time — via the
route's `sitemapQuery`, the ONLY enumeration source (a route without one
contributes nothing). Substitution is by EXACT field name: every `:param` in the
path is filled from the enumerated items' field of the same name —
`/blog/:slug` needs items carrying a `slug` field, and items missing any
param field are skipped (no URL). There is NO `slug`/`id` fallback; a
dynamic route (catch-alls included) with no enumerating query contributes
NOTHING. Queries that enumerate for the sitemap must declare their
variables NULLABLE (`$slug: String`, not `String!`) — the publisher
preflight runs them without path vars, and a `String!` kills the route's
whole sitemap contribution.

Duplicate URLs collapse: one item per value yields one `` per value —
enumerating `/prices/:category` over items that carry a repeating
`category` field produces the 4 distinct URLs, not one per item. When you
need one URL per DISTINCT VALUE (not per item), make the enumerating query
return one item per value — a small dictionary entity whose property equals
the value, or a query over that dictionary (24 items × 4 categories → 4
URLs, not 24).

For this blog, save an INDEX query (no param filter) and point the route's
`sitemapQuery` at it — one `` per post:

```graphql
mutation {
saveSiteQuery(entry: { name: "blog_sitemap", query: "{ blogPosts(limit: 100) { slug } }" }) { status }
}
```

Then add `sitemapQuery: "blog_sitemap"` to the `/blog/:slug` route (step 4)
and re-publish.

If a dynamic route contributes ZERO URLs (compare `sitemapUrls` against your
expectations), either it has no `sitemapQuery`, its items
lack the param field, or an enumerating query failed the publish-time
preflight — most often a non-nullable variable (`String!`) or a query that
doesn't parse / references a non-existent field. The failure is logged
server-side and the route is silently skipped from the sitemap; fix the
query and `publishSite` again.

### Client-side dynamic loading ("показать ещё")

Browser JS gets JSON from a FLOW endpoint: bind a flow to a GET path (e.g.
`/blog/more`), add a graphql node reading the offset from `query.*`, and
finish with a `respond_json` render node (`Content-Type: application/json`).
The page's
JS then fetches that path — conditions and member context are available in
the flow, and the no-JS baseline stays intact (server renders page 1
inline; JS only appends):

```html

```

---

## 4. contact-form

A contact form on a published page: handle + automation flow + template markup +
submission test + reading submissions.

### Step 1 — Create the contact flow on a route

```graphql
mutation {
createFlow(
slug: "contact"
route_path: "/contact"
name: "Contact form"
enabled_cors: false
) {
id
slug
route_path
slug
}
}
```

`slug` is optional (omitted → `"default"`; whitespace normalized to `-`).
`route_path` must equal the **published page path** the form POSTs to. The
POST reaches the flow through the ROUTE'S BINDING (a `methods: ["POST"]`
binding, optionally header-conditioned).
`slug` (the composite key used everywhere else) is
`route_path + ":" + slug` — here `"contact"`. Errors:
`FORM_HANDLE_SLUG_INVALID`, `FLOW_DUPLICATE` (409-equivalent),
`FORM_HANDLE_INVALID_ORIGIN` (only when `allowed_origins` is set badly).
For cross-origin fetch submissions set `enabled_cors: true` +
`allowed_origins: ["https://example.com"]`.

### Step 2 — Attach the automation flow

The flow document is a v2 JSON graph (full reference in `forms-flow.md`).
Contact form: entry → send_email → terminal.

```graphql
mutation {
saveFlowDoc(
slug: "contact"
flow: "{\"version\":2,\"nodes\":[{\"id\":\"n1\",\"type\":\"entry\"},{\"id\":\"n2\",\"type\":\"action\",\"data\":{\"action_type\":\"send_email\",\"config\":{\"to\":[\"sales@example.com\"],\"subject\":\"New contact request\",\"body_template\":\"Name: {{form.name}}\\nEmail: {{form.email}}\\nMessage: {{form.message}}\",\"smtp\":{\"host\":\"smtp.example.com\",\"port\":587,\"username\":\"noreply@example.com\",\"password\":\"…\",\"from\":\"noreply@example.com\",\"from_name\":\"Acme\"}},\"on_error\":\"continue\"}},{\"id\":\"n3\",\"type\":\"terminal\"}],\"edges\":[{\"from\":\"n1\",\"to\":\"n2\"},{\"from\":\"n2\",\"to\":\"n3\"}]}"
) {
slug
}
}
```

`flow` is a **JSON string**. Validation codes: `FORM_FLOW_INVALID` (generic),
`FORM_FLOW_CYCLE`, `FORM_FLOW_SHAPE`, `FORM_FLOW_CONDITION_BAD`, plus
`INVALID_JSON` for unparseable input and `NOT_FOUND` when the handle doesn't
exist. Every `send_email` node carries its own `smtp` object —
`{host, port, username?, password?, from, from_name?}`: ask the user for
their mail server and write the creds into the node. Read it back
with `flowDoc(slug: "contact") { flow }`.

### Step 3 — Template form markup

The public form contract (verified in `internal/render/formpost.go`):

- The form **POSTs to the same path as the page** (`action="/contact"` or no
action attribute). There is no dedicated form endpoint.
- Content type: browser `application/x-www-form-urlencoded` (PRG flow) or
`application/json` (fetch with the header set explicitly). The reliable JS
recipe is `body: new URLSearchParams(data)` — it sets
`application/x-www-form-urlencoded` automatically; a plain object or string
body makes `fetch` send `text/plain`, which the form parser rejects with 404.
- Routing: the POST reaches the handle whose flow is bound to this path's
route with `methods: ["POST"]` (flows-guide.md §6) — create that binding
before publishing.
- Honeypot: include hidden fields named `_company`, `_website`, or
`_phone_extra`; if any is non-empty the submission is silently accepted (200)
and dropped.
- If Cloudflare Turnstile is enabled platform-wide (`RENDER_TURNSTILE_SECRET`),
the rendered form must include the widget and submit
`cf-turnstile-response`; otherwise the POST fails with `CAPTCHA_FAILED`.

```graphql
mutation {
saveSiteTemplate(
path: "contact.liquid"
content: "Contact
"
) {
status
}
}
```

Showing a "thanks" state after the PRG redirect: the template's Liquid context
contains only the flow's result envelopes (`results.` lifted as
`.data`; URL params are not template bindings), so a bare
`{% if submitted %}` is not available. The simplest reliable recipe is a few
lines of inline JS reading `?submitted=1`:

```liquid
{% raw %}Thanks — your request has been sent.
{% endraw %}
```

The no-JS recipe is the flow condition pattern — see step 6.

Create the `/contact` route + flow as in workflow 2, then publish.

### Step 4 — Test the submission against the public endpoint

POST to the page path on the **public** host (preview-host POSTs run the
staged flow — testable there before publish):

```bash
curl -i -X POST https://_{./contact \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{"name":"Jane","email":"jane@example.com","message":"Hi"}'
```

Responses (verified in `formpost.go`):

- `Accept: application/json` → `201 Created` `{"ok":true,"id":""}`
(or 200 `{"ok":true,"id":""}` for a honeypot hit).
- Browser form POST → `303 See Other` redirect to the same path with
`?submitted=1` appended (PRG — refresh doesn't re-POST).
- Errors: 404 when the path has no POST-bound flow; 429
`RATE_LIMIT_EXCEEDED` (per-tenant or per-IP bucket, `Retry-After: 60` —
per-IP default 10/min); 403
`CAPTCHA_FAILED` when Turnstile is on and the token is missing/invalid; 400
`INVALID_REQUEST_BODY` for an unparseable body.

The automation flow runs asynchronously after the 201 — the HTTP response never
reflects flow success. Check the run trail via `flowRunsForFlow`.

### Step 5 — Read the submission

```graphql
query {
landingSubmissions(slug: "contact", limit: 20, offset: 0) {
id
form_name
payload
ip
user_agent
created_at
}
}
```

`payload` is the stored JSON (honeypots and the Turnstile control field
stripped before
persist). Args: `slug` (optional — omit for all forms), `limit` (default
100), `offset` (default 0). Requires `data:write` (note: this query is gated on
`data:write`, NOT `site:manage`). Aggregate view:
`landingSubmissionSummary { slug submissions_7d total last_activity }`.
Per-node execution audit of the flow:
`flowRunsForFlow(slug: "contact") { id action_type status error_message duration_ms started_at }`
— entry/condition/terminal nodes are not recorded, only action visits.

### Step 6 — PRG thanks-state without JavaScript

The FLOW way, no JS anywhere:

- The POST flow ends with a **redirect** node: `location: "?submitted=1"`,
`status: 303`.
- The page is a GET flow with a **condition** node whose predicate is
`{"field": "query.submitted", "operator": "eq", "value": "1"}` — the
then-branch renders the thanks section/template, the else-branch renders
the normal page (the form).

Route carrying both bindings:

```json
{ "path": "/contact", "methods": ["GET", "POST"],
"cache": {"defaultTtl": 3600},
"flows": [{"handle": "contact_page", "methods": ["GET"]},
{"handle": "contact_submit", "methods": ["POST"]}] }
```

This is the no-JS thanks pattern (PRG): the browser POST gets a
`303 See Other` to `?submitted=1`, the follow-up GET takes the condition's
then-branch and renders the thanks block server-side. Verify with curl (no
`Accept: application/json`): the POST must answer `303` +
`Location: /contact?submitted=1`, and GET with the param must render the
thanks branch.

### Step 7 — Contextual pre-fill (CTA → pre-filled form)

Every CTA that leads to a form should CARRY CONTEXT, and the form should
pre-fill from it — «Записаться» on a specific class links to
`/workshops?class=tarty#booking` and the form pre-selects that class; «Заказать
похожее» on a detail page links to the form with the piece pre-filled. A
generic form the visitor has to re-contextualize themselves is a defect
(user directive: rounds shipped bare forms + naked CTAs).

The whole pattern is server-side `site.query` — no JS:

- CTA: `Записаться`
(repeat CTAs elsewhere on the site inherit the SAME param shape).
- The page flow's graphql node binds the param:
`"variables": {"class": "{{ query.class }}"}` — `/workshops?class=tarty`
and `/workshops` are distinct requests, and the optional filter only
applies when the param is present (an absent/empty leaf is omitted, so the
filter is skipped).
- Select pre-fill:
`}}}}}}

{{ posts_list.data.posts[0].title }}

{{ about_page.data.pages[0].title }}

{{ blog_post_by_slug.data.blogPosts[0].title }}

Contact