@alexkroman1/aai-cli 6.5.1 → 6.6.0

package/dist/scaffold/.env.example

@@ -9,3 +9,24 @@
 # Required only if your agent enables the `web_search` builtin
 # (free key: https://brave.com/search/api/):
 # BRAVE_API_KEY=
+
+# --- Durable workflows and uploads -----------------------------------------
+#
+# A durable run needs a database; `api.upload(file)` needs a database AND
+# somewhere to put the bytes. A DEPLOYED agent gets both from the platform
+# (`aai storage enable`), so these four are the LOCAL equivalents and none of
+# them is needed by an agent that has no workflow.
+#
+# All three storage keys or none: two of three resolves to nothing and refuses
+# by name rather than half-working. Nothing creates the bucket for you — a
+# bucket is dashboard state, not a migration.
+#
+# From the Supabase CLI: `supabase start`, then `supabase status -o env` for
+# API_URL and SERVICE_ROLE_KEY. The local stack declares one bucket, `blobs`,
+# and uploads land under an `uploads/` prefix inside it — the same layout
+# production uses beside its `blobs/<sha256>` deploy artifacts.
+#
+# DATABASE_URL=postgresql://postgres:postgres@127.0.0.1:54322/postgres
+# AAI_UPLOAD_STORAGE_URL=http://127.0.0.1:54321
+# AAI_UPLOAD_STORAGE_KEY=<SERVICE_ROLE_KEY>
+# AAI_UPLOAD_STORAGE_BUCKET=blobs

package/dist/scaffold/CLAUDE.md

@@ -1155,6 +1155,29 @@ A query returning more than 1000 rows throws — always bound reads with
   preview and published agents, each with its own schema)
 - `aai dev`: set `DATABASE_URL` in the project `.env`
 
+**A workflow UPLOAD needs one more thing locally: somewhere to put the bytes.**
+A deployed agent gets it from the platform; under `aai dev` the bytes go to a
+bucket you point it at, and the Supabase CLI prints the two values
+(`supabase start`, then `supabase status -o env`):
+
+```sh
+DATABASE_URL=postgresql://postgres:postgres@127.0.0.1:54322/postgres
+AAI_UPLOAD_STORAGE_URL=http://127.0.0.1:54321
+AAI_UPLOAD_STORAGE_KEY=<SERVICE_ROLE_KEY>
+AAI_UPLOAD_STORAGE_BUCKET=blobs
+```
+
+`blobs`, not `uploads`: that is the one bucket the local stack declares
+(`supabase/config.toml`, applied by `supabase start`), and uploads land under an
+`uploads/` PREFIX inside it — the same layout production uses beside its
+`blobs/<sha256>` deploy artifacts. Nothing creates a bucket for you.
+
+`.env.example` in a scaffolded project carries this block commented out.
+
+Without both halves `api.upload(file)` fails naming the one that is missing —
+never quietly into a directory, which is what it used to do and then lose by the
+time a resumed run read it.
+
 Create tables lazily from tool code and upsert with `on conflict`:
 
 ```ts no-check

package/dist/scaffold/package.json

@@ -13,8 +13,8 @@
     "publish:agent": "aai publish"
   },
   "dependencies": {
-    "@alexkroman1/aai": "^6.5.1",
-    "@alexkroman1/aai-ui": "^6.5.1",
+    "@alexkroman1/aai": "^6.6.0",
+    "@alexkroman1/aai-ui": "^6.6.0",
     "@workflow/world-postgres": "4.3.3",
     "react": "^19.2.8",
     "react-dom": "^19.2.8",
@@ -23,7 +23,7 @@
     "zod": "^4.4.3"
   },
   "devDependencies": {
-    "@alexkroman1/aai-cli": "^6.5.1",
+    "@alexkroman1/aai-cli": "^6.6.0",
     "@tailwindcss/vite": "^4.3.3",
     "@types/node": "^26.2.0",
     "@types/react": "^19.2.18",

package/dist/templates/transcription-workflow/client.tsx

@@ -61,11 +61,13 @@
  * CONTIGUOUS prefix, which is honest whether one connection or four are filling
  * it).
  *
- * It is selectable rather than always-on for the reason the modes are: this is the
- * template where a reader runs both over the same recording and sees what each
- * costs. It also degrades on its own — a small file, or an agent deployed before
- * the `/parts` routes existed, sends the single request instead — so leaving it on
- * is safe.
+ * The SDK does this by DEFAULT, so the checkbox is an opt-OUT rather than an
+ * opt-in — and it is here for the reason the mode radios are: this is the template
+ * where a reader runs both over the same recording and sees what each costs. It
+ * also degrades on its own — a small file, or an agent deployed before the
+ * `/parts` routes existed, sends the single request instead — so leaving it on is
+ * safe, and turning it off costs retries as well as speed (a single request is the
+ * one upload path that cannot be re-sent).
  *
  * ## The transcript ARRIVES, rather than appearing at the end
  *
@@ -342,7 +344,8 @@ function UploadPicker({
           <span>Split the file across connections</span>
           <span className="text-xs opacity-70">
             Sends the recording as several parts at once instead of in one request, which is most of
-            the wait on a long file. Falls back to the single request on a small one.
+            the wait on a long file — and is the only upload a dropped connection can resume. Falls
+            back to the single request on a small one.
           </span>
         </span>
       </label>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@alexkroman1/aai-cli",
-  "version": "6.5.1",
+  "version": "6.6.0",
   "type": "module",
   "bin": {
     "aai": "bin.mjs"
@@ -44,8 +44,8 @@
     "p-timeout": "^7.0.1",
     "vite": "^8.2.1",
     "zod": "^4.4.3",
-    "@alexkroman1/aai": "6.5.1",
-    "@alexkroman1/aai-ui": "6.5.1"
+    "@alexkroman1/aai": "6.6.0",
+    "@alexkroman1/aai-ui": "6.6.0"
   },
   "devDependencies": {
     "playwright": "^1.62.1",