@getxflow/cli 0.1.9 → 0.2.0

package/dist/help.js

@@ -3,267 +3,280 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.help = help;
 const ui_1 = require("./ui");
 const version_1 = require("./version");
-/**
- * Справка. Заменяет агенту машинную документацию: у CLI её роль играет `--help`,
- * поэтому текст пишем так, чтобы по нему можно было работать, не открывая сайт.
- */
+/** Help text. For agents this is the reference documentation. */
 function help(topic) {
     if (topic && TOPICS[topic]) {
         (0, ui_1.out)(TOPICS[topic]);
         return;
     }
-    (0, ui_1.out)(`${(0, ui_1.bold)('xflow')} ${(0, ui_1.dim)(version_1.CLI_VERSION)} XFlow application hosting
-
-${(0, ui_1.bold)('Getting started')}
-  xflow login                     sign in through the browser
-  xflow init [dir]                new project from the platform template
-  xflow templates                 which templates are available
-  xflow link <id>                 link this folder to a project (id: xflow projects list)
-  xflow skills [--global]         refresh the platform instructions for an AI agent
-  xflow mcp install               give the agent platform access without a terminal
-
-${(0, ui_1.bold)('Code')}
-  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)
-
-${(0, ui_1.bold)('Releasing')}
-  xflow deploy [--no-push]        send the code, build on the platform, release to dev
-  xflow publish                   show the dev version to visitors
-  xflow rollback <version number> return the project to an earlier version
-  xflow deployments               version history
-
-${(0, ui_1.bold)('Functions')}
-  xflow functions list            what is deployed
-  xflow functions deploy [name]   build and ship a function
-  xflow functions invoke <name> [--data '{"a":1}']
-                                  call a function and print the answer
-  xflow functions logs [name]     function crashes: stack and console output
-  xflow schedules list            what runs on a timer
-  xflow schedules set <name> "0 3 ? * * *"
-                                  run a function on a schedule (UTC)
-  xflow schedules rm <name>       take a schedule off
-  xflow env [check]               function variables: what is stored, what is missing
-  xflow env set NAME=value        store a variable
-  xflow env rm NAME               delete a variable
-
-${(0, ui_1.bold)('Database')}
-  xflow db status                 which migrations are applied and which are waiting
-  xflow db migrate [--dry-run] [--allow-destructive]
-                                  apply the migrations from migrations/*.sql
-
-${(0, ui_1.bold)('Reference')}
-  xflow logs [--limit N]          browser errors from the released application
-  xflow projects list             projects of the organization
-  xflow projects get [id]         project card
-  xflow whoami                    whose key this is and what it can do
-  xflow logout                    forget the key
-
-${(0, ui_1.bold)('Environment')}
-  XFLOW_TOKEN                     access key (for CI, instead of xflow login)
-  XFLOW_API_URL                   platform address when it is not app.getxflow.com
-
+    (0, ui_1.out)(`${(0, ui_1.bold)('xflow')} ${(0, ui_1.dim)(version_1.CLI_VERSION)} XFlow application hosting
+
+${(0, ui_1.bold)('Getting started')}
+  xflow login                     sign in through the browser
+  xflow init [dir]                new project from the platform template
+  xflow templates                 which templates are available
+  xflow link <id>                 link this folder to a project (id: xflow projects list)
+  xflow skills [--global]         refresh the platform instructions for an AI agent
+  xflow mcp install               give the agent platform access without a terminal
+
+${(0, ui_1.bold)('Code')}
+  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)
+
+${(0, ui_1.bold)('Releasing')}
+  xflow deploy [--no-push]        send the code, ship the functions, build on the platform
+  xflow publish                   show the dev version to visitors
+  xflow rollback <version number> return the project to an earlier version
+  xflow deployments               version history
+
+${(0, ui_1.bold)('Functions')}
+  xflow functions list            what is deployed (they ship with xflow deploy)
+  xflow functions invoke <name> [--data '{"a":1}']
+                                  call a function and print the answer
+  xflow functions logs [name]     function crashes: stack and console output
+  xflow schedules list            what runs on a timer
+  xflow schedules set <name> "0 3 ? * * *"
+                                  run a function on a schedule (UTC)
+  xflow schedules rm <name>       take a schedule off
+  xflow env [check]               function variables: what is stored, what is missing
+  xflow env set NAME=value        store a variable
+  xflow env rm NAME               delete a variable
+
+${(0, ui_1.bold)('Database')}
+  xflow db status                 which migrations are applied and which are waiting
+  xflow db migrate [--dry-run] [--allow-destructive]
+                                  apply the migrations from migrations/*.sql
+
+${(0, ui_1.bold)('Reference')}
+  xflow logs [--limit N]          browser errors from the released application
+  xflow projects list             projects of the organization
+  xflow projects get [id]         project card
+  xflow whoami                    whose key this is and what it can do
+  xflow logout                    forget the key
+
+${(0, ui_1.bold)('Environment')}
+  XFLOW_TOKEN                     access key (for CI, instead of xflow login)
+  XFLOW_API_URL                   platform address when it is not app.getxflow.com
+
 More about one command: xflow help <command>`);
 }
 const TOPICS = {
-    db: `${(0, ui_1.bold)('xflow db migrate')}: apply migrations
-
-The files live in the repository: ${(0, ui_1.bold)('migrations/0001_init.sql')}, ${(0, ui_1.bold)('migrations/0002_orders.sql')}
-and so on. The order comes from the file name, which is why the leading number is
-required. Every migration runs in its own transaction, the history is kept in the
-database itself, and anything already applied is not run again.
-
-  --dry-run              report what would be applied without touching the database
-  --allow-destructive    allow operations that destroy data
-
-About destructive ones. The platform keeps no database history and makes no backups,
-so ${(0, ui_1.bold)('DROP TABLE')}, ${(0, ui_1.bold)('DROP COLUMN')}, ${(0, ui_1.bold)('TRUNCATE')} and ${(0, ui_1.bold)('DELETE FROM')} without a
-condition are rejected unless the flag is given. With the flag, the contents of the
-affected tables are dumped and kept for 7 days: that is a "caught it right away"
-safety net, not a backup. ${(0, ui_1.bold)('DROP DATABASE')} is never allowed, because the database
-is shared across the organization.
-
-Editing an already applied file achieves nothing: the comparison is by name, not by
-content. ${(0, ui_1.bold)('xflow db status')} lists such a file separately, so write a new migration
-instead.
-
-One logical database can be attached to several projects, so the history may hold
-migrations that are not in your repository. That is normal, but it also means your
+    db: `${(0, ui_1.bold)('xflow db migrate')}: apply migrations
+
+The files live in the repository: ${(0, ui_1.bold)('migrations/0001_init.sql')}, ${(0, ui_1.bold)('migrations/0002_orders.sql')}
+and so on. The order comes from the file name, which is why the leading number is
+required. Every migration runs in its own transaction, the history is kept in the
+database itself, and anything already applied is not run again.
+
+  --dry-run              report what would be applied without touching the database
+  --allow-destructive    allow operations that destroy data
+
+About destructive ones. The platform keeps no database history and makes no backups,
+so ${(0, ui_1.bold)('DROP TABLE')}, ${(0, ui_1.bold)('DROP COLUMN')}, ${(0, ui_1.bold)('TRUNCATE')} and ${(0, ui_1.bold)('DELETE FROM')} without a
+condition are rejected unless the flag is given. With the flag, the contents of the
+affected tables are dumped and kept for 7 days: that is a "caught it right away"
+safety net, not a backup. ${(0, ui_1.bold)('DROP DATABASE')} is never allowed, because the database
+is shared across the organization.
+
+Editing an already applied file achieves nothing: the comparison is by name, not by
+content. ${(0, ui_1.bold)('xflow db status')} lists such a file separately, so write a new migration
+instead.
+
+One logical database can be attached to several projects, so the history may hold
+migrations that are not in your repository. That is normal, but it also means your
 migration can break somebody else's application.`,
-    logs: `${(0, ui_1.bold)('xflow logs')} and ${(0, ui_1.bold)('xflow functions logs')}: project errors
-
-One stream per project: crashes of the released application in the browser and
-crashes of the cloud functions. The last 200 entries are kept, older ones fall off.
-
-  --limit N          how many to show (10 by default)
-
-A function reports its own crashes: Yandex exposes its logs only over gRPC, so the
-wrapper catches the exception, carries the tail of the console with it (the last 40
-${(0, ui_1.bold)('console.log')} lines of that call) and sends it to the platform. Successful calls
-write nothing, otherwise every request would pay for it in latency.
-
-What never reaches this list: a crash while the module is starting (the function
-never gets as far as the wrapper), going over 90 seconds, and running out of memory.
-Those show up in the answer to ${(0, ui_1.bold)('xflow functions invoke')}.
-
-Browser errors are collected by ${(0, ui_1.bold)('src/utils/error-logger.ts')} of the template and
+    logs: `${(0, ui_1.bold)('xflow logs')} and ${(0, ui_1.bold)('xflow functions logs')}: project errors
+
+One stream per project: crashes of the released application in the browser and
+crashes of the cloud functions. The last 200 entries are kept, older ones fall off.
+
+  --limit N          how many to show (10 by default)
+
+A function reports its own crashes: Yandex exposes its logs only over gRPC, so the
+wrapper catches the exception, carries the tail of the console with it (the last 40
+${(0, ui_1.bold)('console.log')} lines of that call) and sends it to the platform. Successful calls
+write nothing, otherwise every request would pay for it in latency.
+
+What never reaches this list: a crash while the module is starting (the function
+never gets as far as the wrapper), going over 90 seconds, and running out of memory.
+Those show up in the answer to ${(0, ui_1.bold)('xflow functions invoke')}.
+
+Browser errors are collected by ${(0, ui_1.bold)('src/utils/error-logger.ts')} of the template and
 only from released addresses: a local ${(0, ui_1.bold)('npm run dev')} writes nothing here.`,
-    env: `${(0, ui_1.bold)('xflow env')}: environment variables of the functions
-
-Keys, passwords and third-party addresses are kept by the platform, not by the
-repository. A value goes up and never comes back: the only place to see it is inside
-the function. So keep your own copy wherever you got it from.
-
-  xflow env                        what is stored (names, not values)
-  xflow env check                  what the functions of this project are missing
-  xflow env set SMTP_PASSWORD=…    store
-  xflow env rm SMTP_PASSWORD       delete
-
-  --scope project                  visible to this project only, not the whole organization
-
-${(0, ui_1.bold)('check')} reads the sources in ${(0, ui_1.bold)('functions/')} and looks for ${(0, ui_1.bold)('process.env.NAME')}
-references. The same rule applies on deploy: a function receives only the variables it
-mentions by name. A name assembled from an expression (${(0, ui_1.bold)("process.env['KEY_' + n]")})
-never reaches the environment, so read variables literally.
-
-The value reaches the function on deploy, not at the moment it is stored: after
-${(0, ui_1.bold)('env set')} you need ${(0, ui_1.bold)('xflow functions deploy')} for the functions involved. The same
-after a delete: a function already deployed keeps the old value until its next deploy.`,
-    schedules: `${(0, ui_1.bold)('xflow schedules')}: running functions on a timer
-
-A schedule is a Yandex timer trigger: it calls the function itself, with no
-application and no browser involved.
-
-  xflow schedules set report "0 3 ? * * *"     every day at 03:00
-  xflow schedules set digest "0 */4 ? * * *"   every 4 hours
-  xflow schedules rm report                    take off every schedule of a function
-
-Six fields: ${(0, ui_1.bold)('minutes hours day-of-month month day-of-week year')}. Exactly one of
-the day-of-month and day-of-week fields has to be ${(0, ui_1.bold)('?')}, which is not our quirk but
-how Yandex works. ${(0, ui_1.bold)('The time is always UTC')}, local time is not understood.
-
-  --payload '{"mode":"full"}'      the body the function will receive
-
-A scheduled run arrives at the handler as a POST with no headers, and the project
-token is not checked on it: such an event cannot be forged from outside. The function
-has to be deployed already, since the schedule points at it and not the other way round.
-
-A failed run shows up in ${(0, ui_1.bold)('xflow functions logs')}: nobody is watching a scheduled
+    env: `${(0, ui_1.bold)('xflow env')}: environment variables of the functions
+
+Keys, passwords and third-party addresses are kept by the platform, not by the
+repository. A value goes up and never comes back: the only place to see it is inside
+the function. So keep your own copy wherever you got it from.
+
+  xflow env                        what is stored (names, not values)
+  xflow env check                  what the functions of this project are missing
+  xflow env set SMTP_PASSWORD=…    store
+  xflow env rm SMTP_PASSWORD       delete
+
+  --scope project                  visible to this project only, not the whole organization
+
+${(0, ui_1.bold)('check')} reads the sources in ${(0, ui_1.bold)('functions/')} and looks for ${(0, ui_1.bold)('process.env.NAME')}
+references. The same rule applies on deploy: a function receives only the variables it
+mentions by name. A name assembled from an expression (${(0, ui_1.bold)("process.env['KEY_' + n]")})
+never reaches the environment, so read variables literally.
+
+The value reaches the function on deploy, not at the moment it is stored: after
+${(0, ui_1.bold)('env set')} run ${(0, ui_1.bold)('xflow deploy')}. The build ships a function whose code did not
+change but whose variables did, so nothing is left holding an old value. The same after a
+delete: a function already deployed keeps the old value until its next deploy.`,
+    schedules: `${(0, ui_1.bold)('xflow schedules')}: running functions on a timer
+
+A schedule is a Yandex timer trigger: it calls the function itself, with no
+application and no browser involved.
+
+  xflow schedules set report "0 3 ? * * *"     every day at 03:00
+  xflow schedules set digest "0 */4 ? * * *"   every 4 hours
+  xflow schedules rm report                    take off every schedule of a function
+
+Six fields: ${(0, ui_1.bold)('minutes hours day-of-month month day-of-week year')}. Exactly one of
+the day-of-month and day-of-week fields has to be ${(0, ui_1.bold)('?')}, which is not our quirk but
+how Yandex works. ${(0, ui_1.bold)('The time is always UTC')}, local time is not understood.
+
+  --payload '{"mode":"full"}'      the body the function will receive
+
+A scheduled run arrives at the handler as a POST with no headers, and the project
+token is not checked on it: such an event cannot be forged from outside. The function
+has to be deployed already, since the schedule points at it and not the other way round.
+
+A failed run shows up in ${(0, ui_1.bold)('xflow functions logs')}: nobody is watching a scheduled
 function, so the wrapper reports a crash the same way it does on an ordinary call.`,
-    invoke: `${(0, ui_1.bold)('xflow functions invoke')} <name>: call a function
-
-Calls it exactly the way the application does, with the X-Project-Token header. The
-token is taken from the project card on the platform, no local .env is needed.
-
-  --data '{"a":1}'   request body (the method becomes POST by default)
-  --method GET       a different method
-
-Prints the status, the response time and the body. A non-zero exit code on 4xx and
-5xx: in CI such a call has to fail the step. The cause of a crash is shown by
+    invoke: `${(0, ui_1.bold)('xflow functions invoke')} <name>: call a function
+
+Calls it exactly the way the application does, with the X-Project-Token header. The
+token is taken from the project card on the platform, no local .env is needed.
+
+  --data '{"a":1}'   request body (the method becomes POST by default)
+  --method GET       a different method
+
+Prints the status, the response time and the body. A non-zero exit code on 4xx and
+5xx: in CI such a call has to fail the step. The cause of a crash is shown by
 ${(0, ui_1.bold)('xflow functions logs <name>')}.`,
-    mcp: `${(0, ui_1.bold)('xflow mcp install')}: connect the agent to the platform directly
-
-Writes the MCP server into the configuration of a client that has its own connect
-command: today that is Claude Code, and for the rest the command prints what to enter
-by hand. After that the agent runs the platform without a terminal: it inspects the
-database, applies migrations, ships and calls functions, sets schedules, reads logs.
-The commands stay: code, builds and releases are still done by the CLI, because
-pushing sources through MCP means filling the agent context and spending your money.
-
-The command takes the access key from your own login and does not print it: usually
-the agent runs this command itself, and everything printed lands in its context and in
-the chat history.
-
-  --show-token    print the key anyway (not while under an agent)
-
-There is one key per person per organization and its scope is not narrowed: the agent
-sees every project of the organization and names the one it needs. It takes the
+    mcp: `${(0, ui_1.bold)('xflow mcp install')}: connect the agent to the platform directly
+
+Writes the MCP server into the configuration of a client that has its own connect
+command: today that is Claude Code, and for the rest the command prints what to enter
+by hand. After that the agent runs the platform without a terminal: it inspects the
+database, applies migrations, ships and calls functions, sets schedules, reads logs.
+The commands stay: code, builds and releases are still done by the CLI, because
+pushing sources through MCP means filling the agent context and spending your money.
+
+The command takes the access key from your own login and does not print it: usually
+the agent runs this command itself, and everything printed lands in its context and in
+the chat history.
+
+  --show-token    print the key anyway (not while under an agent)
+
+There is one key per person per organization and its scope is not narrowed: the agent
+sees every project of the organization and names the one it needs. It takes the
 project from the ${(0, ui_1.bold)('project_id')} argument, not from your folder, which it cannot see.`,
-    skills: `${(0, ui_1.bold)('xflow skills')}: platform instructions for an AI agent
-
-An agent has no way to know about XFlow: the platform is not in its training. The
-instructions explain how to release and publish, where the design system components
-come from, and where to look for production errors. ${(0, ui_1.bold)('init')} and ${(0, ui_1.bold)('link')} lay them
-down on their own, so this command is for refreshing them after a CLI update: the two
-ship as one version.
-
-The format is shared (agentskills.io) but the folders differ per tool, so we write all:
-
-  .claude/skills/xflow/SKILL.md    Claude Code
-  .agents/skills/xflow/SKILL.md    Codex, OpenClaw
-  .cursor/rules/xflow.mdc          Cursor: it does not read the shared format
-
-  --global    the same in the home folder, which makes the skill visible in every
-              project. There ~/.codex/skills is added as well, because Codex looks in
-              its shared catalog only inside a repository. The Cursor rule and
-              AGENTS.md stay per project, they have no global counterpart
-
-Plus a few pointer lines in ${(0, ui_1.bold)('AGENTS.md')}. A skill is picked up lazily, only when its
-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
+    skills: `${(0, ui_1.bold)('xflow skills')}: platform instructions for an AI agent
+
+An agent has no way to know about XFlow: the platform is not in its training. The
+instructions explain how to release and publish, where the design system components
+come from, and where to look for production errors. ${(0, ui_1.bold)('init')} and ${(0, ui_1.bold)('link')} lay them
+down on their own, so this command is for refreshing them after a CLI update: the two
+ship as one version.
+
+The format is shared (agentskills.io) but the folders differ per tool, so we write all:
+
+  .claude/skills/xflow/SKILL.md    Claude Code
+  .agents/skills/xflow/SKILL.md    Codex, OpenClaw
+  .cursor/rules/xflow.mdc          Cursor: it does not read the shared format
+
+  --global    the same in the home folder, which makes the skill visible in every
+              project. There ~/.codex/skills is added as well, because Codex looks in
+              its shared catalog only inside a repository. The Cursor rule and
+              AGENTS.md stay per project, they have no global counterpart
+
+Plus a few pointer lines in ${(0, ui_1.bold)('AGENTS.md')}. A skill is picked up lazily, only when its
+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
+    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
-into a non-empty one: the platform cannot merge changes, that is git's job.
-
-  --into <dir>       unpack alongside, to compare
-  --revision <N>     a specific revision (the list: xflow deployments)
+    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
+into a non-empty one: the platform cannot merge changes, that is git's job.
+
+  --into <dir>       unpack alongside, to compare
+  --revision <N>     a specific revision (the list: xflow deployments)
   --force            overwrite the folder completely`,
-    deploy: `${(0, ui_1.bold)('xflow deploy')}: build and release
-
-Two steps: sending the sources and building on the platform. The build command and the
-output directory come from xflow.json (npm run build and dist by default).
-
-  --no-push       do not send sources, build from the latest server revision
-  --force         allow overwriting the server revision while sending
-
-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
-not start at all.
-
-The built version is visible on the project page, and the CLI prints the link. Visitors
-see it after ${(0, ui_1.bold)('xflow publish')}. The address of the build itself is not printed:
-it carries the version number, and after the next publish such a link quietly serves an
+    deploy: `${(0, ui_1.bold)('xflow deploy')}: build and release
+
+Three steps: sending the sources, shipping the cloud functions, building the application.
+The build command and the output directory come from xflow.json (npm run build and dist
+by default).
+
+  --no-push       do not send sources, build from the latest server revision
+  --force         allow overwriting the server revision while sending
+
+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
+not start at all.
+
+Everything in ${(0, ui_1.bold)('functions/<name>/index.ts')} is bundled and shipped by the same run,
+before the application is built. That order is not a convention but the only one that
+works: the addresses of the functions are baked into the bundle, so they have to exist
+first. A function whose code and variables did not change is left alone, and a function
+that fails to ship fails the whole build.
+
+A function gone from the sources is deleted from the cloud along with its schedules, and
+the CLI names it before the build starts. That one is final: a function created again
+later gets a different address. If the sources hold no functions at all while the cloud
+holds several, nothing is deleted: that looks like a directory which never made it (a
+${(0, ui_1.bold)('functions/')} line in .xflowignore) rather than a decision.
+
+The database is not part of this: migrations change data in ways nothing can undo, so
+they stay their own command (${(0, ui_1.bold)('xflow db migrate')}).
+
+The built version is visible on the project page, and the CLI prints the link. Visitors
+see it after ${(0, ui_1.bold)('xflow publish')}. The address of the build itself is not printed:
+it carries the version number, and after the next publish such a link quietly serves an
 old copy.`,
-    init: `${(0, ui_1.bold)('xflow init')} [dir]: a new project
-
-Lays down the platform template: React on Vite, Tailwind, a set of components
-(${(0, ui_1.bold)('src/components/ui')}) and ready-made blocks (${(0, ui_1.bold)('src/components/blocks')}): table,
-form, filters, kanban, charts. Projects created in the web get the same template, which
-is what makes the applications look alike.
-
-Building the interface on top of these components and the tokens in ${(0, ui_1.bold)('src/index.css')}
-is not a formality: your own palette on top of them looks foreign inside the platform.
-
-  --name <name>       project name (the folder name by default)
-  --template <id>     a different template (the list: xflow templates)
-  --database <id>     attach a logical database of the organization
-
-The order: the project is created on the platform first, because without it there is
-nowhere to get the token for .env. If writing the files fails, the project stays empty
+    init: `${(0, ui_1.bold)('xflow init')} [dir]: a new project
+
+Lays down the platform template: React on Vite, Tailwind, a set of components
+(${(0, ui_1.bold)('src/components/ui')}) and ready-made blocks (${(0, ui_1.bold)('src/components/blocks')}): table,
+form, filters, kanban, charts. Projects created in the web get the same template, which
+is what makes the applications look alike.
+
+Building the interface on top of these components and the tokens in ${(0, ui_1.bold)('src/index.css')}
+is not a formality: your own palette on top of them looks foreign inside the platform.
+
+  --name <name>       project name (the folder name by default)
+  --template <id>     a different template (the list: xflow templates)
+  --database <id>     attach a logical database of the organization
+
+The order: the project is created on the platform first, because without it there is
+nowhere to get the token for .env. If writing the files fails, the project stays empty
 and the CLI explains how to pick it up with the link command.`,
-    rollback: `${(0, ui_1.bold)('xflow rollback')} <version number>: return an earlier build
-
-Switches the project to the chosen build. Only the build comes back: the sources stay
-at their own revision, and returning them is a separate decision
-(${(0, ui_1.bold)('xflow pull --revision N --into ./old-version')}).
-
+    rollback: `${(0, ui_1.bold)('xflow rollback')} <version number>: return an earlier build
+
+Switches the project to the chosen build. Only the build comes back: the sources stay
+at their own revision, and returning them is a separate decision
+(${(0, ui_1.bold)('xflow pull --revision N --into ./old-version')}).
+
 Visitors keep seeing the published version until ${(0, ui_1.bold)('xflow publish')} is run.`,
 };

package/dist/limits.js

@@ -1,15 +1,8 @@
 "use strict";
-/**
- * Лимиты тарифа в выводе CLI.
- *
- * Два места, где они видны: `xflow whoami` (что есть) и отказ команды (во что
- * упёрлись). Второе важнее: без явной пометки агент читает 403 как ошибку
- * запроса и уходит переписывать команду, которая была верной.
- */
+/** Plan limits in CLI output: whoami and command refusals. */
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.limitLine = limitLine;
 exports.quotaRows = quotaRows;
-/** Что кончилось, по коду отказа гейта. */
 const DENIAL_LABELS = {
     limit_projects: 'projects',
     limit_functions: 'cloud functions',
@@ -21,7 +14,7 @@ const DENIAL_LABELS = {
     subscription_blocked: 'the subscription is unpaid',
     billing_unavailable: 'plan check',
 };
-/** Строка под сообщением отказа: почему повторять команду бесполезно. */
+/** Why repeating the same command will not help. */
 function limitLine(detail) {
     const label = DENIAL_LABELS[detail.code] ?? detail.code;
     const numbers = detail.used !== undefined && detail.limit !== undefined
@@ -29,7 +22,6 @@ function limitLine(detail) {
         : '';
     return `Plan limit: ${label}${numbers}. Repeating the same command will not help.`;
 }
-/** Порядок строк в whoami: сперва штучное, потом объёмы, потом расход месяца. */
 const QUOTA_ORDER = [
     'projects',
     'functions',
@@ -50,9 +42,7 @@ const QUOTA_LABELS = {
     function_minutes: 'Function minutes',
     builds: 'Builds this month',
 };
-/** Гигабайт десятичный, 1000 МБ: так объём и продаётся, шаг докупки 500 МБ
- *  обязан читаться как полгигабайта. Сравнение с байтами живёт на сервере и
- *  остаётся на 1024². */
+/** Decimal units, 1000 MB per GB: matches how volumes are sold. */
 function sizeLabel(mb) {
     if (mb < 1000)
         return `${Math.round(mb)} MB`;
@@ -60,14 +50,14 @@ function sizeLabel(mb) {
     return `${Number.isInteger(gb) ? String(gb) : gb.toFixed(1)} GB`;
 }
 function quotaValue(key, use) {
-    // Обе стороны в одних единицах: «0.2 of 15 GB» читается, «245 of 15360» нет.
+    // Same unit on both sides: "0.2 of 15 GB", not "245 of 15360".
     if (key.endsWith('_mb')) {
         const used = use.limit >= 1000 ? (use.used / 1000).toFixed(1) : String(use.used);
         return `${used} of ${sizeLabel(use.limit)}`;
     }
     return `${use.used} of ${use.limit}`;
 }
-/** Строки таблицы для whoami. Незнакомые ключи не прячем: сервер мог добавить. */
+/** Unknown keys stay visible: the server may add new ones. */
 function quotaRows(quotas) {
     const known = QUOTA_ORDER.filter((key) => quotas[key]);
     const rest = Object.keys(quotas).filter((key) => !QUOTA_ORDER.includes(key));

package/dist/session.js

@@ -5,22 +5,18 @@ exports.anonymous = anonymous;
 const config_1 = require("./config");
 const credentials_1 = require("./credentials");
 const errors_1 = require("./errors");
-/**
- * Соединение с платформой: адрес плюс ключ.
- *
- * Адрес берётся из XFLOW_API_URL, потом из xflow.json, потом умолчание —
- * порядок такой, чтобы разработчик мог указать локальную платформу одной
- * переменной, не правя конфигурацию проекта.
- */
+/** Platform connection: address plus key. */
 function connect(config) {
     const apiUrl = (0, config_1.apiUrlFor)(config);
-    const token = (0, credentials_1.resolveToken)(apiUrl);
+    // XFLOW_TOKEN never follows an address taken from the repo's xflow.json:
+    // a cloned config must not be able to redirect the key elsewhere.
+    const token = (0, credentials_1.resolveToken)(apiUrl, apiUrl === (0, config_1.apiUrlFor)());
     if (!token) {
         throw new errors_1.CliError(`No access key for ${apiUrl}`, 'Sign in: xflow login. In CI pass the key in the XFLOW_TOKEN variable');
     }
     return { apiUrl, token };
 }
-/** Соединение без ключа: только для входа. */
+/** Sign-in only. */
 function anonymous(config) {
     return { apiUrl: (0, config_1.apiUrlFor)(config), token: '' };
 }