npm - @getxflow/cli - Versions diffs - 1.8.0 → 1.9.0 - Mend

@getxflow/cli 1.8.0 → 1.9.0

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.

Files changed (10) hide show

package/skills/xflow/SKILL.md CHANGED Viewed

@@ -1,685 +1,700 @@
----
-name: xflow
-description: Build, deploy and publish apps on the XFlow platform with the xflow CLI. Use whenever a folder has xflow.json (the project root or an app folder in apps/), and for any task that touches a project and its apps, deployment, publishing, rollback, source sync, who may open an app or call a function, sign-in inside a public app, the project database or SQL migrations, cloud functions, schedules, environment variables and secrets, file storage and uploads of photos, video or PDFs, connected accounts of external services, production errors and logs, UI built on the template components, or a public site for people outside the organization (a landing page, presentation or invoice).
----
-# XFlow
-Hosting for web apps. The code lives in an ordinary repository on the developer machine, the
-CLI sends the sources, the platform builds them in a clean sandbox, serves each app at its own
-address and runs its backend: one database and cloud functions per project.
-No `xflow.json` in the folder or above it means it is not bound to a project yet:
-`xflow projects list` names the projects of the organization with their ids, `xflow link <id>`
-binds the folder to one (an empty folder gets the whole project), and `xflow init` starts a new
-project with its first app. A person signed in to several organizations names the one that gets it:
-`xflow init <dir> --org <name>` (ask them which one if unsure; `xflow org` lists them).
-## First rule
-Check commands and flags against `xflow help` and `xflow help <command>`, not against
-memory. If a command is not in the help output, it does not exist: guessing flags is
-pointless. The CLI prints a hint with almost every error, read it in full, it usually
-contains the fix.
-The public documentation, in Russian, goes deeper than this file: its table of contents is
-https://docs.getxflow.com/llms.txt, every page has a Markdown copy. Read the page you need
-instead of guessing; give the person https://docs.getxflow.com when they ask how something works.
-## Keeping these instructions current
-These instructions ship with xflow CLI 1.8.0, so the copy you are reading can be older than
-the CLI answering your commands.
-When the CLI says this file does not match it, run `xflow skills --refresh` and then **read
-again the file it names**: refreshing only writes to disk, and until you re-read it you are
-still working from the old rules. Do it yourself, no need to ask.
-Updating the CLI is not yours. `xflow update` replaces a program shared by every project on
-the machine: offer the update in your summary. The exception is a platform refusing the CLI as too old (`outdated_cli`):
-nothing runs until it is updated, so say what you are doing and run it.
-## Hard rules
-These mistakes cost the most because nothing fails at the moment they are made, or
-the error points away from the cause. The sections below carry the details.
-1. Read environment variables literally: `process.env.API_KEY`. Destructuring
-   (`const { API_KEY } = process.env`), a name built from an expression, `?.` and
-   spreading the environment all read as no mention of the variable at all. The
-   build rejects them, and `xflow env check` names them before that.
-2. A value written with `xflow env set` reaches the functions on the next
-   `xflow deploy functions`, not at the moment it is written.
-3. Never delete a `functions/<name>/` directory unless the user asked for that
-   function to go. The next deploy removes it from the cloud together with its keys and
-   schedules, and that is final.
-4. A function an app calls needs that app in its `callers` in the root
-   `xflow.json`. Without it the call answers 404 `not_bound`, and a new function is not
-   reachable from anywhere.
-5. Every function called by an app open to anyone can be called by
-   anybody on the internet with curl. Write it as such, see **Your function is open to the
-   whole internet**.
-6. An already applied migration is never re-run, and `xflow db migrate` refuses a
-   name it already holds with different content. A schema change is always a new file.
-7. When `xflow db migrate` answers `db_write_locked`, or an INSERT or CREATE TABLE in a
-   function fails with `database size limit ... reached` (53100), the database is over its plan
-   size and Postgres itself refuses. Reads, updates and deletes keep working, so the fix is deleting data
-   (`xflow db exec` or a migration), never a rewrite of the SQL. Write comes back within the hour. The limit
-   is shared by the organization: `xflow db list` shows the size of each project database.
-8. Heavy media does not travel with the sources. Photos, video and PDFs go up with
-   `xflow storage push`, not into the repository: the archive is capped at 10 MB.
-## Projects and apps
-- A project is a box: one database with its migrations, the cloud functions, secrets and
-  members. It has no code of its own.
-- An app is code the platform builds and serves at `https://<id>--<org>.xflowpage.ru`
-  (`<id>` is six random characters the platform gives the app, `<org>` the name of the
-  organization): its own versions, its own access level. A project holds one or more apps,
-  and all of them use the same database and the same functions.
-- A project without apps is fine (`xflow init --no-app`): its functions are workflows, woken
-  by a schedule, by an outside service holding a key, or by `xflow functions invoke`.
-- `xflow projects get` shows the apps with their folders, addresses and access levels, and
-  who may call each function.
-## Folder layout
-One folder per project, apps in subfolders:
-    clinic/
-      xflow.json                 projectId, and who may call each function
-      package.json               dependencies of the functions
-      functions/<name>/index.ts  cloud functions, shared by every app
-      migrations/0001_init.sql   the one database of the project
-      apps/
-        priem/                   an app: a Vite project with its own xflow.json (appId, build)
-        zapis/
-- Two kinds of history: the project root (functions, migrations, `xflow.json`) is one, each
-  app is another. `apps/**` never travels with the root, the root never travels with an app.
-- An app sees only its own folder when it is built. What two apps share is data and logic,
-  and that lives in functions. Functions never go inside an app folder: the build refuses
-  `functions/` there (`functions-in-app`).
-- `xflow apps add <folder>` creates an app, lays the template into `apps/<folder>` and prints
-  its address. Never create an app folder by hand: without its `appId` it is nobody's.
-  `--color <color>` sets the tile the user sees in the project; a wrong one is answered with
-  the list of colors. Its icon and a later color change belong to the person in the web
-  interface.
-- Rename an app folder freely: the app is its `appId`.
-- Commands follow the folder you stand in: inside `apps/zapis` they mean that app, anywhere
-  else in the project they mean the project. `--project <id>` and `--app <id>` name them
-  without a folder.
-- Neither `xflow.json` is edited by hand except `functions.<name>.callers` in the root one.
-## Plan limits
-The organization runs on a plan with limits: apps, active connections, people in the
-organization, database and file storage, function minutes, builds per month and at once, how often
-schedules may run, and which access levels an app may have. The number of functions, schedules
-and projects is not capped; at most 15 new projects a day (UTC) per organization, deleted ones count. Most are finite; a plan
-may leave one uncapped, and then `whoami` prints `no limit` instead of a ceiling.
-`xflow whoami` prints every one of them next to what is used, and the rights of your own key
-with them: destroying data (a migration or `db exec`), deleting files from storage, moving a database and
-linking a connected account each need a right. Reading it before a long task turns a refusal
-halfway through the work into a sentence said before it starts.
-- Connections are counted while active: switching an unused one off frees the seat without
-  deleting it.
-- Function minutes are shared by the whole organization: every app and schedule spends
-  them. When they run out, every function of the organization stops (`functions_stopped`).
-- An unpaid plan stops the functions at once, and five days later freezes the organization:
-  every command except `xflow whoami` answers `subscription_blocked`,
-  apps show a "suspended" page. Nothing is deleted and no code fixes it: tell the
-  person that the owner pays the invoice in the organization settings, section «Тариф» (Plan).
-- The cap on how long one function call may run is written into the function when it is
-  deployed, so a plan change reaches the cloud only with the next `xflow deploy functions` of
-  each project, in both directions.
-- The functions of one project take a plan-set rate: Free 5 calls a second (a burst of 60),
-  Start 20 (300), Business 50 (750). A call over the rate gets 429 at once. Calls at the same time:
-  Free 4, Start 10, Business 25, the rest wait in a queue. Fan out in batches of that size, never
-  all items of a list in parallel.
-A limit refusal is not a bad request. The CLI prints a line starting with `Plan limit:`, the
-API answers `code: "forbidden"` with a `limit` object (`code`, `used`, `limit`). Retrying, renaming or rewriting the code changes nothing: tell the user
-what ran out and stop, only the owner lifts it. A schedule refused for running too often is one
-of these too, not a bad cron string: the minimum interval comes from the plan, never guess it.
-## Deploying
-1. Change the code. In an app folder `npm run typecheck` is a two-second check, `npm run build`
-   a fast way to see build errors early: the platform builds again in its own sandbox.
-2. `xflow deploy functions -m "what changed"` sends the project root, checks it, applies the
-   new migrations, ships the functions and their callers. A migration that fails or would
-   destroy data stops it before any function ships: settle it with `xflow db migrate`
-   (`--allow-destructive`), then deploy again. `xflow db migrate` alone changes the schema
-   without shipping code. Every app runs the new code the moment it finishes: there is
-   no staging and no publish step for server code. Say so to the user.
-3. `xflow deploy apps/zapis -m "what changed"` sends and builds one app; inside `apps/zapis` a
-   plain `xflow deploy` does the same. In the root a plain `xflow deploy` refuses and names the
-   targets. The comment is required: one short line in the language the user speaks.
-4. `xflow publish` in the app folder (or with `--app <id>`) shows that build to visitors.
-A change that touches data and screens goes in this order: the functions (with the migration),
-then every app that shows it. `xflow deploy apps/...` warns when the root holds changes nobody
-deployed.
-- A build of an app is not shown to visitors until `xflow publish`. Publishing points the
-  address at a build and takes a second; `xflow publish <number>` (or `xflow rollback <number>`)
-  points it at an older kept build, and that is the rollback. The very first build of a new
-  app publishes itself.
-- Only the app moves on publish and rollback. Functions come back with
-  `xflow deploy functions --revision N -m "why"` (`xflow deployments functions` lists the revisions);
-  `--project <id>` names the project without a folder.
-- Files of the **three latest successful builds** of each app are kept, plus the live one;
-  `xflow deployments` marks the rest `no pages`. The history keeps 30 builds, a revision stays
-  while its build is in it or it is among the 10 latest. Keep anything you must not lose in
-  your own git repository.
-- Give a person the app address the CLI printed, or the project page it printed. Name builds
-  by their number.
-- `xflow status` says how the local copies differ from the server. A deploy rejected before
-  the build starts means the server holds a revision this folder has never seen: fetch it next
-  to yours (`xflow pull --into ./server-copy`), merge in git, deploy again. `--force` sends this
-  folder over it anyway; the overwritten revision is kept while it is among the last 10, and the
-  deploy prints the `xflow pull --revision <N>` line that brings it back. A folder with no record of the server revision (a fresh clone, a CI checkout) is
-  not rejected: its first deploy goes on top and says so.
-- A deploy that would delete functions gone from the sources refuses until somebody agrees;
-  `--allow-removals` is the only way past it without a terminal. Reaching for it to get a
-  build running means you deleted something the user never asked you to: put the directories
-  back. If the removal is intended, name the functions and let the user answer.
-## Build gate
-Before the sandbox starts, the platform checks the sources. Everything below blocks the build,
-all violations come back together with files and lines, and a rejected attempt costs nothing.
-An app:
-- `package.json` with the build script named in its `xflow.json` (`npm run build` by default),
-  a `vite.config.*` and `vite` in dependencies. No server frameworks: `next`, `nuxt`, Remix,
-  `@sveltejs/kit`, `astro`.
-- `index.html` in the app root with `id="root"` and the script that loads `src/main.tsx`
-  (`.ts`, `.jsx`, `.js` count too). Code under `src/`; root `app/`, `pages/`, `next/` are rejected.
-- Keep `base` in `vite.config.js` as the template has it: the platform serves each build from
-  `/_b/<key>/`, and a build whose `index.html` points elsewhere is refused.
-- The built app at most 15 MB unpacked, the sources at most 10 MB.
-- File names in latin letters, digits, spaces and `. - _ ~` only: `логотип.png` breaks the build.
-- Call functions through `xflow.functions.invoke`, never a hardcoded function address.
-- No keys or tokens in the sources, no server modules (`fs`, `express`, `http`, `child_process`).
-- Outside `src/components/ui` and `src/components/blocks`: no `alert()`, `confirm()`,
-  `prompt()` (use Dialog and Toast), no `console.log` (visitors read the console;
-  only crashes and 5xx reach the logs).
-- A library that needs a provider (`@tanstack/react-query`, `react-redux`, `sonner`,
-  `react-hot-toast`, `react-dnd`) must have it mounted. A missing provider builds fine and
-  gives visitors a white screen.
-- The platform files stay byte for byte as they arrived: `src/lib/platform-auth.ts`,
-  `src/contexts/platform-auth-context.tsx`, `src/hooks/use-platform-auth.ts`,
-  `src/utils/error-logger.ts`, `src/lib/xflow.ts`. The code keeps calling `initPlatformAuth()`
-  and `initErrorLogger()` and importing `index.css`, and the Tailwind
-  `content` globs keep covering `src/**`. A rejection names the revision to take the original
-  from: `xflow pull --revision N --into ./original`, then copy the file back.
-The project root: function names are lowercase latin letters, digits and hyphens, up to 41
-characters (`send-mail`, not `sendMail`); every name under `functions` in `xflow.json` has its
-`functions/<name>/index.ts`; every caller is an app folder of this project (`unknown-caller`).
-Passes with a line `Unfinished:` instead of blocking: the template's page title, no
-`<link rel="icon">` in `index.html`, an `exports.access` left in a function (it does nothing).
-Fix the first two before you tell the person the app is done.
-## The template is a starter kit
-- `src/components/ui` and `src/components/blocks` are a starting set: change them, restyle them
-  or delete what you do not use. Any colors, your own color scheme, inline styles, a single
-  theme without dark mode: all allowed.
-- The template looks like the xflow interface: warm grays, hairline controls (`ctl-solid`,
-  `ctl-raised`, `ctl-inset`, `ctl-select`), segments (`seg-track`, `seg-on`) and surfaces
-  (`surface-raised`, `surface-pop`, `surface-modal`) in `src/index.css`.
-- While any template component is left, the theme token names in `:root` of `src/index.css`
-  and their `hsl(var(--name))` mapping in the Tailwind config stay: those components paint with
-  them. Values change freely; they are HSL components (`216 95% 40%`), not `#hex`. Your own
-  colors go under new names.
-- Images and other assets: import them from `src/` (`import logo from './assets/logo.png'`)
-  so the build puts them next to the code. An absolute path into `public/` (`/logo.png`) goes
-  through the access check of the app and fails inside the xflow frame in Safari.
-## Who opens an app
-A person sets this in the web interface; you cannot, and you should not ask for a way around.
-| Level | Who gets in |
-|---|---|
-| Project members | people who have access to the project |
-| Anyone with the link | anybody, no sign-in at all |
-- The plan decides which levels exist: on Free an app opens only inside xflow, Start adds the
-  direct address and "Anyone with the link".
-- At the closed level the platform signs people in, and a function receives the person in
-  `event.xflow.user` (`id`, `role` in the organization, `name`, `access` to the project).
-  Keep roles inside the app (doctor, receptionist) in your own table keyed by `user.id`.
-- People outside the organization (patients, pickers, clients) are not xflow accounts: make the
-  app "Anyone with the link" and give it its own sign-in, see below.
-- At "Anyone with the link" the platform signs nobody in: `event.xflow.user` is null for
-  visitors. Accounts, sign-in and who sees which rows are the code of your app, see below.
-- `usePlatformAuth()` in the frontend knows the person only inside the xflow frame, and even
-  there it is a hint for drawing the interface, edited from the console by anyone. On the
-  direct address it answers `anonymous`. Guard data in the function, by `event.xflow`.
-## Which functions an app may call
-The root `xflow.json` names the callers of each function:
-    {
-      "projectId": "…",
-      "functions": {
-        "list-slots": { "callers": ["zapis", "priem"] },
-        "book-slot":  { "callers": ["zapis"] }
-      }
-    }
-- A caller is an app folder of this project (`apps/zapis` is `"zapis"`). A function without
-  callers is left out of `functions` or given `"callers": []`, the same thing.
-- A function nobody lists has no callers: no app reaches it. That is a workflow,
-  run by a schedule, a key or `xflow functions invoke`.
-- Callers ship with `xflow deploy functions` and come back with its `--revision N`.
-- The app calls `xflow.functions.invoke('book-slot', { body })` from `src/lib/xflow.ts`. The call
-  goes to `/_fn/book-slot` on the app's own address: no function addresses, tokens or keys in
-  the bundle, nothing to rebuild when a function changes.
-- A refusal throws `XFlowError` with `status` and `code`: `not_bound` (404, add the caller and
-  deploy functions), `not_found` (404, the function is not deployed), `login_required` and
-  `invalid_credential` (401, the visitor has to sign in again), `no_access`, `role_too_low`,
-  `functions_stopped` (403, minutes ran out or the plan is unpaid: a person settles it),
-  `rate_limited` (429), `unavailable` (503, retry later). Branch on `code`, never on the message.
-## Your function is open to the whole internet
-A function is open when an app at "Anyone with the link" is among its callers. `xflow deploy functions` says so in a line of its own, `xflow functions list`
-prints `open`, the web interface marks it.
-Open means anybody can call it with curl, without your app: the browser is not a gate.
-Hiding the address, checking `Origin` or `Referer`, a token baked into the bundle: all of it is
-readable or forgeable and protects nothing. Write every open function as if the request came
-from a stranger, because it may:
-- Check every input: types, lengths, allowed values; refuse fields you do not expect. Put input
-  into SQL as parameters only (`$1`), never into the text.
-- Return only what this caller needs: no `select *` into a response, no rows of other people,
-  no internal fields, no stack traces.
-- Make writes safe to repeat: take a request id from the client and put a unique index on it,
-  so a retry or a replay changes nothing.
-- Deduplicate and limit per visitor where it costs: `event.xflow.ip` is the visitor's address,
-  set by the platform proxy and not by the caller. The proxy caps requests per address; the
-  organization pays for every minute a function runs.
-- A form open to strangers needs a captcha: Cloudflare Turnstile, with the token checked in the
-  function against `https://challenges.cloudflare.com/turnstile/v0/siteverify` and the secret
-  from `xflow env set`. The site key is public and stays in the source. A check in the browser
-  checks nothing.
-- `minRole` on an open function refuses every anonymous visitor (`login_required`): use it only
-  where members call.
-## Sign-in in a public app
-At the closed levels do none of this: the platform already knows the person.
-- Passwords: store only a hash, `crypto.scrypt` from Node with a random salt per user, compare
-  with `crypto.timingSafeEqual`. Never log a password, never return it, never keep it in the
-  browser.
-- Session: after sign-in the function makes a random token (`crypto.randomBytes(32)`), stores
-  its SHA-256 and an expiry in a table and returns the token in the response body. The app keeps
-  it in `localStorage` and sends it on every call in the `X-Session` header. Not a cookie: Cloud
-  Functions drop `Cookie` and `Set-Cookie` both ways. `localStorage` belongs to one address, a
-  neighbouring `*.xflowpage.ru` site does not read it.
-- Any script on the page reads that token, so: an expiry of hours that each call extends,
-  sign-out and a password change delete the session rows, no user text rendered as HTML
-  (`dangerouslySetInnerHTML`), no scripts loaded from outside the build.
-- Never put the token into an address (`?session=`, a link): it stays in history and logs. A file
-  the function makes for this person is fetched with the header and opened as a `blob:` URL.
-- Not the `Authorization` header: `/_fn` replaces it with the platform's own. Nor headers named
-  `X-Xflow-*`, `X-Project-Pass`, `X-Server-Key`, `X-Function-Key`: the platform strips them.
-- Every function that serves a signed-in visitor reads `X-Session` from `event.headers` (match
-  the name in any case), finds the session and filters rows by that user in SQL. A hidden button
-  is not access control.
-- Count failed sign-ins per email and per `event.xflow.ip` in a table and slow them down.
-- Never in the frontend: keys, secrets, the list of users, hashes, a role check that is the only
-  guard.
-- The platform sends no email for your app: confirmation and reset letters need a mail provider
-  whose key goes into `xflow env set`.
-- `xflow dev` does not carry `X-Session` and calls functions as you (a member).
-  Try the sign-in on the app address.
-## A site for people outside the organization
-- A landing page, a presentation, an invoice is an app at "Anyone with the link" (a paid plan):
-  built, published and rolled back like any app, opened by its address without signing in.
-- Search engines are asked not to index apps: do not promise SEO.
-## Cloud functions
-`functions/<name>/index.ts` in the project root exports `handler` (`index.js` and `index.mjs`
-are read too), `export const handler` and `exports.handler` both work. The request arrives as
-`event.httpMethod`, `event.headers`, `event.queryStringParameters` and `event.body`, a string
-(`JSON.parse` it; `event.isBase64Encoded` marks a binary body). The handler returns
-`{ statusCode, body }` where `body` is a JSON string, and may add `headers`.
-`xflow functions list` shows status, callers, `open`, keys, last call and last error.
-- Dependencies (`pg`, a mail client) go into the root `package.json`; the platform installs them
-  on every deploy, and a lock file next to it makes that exact.
-- Code shared by functions lives in a root folder such as `lib/`, imported by relative path: each
-  function is bundled with what it imports. A folder in `functions/` without `index.*` is not a
-  function. Read `process.env` in `functions/<name>/` itself: `xflow env check` looks only there.
-Keep one shape inside that string across the project: `{ success: true, data }` when it worked,
-`{ success: false, error: { message, code } }` when it did not. Branch the frontend on
-`error.code`, never on `error.message`.
-A function whose code and variables did not change is not shipped again, and one that fails to
-ship fails the whole deploy.
-Debugging a deployed function is two commands: `xflow functions invoke <name>` calls it as you,
-through the platform, and prints the body alone, ready for a pipe (`--data '{"a":1}'`, `--data-file
-body.json`, `--method GET`; 4xx and 5xx exit non-zero; Windows PowerShell 5.1 prepends a BOM when
-piping to another program, so read it with `ConvertFrom-Json` or Python's `utf-8-sig`); `xflow functions logs <name>` shows
-the crashes and 5xx answers with stacks and console output, the latest 10 (`--limit N` for more).
-Only failed calls are logged. Empty output does not clear a function that fails at module start,
-runs over its time cap or out of memory: those never reach the logs, `invoke` shows them.
-The body has to be JSON and the CLI checks it before calling. In PowerShell the double quotes
-never reach the CLI (`--data '{"a":1}'` arrives as `{a:1}`): escape them (`--data '{\"a\":1}'`)
-or pass a file. It bites `--payload` of a schedule the same way. A command that worked writes
-nothing to stderr, so a red line there means it really failed.
-### Who is calling
-The platform checks every call before your code runs and hands the answer over in `event.xflow`:
-```js
-exports.handler = async (event) => {
-  const { caller, slug, user, ip } = event.xflow
-  // caller: 'app' (an app of this project), 'service' (another function of this
-  //         project), 'external' (an outside service with a key), 'schedule',
-  //         'platform' (a person through xflow functions invoke or the web interface)
-  // slug:   the address name of the calling app (<id>--<org>), null otherwise
-  // user:   { id, role, name, access } of a signed-in person, null for anonymous
-  //         visitors and keys. access: 'view' | 'edit' on this project
-  // ip:     the visitor's address, null for a schedule
-}
-```
-Never trust an identity that arrives in the body or in a header of the request: the page lives
-on someone else's computer. `event.xflow` is the only identity the platform stands behind.
-Project access is separate from the role: a person who only views the project (`access:
-'view'`) still reaches every function. A function that writes refuses them:
-```js
-if (event.xflow.user && event.xflow.user.access !== 'edit') {
-  return { statusCode: 403, body: JSON.stringify({ error: 'Read-only access' }) }
-}
-```
-To remember who did something, store `user.id` and `user.name` in the row: the name is never
-empty, and the app has no other way to look up other people.
-A function that changes data should say who may call it instead of checking the role by hand:
-```js
-exports.minRole = 'developer'   // 'member' | 'developer' | 'owner'
-```
-The platform refuses anything below that role before your code runs; it applies to people
-(apps, `functions invoke`), not to keys and schedules. `member` is the people who only
-use the apps (clinic employees, managers), `developer` and `owner` build them. In the web
-interface these roles are called «Просмотр» (`member`), «Редактор» (`developer`) and «Админ»
-(`owner`). Without the line
-every member of the project can call the function. Losing access
-closes the function within a minute.
-- Another function of the project: `fetch(`${process.env.XFLOW_FN_URL}/<name>`, { headers:
-  { 'X-Server-Key': process.env.XFLOW_SERVER_KEY } })`. The key opens the functions of its own
-  project only, whatever their callers.
-- An outside service (a payment webhook, a bot, a CRM) calls
-  `https://fn.xflowpage.ru/<projectId>/<name>` (`xflow functions list` prints it) with a key of
-  that function in `X-Function-Key` or `?key=`. Keys are issued by a person on the function's
-  screen in the web interface, never by you: ask the user. A function holds at most two keys,
-  the second one to replace the first without downtime.
-- `exports.access` does nothing any more: who may call is `callers`.
-## Secrets and connected accounts
-Keys and passwords live on the platform, not in the repository: `xflow env set SMTP_PASSWORD=…`
-writes one, `xflow env` lists the names, `xflow env check` names the variables your functions
-read but the platform does not have. Values never come back out: the only place they exist is
-inside the running function. Apps get no variables at all.
-A variable belongs to one project: functions of other projects never see it, and each project
-keeps its own value under the same name.
-`DATABASE_URL` and every name starting with `XFLOW` are filled in by the platform: writing them
-is refused.
-Some variables come from a connected account instead of from you. Credentials of an account
-linked to the project show up in `xflow env` marked read-only, under a prefix chosen at link
-time (`YANDEX_DIRECT_TOKEN`, `YANDEX_DIRECT_CLIENT_LOGIN`): read them like any other variable.
-If calls to that service start failing on authorisation, `xflow status` says whether the token
-is merely expiring (any deploy of the functions renews it) or the account was disconnected on
-the provider's side, which only a human can reconnect.
-`xflow connections` lists those accounts: the ones linked to this project, with the alias and
-the state of the access, and the ones the organization has but this project does not use yet,
-marked `available, not linked`. Check it before telling anyone a service is unavailable.
-`xflow connections link "Яндекс Метрика" --as YANDEX_METRIKA` is that link and
-`xflow connections unlink YANDEX_METRIKA` undoes it; `xflow help connections` has the naming
-rules. In the project folder unlink refuses while a function still reads one of the variables,
-naming those functions, so read that list before reaching for `--yes`.
-Linking needs the `connections:link` right on the key, and only accounts granted to the owner
-of the key personally can be linked at all. A key cannot grant it to itself: ask the person.
-Connecting a new account and switching one off stay with a person too.
-### Asking an API what it returns
-```
-xflow connections call WB /api/v1/supplier/stocks?dateFrom=2026-09-01
-xflow connections call "Яндекс Метрика" /management/v1/counters
-xflow connections call OZON /v1/product/list --method POST --data '{}' \
-    --header '{"Client-Id":"{CLIENT_ID}"}'
-```
-The platform attaches the credentials and makes the request itself: no deploy, and the key never
-reaches you. A linked account is called by its alias, an `available, not linked` one by its
-name: linking first is not needed to look. Calling is looking, not wiring: to use the account
-in code, link it and deploy functions.
-`{NAME}` in the path or in a header value is filled in from the fields of the connection. Take
-the names from `xflow connections`, which prints them in braces: an invented name is left in the
-text and the request goes out anyway, into somebody's live account. Ask for the shape, not the
-volume: one day and `limit=1`; `--json | jq '.response.body | keys'` gives the field names
-without the body entering your context. `POST` and `DELETE` change things in a live account and
-nothing undoes that: ask the person first when the endpoint is not clearly a read.
-## Schedules
-`xflow schedules set report "0 3 ? * * *"` runs a function daily at 03:00. Six fields, UTC,
-and exactly one of day-of-month / day-of-week must be `?`. A run reaches the handler as a POST
-with `event.xflow.caller === 'schedule'`, and `--payload '{"mode":"full"}'` (or
-`--payload-file body.json`) is its body. The function has to be deployed first.
-A schedule is the function plus its cron: `set` with the same pair only changes the payload, a
-new cron is one more schedule next to the old one. The plan caps the count for the whole
-organization, so take the old one off with `xflow schedules rm report "<old cron>"`.
-```
-xflow env set SMTP_PASSWORD=...                 # secrets first: values ride the next deploy
-# write functions/report/index.ts, reading process.env.SMTP_PASSWORD literally
-xflow deploy functions -m "Nightly report"
-xflow schedules set report "0 3 ? * * *" --payload '{"mode":"full"}'
-xflow functions invoke report                   # run it once
-xflow functions logs report                     # crashes of real runs
-```
-## Database
-Schema changes are files: `migrations/0001_init.sql`, `migrations/0002_orders.sql` in the
-project root, applied in filename order by `xflow db migrate` from any folder of the project.
-`xflow db status` shows what is applied and what waits. Never edit an applied file, write a new
-migration instead. Every project has exactly one database of its own, shared by all its apps and
-functions.
-The browser never reaches the database directly. The app reads and writes through a cloud
-function, and inside the handler the connection string is already there:
-```js
-const { Client } = require('pg')
-const db = new Client({ connectionString: process.env.DATABASE_URL })
-```
-The platform passes `DATABASE_URL` only to functions that mention it and sets the project schema
-on every connection, so plain table names (`select * from tasks`) hit your project.
-`migrations/` says what you did; `xflow db schema [table]` says what is in the database now, and
-`xflow db query 'select ...'` reads it inside a READ ONLY transaction (as many rows as its
-own `limit` asks, 50 without one, 300 at most; `--json` prints long values whole). Single quotes hold in PowerShell, bash
-and zsh, cmd.exe wants double ones; a query with quotes of its own goes in a `.sql` file outside
-the project, `xflow db query ../q.sql`.
-A one-off data fix is `xflow db exec 'update ...'` (or `../fix.sql`), not a migration: one
-INSERT, UPDATE, DELETE or MERGE, saved at once, never re-run, no trace in the migration history.
-Schema changes are refused there. Deleting rows, or updating more than 100 in a table (cascades
-and triggers count), asks for `--allow-destructive`, and deleting also for the right below.
-There is no undo: read the rows with `db query` first.
-The platform keeps no database history and no backups, so anything that destroys data
-(`DROP TABLE`, `DROP COLUMN`, `TRUNCATE`, `DELETE`) needs both the `--allow-destructive` flag and
-the right to destroy data on the key, which is off by default and only its owner turns on. It is
-judged by the result, not the text: a migration that dropped or emptied a table, dropped a column
-or deleted rows is rolled back, however the SQL was written. `BEGIN`/`COMMIT` in a migration are
-refused: each one already runs in its own transaction. When the refusal is about the right, the flag changes nothing: say what
-needs deleting and why, and let the person decide. With both in place the affected tables are
-dumped first (up to 50 000 rows each) and kept for 7 days; getting a dump back is a request to
-the person, no command does it. Check with `--dry-run`.
-Pass `DATABASE_URL` as is, without an `ssl` option. The database is PostgreSQL 18, so do not
-tune it from migrations:
-- Installed: `pg_trgm`. `gen_random_uuid()` and `uuidv7()` are built in. Never `uuid-ossp`.
-  Anything else (`postgis`, `pgvector`) is a request to the person.
-- A statement is cut after 10 seconds (in a migration through `xflow db migrate`, after 2 minutes),
-  waiting for a lock after 10, a transaction left open after 60. Connections to the database of
-  one project: Free 10, Start 25, Business 50. A query that needs longer is a wrong query (a missing index, or a report that belongs in a
-  scheduled function writing a summary table).
-Calls of one project run at the same time in one process. A `Client`, even one made at module
-level, gets its own pooled connection for each call, so `connect()` twice is fine. Keep
-per-request data out of module-level variables. Session state (`SET` without `LOCAL`, temp tables,
-advisory locks) lasts until the call ends, and a transaction left open is rolled back: set what
-the call needs inside the handler. A `Client` that listens for `notification` keeps its own
-connection.
-## File storage
-**Static assets of an app** (product photos, video, PDFs, big artwork) you upload yourself:
-```bash
-xflow storage push ./media --to media   # a folder, its structure kept
-xflow storage ls                        # what is there, with addresses and sizes
-```
-`push` prints the address of every file (`/_files/<id>`) and skips what is already stored under
-the same path and size; `--replace` overwrites a file whose size differs and keeps its address.
-Use the address as is inside an app: the app's own host serves it to whoever may open the app,
-including anonymous visitors of a public one. Icons, fonts and small artwork stay in the
-repository.
-Deleting needs a right of its own, off by default, so `xflow storage rm` may answer that the key
-was not granted it. Ask the person and do not look for a way around: whatever the users of the
-app uploaded lives in the same folders, and there is no undo. A folder is
-`xflow storage rm --folder <path> --yes`.
-**Files that users of the app upload** go through a cloud function of your own: it asks the
-platform for a one-time link, the browser sends the bytes straight to storage, and a second call
-records the file:
-```js
-const link = await fetch(`${process.env.XFLOW_API_URL}/api/storage/project/upload-url`, {
-  method: 'POST',
-  headers: {
-    'Content-Type': 'application/json',
-    'X-Server-Key': process.env.XFLOW_SERVER_KEY,
-  },
-  body: JSON.stringify({ fileName, fileSize, contentType, folderPath: 'invoices' }),
-}).then((r) => r.json())
-```
-`confirm` takes the returned `s3Key` and answers with the file and its address; `delete` takes
-that same `url`. No endpoint lists files back, so write the address into a table of your own in
-the same call. What a visitor may do with files is decided inside that function; never send the
-key to the frontend.
-- A name already taken in that folder is refused before the link is issued; `overwrite: true`
-  replaces the bytes and keeps the address.
-- 200 MB per file and the storage quota of the organization, checked again on `confirm`.
-- Confirm only after the PUT has finished, and send on the PUT exactly the `Content-Type` you
-  named: the link is signed for it, a different or missing type gets 403.
-- Assets only: pages, scripts and executables (`html`, `js`, `exe`, …) are refused with
-  `forbidden_type`.
-A refusal comes back as `{ error, code }` (`invalid_name`, `file_too_large`, `quota_exceeded`,
-`not_uploaded`, `duplicate_name`, `forbidden_type`, `not_found`, …): branch on `code`.
-## Organizations and keys
-One key per organization, stored side by side: `xflow org` lists them, `xflow org switch
-<name|id>` changes the active one, `xflow help org` has the precedence rules.
-Inside a project folder commands follow the organization the folder is bound to, whatever the
-active one is. `--project <id>` and `--app <id>` ignore the folder whole (`xflow help project`
-lists the commands that take them). A "not found" on a project you know exists usually means the
-key belongs to another organization: check `xflow org`; signing in to a missing organization is
-`xflow login`, and that needs a person with a browser.
-A key has its owner's level in each project. With view-only access reading works (`projects
-get`, logs, `db query`, `pull`), and every change fails with `Your access to this project is
-view-only`. That is not a bug to work around: tell the person, edit access is theirs to ask for.
-## Do not
-- Deploy with `--force` without checking `xflow status` first.
-- Invent platform commands: what is not in `xflow help` does not exist.
-- Ask for a way to change an app's access level or issue a function key: that is the person's.
-## App design
-- Take a block from `src/components/blocks` or a primitive from `src/components/ui` before
-  writing your own layout; replace or delete them when the design needs something else.
-- Dropdowns, checkboxes, radios and dates through `Select`, `Checkbox`, `RadioGroup`,
-  `DatePicker` from `src/components/ui`: a bare `<select>` opens the system list in Safari
-  and Firefox, out of the app's style.
-- Every screen starts with a clear header; header, filters and content in one column.
-- Draw all four states: loading, error, empty, data. An empty screen says what appears here and
-  offers an action.
-- Colour only when it communicates: status, action, error, success. Grey carries the structure.
-- Density over air: people scan and compare. Numbers in a column, `tabular-nums`.
-- Name the shape first: list, list with detail, dashboard, form, board.
-- Seed 5-10 believable rows in the first migration: a screen with zero rows looks unfinished.
-- Give the app its own page title and icon.
-## Errors from a deployed app
-`xflow logs` prints what broke in the browser on the app addresses: unhandled errors, rejected
-promises and 5xx responses; in an app folder that app, in the project root every app.
-`xflow functions logs [name]` prints function crashes with the tail of their console, and failed
-calls (timeout, out of memory, 5xx; no console for those); `--all` adds every call as its status
-and time, `--cursor` (printed at the end) goes to older ones. A person sees the same in the web
-interface: browser errors in the «Ошибки» (Errors) panel of the app, function crashes on the
-«Ошибки» tab of the function's screen. `xflow db logs` prints what the database refused: failed
-and timed-out queries with their SQL (cut to 2 KB), dropped connections. Kept for 7 days, 1 day on
-the Free plan.
-Run an app locally with `xflow dev` in its folder, not a bare `npm run dev`: every `/_fn/<name>`
-call then goes to the platform as this app, with the same callers and access as on its address,
-and a function someone else deployed answers at once. A bare `npm run dev` has no key, so its
-function calls fail. The server answers `127.0.0.1` alone, because it holds that key. A local
-run reports nothing to the logs.
-## Environment
-For CI and agent runs: `XFLOW_TOKEN` replaces `xflow login`, `XFLOW_API_URL` points at another
-platform host. There is no `.env` from the platform: the bundle carries no tokens or addresses.
+---
+name: xflow
+description: Build, deploy and publish apps on the XFlow platform with the xflow CLI. Use whenever a folder has xflow.json (the project root or an app folder in apps/), and for any task that touches a project and its apps, deployment, publishing, rollback, source sync, who may open an app or call a function, sign-in inside a public app, the project database or SQL migrations, cloud functions, schedules, environment variables and secrets, file storage and uploads of photos, video or PDFs, connected accounts of external services, production errors and logs, UI built on the template components, or a public site for people outside the organization (a landing page, presentation or invoice).
+---
+# XFlow
+Hosting for web apps. The code lives in an ordinary repository on the developer machine, the
+CLI sends the sources, the platform builds them in a clean sandbox, serves each app at its own
+address and runs its backend: one database and cloud functions per project.
+No `xflow.json` in the folder or above it means it is not bound to a project yet:
+`xflow projects list` names the projects of the organization with their ids, `xflow link <id>`
+binds the folder to one (an empty folder gets the whole project), and `xflow init` starts a new
+project with its first app. A person signed in to several organizations names the one that gets it:
+`xflow init <dir> --org <name>` (ask them which one if unsure; `xflow org` lists them).
+## First rule
+Check commands and flags against `xflow help` and `xflow help <command>`, not against
+memory. If a command is not in the help output, it does not exist: guessing flags is
+pointless. The CLI prints a hint with almost every error, read it in full, it usually
+contains the fix.
+The public documentation, in Russian, goes deeper than this file: its table of contents is
+https://docs.getxflow.com/llms.txt, every page has a Markdown copy. Read the page you need
+instead of guessing; give the person https://docs.getxflow.com when they ask how something works.
+## Keeping these instructions current
+These instructions ship with xflow CLI 1.9.0, so the copy you are reading can be older than
+the CLI answering your commands.
+When the CLI says this file does not match it, run `xflow skills --refresh` and then **read
+again the file it names**: refreshing only writes to disk, and until you re-read it you are
+still working from the old rules. Do it yourself, no need to ask.
+Updating the CLI is not yours. `xflow update` replaces a program shared by every project on
+the machine: offer the update in your summary. The exception is a platform refusing the CLI as too old (`outdated_cli`):
+nothing runs until it is updated, so say what you are doing and run it.
+## Hard rules
+These mistakes cost the most because nothing fails at the moment they are made, or
+the error points away from the cause. The sections below carry the details.
+1. Read environment variables literally: `process.env.API_KEY`. Destructuring
+   (`const { API_KEY } = process.env`), a name built from an expression, `?.` and
+   spreading the environment all read as no mention of the variable at all. The
+   build rejects them, and `xflow env check` names them before that.
+2. A value written with `xflow env set` reaches the functions on the next
+   `xflow deploy functions`, not at the moment it is written.
+3. Never delete a `functions/<name>/` directory unless the user asked for that
+   function to go. The next deploy removes it from the cloud together with its keys and
+   schedules, and that is final.
+4. A function an app calls needs that app in its `callers` in the root
+   `xflow.json`. Without it the call answers 404 `not_bound`, and a new function is not
+   reachable from anywhere.
+5. Every function called by an app open to anyone can be called by
+   anybody on the internet with curl. Write it as such, see **Your function is open to the
+   whole internet**.
+6. An already applied migration is never re-run, and `xflow db migrate` refuses a
+   name it already holds with different content. A schema change is always a new file.
+7. When `xflow db migrate` answers `db_write_locked`, or an INSERT or CREATE TABLE in a
+   function fails with `database size limit ... reached` (53100), the organization's space
+   (databases and files together) is full and Postgres itself refuses. Reads, updates and deletes keep working, so the fix is deleting data
+   (`xflow db exec` or a migration), never a rewrite of the SQL. Write comes back within the hour. The limit
+   is shared by the organization: `xflow db list` shows the size of each project database.
+8. Heavy media does not travel with the sources. Photos, video and PDFs go up with
+   `xflow storage push`, not into the repository: the archive is capped at 10 MB.
+## Projects and apps
+- A project is a box: one database with its migrations, the cloud functions, secrets and
+  members. It has no code of its own.
+- An app is code the platform builds and serves at `https://<id>--<org>.xflowpage.ru`
+  (`<id>` is six random characters the platform gives the app, `<org>` the name of the
+  organization): its own versions, its own access level. A project holds one or more apps,
+  and all of them use the same database and the same functions.
+- A project without apps is fine (`xflow init --no-app`): its functions are workflows, woken
+  by a schedule, by an outside service holding a key, or by `xflow functions invoke`.
+- `xflow projects get` shows the apps with their folders, addresses and access levels, and
+  who may call each function.
+## Folder layout
+One folder per project, apps in subfolders:
+    clinic/
+      xflow.json                 projectId, and who may call each function
+      package.json               dependencies of the functions
+      functions/<name>/index.ts  cloud functions, shared by every app
+      migrations/0001_init.sql   the one database of the project
+      apps/
+        priem/                   an app: a Vite project with its own xflow.json (appId, build)
+        zapis/
+- Two kinds of history: the project root (functions, migrations, `xflow.json`) is one, each
+  app is another. `apps/**` never travels with the root, the root never travels with an app.
+- An app sees only its own folder when it is built. What two apps share is data and logic,
+  and that lives in functions. Functions never go inside an app folder: the build refuses
+  `functions/` there (`functions-in-app`).
+- `xflow apps add <folder>` creates an app, lays the template into `apps/<folder>` and prints
+  its address. Never create an app folder by hand: without its `appId` it is nobody's.
+  `--color <color>` sets the tile the user sees in the project; a wrong one is answered with
+  the list of colors. Its icon and a later color change belong to the person in the web
+  interface.
+- Rename an app folder freely: the app is its `appId`.
+- Commands follow the folder you stand in: inside `apps/zapis` they mean that app, anywhere
+  else in the project they mean the project. `--project <id>` and `--app <id>` name them
+  without a folder.
+- Neither `xflow.json` is edited by hand except `functions.<name>.callers` in the root one.
+## Plan limits
+The organization runs on a plan with limits: apps, active connections, people in the
+organization, space shared by databases and files, function minutes, builds per month and at once, how often
+schedules may run, and which access levels an app may have. The number of functions, schedules
+and projects is not capped; at most 15 new projects a day (UTC) per organization, deleted ones count. Most are finite; a plan
+may leave one uncapped, and then `whoami` prints `no limit` instead of a ceiling.
+A paid plan comes in packages (Start S/M/L, Business M/L/XL): the package sets the space,
+database hours and function minutes, the plan sets the rest. More space is a bigger package
+chosen by a person in «Тариф» (Plan); there is no separate purchase of space.
+`xflow whoami` prints every one of them next to what is used, and the rights of your own key
+with them: destroying data (a migration or `db exec`), deleting files from storage, moving a database and
+linking a connected account each need a right. Reading it before a long task turns a refusal
+halfway through the work into a sentence said before it starts.
+- Connections are counted while active: switching an unused one off frees the seat without
+  deleting it.
+- Function minutes are shared by the whole organization: every app and schedule spends
+  them. When they run out, every function of the organization stops (`functions_stopped`).
+- An unpaid plan stops the functions at once, and five days later freezes the organization:
+  every command except `xflow whoami` answers `subscription_blocked`,
+  apps show a "suspended" page. Nothing is deleted and no code fixes it: tell the
+  person that the owner pays the invoice in the organization settings, section «Тариф» (Plan).
+- The cap on how long one function call may run is written into the function when it is
+  deployed, so a plan change reaches the cloud only with the next `xflow deploy functions` of
+  each project, in both directions.
+- The functions of one project take a plan-set rate: Free 5 calls a second (a burst of 60),
+  Start 20 (300), Business 50 (750). A call over the rate gets 429 at once. Calls at the same time:
+  Free 4, Start 10, Business 25, the rest wait in a queue. Fan out in batches of that size, never
+  all items of a list in parallel.
+A limit refusal is not a bad request. The CLI prints a line starting with `Plan limit:`, the
+API answers `code: "forbidden"` with a `limit` object (`code`, `used`, `limit`). Retrying, renaming or rewriting the code changes nothing: tell the user
+what ran out and stop, only the owner lifts it. A schedule refused for running too often is one
+of these too, not a bad cron string: the minimum interval comes from the plan, never guess it.
+## Deploying
+1. Change the code. In an app folder `npm run typecheck` is a two-second check, `npm run build`
+   a fast way to see build errors early: the platform builds again in its own sandbox.
+2. `xflow deploy functions -m "what changed"` sends the project root, checks it, applies the
+   new migrations, ships the functions and their callers. A migration that fails or would
+   destroy data stops it before any function ships: settle it with `xflow db migrate`
+   (`--allow-destructive`), then deploy again. `xflow db migrate` alone changes the schema
+   without shipping code. Every app runs the new code the moment it finishes: there is
+   no staging and no publish step for server code. Say so to the user.
+3. `xflow deploy apps/zapis -m "what changed"` sends and builds one app; inside `apps/zapis` a
+   plain `xflow deploy` does the same. In the root a plain `xflow deploy` refuses and names the
+   targets. The comment is required: one short line in the language the user speaks.
+4. `xflow publish` in the app folder (or with `--app <id>`) shows that build to visitors.
+A change that touches data and screens goes in this order: the functions (with the migration),
+then every app that shows it. `xflow deploy apps/...` warns when the root holds changes nobody
+deployed.
+- A build of an app is not shown to visitors until `xflow publish`. Publishing points the
+  address at a build and takes a second; `xflow publish <number>` (or `xflow rollback <number>`)
+  points it at an older kept build, and that is the rollback. The very first build of a new
+  app publishes itself.
+- Only the app moves on publish and rollback. Functions come back with
+  `xflow deploy functions --revision N -m "why"` (`xflow deployments functions` lists the revisions);
+  `--project <id>` names the project without a folder.
+- Files of the **three latest successful builds** of each app are kept, plus the live one;
+  `xflow deployments` marks the rest `no pages`. The history keeps 30 builds, a revision stays
+  while its build is in it or it is among the 10 latest. Keep anything you must not lose in
+  your own git repository.
+- Give a person the app address the CLI printed, or the project page it printed. Name builds
+  by their number.
+- `xflow status` says how the local copies differ from the server. A deploy rejected before
+  the build starts means the server holds a revision this folder has never seen: fetch it next
+  to yours (`xflow pull --into ./server-copy`), merge in git, deploy again. `--force` sends this
+  folder over it anyway; the overwritten revision is kept while it is among the last 10, and the
+  deploy prints the `xflow pull --revision <N>` line that brings it back. A folder with no record of the server revision (a fresh clone, a CI checkout) is
+  not rejected: its first deploy goes on top and says so.
+- A deploy that would delete functions gone from the sources refuses until somebody agrees;
+  `--allow-removals` is the only way past it without a terminal. Reaching for it to get a
+  build running means you deleted something the user never asked you to: put the directories
+  back. If the removal is intended, name the functions and let the user answer.
+## Build gate
+Before the sandbox starts, the platform checks the sources. Everything below blocks the build,
+all violations come back together with files and lines, and a rejected attempt costs nothing.
+An app:
+- `package.json` with the build script named in its `xflow.json` (`npm run build` by default),
+  a `vite.config.*` and `vite` in dependencies. No server frameworks: `next`, `nuxt`, Remix,
+  `@sveltejs/kit`, `astro`.
+- `index.html` in the app root with `id="root"` and the script that loads `src/main.tsx`
+  (`.ts`, `.jsx`, `.js` count too). Code under `src/`; root `app/`, `pages/`, `next/` are rejected.
+- Keep `base` in `vite.config.js` as the template has it: the platform serves each build from
+  `/_b/<key>/`, and a build whose `index.html` points elsewhere is refused.
+- The built app at most 15 MB unpacked, the sources at most 10 MB.
+- File names in latin letters, digits, spaces and `. - _ ~` only: `логотип.png` breaks the build.
+- Call functions through `xflow.functions.invoke`, never a hardcoded function address.
+- No keys or tokens in the sources, no server modules (`fs`, `express`, `http`, `child_process`).
+- Outside `src/components/ui` and `src/components/blocks`: no `alert()`, `confirm()`,
+  `prompt()` (use Dialog and Toast), no `console.log` (visitors read the console;
+  only crashes and 5xx reach the logs).
+- A library that needs a provider (`@tanstack/react-query`, `react-redux`, `sonner`,
+  `react-hot-toast`, `react-dnd`) must have it mounted. A missing provider builds fine and
+  gives visitors a white screen.
+- The platform files stay byte for byte as they arrived: `src/lib/platform-auth.ts`,
+  `src/contexts/platform-auth-context.tsx`, `src/hooks/use-platform-auth.ts`,
+  `src/utils/error-logger.ts`, `src/lib/xflow.ts`. The code keeps calling `initPlatformAuth()`
+  and `initErrorLogger()` and importing `index.css`, and the Tailwind
+  `content` globs keep covering `src/**`. A rejection names the revision to take the original
+  from: `xflow pull --revision N --into ./original`, then copy the file back.
+The project root: function names are lowercase latin letters, digits and hyphens, up to 41
+characters (`send-mail`, not `sendMail`); every name under `functions` in `xflow.json` has its
+`functions/<name>/index.ts`; every caller is an app folder of this project (`unknown-caller`).
+Passes with a line `Unfinished:` instead of blocking: the template's page title, no
+`<link rel="icon">` in `index.html`, an `exports.access` left in a function (it does nothing).
+Fix the first two before you tell the person the app is done.
+## The template is a starter kit
+- `src/components/ui` and `src/components/blocks` are a starting set: change them, restyle them
+  or delete what you do not use. Any colors, your own color scheme, inline styles, a single
+  theme without dark mode: all allowed.
+- The template looks like the xflow interface: warm grays, hairline controls (`ctl-solid`,
+  `ctl-raised`, `ctl-inset`, `ctl-select`), segments (`seg-track`, `seg-on`) and surfaces
+  (`surface-raised`, `surface-pop`, `surface-modal`) in `src/index.css`.
+- While any template component is left, the theme token names in `:root` of `src/index.css`
+  and their `hsl(var(--name))` mapping in the Tailwind config stay: those components paint with
+  them. Values change freely; they are HSL components (`216 95% 40%`), not `#hex`. Your own
+  colors go under new names.
+- Images and other assets: import them from `src/` (`import logo from './assets/logo.png'`)
+  so the build puts them next to the code. An absolute path into `public/` (`/logo.png`) goes
+  through the access check of the app and fails inside the xflow frame in Safari.
+## Who opens an app
+A person sets this in the web interface; you cannot, and you should not ask for a way around.
+| Level | Who gets in |
+|---|---|
+| Project members | people who have access to the project |
+| Anyone with the link | anybody, no sign-in at all |
+- The plan decides which levels exist: on Free an app opens only inside xflow, Start adds the
+  direct address and "Anyone with the link".
+- At the closed level the platform signs people in, and a function receives the person in
+  `event.xflow.user` (`id`, `role` in the organization, `name`, `access` to the project).
+  Keep roles inside the app (doctor, receptionist) in your own table keyed by `user.id`.
+- People outside the organization (patients, pickers, clients) are not xflow accounts: make the
+  app "Anyone with the link" and give it its own sign-in, see below.
+- At "Anyone with the link" the platform signs nobody in: `event.xflow.user` is null for
+  visitors. Accounts, sign-in and who sees which rows are the code of your app, see below.
+- `usePlatformAuth()` in the frontend knows the person only inside the xflow frame, and even
+  there it is a hint for drawing the interface, edited from the console by anyone. On the
+  direct address it answers `anonymous`. Guard data in the function, by `event.xflow`.
+## Which functions an app may call
+The root `xflow.json` names the callers of each function:
+    {
+      "projectId": "…",
+      "functions": {
+        "list-slots": { "callers": ["zapis", "priem"] },
+        "book-slot":  { "callers": ["zapis"] }
+      }
+    }
+- A caller is an app folder of this project (`apps/zapis` is `"zapis"`). A function without
+  callers is left out of `functions` or given `"callers": []`, the same thing.
+- A function nobody lists has no callers: no app reaches it. That is a workflow,
+  run by a schedule, a key or `xflow functions invoke`.
+- Callers ship with `xflow deploy functions` and come back with its `--revision N`.
+- The app calls `xflow.functions.invoke('book-slot', { body })` from `src/lib/xflow.ts`. The call
+  goes to `/_fn/book-slot` on the app's own address: no function addresses, tokens or keys in
+  the bundle, nothing to rebuild when a function changes.
+- A refusal throws `XFlowError` with `status` and `code`: `not_bound` (404, add the caller and
+  deploy functions), `not_found` (404, the function is not deployed), `login_required` and
+  `invalid_credential` (401, the visitor has to sign in again), `no_access`, `role_too_low`,
+  `functions_stopped` (403, minutes ran out or the plan is unpaid: a person settles it),
+  `rate_limited` (429), `unavailable` (503, retry later). Branch on `code`, never on the message.
+## Your function is open to the whole internet
+A function is open when an app at "Anyone with the link" is among its callers. `xflow deploy functions` says so in a line of its own, `xflow functions list`
+prints `open`, the web interface marks it.
+Open means anybody can call it with curl, without your app: the browser is not a gate.
+Hiding the address, checking `Origin` or `Referer`, a token baked into the bundle: all of it is
+readable or forgeable and protects nothing. Write every open function as if the request came
+from a stranger, because it may:
+- Check every input: types, lengths, allowed values; refuse fields you do not expect. Put input
+  into SQL as parameters only (`$1`), never into the text.
+- Return only what this caller needs: no `select *` into a response, no rows of other people,
+  no internal fields, no stack traces.
+- Make writes safe to repeat: take a request id from the client and put a unique index on it,
+  so a retry or a replay changes nothing.
+- Deduplicate and limit per visitor where it costs: `event.xflow.ip` is the visitor's address,
+  set by the platform proxy and not by the caller. The proxy caps requests per address; the
+  organization pays for every minute a function runs.
+- A form open to strangers needs a captcha: Cloudflare Turnstile, with the token checked in the
+  function against `https://challenges.cloudflare.com/turnstile/v0/siteverify` and the secret
+  from `xflow env set`. The site key is public and stays in the source. A check in the browser
+  checks nothing.
+- `minRole` on an open function refuses every anonymous visitor (`login_required`): use it only
+  where members call.
+## Sign-in in a public app
+At the closed levels do none of this: the platform already knows the person.
+- Passwords: store only a hash, `crypto.scrypt` from Node with a random salt per user, compare
+  with `crypto.timingSafeEqual`. Never log a password, never return it, never keep it in the
+  browser.
+- Session: after sign-in the function makes a random token (`crypto.randomBytes(32)`), stores
+  its SHA-256 and an expiry in a table and returns the token in the response body. The app keeps
+  it in `localStorage` and sends it on every call in the `X-Session` header. Not a cookie: Cloud
+  Functions drop `Cookie` and `Set-Cookie` both ways. `localStorage` belongs to one address, a
+  neighbouring `*.xflowpage.ru` site does not read it.
+- Any script on the page reads that token, so: an expiry of hours that each call extends,
+  sign-out and a password change delete the session rows, no user text rendered as HTML
+  (`dangerouslySetInnerHTML`), no scripts loaded from outside the build.
+- Never put the token into an address (`?session=`, a link): it stays in history and logs. A file
+  the function makes for this person is fetched with the header and opened as a `blob:` URL.
+- Not the `Authorization` header: `/_fn` replaces it with the platform's own. Nor headers named
+  `X-Xflow-*`, `X-Project-Pass`, `X-Server-Key`, `X-Function-Key`: the platform strips them.
+- Every function that serves a signed-in visitor reads `X-Session` from `event.headers` (match
+  the name in any case), finds the session and filters rows by that user in SQL. A hidden button
+  is not access control.
+- Count failed sign-ins per email and per `event.xflow.ip` in a table and slow them down.
+- Never in the frontend: keys, secrets, the list of users, hashes, a role check that is the only
+  guard.
+- The platform sends no email for your app: confirmation and reset letters need a mail provider
+  whose key goes into `xflow env set`.
+- `xflow dev` does not carry `X-Session` and calls functions as you (a member).
+  Try the sign-in on the app address.
+## A site for people outside the organization
+- A landing page, a presentation, an invoice is an app at "Anyone with the link" (a paid plan):
+  built, published and rolled back like any app, opened by its address without signing in.
+- Search engines are asked not to index apps: do not promise SEO.
+## Cloud functions
+`functions/<name>/index.ts` in the project root exports `handler` (`index.js` and `index.mjs`
+are read too), `export const handler` and `exports.handler` both work. The request arrives as
+`event.httpMethod`, `event.headers`, `event.queryStringParameters` and `event.body`, a string
+(`JSON.parse` it; `event.isBase64Encoded` marks a binary body). The handler returns
+`{ statusCode, body }` where `body` is a JSON string, and may add `headers`.
+`xflow functions list` shows status, callers, `open`, keys, last call and last error.
+- Dependencies (`pg`, a mail client) go into the root `package.json`; the platform installs them
+  on every deploy, and a lock file next to it makes that exact.
+- Code shared by functions lives in a root folder such as `lib/`, imported by relative path: each
+  function is bundled with what it imports. A folder in `functions/` without `index.*` is not a
+  function. Read `process.env` in `functions/<name>/` itself: `xflow env check` looks only there.
+Keep one shape inside that string across the project: `{ success: true, data }` when it worked,
+`{ success: false, error: { message, code } }` when it did not. Branch the frontend on
+`error.code`, never on `error.message`.
+A function whose code and variables did not change is not shipped again, and one that fails to
+ship fails the whole deploy.
+Debugging a deployed function is two commands: `xflow functions invoke <name>` calls it as you,
+through the platform, and prints the body alone, ready for a pipe (`--data '{"a":1}'`, `--data-file
+body.json`, `--method GET`; 4xx and 5xx exit non-zero; Windows PowerShell 5.1 prepends a BOM when
+piping to another program, so read it with `ConvertFrom-Json` or Python's `utf-8-sig`); `xflow functions logs <name>` shows
+the crashes and 5xx answers with stacks and console output, the latest 10 (`--limit N` for more).
+Only failed calls are logged. Empty output does not clear a function that fails at module start,
+runs over its time cap or out of memory: those never reach the logs, `invoke` shows them.
+The body has to be JSON and the CLI checks it before calling. In PowerShell the double quotes
+never reach the CLI (`--data '{"a":1}'` arrives as `{a:1}`): escape them (`--data '{\"a\":1}'`)
+or pass a file. It bites `--payload` of a schedule the same way. A command that worked writes
+nothing to stderr, so a red line there means it really failed.
+### Who is calling
+The platform checks every call before your code runs and hands the answer over in `event.xflow`:
+```js
+exports.handler = async (event) => {
+  const { caller, slug, user, ip } = event.xflow
+  // caller: 'app' (an app of this project), 'service' (another function of this
+  //         project), 'external' (an outside service with a key), 'schedule',
+  //         'platform' (a person through xflow functions invoke or the web interface)
+  // slug:   the address name of the calling app (<id>--<org>), null otherwise
+  // user:   { id, role, name, access } of a signed-in person, null for anonymous
+  //         visitors and keys. access: 'view' | 'edit' on this project
+  // ip:     the visitor's address, null for a schedule
+}
+```
+Never trust an identity that arrives in the body or in a header of the request: the page lives
+on someone else's computer. `event.xflow` is the only identity the platform stands behind.
+Project access is separate from the role: a person who only views the project (`access:
+'view'`) still reaches every function. A function that writes refuses them:
+```js
+if (event.xflow.user && event.xflow.user.access !== 'edit') {
+  return { statusCode: 403, body: JSON.stringify({ error: 'Read-only access' }) }
+}
+```
+To remember who did something, store `user.id` and `user.name` in the row: the name is never
+empty, and the app has no other way to look up other people.
+A function that changes data should say who may call it instead of checking the role by hand:
+```js
+exports.minRole = 'developer'   // 'member' | 'developer' | 'owner'
+```
+The platform refuses anything below that role before your code runs; it applies to people
+(apps, `functions invoke`), not to keys and schedules. `member` is the people who only
+use the apps (clinic employees, managers), `developer` and `owner` build them. In the web
+interface these roles are called «Просмотр» (`member`), «Редактор» (`developer`) and «Админ»
+(`owner`). Without the line
+every member of the project can call the function. Losing access
+closes the function within a minute.
+- Another function of the project: `fetch(`${process.env.XFLOW_FN_URL}/<name>`, { headers:
+  { 'X-Server-Key': process.env.XFLOW_SERVER_KEY } })`. The key opens the functions of its own
+  project only, whatever their callers.
+- An outside service (a payment webhook, a bot, a CRM) calls
+  `https://fn.xflowpage.ru/<projectId>/<name>` (`xflow functions list` prints it) with a key of
+  that function in `X-Function-Key` or `?key=`. Keys are issued by a person on the function's
+  screen in the web interface, never by you: ask the user. A function holds at most two keys,
+  the second one to replace the first without downtime.
+- `exports.access` does nothing any more: who may call is `callers`.
+## Secrets and connected accounts
+Keys and passwords live on the platform, not in the repository: `xflow env set SMTP_PASSWORD=…`
+writes one, `xflow env` lists the names, `xflow env check` names the variables your functions
+read but the platform does not have. Values never come back out: the only place they exist is
+inside the running function. Apps get no variables at all.
+A variable belongs to one project: functions of other projects never see it, and each project
+keeps its own value under the same name.
+`DATABASE_URL` and every name starting with `XFLOW` are filled in by the platform: writing them
+is refused.
+Some variables come from a connected account instead of from you. Credentials of an account
+linked to the project show up in `xflow env` marked read-only, under a prefix chosen at link
+time (`YANDEX_DIRECT_TOKEN`, `YANDEX_DIRECT_CLIENT_LOGIN`): read them like any other variable.
+If calls to that service start failing on authorisation, `xflow status` says whether the token
+is merely expiring (any deploy of the functions renews it) or the account was disconnected on
+the provider's side, which only a human can reconnect.
+`xflow connections` lists those accounts: the ones linked to this project, with the alias and
+the state of the access, and the ones the organization has but this project does not use yet,
+marked `available, not linked`. Check it before telling anyone a service is unavailable.
+`xflow connections link "Яндекс Метрика" --as YANDEX_METRIKA` is that link and
+`xflow connections unlink YANDEX_METRIKA` undoes it; `xflow help connections` has the naming
+rules. In the project folder unlink refuses while a function still reads one of the variables,
+naming those functions, so read that list before reaching for `--yes`.
+Linking needs the `connections:link` right on the key, and only accounts granted to the owner
+of the key personally can be linked at all. A key cannot grant it to itself: ask the person.
+Connecting a new account and switching one off stay with a person too.
+### Asking an API what it returns
+```
+xflow connections call WB /api/v1/supplier/stocks?dateFrom=2026-09-01
+xflow connections call "Яндекс Метрика" /management/v1/counters
+xflow connections call OZON /v1/product/list --method POST --data '{}' \
+    --header '{"Client-Id":"{CLIENT_ID}"}'
+```
+The platform attaches the credentials and makes the request itself: no deploy, and the key never
+reaches you. A linked account is called by its alias, an `available, not linked` one by its
+name: linking first is not needed to look. Calling is looking, not wiring: to use the account
+in code, link it and deploy functions.
+`{NAME}` in the path or in a header value is filled in from the fields of the connection. Take
+the names from `xflow connections`, which prints them in braces: an invented name is left in the
+text and the request goes out anyway, into somebody's live account. Ask for the shape, not the
+volume: one day and `limit=1`; `--json | jq '.response.body | keys'` gives the field names
+without the body entering your context. `POST` and `DELETE` change things in a live account and
+nothing undoes that: ask the person first when the endpoint is not clearly a read.
+## Schedules
+`xflow schedules set report "0 3 ? * * *"` runs a function daily at 03:00. Six fields, UTC,
+and exactly one of day-of-month / day-of-week must be `?`. A run reaches the handler as a POST
+with `event.xflow.caller === 'schedule'`, and `--payload '{"mode":"full"}'` (or
+`--payload-file body.json`) is its body. The function has to be deployed first.
+A schedule is the function plus its cron: `set` with the same pair only changes the payload, a
+new cron is one more schedule next to the old one. The plan caps the count for the whole
+organization, so take the old one off with `xflow schedules rm report "<old cron>"`.
+```
+xflow env set SMTP_PASSWORD=...                 # secrets first: values ride the next deploy
+# write functions/report/index.ts, reading process.env.SMTP_PASSWORD literally
+xflow deploy functions -m "Nightly report"
+xflow schedules set report "0 3 ? * * *" --payload '{"mode":"full"}'
+xflow functions invoke report                   # run it once
+xflow functions logs report                     # crashes of real runs
+```
+## Database
+Schema changes are files: `migrations/0001_init.sql`, `migrations/0002_orders.sql` in the
+project root, applied in filename order by `xflow db migrate` from any folder of the project.
+`xflow db status` shows what is applied and what waits. Never edit an applied file, write a new
+migration instead. Every project has exactly one database of its own, shared by all its apps and
+functions.
+The browser never reaches the database directly. The app reads and writes through a cloud
+function, and inside the handler the connection string is already there:
+```js
+const { Client } = require('pg')
+const db = new Client({ connectionString: process.env.DATABASE_URL })
+```
+The platform passes `DATABASE_URL` only to functions that mention it and sets the project schema
+on every connection, so plain table names (`select * from tasks`) hit your project.
+`migrations/` says what you did; `xflow db schema [table]` says what is in the database now, and
+`xflow db query 'select ...'` reads it inside a READ ONLY transaction (as many rows as its
+own `limit` asks, 50 without one, 300 at most; `--json` prints long values whole). Single quotes hold in PowerShell, bash
+and zsh, cmd.exe wants double ones; a query with quotes of its own goes in a `.sql` file outside
+the project, `xflow db query ../q.sql`.
+A one-off data fix is `xflow db exec 'update ...'` (or `../fix.sql`), not a migration: one
+INSERT, UPDATE, DELETE or MERGE, saved at once, never re-run, no trace in the migration history.
+Schema changes are refused there. Deleting rows, or updating more than 100 in a table (cascades
+and triggers count), asks for `--allow-destructive`, and deleting also for the right below.
+There is no undo: read the rows with `db query` first.
+A branch is a database of its own, as the project database is now or was at a moment of its
+history (6 hours back on Free, 3 days on Start, 7 days on Business), made in seconds without
+copying: `xflow db branch create try-orders [--at 2h|14:05|<ISO date>]`. Try a migration or a fix
+there first (`db migrate`, `db exec`, `db query` take `--branch <name>`); nothing reaches the
+project database. After a data mistake, do not roll anything back: branch as of a moment before
+it, check the rows with `db query --branch`, then `xflow db restore --from <branch> --table <t>
+[--where '...']` puts the missing rows back by primary key and keeps all newer data
+(`--overwrite` replaces rows still there and needs the destroy right). Branches per project: 2,
+5, 15 by plan; delete them when done (`xflow db branch delete <name>`). A branch sleeps after a
+quiet minute, has no functions, and a branch of a branch is not made.
+Anything that destroys data
+(`DROP TABLE`, `DROP COLUMN`, `TRUNCATE`, `DELETE`) needs both the `--allow-destructive` flag and
+the right to destroy data on the key, which is off by default and only its owner turns on. It is
+judged by the result, not the text: a migration that dropped or emptied a table, dropped a column
+or deleted rows is rolled back, however the SQL was written. `BEGIN`/`COMMIT` in a migration are
+refused: each one already runs in its own transaction. When the refusal is about the right, the flag changes nothing: say what
+needs deleting and why, and let the person decide. With both in place the affected tables are
+dumped first (up to 50 000 rows each) and kept for 7 days; getting a dump back is a request to
+the person, no command does it. Check with `--dry-run`.
+Pass `DATABASE_URL` as is, without an `ssl` option. The database is PostgreSQL 18, so do not
+tune it from migrations:
+- Installed: `pg_trgm`. `gen_random_uuid()` and `uuidv7()` are built in. Never `uuid-ossp`.
+  Anything else (`postgis`, `pgvector`) is a request to the person.
+- A statement is cut after 10 seconds (in a migration through `xflow db migrate`, after 2 minutes),
+  waiting for a lock after 10, a transaction left open after 60. Connections to the database of
+  one project: Free 10, Start 25, Business 50. A query that needs longer is a wrong query (a missing index, or a report that belongs in a
+  scheduled function writing a summary table).
+Calls of one project run at the same time in one process. A `Client`, even one made at module
+level, gets its own pooled connection for each call, so `connect()` twice is fine. Keep
+per-request data out of module-level variables. Session state (`SET` without `LOCAL`, temp tables,
+advisory locks) lasts until the call ends, and a transaction left open is rolled back: set what
+the call needs inside the handler. A `Client` that listens for `notification` keeps its own
+connection.
+## File storage
+**Static assets of an app** (product photos, video, PDFs, big artwork) you upload yourself:
+```bash
+xflow storage push ./media --to media   # a folder, its structure kept
+xflow storage ls                        # what is there, with addresses and sizes
+```
+`push` prints the address of every file (`/_files/<id>`) and skips what is already stored under
+the same path and size; `--replace` overwrites a file whose size differs and keeps its address.
+Use the address as is inside an app: the app's own host serves it to whoever may open the app,
+including anonymous visitors of a public one. Icons, fonts and small artwork stay in the
+repository.
+Deleting needs a right of its own, off by default, so `xflow storage rm` may answer that the key
+was not granted it. Ask the person and do not look for a way around: whatever the users of the
+app uploaded lives in the same folders, and there is no undo. A folder is
+`xflow storage rm --folder <path> --yes`.
+**Files that users of the app upload** go through a cloud function of your own: it asks the
+platform for a one-time link, the browser sends the bytes straight to storage, and a second call
+records the file:
+```js
+const link = await fetch(`${process.env.XFLOW_API_URL}/api/storage/project/upload-url`, {
+  method: 'POST',
+  headers: {
+    'Content-Type': 'application/json',
+    'X-Server-Key': process.env.XFLOW_SERVER_KEY,
+  },
+  body: JSON.stringify({ fileName, fileSize, contentType, folderPath: 'invoices' }),
+}).then((r) => r.json())
+```
+`confirm` takes the returned `s3Key` and answers with the file and its address; `delete` takes
+that same `url`. No endpoint lists files back, so write the address into a table of your own in
+the same call. What a visitor may do with files is decided inside that function; never send the
+key to the frontend.
+- A name already taken in that folder is refused before the link is issued; `overwrite: true`
+  replaces the bytes and keeps the address.
+- 200 MB per file and the organization's space (databases and files together), checked again
+  on `confirm`.
+- Confirm only after the PUT has finished, and send on the PUT exactly the `Content-Type` you
+  named: the link is signed for it, a different or missing type gets 403.
+- Assets only: pages, scripts and executables (`html`, `js`, `exe`, …) are refused with
+  `forbidden_type`.
+A refusal comes back as `{ error, code }` (`invalid_name`, `file_too_large`, `quota_exceeded`,
+`not_uploaded`, `duplicate_name`, `forbidden_type`, `not_found`, …): branch on `code`.
+## Organizations and keys
+One key per organization, stored side by side: `xflow org` lists them, `xflow org switch
+<name|id>` changes the active one, `xflow help org` has the precedence rules.
+Inside a project folder commands follow the organization the folder is bound to, whatever the
+active one is. `--project <id>` and `--app <id>` ignore the folder whole (`xflow help project`
+lists the commands that take them). A "not found" on a project you know exists usually means the
+key belongs to another organization: check `xflow org`; signing in to a missing organization is
+`xflow login`, and that needs a person with a browser.
+A key has its owner's level in each project. With view-only access reading works (`projects
+get`, logs, `db query`, `pull`), and every change fails with `Your access to this project is
+view-only`. That is not a bug to work around: tell the person, edit access is theirs to ask for.
+## Do not
+- Deploy with `--force` without checking `xflow status` first.
+- Invent platform commands: what is not in `xflow help` does not exist.
+- Ask for a way to change an app's access level or issue a function key: that is the person's.
+## App design
+- Take a block from `src/components/blocks` or a primitive from `src/components/ui` before
+  writing your own layout; replace or delete them when the design needs something else.
+- Dropdowns, checkboxes, radios and dates through `Select`, `Checkbox`, `RadioGroup`,
+  `DatePicker` from `src/components/ui`: a bare `<select>` opens the system list in Safari
+  and Firefox, out of the app's style.
+- Every screen starts with a clear header; header, filters and content in one column.
+- Draw all four states: loading, error, empty, data. An empty screen says what appears here and
+  offers an action.
+- Colour only when it communicates: status, action, error, success. Grey carries the structure.
+- Density over air: people scan and compare. Numbers in a column, `tabular-nums`.
+- Name the shape first: list, list with detail, dashboard, form, board.
+- Seed 5-10 believable rows in the first migration: a screen with zero rows looks unfinished.
+- Give the app its own page title and icon.
+## Errors from a deployed app
+`xflow logs` prints what broke in the browser on the app addresses: unhandled errors, rejected
+promises and 5xx responses; in an app folder that app, in the project root every app.
+`xflow functions logs [name]` prints function crashes with the tail of their console, and failed
+calls (timeout, out of memory, 5xx; no console for those); `--all` adds every call as its status
+and time, `--cursor` (printed at the end) goes to older ones. A person sees the same in the web
+interface: browser errors in the «Ошибки» (Errors) panel of the app, function crashes on the
+«Ошибки» tab of the function's screen. `xflow db logs` prints what the database refused: failed
+and timed-out queries with their SQL (cut to 2 KB), dropped connections. Kept for 7 days, 1 day on
+the Free plan.
+Run an app locally with `xflow dev` in its folder, not a bare `npm run dev`: every `/_fn/<name>`
+call then goes to the platform as this app, with the same callers and access as on its address,
+and a function someone else deployed answers at once. A bare `npm run dev` has no key, so its
+function calls fail. The server answers `127.0.0.1` alone, because it holds that key. A local
+run reports nothing to the logs.
+## Environment
+For CI and agent runs: `XFLOW_TOKEN` replaces `xflow login`, `XFLOW_API_URL` points at another
+platform host. There is no `.env` from the platform: the bundle carries no tokens or addresses.