drivethrough-cli 0.1.3 → 0.1.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/main.mjs +9 -3
- package/package.json +1 -1
package/dist/main.mjs
CHANGED
|
@@ -24022,7 +24022,7 @@ function registerTools(server, ctx) {
|
|
|
24022
24022
|
"create_upload",
|
|
24023
24023
|
{
|
|
24024
24024
|
title: "Create upload link",
|
|
24025
|
-
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.",
|
|
24025
|
+
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 SAME `site` plus 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.",
|
|
24026
24026
|
annotations: { readOnlyHint: false, destructiveHint: false, idempotentHint: false, openWorldHint: false },
|
|
24027
24027
|
inputSchema: {
|
|
24028
24028
|
site: external_exports.string().describe("Site name or id the uploads belong to"),
|
|
@@ -24285,7 +24285,7 @@ function registerTools(server, ctx) {
|
|
|
24285
24285
|
"create_db",
|
|
24286
24286
|
{
|
|
24287
24287
|
title: "Create site database",
|
|
24288
|
-
description:
|
|
24288
|
+
description: `Provision the per-site database. Idempotent. Deploying a drivethrough.json that declares types does this automatically. Site pages read and write rows via the same-origin Data API: GET /api/data?type=X lists, POST /api/data with {type, json} inserts. Anonymous writes (write: "public", or "viewers" on a public site) additionally require Cloudflare Turnstile in that POST: GET /api/config for the turnstile_site_key, load https://challenges.cloudflare.com/turnstile/v0/api.js, render <div class="cf-turnstile" data-sitekey="\u2026"></div> inside the form, and send the widget's "cf-turnstile-response" input value as "turnstile_token" in the body. The widget is usually invisible; owner and invited-viewer writes on private sites skip it entirely.`,
|
|
24289
24289
|
annotations: { readOnlyHint: false, destructiveHint: false, idempotentHint: true, openWorldHint: false },
|
|
24290
24290
|
inputSchema: { site: external_exports.string().describe("Site name or id") }
|
|
24291
24291
|
},
|
|
@@ -27716,7 +27716,13 @@ Declare data types the site collects. The platform owns the write path.
|
|
|
27716
27716
|
}
|
|
27717
27717
|
}
|
|
27718
27718
|
\`\`\`
|
|
27719
|
-
- \`write\`: "public" | "viewers" | "owner".
|
|
27719
|
+
- \`write\`: "public" | "viewers" | "owner". Anonymous writes (public types,
|
|
27720
|
+
or viewer types on a public site) require Cloudflare Turnstile: the page
|
|
27721
|
+
GETs \`/api/config\` for \`turnstile_site_key\`, loads
|
|
27722
|
+
\`https://challenges.cloudflare.com/turnstile/v0/api.js\`, renders
|
|
27723
|
+
\`<div class="cf-turnstile" data-sitekey="\u2026"></div>\` in the form, and sends
|
|
27724
|
+
the widget's \`cf-turnstile-response\` value as \`turnstile_token\` in the
|
|
27725
|
+
POST body. Usually invisible; owner writes never need it.
|
|
27720
27726
|
- \`read\`: "public" | "viewers" | "owner". Defaults follow \`write\` \u2014 owner-authored
|
|
27721
27727
|
types read "public", \`write: "viewers"\` reads "viewers", and \`write: "public"\`
|
|
27722
27728
|
reads "owner" (form submissions belong to whoever typed them). Set
|