drivethrough-cli 0.1.7 → 0.1.8

package/dist/main.mjs

@@ -23869,7 +23869,7 @@ function registerTools(server, ctx) {
     "deploy_site",
     {
       title: "Deploy site",
-      description: "Deploy a site to Drivethrough. Idempotent: creates the site if needed, else ships a new version. Sites are private by default. Pass `files` with generated content (the platform assembles the bundle server-side \u2014 no local filesystem or build toolchain needed), or `directory` when this tool runs on the user's machine. Images and other binary assets \u2014 pick the route by where the bytes live: already at a public URL \u2192 {path, source_url} (fetched server-side); a local file \u2014 the user's, or an attachment already in your runtime \u2014 and no directory deploy here \u2192 create_upload first, then {path, upload_id}; a local project directory with filesystem access \u2192 `directory` carries binaries by itself; already deployed on this site \u2192 {path, from_path} copies it server-side (with delete_paths, a move). Never base64-encode a file, by hand or in code \u2014 inline base64 is capped at 1 MB and is only for tiny pasted assets; a file shipped via upload_id is referenced, never additionally inlined. To rework an already-deployed site, read it back with get_site first, then deploy with mode \"patch\" \u2014 only the files that change. For small text changes to existing files, use edit_site instead: it sends find/replace pairs, never whole files. Every deploy's version number is a restore point: prior versions stay listed (get_site history), diffable, viewable (preview_site), and returnable (revert_site). A successful deploy may still return `warnings` (e.g. a form type anonymous visitors can write with no page loading the Turnstile widget) \u2014 resolve them before telling the user it works.",
+      description: "Deploy a site to Drivethrough. Idempotent: creates the site if needed, else ships a new version. Sites are private by default. Pass `files` with generated content (the platform assembles the bundle server-side \u2014 no local filesystem or build toolchain needed), or `directory` when this tool runs on the user's machine. Images and other binary assets \u2014 pick the route by where the bytes live: already at a public URL \u2192 {path, source_url} (fetched server-side); a local file \u2014 the user's, or an attachment already in your runtime \u2014 and no directory deploy here \u2192 create_upload first, then {path, upload_id}; a local project directory with filesystem access \u2192 `directory` carries binaries by itself; already deployed on this site \u2192 {path, from_path} copies it server-side (with delete_paths, a move). Never base64-encode a file, by hand or in code \u2014 inline base64 is capped at 1 MB and is only for tiny pasted assets; a file shipped via upload_id is referenced, never additionally inlined. To rework an already-deployed site, read it back with get_site first, then deploy with mode \"patch\" \u2014 only the files that change. For small text changes to existing files, use edit_site instead: it sends find/replace pairs, never whole files. Every deploy's version number is a restore point: prior versions stay listed (get_site history), diffable, viewable (preview_site), and returnable (revert_site). A successful deploy may still return `warnings` \u2014 things that will bite at runtime but only for visitors, never for you: a form type anonymous visitors can write with no page loading the Turnstile widget, or a page that fetches a data type its visitors have no permission to read. Resolve them before telling the user it works.",
       // Destructive: the default "replace" mode drops every deployed file the
       // call doesn't re-send, and delete_paths removes files outright. Prior
       // versions stay revertible, but the live site does lose content.
@@ -24664,11 +24664,12 @@ RECIPE \u2014 add an uploaded image to a live site (the complete flow, 4 calls):
 4. edit_site to place it: insert/replace an <img src="/images/photo.jpg" alt="\u2026"> where it belongs. Then preview_site to see it.
 
 RECIPE \u2014 public form that saves to the site's database (RSVPs, leads, guestbooks):
-1. Declare the type in drivethrough.json and deploy it (mode "patch" on a live site): {"types": {"lead": {"write": "public", "fields": {"name": "string", "email": "string", "note": "string?"}, "notify": "owner-email"}}}. Deploying it provisions the database; submissions are owner-only readable by default. Optional: "unique_per": "session" makes a visitor's row update instead of duplicate (RSVPs); "rate_limit" like "5/hour" throttles.
-2. Wire the page, same origin, no SDK: on submit, POST /api/data with JSON body {type: "lead", json: {name, email, note}, turnstile_token}. GET /api/data?type=lead \u2192 {items} lists rows the caller may read.
-3. Turnstile (required for anonymous writes, usually invisible to visitors): GET /api/config \u2192 {turnstile_site_key}; load https://challenges.cloudflare.com/turnstile/v0/api.js; put <div class="cf-turnstile" data-sitekey="\u2026"></div> inside the form; send its "cf-turnstile-response" input value as turnstile_token.
-4. Anonymous visitors only reach a public site (set_privacy) or a shared one \u2014 on a private site the form works for invited viewers.
-5. Verify: the deploy response includes a warning when an anonymously-writable type is declared but no page loads the Turnstile widget \u2014 fix it before telling the user it works. End-to-end test: have the user submit once, then query_db {action: "list", type: "lead"} to show the row landed. (Local dev accepts any turnstile_token \u2014 the test secret always passes \u2014 so there a scripted POST to /api/data proves the whole path.)
+1. Declare the type in drivethrough.json and deploy it (mode "patch" on a live site): {"types": {"lead": {"write": "public", "fields": {"name": "string", "email": "string", "note": "string?"}, "notify": "owner-email"}}}. Deploying it provisions the database. Optional: "unique_per": "session" makes a visitor's row update instead of duplicate (RSVPs); "rate_limit" like "5/hour" throttles.
+2. Decide who may SEE the submissions \u2014 "write" and "read" are separate, and "anyone may write" never implies "anyone may read". Collected rows default to owner-only, so a page that lists them is empty for everyone but you. If the user wants the entries shown back on the page \u2014 a potluck signup list, a guestbook, a public RSVP list, "show who's coming" \u2014 you MUST add "read": "public" to that type (the only valid values are "public" | "viewers" | "owner"). This is a deliberate publishing decision about other people's names and words: make it when the user asked for a visible list, tell them their guests' entries will be public, and say so on the form itself so people know before they type. Leave it owner-only for anything that collects private data \u2014 emails, addresses, orders, applications \u2014 and show the user those rows with query_db instead.
+3. Wire the page, same origin, no SDK: on submit, POST /api/data with JSON body {type: "lead", json: {name, email, note}, turnstile_token}. GET /api/data?type=lead \u2192 {items} lists rows the caller may read.
+4. Turnstile (required for anonymous writes, usually invisible to visitors): GET /api/config \u2192 {turnstile_site_key}; load https://challenges.cloudflare.com/turnstile/v0/api.js; put <div class="cf-turnstile" data-sitekey="\u2026"></div> inside the form; send its "cf-turnstile-response" input value as turnstile_token.
+5. Anonymous visitors only reach a public site (set_privacy) or a shared one \u2014 on a private site the form works for invited viewers.
+6. Verify \u2014 you have no browser, so the deploy response is your feedback loop: it returns \`warnings\` when an anonymously-writable type has no Turnstile widget on any page, and when a page fetches a type its visitors aren't allowed to read (the fetch 403s inside THEIR browser; the page looks perfect to you because you're the owner). Never report success while a warning stands. Then have the user submit once and query_db {action: "list", type: "lead"} to show the row landed. (Local dev accepts any turnstile_token \u2014 the test secret always passes \u2014 so there a scripted POST to /api/data proves the whole path.)
 
 Custom domains (paid plans): manage_domain attaches a domain the user already owns. After attaching, check_domain {action: "connect"} looks up one-click setup at their registrar (relay the URL when offered, else the exact DNS records from attach), and check_domain {action: "status"} polls until "active" \u2014 DNS seen, then TLS issued.`;
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "drivethrough-cli",
-  "version": "0.1.7",
+  "version": "0.1.8",
   "description": "Agent-first hosting CLI. Say what you want. Stay in the car.",
   "type": "module",
   "license": "MIT",