drivethrough-cli 0.1.1 → 0.1.3

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 on the user's machine and no local filesystem 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 emit base64 by hand \u2014 inline base64 content is capped at 1 MB and is only for tiny pasted assets. 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).",
+      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).",
       // 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.
@@ -24021,23 +24021,27 @@ function registerTools(server, ctx) {
   server.registerTool(
     "create_upload",
     {
-      title: "Create upload URL",
-      description: `Mint a short-lived signed URL the USER can upload one local file to \u2014 the route for large binary assets (photos, PDFs, audio, video) when you have no local filesystem and the file isn't hosted anywhere. The bytes never pass through you: relay the returned upload command to the user, wait for them to run it, then reference the file in deploy_site as {path, upload_id} (mode "patch" adds it to a live site). Choosing a route for a binary asset: already on the public web \u2192 deploy_site {path, source_url}; local file + this server runs on the user's machine \u2192 deploy the directory; local file + chat-only connection \u2192 this tool. Tiny pasted assets (\u22641 MB, e.g. a favicon) may still go inline as base64 content. Each link takes exactly one file, is capped at 25 MB, and expires in 15 minutes. Upload ids are single-use: the deploy that references one consumes it (the bundle keeps the bytes; the staged copy is removed and its quota refunded) \u2014 to rename or duplicate the file later, use deploy_site {path, from_path}. An upload no deploy references within 24 hours is deleted, so deploy soon after the user confirms. Pass size_bytes when the user told you the file size \u2014 quota errors then surface here instead of failing the user's upload.`,
+      title: "Create upload link",
+      description: "Mint a short-lived upload link the USER opens in their browser to add local files (photos, PDFs, audio, video) \u2014 the route for binary assets when you cannot reach the bytes and they aren't hosted anywhere. Two-step: (1) relay the returned upload_url as a clickable link \u2014 it opens a drag-and-drop page (no sign-in needed) that takes up to 20 files, 25 MB each, and expires in 30 minutes. (2) When the user says they're done, call this tool again with the returned `session` \u2014 it lists what they uploaded ({upload_id, filename, size_bytes}); ship each with deploy_site files: [{path, upload_id}] (mode \"patch\" adds them to a live site). Never base64-encode a file instead \u2014 but if the bytes are already in YOUR runtime (e.g. a chat attachment mounted in your sandbox) AND you can make HTTP requests, you may PUT them straight to the returned put_url (one file per request, its filename as the last path segment) without involving the user. Choosing a route for a binary asset: already on the public web \u2192 deploy_site {path, source_url}; this server runs on the user's machine \u2192 deploy the directory; file only in the chat or on the user's machine \u2192 this tool. Tiny pasted assets (\u22641 MB, e.g. a favicon) may still go inline as base64 content. Upload ids are single-use: the deploy that references one consumes it (the bundle keeps the bytes; the staged copy is removed and its quota refunded) \u2014 to rename or duplicate the file later, use deploy_site {path, from_path}. An upload no deploy references within 24 hours is deleted, so deploy soon after the user confirms. Pass size_bytes when the user told you a file's size \u2014 quota errors then surface here instead of failing their upload.",
       annotations: { readOnlyHint: false, destructiveHint: false, idempotentHint: false, openWorldHint: false },
       inputSchema: {
-        site: external_exports.string().describe("Site name or id the upload belongs to"),
-        filename: external_exports.string().optional().describe(`The file's name, e.g. "dog.jpg" \u2014 its extension names the stored object`),
-        size_bytes: external_exports.number().int().optional().describe("Expected file size in bytes, if known \u2014 checked against the 25 MB cap and storage quota now")
+        site: external_exports.string().describe("Site name or id the uploads belong to"),
+        session: external_exports.string().optional().describe(
+          "A session id this tool returned earlier: list that session's uploaded files instead of minting a new link. Call this after the user says they're done uploading."
+        ),
+        size_bytes: external_exports.number().int().optional().describe(
+          "Expected size in bytes of the largest file, if known \u2014 checked against the 25 MB cap and storage quota at mint time"
+        )
       }
     },
-    async ({ site, filename, size_bytes }) => {
+    async ({ site, session, size_bytes }) => {
       try {
+        if (session !== void 0) {
+          return ok(await ctx.api.request("GET", `${sitePath(site)}/uploads/${encodeURIComponent(session)}`));
+        }
         return ok(
           await ctx.api.request("POST", `${sitePath(site)}/uploads`, {
-            body: {
-              ...filename !== void 0 ? { filename } : {},
-              ...size_bytes !== void 0 ? { size_bytes } : {}
-            }
+            body: { ...size_bytes !== void 0 ? { size_bytes } : {} }
           })
         );
       } catch (error2) {
@@ -24644,7 +24648,7 @@ var init_tools = __esm({
 Work token-efficiently \u2014 generated output is your scarcest resource:
 - LOCATE, don't read: to find where text lives on a deployed site, call get_site with \`find\` \u2014 it returns byte-exact matching lines. Use \`manifest_only\` to see what files exist. Read full contents (\`paths\`) only when you genuinely need them; a bare get_site inlines every text file.
 - EDIT, don't resend: change existing files with edit_site (exact find/replace). Never re-emit a whole file to change a small part. Use deploy_site mode "patch" for new files or wholesale rewrites \u2014 unchanged files carry forward automatically.
-- REFERENCE, don't inline: never generate base64 by hand. To ship an image or other binary asset, pick the route by where the bytes live: already at a public URL \u2192 deploy_site {path, source_url}, fetched server-side; a local file on the user's machine \u2192 create_upload mints a signed URL the user uploads it to, then deploy_site {path, upload_id}. (Agents with a local filesystem deploy the directory instead \u2014 binaries ride along.) To move or duplicate an ALREADY-DEPLOYED file, {path, from_path} copies it server-side \u2014 never re-upload unchanged bytes. Inline base64 content is capped at 1 MB and exists only for tiny pasted assets like a favicon.
+- REFERENCE, don't inline: never base64-encode a file \u2014 not by hand, not in code, and never as a data: URI in HTML. To ship an image or other binary asset, pick the route by where the bytes live: already at a public URL \u2192 deploy_site {path, source_url}, fetched server-side; a local file (the user's, or a chat attachment already in your runtime) \u2192 create_upload returns a link the user opens in their browser to drag files in; when they say done, call create_upload {session} for the upload_ids, then deploy_site {path, upload_id}. (Agents with a local filesystem deploy the directory instead \u2014 binaries ride along.) To move or duplicate an ALREADY-DEPLOYED file, {path, from_path} copies it server-side \u2014 never re-upload unchanged bytes, and once an upload_id exists, reference it rather than inlining the same bytes again. Inline base64 content is capped at 1 MB and exists only for tiny pasted assets like a favicon.
 - MERGE, don't replace: to change a few fields of a database row, write_db update with \`merge\` (null deletes a field). No need to fetch the row first.
 - UNDO by version, never by inverse edits: every deploy is a numbered version the platform keeps. When the user wants a change undone, call revert_site \u2014 it restores the exact bytes of any prior version in one call and proves it. Reconstructing old content from memory with edit_site is how sites end up in a state that is neither old nor new.
 - LOOK at what shipped: you have no browser, but preview_site returns a real rendered screenshot of any version \u2014 your only way to see visual results. Use it after layout/style/animation work, or to eyeball an old version before reverting.
@@ -27757,7 +27761,8 @@ continue in a later session:
   Already at a public URL \u2192 deploy_site \`{path, source_url}\` (fetched
   server-side). Local file and you have the filesystem \u2192 deploy the directory
   (binaries ride along). Local file but chat-only (remote MCP) \u2192
-  \`create_upload\` mints a signed URL the user uploads the file to, then
+  \`create_upload\` returns a browser drag-and-drop link for the user; once
+  they're done, \`create_upload {session}\` lists the upload_ids, then
   deploy_site \`{path, upload_id}\`. To rename or duplicate an already-deployed
   file, deploy_site \`{path, from_path}\` copies it server-side (with
   \`delete_paths\`, a move). Never hand-generate base64 \u2014 inline base64 is

package/package.json

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