shiply-cli 0.27.2 → 0.29.0

package/skill/references/client-work.md

@@ -31,16 +31,49 @@ list_project_files  — files uploaded by the customer
 resend_intake_invite — re-email the customer their intake link (requires customerEmail on project)
 ```
 
-REST: `POST/GET /api/v1/projects · GET/PATCH /api/v1/projects/{id} ·
-POST /api/v1/projects/{id}/regenerate-brief`
-(archive: `PATCH /api/v1/projects/{id}` with `{"status":"archived"}` — no
-dedicated `/archive` route).
+REST:
+
+| Endpoint | Action |
+|---|---|
+| `POST/GET /api/v1/projects` | create / list |
+| `GET/PATCH /api/v1/projects/{id}` | read / update brief or metadata |
+| `POST /api/v1/projects/{id}/regenerate-brief` | re-run AI from current intake responses |
+| `POST /api/v1/projects/{id}/archive` `{reason?}` | dedicated archive route — mirrors `archive_project` (`PATCH .../{id}` `{"status":"archived"}` still works too, back-compat) |
+| `GET /api/v1/projects/{id}/files/zip` | download every customer-uploaded file as one .zip |
+| `GET /api/v1/projects/{id}/files/{fileId}/download` | 302-redirect to a short-lived signed URL for one file |
+| `POST /api/v1/projects/{id}/upload` | dev sends the customer a file (multipart `file` field, ≤25 MB) |
+| `PATCH /api/v1/projects/{id}/status-note` `{note}` | short customer-facing status line shown in the portal header (`note:null` clears it) |
+| `POST /api/v1/projects/{id}/resend-portal-link` | dev re-sends the customer's **portal** link — different from `resend_intake_invite`/`resend-invite` below, which re-sends the original **intake** invite |
 
 CLI: `shiply project ls · shiply project create <label> [--customer-email <e>]
 [--customer-name <n>] · shiply project get <id> · shiply project archive <id>`
 
 Docs: https://shiply.now/docs/projects
 
+### Intake — the customer-facing side (token auth, not Bearer)
+
+The intake URL a customer opens is token-scoped, not account-scoped — no
+Bearer key. These routes power the wizard, portal chat, and dev-side nudges:
+
+| Endpoint | Action |
+|---|---|
+| `GET /api/v1/intake/{token}/state` | current status + saved wizard responses + project label |
+| `PATCH /api/v1/intake/{token}` `{stepKey, data}` | save one wizard step (auto-save as the customer types) |
+| `POST /api/v1/intake/{token}/submit` | run AI brief generation from the saved responses |
+| `GET /api/v1/intake/{token}/contract` | the project's contract, if one has been sent to this token |
+| `GET/POST /api/v1/intake/{token}/files` | list / upload customer attachments |
+| `DELETE /api/v1/intake/{token}/files/{fileId}` | remove an uploaded attachment |
+| `GET/POST /api/v1/intake/{token}/messages` `{body}` (POST) | portal chat thread with the dev, oldest-first, `?before=` cursor |
+| `POST /api/v1/intake/{token}/nudge` | dev-triggered reminder ping to the customer |
+| `POST /api/v1/intake/{token}/email-link` | re-email the customer their intake link |
+| `POST /api/v1/intake/{token}/cookie` | set the portal session cookie for this token |
+| `GET /api/v1/intake/{token}/activity` | activity/audit log for this intake |
+| `POST /api/v1/intake/{token}/suggest` | AI suggestion helper for a wizard field |
+
+Dev-side equivalent for re-sending the invite email is `resend_intake_invite`
+(MCP) / `POST /api/v1/projects/{id}/resend-invite` — different from the
+customer-token `email-link` route above.
+
 ## Group work by client (optional, for freelancers)
 
 Building sites for clients? Pass an optional `client` (a name or email) on any
@@ -56,7 +89,28 @@ drive/intake/contract all land under the same client. List calls take an
 optional `clientId` filter (`list_sites`/`list_drives`/`list_projects`).
 Omit `client` for personal projects; shiply works identically.
 CLI: `--client "<name-or-email>"` on publish/drive/project, plus
-`shiply client ls|show`.
+`shiply client ls|show`. Re-assign (or clear) a client on an already-published
+site directly: `PATCH /api/v1/publish/{slug}/client` `{clientId}`
+(`clientId: null` clears it) — no MCP tool for this yet, REST only.
+
+REST (Bearer; Studio plan — `assertStudioEntitled` gates `POST`):
+
+| Endpoint | Action |
+|---|---|
+| `GET /api/v1/clients` | list your clients → `{clients}` |
+| `POST /api/v1/clients` `{name, email?, phone?, company?, notes?}` | create a client explicitly (usually unnecessary — clients self-assemble from `client`/`customerEmail`) |
+| `GET /api/v1/clients/{id}` | rollup view: sites, drives, projects, contracts, invoices under this client |
+| `GET /api/v1/clients/{id}/invoices` | list invoices for this client |
+| `POST /api/v1/clients/{id}/invoices` `{description, amountCents, currency?, dueDate?, projectId?}` | create an invoice |
+| `POST /api/v1/invoices/{id}/send` | email the invoice to the client |
+| `POST /api/v1/invoices/{id}/void` | void an unpaid invoice |
+| `POST /api/v1/clients/{id}/portal` | enable the client's public portal (idempotent) → `{portalUrl}` |
+| `DELETE /api/v1/clients/{id}/portal` | disable the portal — the link dies immediately |
+| `POST /api/v1/clients/{id}/portal/rotate` | mint a fresh portal token (old link dies instantly) |
+
+No `list_clients`/`get_client`/portal-management MCP tools exist yet — this
+is REST + CLI (`shiply client ls|show`) only; an MCP agent reads client data
+indirectly via `list_sites`/`list_drives`/`list_projects` with `clientId`.
 
 ## Contracts — draft, sign, amend (extends Projects)
 
@@ -91,7 +145,7 @@ Example agent flow (draft → tweak fee → send → poll → amend):
 6. `contract_send({contractId: amendment.id})` (no PATCH needed if the amend fields are right)
 
 REST (Bearer for dev, portal cookie for customer):
-`POST /api/v1/projects/{id}/contracts` (draft) ·
+`POST /api/v1/projects/{id}/contract` (draft — singular; the plural `/contracts` is a GET-only read bundle) ·
 `GET/PATCH /api/v1/contracts/{id}` (read either-party / dev edit) ·
 `POST /api/v1/contracts/{id}/send` (dev) ·
 `POST /api/v1/contracts/{id}/view` (customer ping) ·
@@ -141,12 +195,13 @@ refund_order     — issue Stripe refund (within refund window; goes back to buy
 get_connect_status — Stripe Connect onboarding state + actionable URL
 ```
 
-REST: `POST /api/v1/listings · PATCH /api/v1/listings/{id} ·
-POST /api/v1/listings/{id}/checkout · POST /api/v1/orders/{id}/refund ·
-GET /api/v1/connect/status`
-(no GET listing index over REST yet — use the MCP `list_listings` /
-`list_my_sales` / `list_my_orders` tools for machine output, or the
-dashboard `/dashboard/sales` page for humans.)
+REST: `GET/POST /api/v1/listings · PATCH /api/v1/listings/{id} ·
+POST /api/v1/listings/{id}/checkout · GET /api/v1/orders ·
+POST /api/v1/orders/{id}/refund · GET /api/v1/connect/status`
+(`GET /api/v1/listings` and `GET /api/v1/orders` list your own listings/
+orders — `?limit=` supported; MCP mirrors are `list_listings` /
+`list_my_orders`. Sales specifically: `GET /api/v1/listings/sales` /
+`list_my_sales`.)
 
 CLI: `shiply listing ls · shiply listing create <site-slug> --price <cents>
 --jurisdiction "<region>" · shiply listing rm <slug> --id <listing-id>`
@@ -157,3 +212,29 @@ isn't `'ready'` it returns an `onboardingUrl` you should hand to the
 user as a clickable link.
 
 Docs: https://shiply.now/docs/marketplace
+
+## Inbox threads — reply, forward, archive, summarize, AI draft
+
+The account-wide inbox (replies, unsubscribes, complaints, bounces across
+every site) beyond the read-only MCP tools in [email.md](email.md):
+
+MCP tools: `list_inbox` (filtered list + counts in one call — filters
+`all|unread|replies|unsubscribes|complaints|bounces|archived`), `read_thread`
+(marks read implicitly), `mark_thread_read`, `summarize_thread`,
+`reply_to_thread`, `forward_thread`, `archive_thread`, `unarchive_thread`.
+
+REST (Bearer):
+
+| Endpoint | Action |
+|---|---|
+| `GET /api/v1/inbox/threads?filter=&limit=&offset=` | atomic snapshot: `{threads, counts}` |
+| `GET /api/v1/inbox/threads/{id}` | one thread (also marks read) |
+| `PATCH /api/v1/inbox/threads/{id}` `{action:"mark_read"\|"archive"\|"unarchive"}` | thread lifecycle |
+| `POST /api/v1/inbox/threads/{id}/reply` `{body, subject?}` | reply from the original recipient alias, threaded via In-Reply-To |
+| `POST /api/v1/inbox/threads/{id}/forward` `{to, messageId?, subject?, note?}` | forward one message to a new address |
+| `POST /api/v1/inbox/threads/{id}/summarize` | AI summary of the thread |
+| `POST /api/v1/inbox/threads/{id}/ai-reply` | AI-drafted reply body (review before sending — no matching MCP tool yet) |
+
+**Gap (intentional, tracked):** the CLI has no `shiply inbox` thread-action
+subcommands (reply/forward/archive/summarize) — use MCP or REST for those;
+`shiply email inbox` only reads.

package/skill/references/custom-domains.md

@@ -40,6 +40,8 @@ shiply domain sub add www.example.com --site my-site   # map a subdomain → sit
 shiply domain ls                            # list all domains + subdomains + status
 shiply domain sync example.com              # re-sync DNS records with a connected provider
 shiply domain primary <hostname>            # mark hostname canonical (siblings 301)
+shiply domain check example.com             # re-poll cert/DNS/HTTPS readiness per subdomain
+shiply domain rm example.com --yes          # remove a domain (its subdomains stop resolving)
 ```
 
 For one-click connect (`shiply domain connect`), the CLI prints an

package/skill/references/databases.md

@@ -95,6 +95,11 @@ for D1 and Neon), `POST .../attach` to bind, `DELETE` to drop. Neon-only:
 `POST/GET/DELETE /api/v1/databases/{id}/branches[/{branchId}]` (400 on
 D1 rows).
 
+Main MCP server (account-wide lifecycle — start here to discover a
+databaseId): `list_databases`, `create_database`, `delete_database`,
+`attach_database`. Then, to query/introspect one database, connect the
+per-DB MCP server below with that id.
+
 Per-DB MCP server (so an agent can be scoped to one DB):
 `https://shiply.now/api/mcp/db/<id>/sse` (or `/mcp` for streamable-http),
 Bearer `shp_…` — tools: `db_query`, `db_list_tables`, `db_schema`. The same

package/skill/references/drives.md

@@ -0,0 +1,70 @@
+---
+type: reference
+title: Drives (private storage — REST, CLI, MCP)
+description: Full reference for Drives — private cloud storage for agent memory, notes, and assets. Staged uploads, sharing links, client assignment, and publish-from-drive.
+timestamp: 2026-07-14
+---
+
+# Drives — private cloud storage
+
+Part of the shiply skill (see SKILL.md for publish basics). A Drive is
+private storage — files, notes, context — that is **not** served publicly
+like a published site. Every account gets a `default` drive on first use;
+you can also create named drives (e.g. one per client).
+
+## REST (Bearer `shp_...`)
+
+| Endpoint | Action |
+|---|---|
+| `GET /api/v1/drives?clientId=` | list your drives (optional client filter) → `{drives}` |
+| `POST /api/v1/drives` `{name, client?}` | create a named drive. `client` is the same optional `{clientId?, clientEmail?, clientName?, clientCompany?}` shape used on publish/create_project |
+| `GET /api/v1/drives/default` | the account's auto-provisioned default drive (creates it on first call) |
+| `GET /api/v1/drives/{id}` | drive detail |
+| `DELETE /api/v1/drives/{id}` | delete a drive and its files |
+| `GET /api/v1/drives/{id}/files?prefix=&cursor=` | list files (optional path-prefix filter, pagination cursor) |
+| `POST /api/v1/drives/{id}/files/uploads` `{files:[{path,size,contentType?,hash}]}` | stage up to 1000 files → presigned PUT URLs (same 3-step flow as site publish) |
+| `POST /api/v1/drives/{id}/files/finalize` `{files:[{path,size,contentType?,hash}]}` | confirm uploads landed — same `files` array as the uploads call |
+| `GET /api/v1/drives/{id}/files/{...path}` | `{url}` — a presigned, time-limited download URL for one file |
+| `DELETE /api/v1/drives/{id}/files/{...path}` | delete one file (optional `If-Match` header for optimistic concurrency) |
+| `POST /api/v1/drives/{id}/assign-client` `{clientId}` | file this drive under a client (`clientId: null` clears it) |
+| `POST /api/v1/drives/{id}/share` `{instructions?}` | enable a public share link for the drive |
+| `DELETE /api/v1/drives/{id}/share` | disable the share link |
+| `POST /api/v1/drives/{id}/share/rotate` | mint a fresh share token — the old link dies instantly |
+| `POST /api/v1/drives/{id}/share/invite` `{emails:[...max 50], message?}` | email the share link to a list of addresses |
+
+`{id}` is the drive's public id (`drv_...`), or the literal string
+`default` where the endpoint supports it (only `GET /api/v1/drives/default`
+resolves the alias itself — everywhere else, resolve `default` to a real
+`drv_...` id first via that call).
+
+## CLI
+
+The CLI only operates on the account's **default** drive — for named/
+per-client drives, use REST or MCP.
+
+```bash
+shiply drive ls [prefix]                # list files (optionally under a prefix)
+shiply drive put <file> [as-path]       # stage + finalize a file into the default drive
+shiply drive get <path> [out-file]      # download; omit out-file to print to stdout
+shiply drive rm <path>                  # delete a file
+shiply drive publish [prefix]           # snapshot the default drive (or a prefix) as a new live site
+```
+
+## MCP tools
+
+| Tool | Purpose |
+|---|---|
+| `list_drives` | your drives (optional `clientId` filter) |
+| `create_drive` | create a named drive (`name`, optional `client`) |
+| `drive_list_files` | list files in a drive (`driveId` = `drv_...` or `"default"`, optional `prefix`) |
+| `drive_put_file` | write a file inline (utf8 or base64, ≤2 MB — use the REST staged-upload flow above for bigger files) |
+| `drive_delete_file` | delete a file from a drive |
+| `publish_from_drive` | snapshot a drive (or a path prefix within it) into a new live site |
+
+**Gap (intentional, tracked):** file download, drive delete, and the
+share/assign-client family (`share`, `share/rotate`, `share/invite`,
+`assign-client`) are REST-only today — there is no `drive_download`,
+`delete_drive`, or share-management MCP tool yet. Use the REST endpoints
+above from an MCP-only agent until parity lands.
+
+Docs: https://shiply.now/docs/drives

package/skill/references/email.md

@@ -127,6 +127,22 @@ the confirmed audience (unsubscribe link auto-added). `list_tests()` — all
 tests for this key. `resend_confirmation({ testId, email })` — re-send the
 opt-in to one address.
 
+REST (Bearer, mirrors the MCP tools above):
+
+| Endpoint | Action |
+|---|---|
+| `GET /api/v1/tests` | list your demand tests → `{tests}` |
+| `POST /api/v1/tests` `{idea, copy:{headline, sub?, cta?}, price?, captureFields?, sendingDomainId?}` | create a test — deploys the capture page + provisions the confirmed-subscriber segment |
+| `GET /api/v1/tests/{id}` | merged status object — same shape as `get_test_status` |
+| `PATCH /api/v1/tests/{id}/branding` `{brandName?, logoUrl?, brandColor?, accentColor?, footerText?, replyTo?}` | customize the capture page's branding |
+| `POST /api/v1/tests/{id}/broadcasts` `{subject, html, text?}` | email the confirmed audience — same as `send_broadcast` |
+| `POST /api/v1/tests/suggest-copy` `{idea}` | AI-drafted `{headline, sub, cta}` from a one-line idea (MiniMax; 503 `service_unavailable` if no AI provider is configured) |
+
+`list_tests` maps to `GET /api/v1/tests` above. `resend_confirmation` (re-send
+the opt-in email to one address) is **MCP-only today** — no REST route exists
+yet; use the MCP tool from a REST-only agent by proxying through an MCP
+client, or ask for the confirmation link to be resent from the dashboard.
+
 ## Sending domains — outbound email on your domain
 
 For agents that want shiply to send emails (demand-test broadcasts, project
@@ -140,6 +156,14 @@ to add), `verify_sending_domain`, `remove_sending_domain`.
 REST: `GET/POST /api/v1/sending-domains ·
 POST /api/v1/sending-domains/{id}/verify · DELETE /api/v1/sending-domains/{id}`
 
+Auto-DNS shortcuts (skip the "copy these records to your registrar" step —
+user supplies a scoped, never-stored Cloudflare API token for the domain's
+zone): `POST /api/v1/sending-domains/{id}/auto-dns` `{provider:"cloudflare",
+token}` adds the SPF/DKIM records automatically; `POST
+/api/v1/sending-domains/{id}/email-routing` `{provider:"cloudflare", token}`
+additionally turns on inbound Email Routing and binds the catch-all to
+shiply's inbound worker. No MCP tools for either yet — REST only.
+
 CLI: `shiply sending-domain ls · shiply sending-domain add <domain> ·
 shiply sending-domain verify <id> · shiply sending-domain rm <id> --yes`
 

package/skill/references/publishing.md

@@ -70,7 +70,9 @@ shiply publish <dir> --json                 # one machine-readable JSON line, no
 - **`shiply verify <slug>`** prints a human report PLUS a stable machine marker
   line `VERIFY status=LIVE http=200 ssl=valid thumb=…` (or `status=PENDING`).
   Headless agents should parse that `VERIFY status=…` line — it's the
-  contract, like `SITE_READY` in `status`.
+  contract, like `SITE_READY` in `status`. REST: `GET /api/v1/sites/{slug}/verify`
+  (public, no auth — mirrors `site_status`) → `{status, ssl, http, thumbnailUrl,
+  consoleErrorsDeepLink}`. MCP: `verify_site`.
 - **`shiply publish <dir> --as <name>`** gives a stable preview URL that the
   next publish with the same `--as <name>` reuses — no more changing URLs or
   orphaned scratch sites across iterations, independent of the source dir.

package/skill/references/site-features.md

@@ -44,21 +44,36 @@ see [email.md](email.md).
 
 ## Access control — password or invite-only sites (paid)
 
-To password-protect or restrict a site: PATCH /api/v1/publishes/<slug>/access
+CLI (preferred): `shiply access <slug>` prints the current policy (plus a
+stable `ACCESS slug=… mode=…` marker line); set it with
+`shiply access <slug> --password "..."`, `--restricted --email a@b.com
+--domain example.com` (both flags repeatable — each set REPLACES the previous
+lists), or `--public` to open it up.
+REST: PATCH /api/v1/publishes/<slug>/access
 with {"mode":"password","password":"..."} or {"mode":"restricted",
 "allowedEmails":[...],"allowedDomains":[...]}, or set mode "public" to open it.
-GET returns the policy (never the hash). MCP tool: `set_site_access`. Enforced
+GET returns the policy (never the hash). MCP tools: `get_site_access` (read),
+`set_site_access` (write). Enforced
 at the edge before any content/proxy/data is served; visitors get a 7-day
 signed cookie; changing any setting signs current visitors out.
 Docs: /docs/access-control
 
 ## Variables — encrypted per-user KV
 
-For API keys the user's sites need: GET/PUT /api/v1/variables
-{"name","value"}, DELETE /api/v1/variables/{NAME}; GET ?reveal=1 returns
-plaintext values. MCP: `set_variable`. Referenced by proxy routes (`${VAR}`)
-and injected into Workers as `env.<NAME>`. Supabase can be connected from the
-dashboard and lands here as SUPABASE_URL + SUPABASE_ANON_KEY.
+CLI (preferred): `shiply variable ls [--reveal]`, `shiply variable set <NAME>
+<value>` (or `--stdin`), `shiply variable rm <NAME> --yes`.
+REST: GET/PUT /api/v1/variables {"name","value"}, DELETE
+/api/v1/variables/{NAME}; GET ?reveal=1 returns plaintext values.
+MCP: `list_variables`, `set_variable`, `delete_variable`. Referenced by proxy
+routes (`${VAR}`) and injected into Workers as `env.<NAME>`. Supabase can be
+connected from the dashboard and lands here as SUPABASE_URL + SUPABASE_ANON_KEY.
+
+Expose (or stop exposing) a saved account variable to one specific site's
+Worker env, independent of proxy routes: CLI `shiply variable attach <NAME>
+--site <slug>` / `shiply variable detach <NAME> --site <slug>` (both
+idempotent). REST: `POST /api/v1/variables/{name}/attach` `{slug}` / `POST
+/api/v1/variables/{name}/detach` `{slug}`. MCP: `attach_variable`,
+`detach_variable`, `list_site_variables`.
 
 ## Drives — private cloud storage (agent memory + assets)
 
@@ -66,6 +81,8 @@ Private storage for files/notes/context you don't want on a public site.
 MCP tools: `list_drives`, `create_drive`, `drive_put_file` (driveId
 "default", utf8/base64, ≤2 MB), `drive_list_files`, `drive_delete_file`,
 `publish_from_drive` (snapshot a drive into a live site).
+Full reference (REST staged uploads, sharing, client assignment, CLI):
+[drives.md](drives.md).
 
 ## Path-mounting + public profile
 
@@ -73,7 +90,8 @@ MCP tools: `list_drives`, `create_drive`, `drive_put_file` (driveId
   (host/docs → target).
 - `set_profile` / `feature_site` (MCP) — stand up the user's public portfolio
   at <handle>.shiply.now and feature a public site on shiply.now/explore.
-- `export_account` (MCP) — JSON bundle of the user's data (no secrets).
+- `export_account` (MCP) / `GET /api/v1/account/export` (REST) — JSON bundle
+  of the user's data (no secrets).
 - Site metadata: `PATCH /api/v1/publish/<slug>/metadata`
   {"title?","spaMode?","addedToProfile?"}.
 

package/skill/references/ssr-frameworks.md

@@ -1,57 +1,57 @@
----
-type: reference
-title: SSR frameworks
-description: Deploy full server-side-rendered apps — SvelteKit, Astro, Qwik, the Nitro family (Nuxt, SolidStart, Analog, TanStack Start), React Router v7, Next.js via OpenNext, and Hono/raw Workers.
-timestamp: 2026-07-04
----
-
-# SSR / server frameworks (live: every major JS framework)
-
-Part of the shiply skill (see SKILL.md for publish basics). Requires sign-in +
-Developer plan.
-
-`shiply publish` auto-detects an SSR build and deploys the worker bundle with
-`nodejs_compat`, serving static assets from the edge. Live and verified on prod:
-SvelteKit (`@sveltejs/adapter-cloudflare`), Astro (`@astrojs/cloudflare`), Qwik
-City, the Nitro family (Nuxt, SolidStart, Analog, TanStack Start), React Router
-v7, and Next.js (via OpenNext) — plus wrangler workers (`wrangler.toml` with
-`main` — Hono, itty-router, raw `fetch`). **Build first** (`npm run build`),
-then `shiply publish .`. Force the static path with `--framework=<name>`, or
-skip SSR detection entirely with `--no-ssr`.
-
-Per-framework build setup:
-
-- **SvelteKit** — `@sveltejs/adapter-cloudflare`, then `npm run build`,
-  `shiply publish .`
-- **Astro** — `@astrojs/cloudflare` adapter, `npm run build`, `shiply publish .`
-- **Qwik City** — `@builder.io/qwik-city` cloudflare-pages adapter,
-  `npm run build`, `shiply publish .`
-- **Nitro family (Nuxt, SolidStart, Analog, TanStack Start)** — build with the
-  `cloudflare`(-module) Nitro preset, then `shiply publish .`
-- **React Router v7** — framework mode (`@react-router/dev`), `react-router
-  build`, then `shiply publish .`
-- **Next.js** — build via `@opennextjs/cloudflare` (OpenNext), then
-  `shiply publish .`. Plain SSR works today; **ISR / on-demand revalidate is
-  not live yet**, and Next 16 must build with `next build --webpack` (not
-  Turbopack). `shiply publish` runs a **PREFLIGHT** on Next source dirs: it
-  auto-fixes Turbopack build scripts, translates `vercel.json` crons to
-  `.shiply/crons.json`, and refuses to publish raw source with no worker
-  build — read its `FIX`/`WARN` lines, do what they say, re-run.
-
-  Publish output is self-describing — trust it over memory: finalize streams
-  per-phase progress lines, a failed worker deploy prints a structured `fix:`
-  line to execute verbatim, and after every worker deploy the server probes
-  the live site — a non-zero exit with a `runtime error:` line means
-  DEPLOYED BUT BROKEN (the actual worker exception + likely fix are printed,
-  e.g. a missing `shiply secret set`); fix the printed cause and republish.
-- **Wrangler workers** — any repo with `wrangler.toml` declaring `main`
-  (Hono, itty-router, raw `fetch` handler) deploys as-is.
-
-How serving works: the deployed worker receives every request; static assets
-are tried first (the worker calls `env.ASSETS`, 200 = asset served from the
-edge / 404 = your SSR handler runs). The worker gets the same bindings,
-secrets, and crons as Functions — see [functions.md](functions.md). Bundle
-cap 8 MB.
-
-Plan gate: Free/Hobby get `402 payment_required` — upgrade at
-https://shiply.now/dashboard/plan.
+---
+type: reference
+title: SSR frameworks
+description: Deploy full server-side-rendered apps — SvelteKit, Astro, Qwik, the Nitro family (Nuxt, SolidStart, Analog, TanStack Start), React Router v7, Next.js via OpenNext, and Hono/raw Workers.
+timestamp: 2026-07-04
+---
+
+# SSR / server frameworks (live: every major JS framework)
+
+Part of the shiply skill (see SKILL.md for publish basics). Requires sign-in +
+Developer plan.
+
+`shiply publish` auto-detects an SSR build and deploys the worker bundle with
+`nodejs_compat`, serving static assets from the edge. Live and verified on prod:
+SvelteKit (`@sveltejs/adapter-cloudflare`), Astro (`@astrojs/cloudflare`), Qwik
+City, the Nitro family (Nuxt, SolidStart, Analog, TanStack Start), React Router
+v7, and Next.js (via OpenNext) — plus wrangler workers (`wrangler.toml` with
+`main` — Hono, itty-router, raw `fetch`). **Build first** (`npm run build`),
+then `shiply publish .`. Force the static path with `--framework=<name>`, or
+skip SSR detection entirely with `--no-ssr`.
+
+Per-framework build setup:
+
+- **SvelteKit** — `@sveltejs/adapter-cloudflare`, then `npm run build`,
+  `shiply publish .`
+- **Astro** — `@astrojs/cloudflare` adapter, `npm run build`, `shiply publish .`
+- **Qwik City** — `@builder.io/qwik-city` cloudflare-pages adapter,
+  `npm run build`, `shiply publish .`
+- **Nitro family (Nuxt, SolidStart, Analog, TanStack Start)** — build with the
+  `cloudflare`(-module) Nitro preset, then `shiply publish .`
+- **React Router v7** — framework mode (`@react-router/dev`), `react-router
+  build`, then `shiply publish .`
+- **Next.js** — build via `@opennextjs/cloudflare` (OpenNext), then
+  `shiply publish .`. Plain SSR works today; **ISR / on-demand revalidate is
+  not live yet**, and Next 16 must build with `next build --webpack` (not
+  Turbopack). `shiply publish` runs a **PREFLIGHT** on Next source dirs: it
+  auto-fixes Turbopack build scripts, translates `vercel.json` crons to
+  `.shiply/crons.json`, and refuses to publish raw source with no worker
+  build — read its `FIX`/`WARN` lines, do what they say, re-run.
+
+  Publish output is self-describing — trust it over memory: finalize streams
+  per-phase progress lines, a failed worker deploy prints a structured `fix:`
+  line to execute verbatim, and after every worker deploy the server probes
+  the live site — a non-zero exit with a `runtime error:` line means
+  DEPLOYED BUT BROKEN (the actual worker exception + likely fix are printed,
+  e.g. a missing `shiply secret set`); fix the printed cause and republish.
+- **Wrangler workers** — any repo with `wrangler.toml` declaring `main`
+  (Hono, itty-router, raw `fetch` handler) deploys as-is.
+
+How serving works: the deployed worker receives every request; static assets
+are tried first (the worker calls `env.ASSETS`, 200 = asset served from the
+edge / 404 = your SSR handler runs). The worker gets the same bindings,
+secrets, and crons as Functions — see [functions.md](functions.md). Bundle
+cap 8 MB.
+
+Plan gate: Free/Hobby get `402 payment_required` — upgrade at
+https://shiply.now/dashboard/plan.