@getxflow/cli 0.7.0 → 0.8.1

package/README.md

@@ -18,7 +18,7 @@ else's code belongs next to it.
 |---|---|
 | `login` / `logout` / `whoami` | sign in through the browser, sign out, whose key this is and what it can do |
 | `init` / `link` | new project, link a folder to an existing one |
-| `status` / `push` / `pull` | state, sending and fetching sources |
+| `status` / `pull` | state of the sources on the server and fetching them back |
 | `deploy` / `publish` / `rollback` / `deployments` | build, publish, roll back, version history |
 | `db status` / `db migrate` | migrations from `migrations/*.sql` with a gate on destructive ones |
 | `db schema` / `db query` | tables and columns, reading data in a read-only transaction |

package/dist/bin.js

@@ -167,9 +167,6 @@ async function run(args) {
         case 'status':
             await (0, sources_1.status)();
             return;
-        case 'push':
-            await (0, sources_1.push)(rest);
-            return;
         case 'pull':
             await (0, sources_1.pull)(rest);
             return;

package/dist/commands/deploy.js

@@ -100,6 +100,18 @@ async function startBuild(client, projectId, revision, allowRemovals) {
         });
     }
 }
+/**
+ * Ask whether the plan allows a build before the sources go up.
+ *
+ * The gate sits on the build itself, so a refusal used to arrive after the archive
+ * had already become a revision, leaving the project looking like a forgotten
+ * deploy. Same gate, same wording, one round trip earlier. A platform older than
+ * this CLI answers the plain build state instead, and the deploy carries on as
+ * before: the check is an improvement, not a requirement.
+ */
+async function assertBuildAllowed(client, projectId) {
+    await (0, api_1.apiJson)(client, `/api/v1/projects/${projectId}/builds?check=plan`);
+}
 async function deploy(args) {
     const { root, config } = (0, config_1.requireProject)();
     const client = await (0, session_1.connectProject)(root, config);
@@ -107,12 +119,13 @@ async function deploy(args) {
     if ((0, args_1.flagBool)(args, 'no-push')) {
         const server = await (0, sources_1.latestRevision)(client, config.projectId);
         if (!server) {
-            throw new errors_1.CliError('The server holds no sources', 'Send them: xflow push');
+            throw new errors_1.CliError('The server holds no sources', 'Repeat without --no-push, so that the sources go up first');
         }
         revision = server.revision;
         (0, ui_1.warn)(`Sources not sent (--no-push), the build runs from revision ${revision}`);
     }
     else {
+        await assertBuildAllowed(client, config.projectId);
         revision = (await (0, sources_1.pushSources)(root, config, client, { force: (0, args_1.flagBool)(args, 'force') })).revision;
     }
     (0, ui_1.step)(`Building on the platform from revision ${revision}`);

package/dist/commands/sources.js

@@ -2,7 +2,6 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.latestRevision = latestRevision;
 exports.pushSources = pushSources;
-exports.push = push;
 exports.pull = pull;
 exports.status = status;
 const node_fs_1 = require("node:fs");
@@ -69,7 +68,7 @@ async function confirmForce(client, projectId, server, local) {
     if (!confirmed)
         throw new errors_1.CliError('Cancelled');
 }
-/** Used by push and by the first step of deploy. */
+/** The first step of deploy: sources go up as a revision before the build. */
 async function pushSources(root, config, client, options) {
     const tree = prepareTree(root, config);
     const state = (0, config_1.readState)(root);
@@ -111,11 +110,6 @@ async function pushSources(root, config, client, options) {
     }
     return { revision: result.revision, status: result.status };
 }
-async function push(args) {
-    const { root, config } = (0, config_1.requireProject)();
-    const client = await (0, session_1.connectProject)(root, config);
-    await pushSources(root, config, client, { force: (0, args_1.flagBool)(args, 'force') });
-}
 function hasContent(dir) {
     if (!(0, node_fs_1.existsSync)(dir))
         return false;
@@ -169,7 +163,7 @@ async function status() {
     (0, ui_1.out)(`Local:      ${tree.files.length} files, ${(0, ui_1.formatBytes)(tree.archive.length)} archived`);
     if (!server) {
         (0, ui_1.out)('On the server: no sources yet');
-        (0, ui_1.note)((0, ui_1.dim)('  Send them: xflow push'));
+        (0, ui_1.note)((0, ui_1.dim)('  Send and build them: xflow deploy'));
     }
     else {
         (0, ui_1.out)(`On the server: revision ${server.revision}, ${server.file_count} files, ${(0, ui_1.formatAge)(server.created_at)}`);
@@ -182,7 +176,7 @@ async function status() {
         }
         else {
             (0, ui_1.out)(`State: ${(0, ui_1.bold)('local changes')}`);
-            (0, ui_1.note)((0, ui_1.dim)('  Send them: xflow push'));
+            (0, ui_1.note)((0, ui_1.dim)('  Send and build them: xflow deploy'));
         }
     }
     (0, ui_1.out)('');

package/dist/help.js

@@ -19,9 +19,8 @@ ${(0, ui_1.bold)('Getting started')}
   xflow skills                    pick the agents that get the platform instructions
   xflow mcp install               give the agent platform access without a terminal
 
-${(0, ui_1.bold)('Code')}
+${(0, ui_1.bold)('Sources')}
   xflow status                    what is on the server and how the local copy differs
-  xflow push [--force]            send the sources as a new revision
   xflow pull [--into dir] [--revision N]
                                   fetch the sources (the latest revision by default)
 
@@ -81,7 +80,7 @@ Which key a command then uses, in order:
 
   1. XFLOW_TOKEN, when set (and only for the default platform address)
   2. the organization this folder is bound to (${(0, ui_1.bold)('.xflow/state.json')}, written by
-     init, link and the first successful push or pull)
+     init, link and the first successful deploy or pull)
   3. the active organization
 
   xflow org                      the stored organizations, the active one marked
@@ -322,20 +321,6 @@ Plus a few pointer lines in ${(0, ui_1.bold)('AGENTS.md')}. A skill is picked up
 description matches the task, and "add a customers table" will not trigger it. AGENTS.md
 is always read by the agent, which is why the pointer is appended there, at the end of
 the file and once. ${(0, ui_1.bold)('CLAUDE.md')} is left alone: Claude Code reads .claude/skills anyway.`,
-    push: `${(0, ui_1.bold)('xflow push')}: send the sources
-
-The whole working copy goes up at once, as one revision. What is not sent:
-node_modules, .git, dist, build, .next, any .env, plus everything listed in
-.xflowignore and in the ignore field of xflow.json.
-
-If the server holds a revision newer than the one you worked from, the push is
-rejected. That means somebody pushed before you: fetch their changes alongside
-(${(0, ui_1.bold)('xflow pull --into ./server-copy')}), merge them in git on your side, and retry.
-
---force overwrites the server revision. Before that the CLI shows whose work you are
-about to destroy and asks for confirmation by typing the project name. In a
-non-interactive run (CI, an agent) there is no way to confirm: a version conflict has
-to fail the build rather than silently destroy somebody else's work.`,
     pull: `${(0, ui_1.bold)('xflow pull')}: fetch the sources
 
 By default it fetches the latest revision into the project folder and refuses to write
@@ -354,6 +339,18 @@ by default).
   --force            allow overwriting the server revision while sending
   --allow-removals   agree in advance to remove the functions gone from the sources
 
+The whole working copy goes up at once, as one revision. What is not sent: node_modules,
+.git, dist, build, .next, any .env, plus everything listed in .xflowignore and in the
+ignore field of xflow.json.
+
+If the server holds a revision newer than the one you worked from, the sources are
+rejected and the build does not start. That means somebody deployed before you: fetch
+their changes alongside (${(0, ui_1.bold)('xflow pull --into ./server-copy')}), merge them in git on
+your side, and retry. ${(0, ui_1.bold)('--force')} overwrites the server revision, and before that the
+CLI shows whose work you are about to destroy and asks for confirmation by typing the
+project name. In a non-interactive run (CI, an agent) there is no way to confirm: a
+version conflict has to fail the build rather than silently destroy somebody else's work.
+
 The platform builds, in a clean sandbox on one Node version for everybody, so "it
 worked on my machine" no longer depends on your machine. Before the build the project
 is checked against the template: mismatches are printed as a list and the build does

package/dist/version.js

@@ -2,6 +2,6 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.DEFAULT_API_URL = exports.CLI_VERSION = void 0;
 /** Keep in sync with cli/package.json. */
-exports.CLI_VERSION = '0.7.0';
+exports.CLI_VERSION = '0.8.1';
 /** Overridden by XFLOW_API_URL or the `api` field in xflow.json. */
 exports.DEFAULT_API_URL = 'https://app.getxflow.com';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@getxflow/cli",
-  "version": "0.7.0",
+  "version": "0.8.1",
   "description": "CLI for the XFlow platform: source sync, deployment and publishing of applications",
   "license": "UNLICENSED",
   "engines": {

package/skills/xflow/SKILL.md

@@ -361,12 +361,17 @@ const link = await fetch(`${process.env.XFLOW_API_URL}/api/storage/project/uploa
 ```
 
 `confirm` takes the same fields plus the returned `s3Key` and answers with the file and its
-public address; `delete` takes the file `url`. Never pipe the bytes through the function itself.
+address; `delete` takes that same `url`. Never pipe the bytes through the function itself.
 
 There is no endpoint that lists the files back, so the address that `confirm` returns is the
 only copy you get: write it into a table of your own in the same call, and the application
 reads its files from there.
 
+That address never expires and is safe to store, but it is not a public link. It opens only
+for a visitor who is signed in and has access to this project, the same rule that guards the
+application itself, so it works on your pages and does nothing in an email or on a page
+anyone can open.
+
 Four things bite an upload that otherwise looks right, and none of them is obvious from the
 answers you get:
 
@@ -397,19 +402,19 @@ key that reached a visitor lets them delete every file of the project.
 ## Syncing code
 
 `xflow status` shows how the local copy differs from the server revision.
-`xflow push` sends sources, `xflow pull` fetches them.
+`xflow deploy` sends sources, `xflow pull` fetches them.
 
-If a push is rejected, the server revision is newer, meaning someone pushed first.
-Fetch their work next to yours (`xflow pull --into ./server-copy`), merge it locally,
-then push again. `--force` destroys their work: a last resort, not a way around the
-error.
+If a deploy is rejected before the build starts, the server revision is newer, meaning
+someone deployed first. Fetch their work next to yours (`xflow pull --into ./server-copy`),
+merge it locally, then deploy again. `--force` destroys their work: a last resort, not a
+way around the error.
 
 ## Organizations and keys
 
 A key belongs to one organization, and `xflow login` stores it next to the ones already
 stored instead of replacing them. Which key a command uses, in order: `XFLOW_TOKEN` when
 set (default platform address only), then the organization the project folder is bound
-to (`.xflow/state.json`, written by init, link and the first successful push or pull),
+to (`.xflow/state.json`, written by init, link and the first successful deploy or pull),
 then the active organization. `xflow org` lists the stored organizations with the active
 one marked, `xflow org switch <name|id>` makes another one active without a browser, and
 `xflow whoami` names the organization behind the current key.
@@ -430,8 +435,8 @@ read-only queries, migrations, function logs and invocations, schedules, environ
 variables, versions, publish and rollback. They answer with aggregates and say explicitly
 when a result is truncated, which parsing terminal output does not.
 
-Anything that depends on the working copy stays in the CLI: sending sources (`xflow push`),
-building and shipping the functions (`xflow deploy`), creating a project (`xflow init`). The
+Anything that depends on the working copy stays in the CLI: sending sources, building and
+shipping the functions (`xflow deploy`), creating a project (`xflow init`). The
 tools cannot see the folder you are working in, so a build started from there would release
 whatever revision the server happens to hold, not what you have on disk. Pulling a repository
 through tool calls also burns the user's tokens for nothing.
@@ -440,7 +445,7 @@ through tool calls also burns the user's tokens for nothing.
 
 - Edit `xflow.json` by hand: the CLI writes it.
 - Commit `.env`: it holds the project token.
-- Push with `--force` without checking `xflow status` first.
+- Deploy with `--force` without checking `xflow status` first.
 - Invent platform commands: what is not in `xflow help` does not exist.
 
 ## App design