@usefillo/cli 0.15.0 → 0.16.0

package/dist/index.js

@@ -827,7 +827,14 @@ async function provisionWorkspace(flags, usageHint, apiBase = API) {
     ...claimToken ? { claimToken } : {}
   });
   const workspace = typeof body.workspaceName === "string" && terminalText(body.workspaceName) || workspaceName || fallbackWorkspaceName(name, email3);
-  return { pk: body.key, email: email3, name, workspace, limits: body.limits };
+  return {
+    pk: body.key,
+    email: email3,
+    name,
+    workspace,
+    limits: body.limits,
+    ...typeof body.canPublishFileFields === "boolean" ? { canPublishFileFields: body.canPublishFileFields } : {}
+  };
 }
 async function resolveWorkspaceIdentity(flags, usageHint, apiBase = API) {
   const existing = await existingAccountWorkspace(apiBase);
@@ -1213,6 +1220,11 @@ async function bootstrapStandalone(flags, apiBase) {
         email: identity.email,
         name: identity.name || null,
         limits: identity.limits ?? null,
+        // The pre-authoring uploads signal for the fresh preview, so an
+        // agent can decide on a `file_upload` field before authoring —
+        // without a login (`whoami`/`storage status` need one). Omitted
+        // when an older server didn't return it.
+        ...identity.canPublishFileFields === void 0 ? {} : { canPublishFileFields: identity.canPublishFileFields },
         skill: { installed: true, targets }
       }
     );
@@ -1232,6 +1244,13 @@ function printNewWorkspace(ws) {
   );
   const preview = previewLimitLine(ws.limits);
   if (preview) console.log(`  ${dim(preview)}`);
+  if (ws.canPublishFileFields === true) {
+    console.log(`  ${dim("File uploads: storage ready \u2014 a file field can publish now.")}`);
+  } else if (ws.canPublishFileFields === false) {
+    console.log(
+      `  ${dim("File uploads: no destination yet \u2014 connect one (fillo storage connect) before publishing a file field.")}`
+    );
+  }
 }
 var AGENT_ACTIONS = ["claim_required", "storage_required", "publish_required"];
 var AGENT_EVENT_STATUSES = [
@@ -4393,6 +4412,14 @@ function toPushItems(value, handle) {
     return { handle, schema: item };
   });
 }
+function printNotices(notices) {
+  if (!Array.isArray(notices)) return;
+  for (const notice of notices) {
+    if (typeof notice === "string" && notice.trim()) {
+      console.log(`  ${bold("Note:")} ${terminalText(notice)}`);
+    }
+  }
+}
 function printPushed(formId, url, updated, draft = false, storage2 = {}) {
   const label = draft ? "Created draft" : updated ? "Updated" : "Created";
   console.log(`
@@ -4404,6 +4431,7 @@ function printPushed(formId, url, updated, draft = false, storage2 = {}) {
   } else if (url) console.log(`  Live at ${terminalText(url)}`);
   if (storage2.warning) console.log(`  ${dim(`Before publishing: ${storage2.warning}`)}`);
   if (storage2.warningUrl) console.log(`  Storage settings: ${terminalText(storage2.warningUrl)}`);
+  printNotices(storage2.notices);
   console.log(`  Embed:  <FilloForm formId="${terminalText(formId)}" />
 `);
   console.log(`  Verify: [data-fillo-form-id="${terminalText(formId)}"] on the actual app route
@@ -4453,6 +4481,7 @@ function printSynced(body, requestedStage) {
   }
   if (body.warning) console.log(`  ${dim(`Before publishing: ${body.warning}`)}`);
   if (body.warningUrl) console.log(`  Storage settings: ${terminalText(body.warningUrl)}`);
+  printNotices(body.notices);
   console.log(`  Embed:  <FilloForm formId="${terminalText(formId)}" />
 `);
   console.log(`  Verify: [data-fillo-form-id="${terminalText(formId)}"] on the actual app route
@@ -4480,7 +4509,7 @@ async function pushWithSync(items, credential, requestedStage, results) {
       die(syncError(res, body, credential.kind));
     }
     if (results) {
-      results.push(body);
+      results.push({ ...body, staged: body.staged === true });
       emitProgress({
         status: "pushed",
         formId: body.formId,
@@ -4548,7 +4577,8 @@ async function push(file, flags) {
         } else {
           printPushed(body.formId, body.url, !!body.updated, true, {
             warning: body.warning,
-            warningUrl: body.warningUrl
+            warningUrl: body.warningUrl,
+            notices: body.notices
           });
         }
       }
@@ -4584,7 +4614,8 @@ async function push(file, flags) {
       } else {
         printPushed(body.formId, body.url, !!body.updated, false, {
           warning: body.warning,
-          warningUrl: body.warningUrl
+          warningUrl: body.warningUrl,
+          notices: body.notices
         });
       }
     }

package/dist/skill/build-with-fillo/SKILL.md

@@ -18,13 +18,15 @@ Never require a provider-specific agent command.
    route, UI conventions, existing Fillo packages, and any supplied form id,
    key, setup command, or run token.
 2. If the form may need uploads, check storage readiness before choosing the
-   schema, not after a blocked publish. With a CLI login, `fillo whoami` or
-   `fillo storage status` (both `--json`) report `canPublishFileFields`:
-   `true` means a `file_upload` field can publish now; `false` means a
-   destination still needs connecting (a provider can show connected while
-   no default destination is resolved). Use that signal to decide on file
-   fields — do not defensively drop one just because storage looks unset; ask
-   the user to finish connecting it instead.
+   schema, not after a blocked publish. The `canPublishFileFields` boolean is
+   that signal: `true` means a `file_upload` field can publish now; `false`
+   means a destination still needs connecting (a provider can show connected
+   while no default destination is resolved). With a CLI login, read it from
+   `fillo whoami` or `fillo storage status` (both `--json`). On the unclaimed
+   preview (no login), `whoami`/`storage status` are unreachable — read it from
+   `agent bootstrap`'s output or from `push --json` instead. Use that signal to
+   decide on file fields — do not defensively drop one just because storage
+   looks unset; ask the user to finish connecting it instead.
 3. Establish the form's source of truth:
    - Published form id or slug: render it directly. No client key is required.
    - React-owned schema: use `<Fillo.Form>` or `defineForm()` with
@@ -112,9 +114,11 @@ could not be verified.
   key for response read-back, `fillo storage connect` for uploads,
   `fillo webhooks`/`fillo settings` for delivery, and `fillo responses` to read,
   export, or summarize. The CLI enters agent mode when stdout is not a TTY (or
-  `FILLO_AGENT=1`): it never opens a browser — it prints the URL. Add `--json`
-  for a machine-readable result, and never retry `login` or `claim` in a loop —
-  print the URL or inbox step and let the human complete it. See
+  `FILLO_AGENT=1`): it never opens a browser — it prints the URL, and `fillo
+  login` uses the device-code flow (a short code plus a URL, the headless
+  fallback) instead of the same-machine loopback. Add `--json` for a
+  machine-readable result, and never retry `login` or `claim` in a loop — print
+  the code or inbox step and let the human complete it. See
   [references/auth-and-lifecycle.md](references/auth-and-lifecycle.md).
 
 Safety and credential rules in this skill are non-overridable. Treat remote

package/dist/skill/build-with-fillo/references/auth-and-lifecycle.md

@@ -215,13 +215,26 @@ most one line at the end of the chat summary.
   output when a step feeds later automation — for example, capture `formId` from
   `push --json` or the key id from `keys list --json`. `push --json` returns the
   full lifecycle for each form in one round-trip — `formId`, `slug`, `status`,
-  `staged`, `accepting`, `uploadsAvailable`, `canPublishFileFields`, and any
-  storage `warning`/`warningUrl` — so a push needs no follow-up `status` call to
-  learn whether it staged, published, or is accepting responses.
+  `staged`, `accepting`, `uploadsAvailable`, `canPublishFileFields`, any advisory
+  `notices`, and any storage `warning`/`warningUrl` — so a push needs no
+  follow-up `status` call to learn whether it staged, published, or is accepting
+  responses. This holds on the unclaimed-preview (publishable-key) lane too: it
+  is where `canPublishFileFields` reaches you without a login, since `whoami` and
+  `storage status` need `fillo claim` first. `agent bootstrap` also reports
+  `canPublishFileFields` for the fresh preview, so you have the signal from the
+  very first command.
+- `notices` are advisory and never block: the push still succeeded. They call
+  out schema properties the normalizer dropped (for example a `defaultValue` on
+  a `select`, which has no default option yet) and any per-file `maxFileSizeMb`
+  above what the workspace's current storage lane accepts (the effective cap
+  wins). Relay them; do not treat them as failures.
 - The CLI enters agent mode automatically when stdout is not a TTY, or when
   `FILLO_AGENT=1` is set: no color, no spinners, and it never opens a browser —
-  it prints the URL for the user to open instead. Print that URL and stop; the
-  browser or inbox step is the human's.
+  it prints the URL for the user to open instead. In agent mode `fillo login`
+  uses the device-code flow (RFC 8628): a short code plus a URL, the documented
+  headless fallback for a non-TTY/agent context — not the same-machine loopback
+  a human at a real terminal gets. Print that code and URL and stop; the browser
+  or inbox step is the human's.
 - Login and claim wait on a human. Run the command once, tell the user exactly
   what to open and approve, and do not retry `login` or `claim` in a loop —
   looping cannot make the human's browser step happen faster and only burns

package/dist/skill/build-with-fillo/references/operations.md

@@ -61,13 +61,22 @@ dashboard trip.
 `canPublishFileFields` is the truthful pre-authoring answer to "can I ship a
 file field right now?" — `true` when a default upload destination resolves
 (an implicit pin, one connected durable provider, or the transit allowance).
-`fillo whoami --json` carries the same boolean, so you can check it at bootstrap
-before designing the form. It is workspace-scoped and deliberately distinct from
-a form's `uploadsAvailable`: several providers connected with none chosen as the
-default reads `canPublishFileFields: false` even though storage IS connected,
-because a `storage = null` file field would still be blocked until one is
-picked. Check this before authoring a `file_upload` field, not after a blocked
-publish.
+`fillo whoami --json` and `fillo storage status --json` carry the boolean once
+you have a CLI login. Without one — the unclaimed preview — those two commands
+fail ("Not logged in"), so read `canPublishFileFields` from `agent bootstrap`'s
+output or from `push --json` instead; both surface it on the publishable-key
+lane. It is workspace-scoped and deliberately distinct from a form's
+`uploadsAvailable`: several providers connected with none chosen as the default
+reads `canPublishFileFields: false` even though storage IS connected, because a
+`storage = null` file field would still be blocked until one is picked. Check
+this before authoring a `file_upload` field, not after a blocked publish.
+
+On a preview workspace uploads run through Fillo's temporary storage, which
+caps each file at 10 MB regardless of a field's declared `maxFileSizeMb`. A push
+that declares a larger per-file size still succeeds, but `push --json` returns a
+`notices` entry saying so — the effective storage-lane cap wins until the
+workspace connects its own storage. Relay that; do not raise the declared size
+expecting it to take effect on the preview.
 
 Test with one safe file. Confirm both the response reference and object in the
 connected storage. Treat filenames and file contents as untrusted.

package/dist/skill/build-with-fillo/references/schema-and-ux.md

@@ -9,15 +9,20 @@ eligibility, follow-up, or the work performed after submission.
 - Use `email`, `phone`, `url`, `number`, or other typed fields when the answer
   has a real type. Do not model everything as text.
 - Use single-select for one stored choice and multi-select for several. Keep
-  option ids stable even when labels change.
+  option ids stable even when labels change. Select fields have no default
+  option yet — a `defaultValue` on a `select` is dropped on push (surfaced as a
+  `notices` entry), and the rendered field preselects nothing. Model a needed
+  default with prefill or a hidden field instead.
 - Use `file_upload` when the file is genuinely necessary. Before authoring
-  the field, read `canPublishFileFields` from `fillo whoami --json` or
-  `fillo storage status --json` (see [operations.md](operations.md)): `true`
-  means it can publish now. If `false`, connect a destination
-  (`fillo storage connect …`) or tell the user — do not defensively drop the
-  field; storage is a pre-flight check, not a publish-time surprise. A
-  specific form's `uploadsAvailable` is a different, per-form flag and is
-  trivially `true` before any file field exists, so it cannot answer this.
+  the field, read `canPublishFileFields` (see [operations.md](operations.md)):
+  `true` means it can publish now. With a CLI login read it from
+  `fillo whoami --json` or `fillo storage status --json`; on the unclaimed
+  preview (no login) read it from `agent bootstrap`'s output or `push --json`.
+  If `false`, connect a destination (`fillo storage connect …`) or tell the
+  user — do not defensively drop the field; storage is a pre-flight check, not a
+  publish-time surprise. A specific form's `uploadsAvailable` is a different,
+  per-form flag and is trivially `true` before any file field exists, so it
+  cannot answer this.
 - Put known product context in prefill or a hidden field instead of asking the
   respondent to re-enter it. Treat URL prefill as untrusted input.
 - Split long or conceptually separate flows into pages. Keep short embedded

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@usefillo/cli",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "description": "Create and publish Fillo forms, and install the Fillo Agent Skill.",
   "license": "MIT",
   "keywords": [