@getxflow/cli 1.4.0 → 1.5.0

package/skills/xflow/SKILL.md

@@ -1,735 +1,719 @@
----
-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 page on xflowpage.ru (a landing page, presentation or invoice for people outside the organization).
----
-
-# 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.4.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 `permission denied` (42501), 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, functions, pages, active connections,
-people in the organization, database and file storage, function minutes, builds per month and at once, schedules
-(one count for all projects of the organization) and how often they may run, and which access levels an app may have. 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, page 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 and pages 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.
-- One function runs at most a plan-set number of calls at once: Free 5, Start 15, Business 35
-  per cloud zone (the cloud has three, the spread is not promised). A call over it gets 429 at
-  once: 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 page is never
-  a caller. 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.
-
-## Page or app
-
-- A page is finished static files at `https://<name>.xflowpage.ru`: public, live the moment it
-  is uploaded, no build, no publish step, no database. A landing page, a presentation, an invoice.
-- An app is source the platform builds: versions and publish, access levels, a database through
-  functions. Anything people sign in to, enter data into or come back to.
-- Keep the sources of a page outside the project folder, or list them in `.xflowignore`: the
-  root travels with `deploy functions`.
-- A page has no backend. A form or a lookup for strangers is an app at "Anyone with the link"
-  (a paid plan): the platform checks every call to its functions.
-- A function key on a page is allowed, and it opens that function to every visitor: an HTML
-  form posts to `https://fn.xflowpage.ru/<projectId>/<name>?key=...`, fetch cannot read the
-  answer (no CORS). Nothing guards it but the function's own checks: say so to the user.
-
-## 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 goes to the whole organization unless you say otherwise: `--scope project` keeps it
-to this project alone, `--scope organization` is the default, and a third word is refused.
-Pick the narrow one for anything that belongs to one project. These commands see only what
-this project can see, so `env rm` reports a variable of another project missing even though
-names are unique within the organization.
-
-`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`.
-
-An organization can have own database servers. `xflow db list` names the server of each project
-database (`platform` is the common one) and the own servers with the room used.
-- A new project with its database on a chosen server: `xflow init --server <name>`.
-- An existing one: `xflow db move --to <name> --yes`. Writes close while it
-  copies, usually a couple of minutes; the platform switches the functions itself. It needs the
-  right to move databases, off on the key by default: refused for the right, say what should move
-  where and why, and the person turns it on or moves it in the «Базы данных» (Databases) section.
-- Buying, paying for and deleting servers are the person's, in the web interface.
-
-Code stays the same on an own server: pass `DATABASE_URL` as is, without an `ssl` option. While
-an own server is not running, migrations and queries say so and functions that use the database
-time out: tell the person instead of retrying.
-
-An own server comes tuned and guarded, so do not tune it from migrations:
-- Installed: `pgcrypto`, `pg_trgm`, `unaccent`, `citext`, `btree_gin`, `btree_gist`,
-  `pg_stat_statements`. `gen_random_uuid()` is built in everywhere, `uuidv7()` on an own server.
-  Never `uuid-ossp`. Anything else (`postgis`, `pgvector`) is a request to the person.
-- A statement is cut after 30 seconds, waiting for a lock after 3, a transaction left open after
-  30. 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). A scheduled job that genuinely needs more runs
-  `SET statement_timeout = '5min'` on its own connection. A database that used `citext` or
-  another extension type cannot move back to `platform`.
-- A restart on a plan change takes about a minute.
-
-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`.
-
-## Pages
-
-A page is a public static site at `https://<name>.xflowpage.ru`, outside projects. Anyone with
-the address opens it, without signing in.
-
-- `xflow pages create "Price list" ./dist` makes a page with the built site on it and prints its
-  address: there are no empty pages. `--slug price-list` picks the name, otherwise it comes from
-  the title with a random tail.
-- `xflow pages deploy <page> <folder|.zip|.html> -m "what changed"` uploads a new version.
-- **Both are public the moment the command finishes**: no draft, no publish step.
-- `xflow pages status <page>` lists the versions, `xflow pages rollback <page> <N>` puts one back
-  in seconds; the files of the last 5 are kept.
-- `xflow pages rm <page> --yes` deletes the page: the address goes empty and every version is
-  gone for good, without `--yes` the command names what goes and stops. The name stays reserved
-  for the organization. A page put up to try something out is yours to take down when you are
-  done: do not leave it standing.
-- Names are 3-40 characters. At most 100 pages per organization, 20 new and 200 uploads a day,
-  10 seconds between uploads of one page: batch changes into one upload.
-- Static files only, what the build writes (`dist`), never a folder with `package.json`. At most
-  5 MB zipped, 25 MB unpacked, 1000 files. Everything a page shows travels inside it: project
-  file storage does not serve pages.
-- A backend for a page: see **Page or app**.
-- Everything in a page is readable by every visitor. A known key format gets the upload refused,
-  anything else simply leaks.
-- Search engines are asked not to index pages or apps: do not promise SEO.
-- The tab icon is the platform's on every page: do not spend a request on a favicon of your own.
-- A page is deleted by whoever made it, or by the owner of the organization. Switching a page
-  off for a while is for a person, in the platform interface.
-
-## 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` prints function crashes. 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. The last 200 records of each stream are kept.
-
-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 page on xflowpage.ru (a landing page, presentation or invoice for people outside the organization).
+---
+
+# 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.5.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, functions, pages, active connections,
+people in the organization, database and file storage, function minutes, builds per month and at once, schedules
+(one count for all projects of the organization) and how often they may run, and which access levels an app may have. 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, page 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 and pages 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.
+- One function runs at most a plan-set number of calls at once: Free 5, Start 15, Business 35
+  per cloud zone (the cloud has three, the spread is not promised). A call over it gets 429 at
+  once: 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 page is never
+  a caller. 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.
+
+## Page or app
+
+- A page is finished static files at `https://<name>.xflowpage.ru`: public, live the moment it
+  is uploaded, no build, no publish step, no database. A landing page, a presentation, an invoice.
+- An app is source the platform builds: versions and publish, access levels, a database through
+  functions. Anything people sign in to, enter data into or come back to.
+- Keep the sources of a page outside the project folder, or list them in `.xflowignore`: the
+  root travels with `deploy functions`.
+- A page has no backend. A form or a lookup for strangers is an app at "Anyone with the link"
+  (a paid plan): the platform checks every call to its functions.
+- A function key on a page is allowed, and it opens that function to every visitor: an HTML
+  form posts to `https://fn.xflowpage.ru/<projectId>/<name>?key=...`, fetch cannot read the
+  answer (no CORS). Nothing guards it but the function's own checks: say so to the user.
+
+## 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 goes to the whole organization unless you say otherwise: `--scope project` keeps it
+to this project alone, `--scope organization` is the default, and a third word is refused.
+Pick the narrow one for anything that belongs to one project. These commands see only what
+this project can see, so `env rm` reports a variable of another project missing even though
+names are unique within the organization.
+
+`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 30 seconds, waiting for a lock after 10, a transaction left open after
+  60. 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`.
+
+## Pages
+
+A page is a public static site at `https://<name>.xflowpage.ru`, outside projects. Anyone with
+the address opens it, without signing in.
+
+- `xflow pages create "Price list" ./dist` makes a page with the built site on it and prints its
+  address: there are no empty pages. `--slug price-list` picks the name, otherwise it comes from
+  the title with a random tail.
+- `xflow pages deploy <page> <folder|.zip|.html> -m "what changed"` uploads a new version.
+- **Both are public the moment the command finishes**: no draft, no publish step.
+- `xflow pages status <page>` lists the versions, `xflow pages rollback <page> <N>` puts one back
+  in seconds; the files of the last 5 are kept.
+- `xflow pages rm <page> --yes` deletes the page: the address goes empty and every version is
+  gone for good, without `--yes` the command names what goes and stops. The name stays reserved
+  for the organization. A page put up to try something out is yours to take down when you are
+  done: do not leave it standing.
+- Names are 3-40 characters. At most 100 pages per organization, 20 new and 200 uploads a day,
+  10 seconds between uploads of one page: batch changes into one upload.
+- Static files only, what the build writes (`dist`), never a folder with `package.json`. At most
+  5 MB zipped, 25 MB unpacked, 1000 files. Everything a page shows travels inside it: project
+  file storage does not serve pages.
+- A backend for a page: see **Page or app**.
+- Everything in a page is readable by every visitor. A known key format gets the upload refused,
+  anything else simply leaks.
+- Search engines are asked not to index pages or apps: do not promise SEO.
+- The tab icon is the platform's on every page: do not spend a request on a favicon of your own.
+- A page is deleted by whoever made it, or by the owner of the organization. Switching a page
+  off for a while is for a person, in the platform interface.
+
+## 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` prints function crashes. 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. The last 200 records of each stream are kept.
+
+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.