Source: schemas/skills.json
Generated automatically from the published contract sources.
Source path: schemas/skills.json.
Complete source
{
"title": "Turn Zero Cloud — the skill rows",
"description": "The skill enumeration (API-L0-10: the shipped set is derived from what the platform offers, never a hand-kept server list — these are contract rows like the tool catalog's, held by a test in the platform's suite). Each row names the management task and the enumerated actions it drives; a row naming an action the contract lacks fails the suite (CTX-04's gate). A row publishes as a served skill exactly when every action it drives is implemented: the served set grows as actions land, and a row with no actions yet names a task whose capabilities arrive at a later rung. Q-144's initial eleven are the seed the derivation is checked against.",
"version": "2026-10-07.5",
"skills": [
{
"name": "store-key",
"summary": "Put a secret under the platform's custody by name and rotate it later without a code change (CHI-L0-08; SCRT-L0-01).",
"must": [
"Name the secret and call store_secret with no value, never passing the value as a tool argument: with value_file naming a local file holding the value, run the command it answers, command_windows on Windows, and without one hand it to the builder (CHI-L0-08; SCRT-L0-01).",
"For a value nobody chooses, such as a session signing secret, call store_secret with application and generate, which creates it in custody and answers none, and never generate a key a provider issued (SEC-L0-20).",
"Never write the value into code, the manifest, or a committed file, and never paste it into a tool call, since a host may record a tool's arguments and output in its transcript (SCRT-L0-01; CHI-L0-08).",
"Declare an outside API's key with declare_upstream, whose gateway applies it at its edge, unless its client's host is fixed in code you must not change; bind that client's key, or a value the code uses itself, in the manifest's settings (EGW-L0-03; MAN-14).",
"Rotate a secret the same way, calling rotate_secret with no value, which needs no code change, a bound setting's rotation taking effect at the environment's next deploy or promote, and at a restart_application where the running copy already carries the binding (CHI-L0-08; SCRT-L0-05; MAN-14).",
"Where an upstream names the secret, expect no redeploy: the gateway applies the new value from its next call (SCRT-L0-05; EGW-L0-03).",
"Where rotate_secret's answer carries next, make that restart_application call once the command ends with status 0: the restart is a separate call so a copied line cannot itself make the running copy read a value (SEC-L0-19; MAN-14).",
"Where a key under the wrong name or level belongs under a new name or at the application's other environment, store it there first, then delete the wrong entry with delete_secret once nothing uses it, handing the person the approval link (SCRT-L0-07; SCRT-L0-08; API-L0-07).",
"Where a key belongs under the same name at another level (account, application, or one environment), not between environments, end the wrong entry's uses, delete it with delete_secret, hand the person the approval link, and store it only once read_pending_action reads completed (SCRT-L0-07; API-L0-07)."
],
"actions": [
"store_secret",
"rotate_secret",
"delete_secret",
"read_pending_action"
],
"page": "/cloud/getting-started/store-a-secret/",
"short_path": {
"lead": "This is the short path for storing the key an outside API issued. Each step names the rules it follows.",
"steps": [
"Call store_secret with the name and no value, with value_file naming a local file that holds the value, and run the command it answers once, command_windows on Windows; without a file, hand the line to the builder (rules 1 and 3).",
"Give the code the key through declare_upstream, whose gateway applies it at the edge; bind it in the manifest's settings only where the client's host is fixed in code you must not change, or the code uses the value itself (rule 4).",
"Rotate later with rotate_secret the same way: an upstream takes the new value at its next call, a bound setting at the next deploy or promote, or at the restart_application the answer's next names (rules 5, 6, and 7)."
],
"scoped": [
{
"where": "nobody chooses the value, such as a session signing secret",
"rules": [
2
]
},
{
"where": "a key stands under the wrong name or level",
"rules": [
8,
9
]
}
]
}
},
{
"name": "delete-account",
"summary": "The erasure route: export the account's declarations and each application's data first, then delete the account through the browser approval. The source stays with the builder. Each application's database contents and stored files leave through request_export, one application and one environment per export; read_export reads each export's manifest, and mint_download_grant answers the line that downloads its files.",
"must": [
"Run export_account first and keep its answer; the export holds the account's declarations and not its code, database contents, or files (ACB-L0-47).",
"For each application holding a database or stored files, call request_export for each environment it uses, read read_export until the state is completed, then call mint_download_grant and run the line it answers, which downloads every file the manifest names (API-L0-18; API-L0-23).",
"Call delete_account, hand the person the approval link, and read the outcome through read_pending_action (CHI-L0-12)."
],
"actions": [
"export_account",
"request_export",
"read_export",
"mint_download_grant",
"delete_account",
"read_pending_action"
],
"page": "/cloud/guides/export-or-delete-your-account/"
},
{
"name": "platform-admin",
"summary": "The super-admin's control plane: enumerate accounts, read standing, suspend and reinstate, and move an application's egress enforcement mode (API-L0-12; EGW-L0-17). The control plane's own record is read the same way: read_control_plane_logs answers the control_plane scope's entries and read_control_plane_counters its totals. Both are super-admin reads over the logging service, so a sign-in refusal, a sweep failure, or the listen banner is readable through the management surface rather than the container log alone.\n\nThe plan entitlements are the operator's: set_plan_quota sets a served quantity row with no deploy, the pricing registry's cell following by registrar transaction (PRC-L0-16). The read_platform_usage call answers every application's plan and usage states beside the quantity rows, with each resource's month-to-date cost from the hosting subscription's cost service where the read asks for it.\n\nThe platform's own status is read the same way: read_platform_status answers the status document — the overall state, the open incidents, every component's state, the availability figures, the signals, the passes, the capacity rows, and the incident history. Its summary_text is the paragraph to print for a \"show me the status\" ask. The record_incident call opens or amends an incident by hand, and set_status_setting sets one of the record's served values, the watched conditions' thresholds among them.",
"must": [
"Act under a credential holding super_admin; every action here is the operator's and refuses any other grant (API-L0-12).",
"Move an application's egress mode with set_egress_mode only after reading its undeclared destinations, because enforce refuses them (EGW-L0-17).",
"Set a plan's served quantity with set_plan_quota and record the pricing registry's cell through the registrar in the same change (PRC-L0-16).",
"Print read_platform_status's summary_text for a status ask and read one section for a question; open or amend an incident with record_incident, never by a database write (API-L0-12)."
],
"actions": [
"list_accounts",
"read_operated_account",
"suspend_account",
"reinstate_account",
"set_egress_mode",
"read_control_plane_logs",
"read_control_plane_counters",
"set_plan_quota",
"read_platform_usage",
"read_platform_status",
"record_incident",
"set_status_setting"
]
},
{
"name": "deploy",
"summary": "Ask the builder which plan the application starts on (`free`, `standard`, or `pro`), create the application on that plan, declare its manifest, and deploy a built artifact (CHI-L0-07; PLD-L0-63). A new application has one environment, production, so its deploy reaches production (PLD-L0-96). `create_environment` turns on a development environment, after which a deploy goes to development and `promote` moves a version to production (PLD-L0-43). The deployed backend runs under the platform's hosting and network controls, and the artifact is written for it — each rule of this skill is owned by the statement named beside it.\n\nA web client is optional: an application without one, the backend of a mobile app among them, ships no `client/` folder, and the serving router forwards every request to its own routes (CQ-112).\n\nA folder deploys by one call and one line, the same whichever environment it goes to (PLD-L0-86; PLD-L0-94). Call `deploy` with the application, naming no environment and neither `artifact` nor `upload`; it answers `awaiting_command` with `command`, one line, `command_windows`, its Windows form, and `next`, a `read_status` call. Run that line once, as given, from the application's folder, on Node.js 24 or later.\n\nThe line pipes a one-time code to the command, the one credential the line may carry, because the agent's own shell presents it. Until the code ends at `expires_at`, treat the line as a credential: run only the line your own call answered, and paste it nowhere. The command zips the folder, sends the code once to prepare its upload, uploads the zip, starts its deploy, and then waits for that deploy under the upload's grant, which no answer shows a tool, printing each step and the outcome. It ends 0 for a deployed version, 1 for a failed one, 2 where it stopped before the outcome, and 3 where nothing was started. `TURNZERO_DEPLOY_NO_WAIT` in the shell returns it after the start.\n\nWhere the command returned before the outcome, the `next` call, `read_status` with `wait_seconds`, holds its answer until the deploy ends, up to 45 seconds, and leads with a one-line `summary` (MAPI-04). A start the command reports refused is made again through the `retry` that `read_status`'s `pending_upload` carries, once its cause is cleared; where `retry` is null, call `deploy` again and run the fresh line, the folder fixed first where its zip was refused. A line refused `deploy_code_refused` is answered the same way, and the new answer's `previous_code` says what became of the old code. No call from a tool names `zip_sha256`: one that does is refused `local_route_required`. A job with no tool to call `deploy` runs the command under `TURNZERO_CLOUD_MINTED_TOKEN`, and a script may still upload to a declared area under `mint_upload_grant` and name the file in `artifact`.\n\nStored values reach the code in two ways (MAN-14; EGW-L0-01). A key an upstream names stays at the gateway, which applies it at its edge. Where the upstream declares `settings`, each deploy, promote, and restart sets a base-URL setting (an environment variable) and a key setting holding an egress key, so an unchanged SDK reaches the API through the gateway. A value the code reads itself is bound in the manifest's `settings` and enters the container as that setting.\n\nEgress: the manifest's `egress` member declares external hosts. Enforcement depends on the observe or enforce mode explained below (ADM-L0-03; EGW-L0-17), as exact lowercase hostnames and `*.example.com` host families (MAN-09), CONNECT tunnels to port 443, without TLS or HTTP inspection (EGW-L0-12). The list names the hosts the application's own process dials: an upstream declared with `declare_upstream` is dialled by the gateway, and it and the platform's own endpoints — the declared services' and the platform origin — need no entry (EGW-L0-15). Private, loopback, link-local (the metadata address among them), reserved, and platform addresses refuse by class whatever the list says (EGW-L0-13).\n\nCovered clients: use the runtime's global `fetch`, undici, or an SDK built on fetch — the runtime harness routes them through the cell's egress proxy automatically (HST-L0-01); axios reads the proxy environment the harness sets (`HTTPS_PROXY`, `HTTP_PROXY`, `NO_PROXY`).\n\nThe clients `node:https`, node-fetch, got, and ws read neither, so they route only through an explicit proxy agent the code builds from `HTTPS_PROXY` (`new HttpsProxyAgent(process.env.HTTPS_PROXY)` from `https-proxy-agent`, passed as the client's `agent` option, got's under `agent.https`). Without one, their calls bypass the proxy and receive no proxy refusal. They may connect or fail according to the deployed network rules, the establishment itself still recorded by the harness's connection observer as `egress_establishment`. A native addon or a child process alone opens sockets no record sees (EGW-L0-17).\n\nRefusals and where to read them: in enforce mode an undeclared destination is refused at establishment as `egress_undeclared` with the attempted host and the remedy — the exact manifest edit, \"add `api.example.com` to the manifest's `egress` list and redeploy\". The refusal is recorded always and answered 403 with the `X-Egress-Refusal` header where the client's route carries the proxy's answer (EGW-L0-14).\n\nRead the records with `read_logs`: `source: \"egress\"` for the tunnel seat's rows, and `filter: \"undeclared\"` for the hosts the manifest does not declare with the platform endpoints subtracted. Read `source: \"harness\"` for the connection observer's records — one `egress_establishments` record per host, port, and outcome a minute with the proxied mark, and each failed `egress_establishment` whole — and `source: \"container\"` for the process's console, where the harness's `process_ended` and `harness_refusal` lines land. Read `source: \"router\"` for the serving router's `window_ended` rows, and `source: \"all\"` for every stored source merged by time, the console excepted.\n\nObserve versus enforce: an application begins in `observe`, where an undeclared destination is carried and recorded with the name it would refuse under. The operator's `set_egress_mode` moves it to `enforce`, the mode readable as `egress_mode` on `read_status` (EGW-L0-17; API-L0-12). The mode gates the declaration check alone, the port rule and the address classes refusing in both.\n\nThe window: an ordinary HTTP request handler completes inside the platform's configured request window (HST-L0-02 — configuration with a stated default, never a number in this text). Past it the serving router answers 504 `window_ended` where no response header has gone out and cuts a streaming response otherwise, and the handler's `request.signal` aborts. A handler that ends its response on the abort has yielded; one that does not ends the process after the grace interval, other interrupted requests logged under `process_ended` and the container restarting. Callers may receive transport or provider failures (HST-L0-03).\n\nUpgraded connections are outside that request deadline, while their initial upgrade requests still undergo router and scheduled-path checks (HST-L0-03). No work runs outside a handler — a timer, a polling loop, a detached promise, or a child process past the response is forbidden and ends at the next process end (HST-L0-04).\n\nThe router mark: the application is reachable through its managed URL alone; a request to the provider default hostname without the serving router's mark is refused 403 `router_mark_required` by the harness and recorded as `harness_refusal` (SVC-L0-07; HST-L0-01). The artifact exposes one server honoring `PORT` and nothing for the harness's sake (HST-L0-05; PLD-L0-60).\n\nA scheduled handler is an ordinary route of the same server the platform invokes through the serving router, calling the declared path with `POST` and an empty body (SCH-L0-02). Each run carries four headers the router alone sets (HST-L0-06): `x-turnzero-cloud-invocation` with the value `schedule`, `x-turnzero-cloud-schedule` naming the declared schedule, `x-turnzero-cloud-run` carrying the run's identifier, and `x-turnzero-cloud-schedule-due` carrying the due instant in UTC. Any other header whose name begins `x-turnzero-cloud-` is the platform's own: never log or echo one, and never log the request's headers whole (HST-L0-05); the router's mark never reaches the handler (HST-L0-01).\n\nOn a declared path the platform's harness refuses a request without that header 404 `scheduled_handler_only`, so the handler receives scheduled runs alone and is written idempotent per the `x-turnzero-cloud-schedule-due` instant. It completes inside the schedule kind's window with `request.signal` (HST-L0-02) and runs no timers (HST-L0-04). The plan's shortest interval and schedule count are the pricing registry's rows, refused at submit by name (SCH-L0-01).",
"must": [
"Ask the builder which plan the application starts on, free, standard, or pro, and create it on that plan with create_application (CHI-L0-07).",
"Where the code calls an external API on a stored key, store the key by calling store_secret with no value and running the command it answers, command_windows on Windows, never passing the value as a tool argument (CHI-L0-08; SCRT-L0-01).",
"Declare an outside API's key with declare_upstream, whose gateway applies it at its own edge so the key never enters the container; bind it in the manifest's settings only where its client's host is fixed in code you must not change (EGW-L0-03; MAN-14).",
"Where the API's SDK reads its base URL and key from settings, name them in declare_upstream's settings, the key as the SDK's bearer setting, such as OPENAI_API_KEY or ANTHROPIC_AUTH_TOKEN, so the SDK reaches the API unchanged (EGW-L0-01; SEC-L0-18).",
"Choose by whether you may edit the client: where you may, make it read its base URL and key from settings and declare the upstream; where its host is fixed in code you must not change, bind the key (EGW-L0-03; MAN-14).",
"Bind a value the code uses itself in the manifest's settings, a rotation taking effect at the environment's next deploy or promote, and at a restart_application where the running copy already carries the binding (MAN-14).",
"Where a clone or a re-creation must reproduce the application, put its upstreams, its realm's sign_in_methods, creation, entra, and apple members, and its push providers in the manifest's upstreams member, realm member, and push entry; configure_realm keeps the realm's other settings (EGW-L0-02; ACS-L0-07; PSH-L0-01).",
"Declare in the manifest's egress list each host the application's own process dials, as an exact lowercase hostname or a *.example.com family; an upstream reached through the gateway needs no entry, nor do the platform's own endpoints (MAN-09; EGW-L0-15; EGW-L0-17).",
"Use the runtime's global fetch, undici, or an SDK built on fetch for outbound calls; node:https, node-fetch, got, and ws need an explicit proxy agent built from HTTPS_PROXY (HST-L0-01).",
"Expose one server that honors PORT and nothing else for the harness's sake (HST-L0-05; PLD-L0-60).",
"Serve the exact path the manifest's health member names, conventionally /health, from the moment the server listens, answering 503 until the application is ready, never a 4xx, and then exactly 200, the gate passing on the first 200 within its bound (MAN-05; PLD-L0-63).",
"Expect the gate to end the deploy early where a run of probes answers one stable 4xx status from the application's own process, and read the section The health check of read_documentation's page /cloud/getting-started/deploy-an-application/ for the gate's figures (PLD-L0-63; PLD-L0-59).",
"For a new application that keeps its data in the database, run the turnzero-cloud command's scaffold line, which writes the smallest such service with its migration, health read, manifest, and tests, as step 1 of read_documentation's page /cloud/getting-started/build-a-database-backed-service/ gives it (PLD-L0-103; DBS-L0-06).",
"Note that a server with a database may wait to listen until its migrations finish, the one exception to rule 11's listen-time health path, because the gate reads a server not yet listening as starting and keeps waiting (DBS-L0-06; PLD-L0-63).",
"Where the manifest declares the database kind, have the health path perform one read over the connection and answer 503 while it fails, so the gate proves the injected setting reaches the database (DBS-L0-06; PLD-L0-63).",
"Where the manifest declares the database kind, run the application's tests over the Database package's test double, @turnzero/database/testing, before the first deploy, as read_documentation's page /cloud/guides/test-your-application-locally/ says, since it runs migrations and queries locally and spends no deploy of the day (DB-L0-06; PRC-L0-16).",
"End the response when request.signal aborts, the AbortSignal the harness attaches to each node:http request and aborts when its window ends; a handler that keeps running past the grace interval ends the process (HST-L0-03).",
"Run no timer, polling loop, detached promise, or child process past a response; work runs inside request and scheduled handlers alone (HST-L0-04).",
"Expect a declared schedule path to answer any caller but the platform's scheduler 404 scheduled_handler_only, which a request of your own may confirm, and prove a handler with run_schedule alone (HST-L0-06; SCH-L0-02).",
"Submit the manifest with submit_manifest before the first deploy and again after every change to it, because a deploy reads the recorded manifest and never the zip's copy (ADM-L0-07; PLD-L0-63).",
"Where the manifest declares the database kind, have the process entry read the client pool's maximum from APP_DATABASE_CONNECTION_LIMIT, which each deploy, promote, and restart injects, using 1 where it is absent (PLD-L0-63).",
"Where the manifest declares the database kind, set the client pool's maximum from that setting and never above it: the plan's connection_limit, the database connections each process holds open at once (DBS-L0-04).",
"Note that the role admits twice the connection_limit, the second half a deploy's overlap of the previous and the new container, so a pool of that size is refused nothing (DBS-L0-04).",
"Before the first deploy, run the application on your machine as skill:deploy:local-run and the section Run locally of read_documentation's page /cloud/getting-started/deploy-an-application/ say, and request the manifest's health path, which answers 503 while starting, never a 4xx, then exactly 200 (PLD-L0-63).",
"Build the application into a folder whose root holds package.json; the command zips that folder, and the platform runs npm install --omit=dev, where there is anything to install, then npm start (PLD-L0-63; PLD-L0-60; PLD-L0-94).",
"In Windows PowerShell, run each npm and npx command as the section Windows PowerShell of read_documentation's page /cloud/getting-started/prerequisites/ says, because the default execution policy there can block the scripts npm and npx run (PLD-L0-64).",
"Build no zip of your own inside the application's folder, because the command's zip would carry it (PLD-L0-94).",
"With a web client, put its files at client/index.html, client/app.js, and client/styles.css under that root, which the platform serves at /, /app.js, and /styles.css ahead of your routes, serve other files from your routes, and ship no client/ folder without one (PLD-L0-63; CQ-112).",
"Leave manifest.json in the zip the project's own copy, which no deploy runs under, the recorded manifest being the one submit_manifest took; the copy is optional, and one that differs draws manifest_notice, warning that the deploy runs under the recorded one (PLD-L0-63).",
"Call deploy with the application, naming no environment and neither artifact nor upload, and local_path only where you will run the line from another folder (PLD-L0-86; PLD-L0-96).",
"Run command, or command_windows on Windows, once and as given from the application's folder, on Node.js 24 or later, before its expires_at: it zips the folder, prepares the upload under its one-time code, uploads the zip, and starts the deploy (PLD-L0-86; PLD-L0-94).",
"Treat the line as a credential until its code ends: run only the line your own deploy call answered, and paste it into no file, message, or report, a feedback report included (PLD-L0-86; PLD-L0-94).",
"Let the command wait, usually four minutes and at most fifteen: it prints each step and the outcome, ending 0 for a deployed version, 1 for a failed one, 2 where it stopped before the outcome, and 3 where nothing started (PLD-L0-94; PLD-L0-86).",
"Where your shell tool bounds a command below that, set TURNZERO_DEPLOY_NO_WAIT in the shell so the command returns after the start, and read the deploy with the next call (PLD-L0-86).",
"For another deploy, or where the line is refused deploy_code_refused, call deploy again and run the fresh line, because a code is used once and each new call ends the last code (PLD-L0-86).",
"Where a deploy answer's previous_code names a started upload whose id no prepared: line of yours printed, roll back, rotate the application's secrets and its database credential, and report it (PLD-L0-86).",
"Make the next call as the answer names it, read_status with wait_seconds, where the command returned before the outcome or for the whole record: it holds its answer until the deploy ends and leads with a one-line summary (PLD-L0-86; MAPI-04).",
"Where the command prints a refused start, or read_status names a pending_upload, clear the refusal's cause and make the call its retry carries; where retry is null, fix the folder where its zip was refused and call deploy again for a fresh line (PLD-L0-86).",
"Where settled is false, call read_status with wait_seconds 45 again, and read a failed row's outcome, a failed build's last lines among them, before any retry (MAPI-04; PLD-L0-63).",
"Read the process's console with read_logs under source container, and the connection observer's records under source harness (LGS-L0-15; EGW-L0-17).",
"Once production reads deployed after a deploy, check it as the release skill says, requesting each changed route that reads on the production hostname and reading read_logs for its errors (PLD-L0-96; LGS-L0-15).",
"Where the builder wants each version tried before production, turn on the development environment with create_environment, before or after submit_manifest since the two calls work in either order, after which each deploy goes to development (PLD-L0-96; DBS-L0-01).",
"Before the promote, request each route the change touched on the development hostname the deploy answered and read read_logs for errors, fixing the code and deploying again on any failure (PLD-L0-43; LGS-L0-15).",
"Once development reads deployed and the builder agrees, promote the version with promote and wait_seconds, the release skill's act, reading it to its end the same way (PLD-L0-63; PLD-L0-43).",
"Only to run the application on your own machine, call submit_manifest again naming local_run: true, and run the line it answers as provisioning.command, or provisioning.command_windows on Windows, once as given, in the application's folder, before its expires_at (SEC-L0-19; SEC-L0-07).",
"Only to run the application on your own machine, where the answer carries provisioning.next and no provisioning.command, the submission named no local_run and minted nothing for a local run: submit again naming it (SEC-L0-07).",
"Only to run the application on your own machine, take the line only where the application reads a setting it writes: the deploy does not depend on it, composing the same settings from custody whether or not it ran (DBS-L0-02; SEC-L0-07).",
"Only to run the application on your own machine, note that the line re-mints the development credentials over the wire and writes them into the environment file, printing each as a count of characters, so no value enters your context (DBS-L0-02; SEC-L0-07).",
"Only to run the application on your own machine, for a re-run, submit the manifest again naming local_run: each line runs once, and a resubmission of the recorded manifest answers a fresh line and records nothing new (SEC-L0-19).",
"Only to run the application on your own machine, where the line is run again with development on, deploy the development environment again afterwards, since the re-run revokes its running credentials (DBS-L0-02; SEC-L0-07).",
"Where submit_feedback is listed, file a refusal you did not expect from a deploy, a promote, or a read, or a step that needs a capability the platform lacks, with submit_feedback before moving on, quoting the refusal's reference in the evidence member (CHI-L0-14).",
"Where you file a report, put no personal details in it: no names, email addresses, telephone numbers, or anything else that identifies a person (CHI-L0-14).",
"Where the manifest declares an invited or workforce audience, the deploy's check reaches the health path with nothing listed, and session_free_paths opens a path and all below it to everyone, as the section Choosing the health path of read_documentation's page /cloud/guides/author-the-manifest/ says (ADM-L0-05; MAN-10).",
"Where the project holds no application, start one with the turnzero-cloud command's scaffold line: with no template for a hello-world service, database-service where it keeps its data in the database, scheduled-job where it runs work on a schedule, as read_documentation's page /cloud/concepts/turnzero-cloud-command/ describes (PLD-L0-103).",
"Where your tool refuses to leave a server running in the background, check the health path in one foreground command, as the section Your tool refuses a background process or a file deletion of read_documentation's page /cloud/troubleshooting/setup/ shows (PLD-L0-63).",
"Where the outside API is an AI model and the application holds no provider key, use the AI Allowance package in place of a stored key, as skill:use-ai-allowance says (AIA-L0-01)."
],
"actions": [
"create_application",
"store_secret",
"declare_upstream",
"submit_manifest",
"read_plan_quotas",
"deploy",
"read_status",
"read_logs",
"create_environment",
"promote"
],
"short_path": {
"lead": "This is the short path for an application whose manifest declares no database or schedule and whose code calls no outside API that needs a key or other secret. Each step names the rules below it follows, and the other rules apply where your application needs what they cover. For a new application whose manifest declares the database kind, the path is the section Steps of read_documentation's page /cloud/getting-started/build-a-database-backed-service/, and for an application you already have, of /cloud/guides/add-a-database/; the rules of skill:deploy:database apply.",
"steps": [
"Ask the builder which plan the application starts on and create it on that plan (rule 1).",
"Start from the scaffold's service where the project holds no application (rule 54). Then write one server that honors PORT, serves the health path from the moment it listens, ends each response when request.signal aborts, and runs nothing past a response (rules 10, 11, 12, 17, and 18).",
"List each host the process dials in the manifest's egress member, call out through fetch, and submit the manifest with submit_manifest (rules 8, 9, and 20).",
"Run the server on your machine and request the manifest's health path, then build the application into a folder whose root holds package.json, with no zip of your own inside it (rules 24, 25, 26, 27, and 29).",
"Call deploy naming no environment, run the line it answers as command, or command_windows on Windows, once from that folder before its code expires, and let it wait (rules 30, 31, 32, 33, 34, 35, 36, 37, 38, and 39).",
"Request each changed route on the production hostname the deploy answered, read read_logs for errors, and fix the code and deploy again on any failure (rules 40 and 41)."
],
"scoped": [
{
"where": "the code calls an external API that needs a key or other secret",
"rules": [
2,
3,
4,
5,
56
],
"part": "stored-key"
},
{
"where": "the code reads a value it binds in the manifest's settings",
"rules": [
6
]
},
{
"where": "the manifest declares the database kind",
"rules": [
13,
14,
15,
16,
21,
22,
23
],
"part": "database"
},
{
"where": "the manifest declares a schedule",
"rules": [
19
]
},
{
"where": "the application has a web client",
"rules": [
28
]
},
{
"where": "the builder wants each version tried before production",
"rules": [
42,
43,
44
],
"part": "development"
},
{
"where": "you run the application on your own machine",
"rules": [
45,
46,
47,
48,
49,
50
],
"part": "local-run"
},
{
"where": "the manifest declares an invited or workforce audience",
"rules": [
53
]
},
{
"where": "your tool refuses to leave a server running in the background",
"rules": [
55
]
}
]
},
"page": "/cloud/getting-started/deploy-an-application/"
},
{
"name": "use-ai-allowance",
"summary": "Generate text under the plan's included AI allowance on a key the platform keeps, with no provider key of your own, and read what is left on every answer (AIA-L0-01; AIA-L0-02; AIA-L0-03). The call leaves through the platform-held upstream and draws no egress entry and no stored key; a call through your own declared upstream draws nothing from the allowance (AIA-L0-01; AIA-L0-05).",
"must": [
"Take the ai_allowance library entry as the add-library-entry skill says and declare it as file:lib/ai_allowance in package.json, since the package calls the platform's own route on a key the platform keeps (AIA-L0-01; AIA-L0-02).",
"Call generateText with a transport your application supplies, a prompt, and an optional JSON Schema, and read the allowance figures on every answer, used, quota, and resetsAt (AIA-01; AIA-02).",
"Read the plan's monthly units with read_plan_quotas before relying on the allowance, and the month's draw with read_usage, since the allowance is metered in token units per application per UTC month (AIA-L0-03).",
"Expect allowance_exhausted once the month's units are drawn and allowance_unavailable while the platform's key is not in place, each refused by name and never charged, and fall back to a declared upstream on your own key where the application must still answer (AIA-L0-04; AIA-03).",
"Run the application's tests over the package's test double at @turnzero/ai_allowance/testing, which needs no gateway, no key, and no provider (AIA-L0-06; AIA-06).",
"Declare no egress entry and store no provider key for the allowance, since the call leaves through the platform-held upstream and the gateway is provider-blind at its edge (AIA-L0-05)."
],
"actions": [
"list_library",
"read_library_entry",
"submit_manifest",
"read_plan_quotas",
"read_usage"
],
"short_path": {
"lead": "This is the short path for an application that needs an AI model's answer at runtime and holds no provider key. Each step names the rules it follows.",
"steps": [
"Take the package and declare it (rule 1).",
"Call generateText and read the allowance figures on each answer (rule 2).",
"Read the plan's monthly units and the month's draw, and handle allowance_exhausted with a fallback or a refusal of your own (rules 3 and 4).",
"Test over the package's double before the first deploy (rule 5)."
],
"scoped": []
},
"page": "/cloud/backend-packages/ai-allowance/"
},
{
"name": "mobile-backend",
"summary": "Build the backend of a mobile app whose client the developer's own tools build: the application runs with no web client, and each environment's realm signs the app's users in (CQ-112; ACS-L0-15). The steps run in order: the declaration on each environment's realm, the sign-in in a development build, the bearer, the version header, the versions read before a promote, and the push where the app notifies its users.\n\nThe declaration: `submit_manifest` with `{\"kind\": \"accounts\"}` in `services` gives each environment the application has a realm, production's alone on a new application (SVC-L0-10). `configure_realm` declares the app on it as a public client, `clients` carrying its `client_id` and its redirect URIs (ACS-L0-07; ACS-L0-15). On an application with one environment, the production realm carries both builds' redirect URIs (ACS-L0-15). With development turned on, the development realm carries the debug build's and the production realm the store build's. `read_realm` answers the declared clients, and no client holds a secret.\n\nThe sign-in: on one environment a debug build and a store build both name the production hostname, `<label>.ai.host`. With development turned on, a debug build names the development hostname, `<label>-dev.ai.host`. The app runs the authorization code flow with PKCE under S256 in the system browser sheet, the endpoints under `/__account/oauth/` on that hostname (ACS-L0-14). Expo Go's `exp://` redirect is outside the redirect rule, so the sign-in is tested in a development build with the app's own scheme. The token endpoint answers the session token, its hour, and a rotating refresh credential, and the app keeps one refresh in flight at a time.\n\nThe bearer: every backend call carries `Authorization: Bearer <token>`, which the serving router verifies as it verifies the session cookie (ACS-L0-06). An expired or ended bearer is refused 401 before the backend. The backend verifies the token through the Account package's verification client, with the router's `x-turnzero-cloud-session` header beside it. A user who signed in by work account alone has the address the tenant asserts, with `source` `tenant`, and `verified` true only where the app registration sends the `xms_edov` optional claim as true.\n\nThe version header: every call carries `x-turnzero-cloud-client: <client_id>/<version>` (SVC-L0-11). A version below the client's declared minimum is refused 426 `client_upgrade_required`, naming the minimum and the store link. Each answer names the serving deploy version in `x-turnzero-cloud-version`.\n\nThe versions before a promote: a promote, or a deploy to production on one environment, changes the backend every installed copy of the app calls. Declare the store build on the production realm, then read the versions in use on that realm with `read_realm` before that act (SVC-L0-11).\n\nThe push: declare `{\"kind\": \"push\"}` in `services`, store the Apple signing key and the Google service-account file with `store_secret`, and name them in `configure_push` on each environment (PSH-L0-01). After sign-in the app registers its device with `PUT /__account/devices/<installation id>` under the bearer (PSH-L0-02). The backend sends through the Push package's client under the platform credential, naming the users to reach (PSH-L0-03).",
"must": [
"Create the application with create_application and deploy its backend with no client/ folder where it has no web client; the router forwards every request to its own routes (CQ-112; PLD-L0-63).",
"Declare the accounts kind in the manifest's services and resubmit it with submit_manifest, so each environment holds a realm (SVC-L0-10; ACS-L0-07).",
"Declare the app with configure_realm, its client_id and redirect URIs, both builds on the production realm on one environment, and the debug build's on the development realm once development is turned on (ACS-L0-15).",
"Set a realm's sign_in_methods, creation, entra, and apple members in the manifest's realm member or with configure_realm, which refuses a field the manifest names; set its limits, session days, invitation days, and native clients, which differ by environment, with configure_realm alone (ACS-L0-07).",
"Where users sign in with work accounts, list the callbacks.entra address that configure_realm and read_realm answer, exactly as answered, as a web redirect URI of the tenant's app registration (ACS-L0-09).",
"Under a workforce audience, name entra in the realm member's sign_in_methods and give its entra member the audience's tenant in the same manifest, since the audience alone signs nobody in (ADM-L0-05; ACS-L0-09).",
"Point the debug build at the production hostname on one environment, and at the development hostname once development is turned on (ACS-L0-15).",
"Sign in from a development build through the authorization code flow with PKCE under S256, and never through Expo Go's exp:// redirect (ACS-L0-14; ACS-L0-15).",
"Keep the token and the refresh credential in the platform's secure store and run one refresh at a time, replacing both values with each refresh answer because the endpoint rotates the credential (ACS-L0-14).",
"Send the token as Authorization: Bearer on every backend call, and verify it with the Account package's client: built with the realm's keys and the x-turnzero-cloud-session header where a route needs the id alone, and without keys where it needs the user's addresses (ACS-L0-06).",
"Send x-turnzero-cloud-client with the client_id, a slash, and the app's version on every call, and show a 426 answer's update_url instead of retrying (SVC-L0-11).",
"Before a promote, or a deploy that reaches production, declare the store build on the production realm and read its versions in use with read_realm, raising the minimum or keeping the backend compatible (SVC-L0-11).",
"Where the app receives notifications, declare the push kind, name each provider's stored credential in configure_push per environment or in the manifest's push entry for all, register the device after sign-in, and send through the Push package's client (PSH-L0-01; PSH-L0-02; PSH-L0-03)."
],
"actions": [
"create_application",
"submit_manifest",
"configure_realm",
"read_realm",
"configure_push",
"deploy",
"promote"
],
"page": "/cloud/getting-started/build-a-mobile-app-backend/",
"short_path": {
"lead": "This is the short path for the backend of a mobile app whose users sign in through the platform's realm, with no work accounts and no push. Each step names the rules it follows.",
"steps": [
"Create the application and deploy its backend with no client folder (rule 1).",
"Declare the accounts kind in the manifest's services, resubmit it, and declare the app on the realm with configure_realm, its client_id and redirect URIs (rules 2, 3, and 4).",
"Sign in from a development build through the authorization code flow with PKCE under S256, and keep the token and the refresh credential in the platform's secure store (rules 8 and 9).",
"Send the token as Authorization: Bearer and the client header on every call (rules 10 and 11).",
"Before a promote, declare the store build on the production realm and read its versions in use with read_realm (rule 12)."
],
"scoped": [
{
"where": "users sign in with work accounts",
"rules": [
5,
6
]
},
{
"where": "the app receives notifications",
"rules": [
13
]
}
]
},
"reasoning_part": true
},
{
"name": "schedule",
"summary": "Declare an application's schedules, make them effective with a deploy, and observe them — recurring, time-driven invocation of the application's own handlers (SVC-L0-15; SCH-L0-07; SCH-L0-01 owns the entry's shape and bounds). On one environment the deploy to production makes them effective (PLD-L0-96); on two, the deploy for development and the promote for production do.\n\nDeclare: the manifest's `schedule` services entry carries `schedules`, each a `name` matching `^[a-z][a-z0-9_]*$` (so `hourly_heartbeat` passes and `hourly-heartbeat` is refused), a five-field `cron` in UTC at the minute grain, and an absolute `path` on the application's own server under neither reserved prefix. Before the first submission, read the plan's shortest interval (`schedule-minimum-interval`) and schedule count (`schedule-count-limit`) with `read_plan_quotas`. The `submit_manifest` call refuses by name a declaration below the plan's shortest interval (`schedule_interval_below_plan`) or past its count (`schedule_count_over_plan`) — the pricing registry's rows, served per plan — and converges standing declarations. A declaration fires only against a deploy or promote made at or after it, so deploy after every change to the entry, and, with two environments, promote once development reads deployed and the builder agrees. Until then `read_schedules` answers `deployed: false` with the reason, `no_deploy` or `awaiting_deploy`.\n\nAt submission, each of `submit_manifest`'s schedule rows names in `starts_with` the act its environment awaits, `the next deploy to development`, `the next promote to production`, or `the environment's resume` where it is halted, or reads `already running`, its `next_due` null until then (SCH-L0-07). On an application with one environment, production's rows await `the next deploy to production` instead. Each row also carries `window_seconds`, the schedule kind's window in seconds, which a run completes inside (SCH-L0-01; SCH-L0-05). The window is a platform setting, the same on every plan, so `read_plan_quotas` has no row for it.\n\nThe handler: an ordinary route the platform invokes through the serving router, calling the declared path with `POST` and an empty body (SCH-L0-02). The rest of what it receives and what it must do — the invocation headers, the closure of a declared path to every other caller, the window, no timers — are the `deploy` skill's scheduled-handler clauses (HST-L0-06; HST-L0-02). They are stated once there and not repeated here. The section Run scheduled work of read_documentation's page /cloud/guides/author-the-manifest/ describes on one page everything a handler receives and must do. The section A handler without the package of read_documentation's page /cloud/backend-packages/schedule/ shows the smallest handler on plain `node:http`, with no package.\n\nWhile idle: a due run wakes a stopped environment, a Free application after its idle stop among them, and the wake is spent inside the schedule kind's window (SCH-L0-07; SCH-L0-05). State: a handler keeps its state between runs in a JSON file in a declared storage area, or in the database where one is declared (OST-L0-02). The file is written with a conditional put, `If-Match` on the version read and `If-None-Match: *` for the first write, so a run never overwrites another run's write unseen. The section What an application must do of read_documentation's page /cloud/backend-packages/schedule/ shows a handler that reads and writes that file with plain `fetch`, no client package needed. Counters are write-only tallies read through `read_counters`, never state (LGS-L0-15).\n\nObserve: `read_schedules` answers each declaration's next due time, the run in flight, the last run, and the recent runs with outcome, status, and duration. The `run_schedule` call fires one now as a manual run, answered `running` and read back through `read_schedules` (refused `run_in_flight` while one runs, `schedule_not_deployed` where the environment holds no deploy or promote made at or after the declaration). With `wait_seconds` (1 to 45), it holds until the run ends and answers with `settled` and `waited_ms`. The `read_logs` call with `source: \"platform\"` carries one event per run outcome and `source: \"router\"` the `window_ended` rows naming the schedule kind. A plan change onto a plan whose rows the standing declarations violate is refused `plan_schedule_conflict` (ACB-L0-22).",
"must": [
"Declare each schedule in the manifest's schedule entry with a name matching ^[a-z][a-z0-9_]*$, a five-field UTC cron at the minute grain, and an absolute path on the application's own server (SCH-L0-01).",
"Read the plan's shortest interval, in minutes, and schedule count with read_plan_quotas before the first submission, and keep within both, or submit_manifest refuses by name (SCH-L0-01).",
"On an application with one environment, deploy after every change to the entry as the deploy skill says, and promote nothing, since the deploy reaches production (SCH-L0-07; PLD-L0-96).",
"After every change to the entry, deploy for development as the deploy skill says, and once development reads deployed and the builder agrees, promote with wait_seconds, since a declaration fires only against a deploy or promote made at or after it (SVC-L0-15; SCH-L0-07; MAPI-04).",
"Expect a due run to wake a stopped environment, a Free application after its idle stop among them, the wake spent inside the schedule kind's window, so leave the handler room inside it (SCH-L0-07; SCH-L0-05).",
"Keep what a handler carries between runs in a JSON file in a declared storage area, written with a conditional put, or in the database where one is declared, and never in counters, which are write-only tallies (OST-L0-02; LGS-L0-15).",
"Serve the declared path to POST with an empty body, write the handler idempotent per the x-turnzero-cloud-schedule-due instant, and complete it inside the schedule kind's window, as the section Run scheduled work of read_documentation's page /cloud/guides/author-the-manifest/ explains in full (SCH-L0-02; HST-L0-06; HST-L0-02).",
"Read runs through read_schedules and read_logs with source platform, a handler's own console output with source container, which also takes wait_seconds, and fire one now with run_schedule, whose wait_seconds holds its answer until the run ends (SVC-L0-15; SCH-L0-06; MAPI-04; PLD-L0-62)."
],
"actions": [
"submit_manifest",
"deploy",
"promote",
"read_schedules",
"run_schedule",
"read_logs"
],
"page": "/cloud/backend-packages/schedule/",
"short_path": {
"lead": "This is the short path for adding a scheduled handler to an application that already deploys. Each step names the rules it follows.",
"steps": [
"Read the plan's shortest interval and schedule count with read_plan_quotas, then declare each schedule in the manifest's schedule entry, a name, a five-field UTC cron, and an absolute path, and submit the manifest (rules 1 and 2).",
"Serve the declared path to POST with an empty body, check the x-turnzero-cloud-schedule-due header, make the handler safe to repeat, and keep what it carries between runs in a declared storage area or the database (rules 6 and 7).",
"Deploy as the deploy skill's step 5 says; with two environments, promote once development reads deployed and the builder agrees, since a declaration fires only against a deploy or promote made at or after it (rules 3 and 4).",
"Read the runs with read_schedules and read_logs with source platform, fire one now with run_schedule, and leave the handler room inside the window, since a due run may first wake a stopped environment (rules 5 and 8)."
],
"scoped": []
},
"reasoning_part": true
},
{
"name": "manifest-author",
"summary": "Author or change an application's run-layer manifest against the served schema (ADM-L0-07). The schema's `egress` description explains the host-family grammar, observe and enforce modes, CONNECT tunnels restricted to port 443 without TLS inspection, recorded refusals and remedies, and platform endpoints that need no entry (MAN-09; ADM-L0-03; EGW-L0-12; EGW-L0-17).",
"must": [
"Write the manifest against the served schema and submit it with submit_manifest; a refusal names the member at fault (ADM-L0-07).",
"Declare in the egress member each host the application's own process dials, an upstream reached through the gateway and the platform's own endpoints needing no entry, and declare every managed service the application uses (MAN-09; EGW-L0-15; ADM-L0-03).",
"Under an invited or workforce audience, list in session_free_paths only the paths a provider calls without a signed-in user, such as a payment webhook, and have each such route check the provider's signature (MAN-10; ADM-L0-05).",
"Declare in the upstreams member each upstream the application calls on a stored key, so a re-creation or a clone needs store_secret alone; a change to a declared upstream is made there, never through declare_upstream (EGW-L0-02).",
"To end an upstream, remove its entry from the upstreams member and submit the manifest, deploy and promote the version that no longer calls it, then call undeclare_upstream, since no submission ends an upstream (EGW-L0-01; EGW-L0-02)."
],
"actions": [
"submit_manifest",
"undeclare_upstream"
],
"page": "/cloud/guides/author-the-manifest/",
"short_path": {
"lead": "This is the short path for writing or changing a manifest. Each step names the rules it follows.",
"steps": [
"Read the schema with read_context manifest_schema and write the manifest against it (rule 1).",
"Declare every managed service, each host the process dials in egress, and each upstream called on a stored key in upstreams (rules 2 and 4).",
"Submit with submit_manifest, whose refusal names the member at fault; to end an upstream, remove its entry, deploy and promote, then call undeclare_upstream (rules 1 and 5)."
],
"scoped": [
{
"where": "the audience is invited or workforce",
"rules": [
3
]
}
]
}
},
{
"name": "add-service",
"summary": "Add a managed service to an application by declaring it in the manifest (SVC-L0-06). A database declaration provisions the development database and its owner role at the submission. Its credential is never answered to this tool, whose answer states credentials: withheld. Only for a local run, a resubmission naming local_run answers, as provisioning, the one line that re-mints the development credentials on the developer's machine and writes the environment file (DBS-L0-02; SEC-L0-07; SEC-L0-19).",
"must": [
"Declare the service in the manifest and resubmit it; the platform provisions what the kind needs, which for object_storage is nothing, and injects any settings it adds at the next deploy (SVC-L0-06).",
"Where the manifest declares the database kind, follow the section Steps of read_documentation's page /cloud/guides/add-a-database/ for an application you already have, or of /cloud/getting-started/build-a-database-backed-service/ for a new one (DBS-L0-06).",
"Note first that the local run's line serves a local run of the application alone, and the deploy does not depend on it, composing the same settings from custody whether or not it ran (DBS-L0-02; SEC-L0-07).",
"Where the resubmission provisioned a development database, the answer states credentials: withheld: only to run the application on your own machine, submit again naming local_run: true (DBS-L0-02; SEC-L0-07).",
"Then run the line that answer carries as provisioning.command, or provisioning.command_windows on Windows, once as given, so the development credentials it re-mints are written into the environment file and never into your context (SEC-L0-19).",
"Where you ran the line with development turned on, deploy development again afterwards, since the run revokes the credentials its running copy holds (DBS-L0-02; SEC-L0-07).",
"Where the manifest declares the database kind, have the process entry read the client pool's maximum from APP_DATABASE_CONNECTION_LIMIT, which each deploy, promote, and restart injects, using 1 where it is absent (PLD-L0-63).",
"Where the manifest declares the database kind, set the client pool's maximum from that setting and never above it: the plan's connection_limit, the database connections each process holds open at once (DBS-L0-04).",
"Note that the role admits twice the connection_limit, the second half a deploy's overlap of the previous and the new container, so a pool of that size is refused nothing (DBS-L0-04).",
"Where the manifest declares the database kind, run the application's tests over the Database package's test double, @turnzero/database/testing, before the first deploy, as read_documentation's page /cloud/guides/test-your-application-locally/ says, since it runs migrations and queries locally and spends no deploy of the day (DB-L0-06; PRC-L0-16).",
"Where the manifest declares the object_storage kind, which provisions nothing, follow the section A minimal upload service of read_documentation's page /cloud/guides/store-files/, which joins the entry, the area's declaration, the package's install, and the transport in one service (SVC-L0-06; OST-L0-01)."
],
"actions": [
"submit_manifest"
],
"page": "/cloud/guides/add-a-database/",
"short_path": {
"lead": "This is the short path for adding a database to an application. For storage, follow the section rule 11 names instead. Each step names the rules it follows.",
"steps": [
"Declare {\"kind\": \"database\"} in the manifest's services and resubmit it; the platform provisions the development database and injects its settings at the next deploy, and the answer withholds the credentials (rules 1 and 4).",
"Follow the section Steps of the page rule 2 names for the migrations and the client, and read the pool's maximum from APP_DATABASE_CONNECTION_LIMIT (rules 2, 7, 8, and 9).",
"Run the tests over the Database package's test double before the first deploy (rule 10).",
"Only to run the application on your own machine, submit again with local_run true, run the one line it answers once, and deploy development again where it is on (rules 3, 5, and 6)."
],
"scoped": [
{
"where": "the manifest declares the object_storage kind",
"rules": [
11
]
}
]
}
},
{
"name": "diagnose",
"summary": "Read status, logs, counters, and version history to find what is wrong (CHI-L0-09). purge_logs erases the application's own records ahead of retention — one environment's, or every environment's — under the approval flow (LGS-L0-19).",
"must": [
"Read read_status first for the application's state, version, plan, and connection limit, then read_logs by source and read_counters (CHI-L0-09).",
"Compare list_versions before rolling back; purge_logs erases records ahead of retention and completes only through the approval flow (LGS-L0-19)."
],
"actions": [
"read_status",
"read_logs",
"read_counters",
"list_versions",
"purge_logs"
],
"page": "/cloud/guides/read-logs-and-counters/"
},
{
"name": "release",
"summary": "Promote the development version to production, and roll back on the builder's word (CHI-L0-07; CHI-L0-09).",
"must": [
"On an application with one environment, skip the promote, since its deploy already reaches production, and start at the check of production (PLD-L0-96).",
"Promote the development version to production with promote and wait_seconds, which holds its answer until the promote ends, up to 45 seconds, since production receives versions through promote alone (CHI-L0-07; MAPI-04).",
"Where settled is false, make the next call it names, read_status with wait_seconds 45 (MAPI-04).",
"Once production reads deployed, request each changed route that reads on the production hostname, and a changed route that writes only where the builder names a request safe for production's data; any GET with side effects, or any route you cannot place, writes (PLD-L0-43).",
"Read read_logs with source container (LGS-L0-15) for production's errors right after the requests, and once more about a minute later where its detail says lines may still be in the ingestion, which takes up to about a minute (PLD-L0-59).",
"On a failure, say whether the release applied a migration, then tell the builder and roll back with roll_back on their word, since a rollback moves code and never a migration's data (PLD-L0-57).",
"Roll back with roll_back and wait_seconds once the builder asks for it, naming the version list_versions shows, and read it to its end the same way (CHI-L0-09; MAPI-04).",
"Read harness_current on list_versions before promoting: a promote carries the deploy's image and its harness, so a version whose harness is not current stays so in production; a new deploy takes the current harness (PLD-L0-63).",
"Where submit_feedback is listed, file a refusal you did not expect from a deploy, a promote, or a read, or a step that needs a capability the platform lacks, with submit_feedback before moving on, quoting the refusal's reference in the evidence member (CHI-L0-14).",
"Where you file a report, put no personal details in it: no names, email addresses, telephone numbers, or anything else that identifies a person (CHI-L0-14).",
"Where you request a route in Windows PowerShell, use curl.exe, as the section Windows PowerShell of read_documentation's page /cloud/getting-started/prerequisites/ says, because Invoke-WebRequest there throws on an error status and lacks the switch that returns it (PLD-L0-43; PLD-L0-64)."
],
"actions": [
"promote",
"roll_back",
"list_versions",
"read_status",
"read_logs"
],
"page": "/cloud/guides/manage-versions-and-environments/",
"short_path": {
"lead": "This is the short path for promoting a version that development already serves. Each step names the rules it follows.",
"steps": [
"Read list_versions and its harness_current before promoting (rule 8).",
"Call promote with wait_seconds; where settled is false, call read_status with wait_seconds 45 until production reads deployed (rules 2 and 3).",
"Request each changed route that reads on the production hostname, and read read_logs with source container right after and about a minute later (rules 4 and 5).",
"On a failure, say whether the release applied a migration, and roll back with roll_back on the builder's word, naming the version list_versions shows (rules 6 and 7)."
],
"scoped": [
{
"where": "the application has one environment",
"rules": [
1
]
},
{
"where": "submit_feedback is listed and a refusal or a missing capability is met",
"rules": [
9,
10
]
},
{
"where": "you request a route in Windows PowerShell",
"rules": [
11
]
}
]
}
},
{
"name": "move-existing-app",
"summary": "Bring an existing application onto Turn Zero Cloud: ask the builder which plan it starts on (`free`, `standard`, or `pro`), create it on that plan, declare, store its keys behind declared upstreams or bound settings, deploy (CHI-L0-07; CHI-L0-08; EGW-L0-03; MAN-14).",
"must": [
"Ask the builder which plan the application starts on and create it on that plan (CHI-L0-07).",
"Declare the manifest, and store every key by calling store_secret with no value and running the command it answers, command_windows on Windows, never passing the value as a tool argument (CHI-L0-08; SCRT-L0-01).",
"Declare each API the code calls on a key with declare_upstream where its client can send its requests through a base URL, naming in its settings the base-URL and bearer settings, so the SDK reaches it through the gateway unchanged (EGW-L0-03; EGW-L0-01).",
"Bind any other stored value the code reads from its environment in the manifest's settings, never an upstream's key, knowing the value then enters the container (MAN-14).",
"Deploy the built artifact as the deploy skill says: call deploy, run the line it answers once from the application's folder, then read_status with wait_seconds where that line returned before the outcome (PLD-L0-86; PLD-L0-94; MAPI-04).",
"Put the application's upstreams, its realm's sign_in_methods, creation, entra, and apple members, and its push providers in the manifest's upstreams member, realm member, and push entry in place of their declaring calls; configure_realm keeps the realm's other settings (EGW-L0-02; ACS-L0-07; PSH-L0-01)."
],
"actions": [
"create_application",
"submit_manifest",
"store_secret",
"declare_upstream",
"deploy"
],
"page": "/cloud/getting-started/deploy-an-application/",
"short_path": {
"lead": "This is the short path for bringing an application that already runs elsewhere. Each step names the rules it follows.",
"steps": [
"Ask the builder which plan it starts on and create it on that plan (rule 1).",
"Write the manifest with its upstreams, realm, and push entries, and store every key with store_secret and the command it answers (rules 2 and 6).",
"Reach each API the code calls on a key through declare_upstream's gateway, binding in the manifest's settings only a value the code reads itself (rules 3 and 4).",
"Deploy the built artifact as the deploy skill says, and read read_status with wait_seconds where the line returned before the outcome (rule 5)."
],
"scoped": []
}
},
{
"name": "develop-then-promote",
"summary": "Work in the development environment beside production and promote between them (PLD-L0-40).",
"must": [
"Where the application has one environment, turn the development environment on with create_environment first (PLD-L0-96).",
"Deploy to the development environment beside production, and promote a version between them with promote (PLD-L0-40).",
"Read list_versions to learn which version serves each environment (PLD-L0-40)."
],
"actions": [
"create_environment",
"deploy",
"promote",
"list_versions"
],
"page": "/cloud/getting-started/deploy-an-application/",
"short_path": {
"lead": "This is the short path for trying each version on development before production. Each step names the rules it follows.",
"steps": [
"Turn development on with create_environment where the application has one environment (rule 1).",
"Deploy to development as the deploy skill says, then promote with promote as the release skill says (rule 2).",
"Read list_versions to see which version each environment serves (rule 3)."
],
"scoped": []
}
},
{
"name": "cost-review",
"summary": "Review an application's plan and its usage against the plan's served quantities, and move the plan (CHI-L0-09). The read_usage call answers each measure's reading, its state, and its quantity with the live count since the reading beside it, and `month_total`, the month's figure to compare with the quantity. The set_plan call moves the application between Free, Standard, and Pro under the one-Free rule. The billing reads arrive with the billing surfaces (CHI-L0-11, dormant until C5).",
"must": [
"Read read_usage for each measure's reading, state, and quantity before moving the plan (CHI-L0-09).",
"Move the plan with set_plan under the one-Free rule; the plan's served quantities follow (CHI-L0-09)."
],
"actions": [
"read_usage",
"set_plan"
],
"page": "/cloud/guides/plan-and-usage/"
},
{
"name": "add-library-entry",
"summary": "Add a library entry to this project: choose it from the inventory by its Selection summary, then take it with the line read_library_entry answers, which checks every file against its hash before it writes the entry into the library folder with its manifest row. The manifest records name, version, content hash, and the commit published from (Q-239).\n\nCall read_library_entry with the entry’s name alone. Run the line its answer carries as download.command, or download.command_windows on Windows, at the project’s root, the folder that holds system/ or system.json beside app/ or, on a first take, the folder a new system/ is made in; then do what download.next says. Where an answer carries no download, as on the HTTP route, write the line as read_documentation’s page /cloud/concepts/turnzero-cloud-command/ gives it; where download.next says no line takes the entry, the entry cannot be taken. The line is the turnzero-cloud command’s library take. It reads every listed file, checks each against its SHA-256 and the entry’s closure hash, and writes nothing where a check fails; it then writes the entry’s manifest row from the published catalog’s own values and replaces the entry’s folder whole (LC-05; LC-07).\n\nA package that carries runtime code arrives as an npm package inside the entry — its compiled modules under lib/ with their declarations and a package.json beside them — and carries no source and no tests (LC-01; Q-235). For such a package the line also copies its package.json and lib/ into app/lib/<name>/ on a first take, declares @turnzero/<name> as file:lib/<name> in app/package.json, and runs npm install. Commit what the line wrote, import the package by its npm name, and include the copy’s folder in the deploy artifact. The application installs no compiler (SPM-L0-49).\n\nEnd with the proof: where the project holds the Turn Zero Blueprint registrar, run the registrar’s validate with kind library, which rehashes the folder against its manifest and is the fetch’s proof (SPM-L0-49). Where it holds no registrar, call list_library with installed set to the manifest’s rows — each row’s name, version, and closure_hash as hash. Read each fetched entry’s standing: current is the proof, the recorded hash equal to the served closure hash. The standing newer means the publish moved between the take and the check — run the entry’s line again, which takes it whole and rewrites its row (LC-04).\n\nThe standing withdrawn means the served library no longer carries the entry, which the project keeps using from its copy. The standing not_held means the served library carries an entry the manifest does not name, compared with nothing and not an instruction to take it (LC-06). The kit-free reading compares the manifest’s hash with the served one and reads no vendored file, so a hand edit of a vendored file is found only by validate (LC-07): keep the folder read-only by rule (SPM-L0-49).\n\nThe instance file pins the version (FTR-L0-62). At each submission, the application manifest’s packages member is copied from the folder manifest’s rows, name and version, and never kept by hand beside them (MAN-13). The folder rule: the default home is the project’s own ./system/, and a system.json pointer file at the project root names a shared folder instead. An existing folder at the repository root above the project is used only when the pointer names it (SPM-L0-50).",
"must": [
"Choose the entry by its Selection summary through list_library, then call read_library_entry with its name alone (API-L0-14).",
"At the project's root, the folder that holds system/ or system.json beside app/ or, on a first take, the folder a new system/ is made in, run the line the entry answer carries as download.command, or download.command_windows on Windows, as given (LC-05; PLD-L0-94).",
"Leave the writes to the line: it checks every file against its SHA-256 and the closure hash, writes the entry's manifest row and folder, and for a package with compiled modules copies them into the application's folder and runs npm install (LC-05; LC-07; SPM-L0-49).",
"In Windows PowerShell, run each npm command as the section Windows PowerShell of read_documentation's page /cloud/getting-started/prerequisites/ says, because the default execution policy there blocks npm (PLD-L0-64).",
"Write no manifest row and copy no entry file by hand: where the line refuses, it writes nothing and says why, and running it again takes the entry whole (LC-07).",
"Where list_library names the entry library/prd and the project numbers under neither FTR nor PLAT, take it by name with the project's first entry (FTR-L0-106).",
"Note that library/prd holds the library's own requirements documents, which declare the FTR-L0 and PLAT statements the packages, these skills, and Turn Zero Blueprint's text cite, and that it carries no Selection summary and no version (FTR-L0-106).",
"Note that holding library/prd reserves FTR and PLAT as document prefixes in the project, so a project that numbers under either leaves it untaken and reads those statements from the served library (FTR-L0-106).",
"Commit what the line wrote, the application's copy, its package.json, and its lockfile among it, import a package with compiled modules by its npm name, and include the copy's folder in the artifact: app/lib/, or lib/ where the project has no app/ (SPM-L0-49; Q-235).",
"Check the download: validate with kind library where the registrar is held, or list_library with installed set to the manifest's rows otherwise (SPM-L0-49).",
"Where validate names the row library/prd unaddressable, the installed registrar predates that entry: prove that row the second way (LC-07).",
"Keep the vendored folder read-only; a hand edit is found only by validate (LC-07).",
"At each submit_manifest, copy each folder manifest row's name and version into the application manifest's packages member; never keep that list by hand beside the folder manifest (MAN-13)."
],
"actions": [
"list_library",
"read_library_entry"
],
"page": "/cloud/guides/use-the-library/"
},
{
"name": "update-library",
"summary": "Take a newer version of an entry this project holds: compare what the project holds against what is served — each manifest row by its hash, through the installed comparison list_library makes (LC-06) — and ask once per entry.\n\nTake each accepted entry with the line read_library_entry answers as download.command, or download.command_windows on Windows, run as given at the project’s root. The line checks every file against its hash and replaces the entry folder whole with the served closure (LC-05). It rewrites the entry’s manifest row from the published catalog’s own values — name@version, the content hash, the commit published from, and when it was fetched (LC-07). Where the package carries compiled modules, the line also replaces the application’s copy of its package.json and lib/ and runs npm install (SPM-L0-49; Q-235). Run the package’s Lifecycle, Migration, and Removal section; where the project uses Turn Zero Blueprint, also move the package’s version pin through its registrar in the same change, and otherwise leave the pin (Q-239; FTR-L0-49). Copy each folder manifest row’s name and version into the application manifest’s packages member at the next submission (MAN-13).\n\nEnd with the proof: where the project holds the Turn Zero Blueprint registrar, run the registrar’s validate with kind library, which rehashes the folder against its manifest and is the take’s proof (SPM-L0-49). Where it holds no registrar, call list_library with installed set to the rewritten manifest’s rows — each row’s name, version, and closure_hash as hash. Read each taken entry’s standing: current is the proof. The standing newer means the publish moved during the take — run that entry’s line again, which takes it whole and rewrites its row (LC-04).\n\nThe standing withdrawn means the served library no longer carries the entry, which the project keeps using from its copy. The standing not_held means the served library carries an entry the project never took, which the take leaves alone (LC-06). The kit-free reading compares the manifest’s hash with the served one and reads no vendored file, so a hand edit of a vendored file is found only by validate (LC-07): keep the folder read-only by rule (SPM-L0-49).\n\nThe folder rule: the default home is the project’s own ./system/, and a system.json pointer file at the project root names a shared folder instead. An existing folder at the repository root above the project is used only when the pointer names it (SPM-L0-50).",
"must": [
"Compare each held entry's hash against the served one through the installed comparison list_library makes, and ask once per entry before taking it (LC-04; LC-06).",
"Take each accepted entry by calling read_library_entry with its name alone and running the line the answer carries as download.command, or download.command_windows on Windows, as given at the project's root (LC-05; PLD-L0-94).",
"Leave the writes to the line: it checks every file against its hash, rewrites the manifest row, replaces the entry folder whole, and where the package carries compiled modules replaces the application's copy and runs npm install (LC-05; LC-07; SPM-L0-49).",
"In Windows PowerShell, run each npm command as the section Windows PowerShell of read_documentation's page /cloud/getting-started/prerequisites/ says, because the default execution policy there blocks npm (PLD-L0-64).",
"Retake the entry library/prd only where you want its newer text: it has no Lifecycle section, no pin, and no instance file, so its take is the line alone, and it reads newer at most publications (FTR-L0-106).",
"Read the Lifecycle, Migration, and Removal section's entries above the version you hold and nothing below (FTR-L0-49).",
"Run the package's Lifecycle, Migration, and Removal section; where the project uses Turn Zero Blueprint, also move the package's version pin through its registrar in the same change, and otherwise leave the pin (FTR-L0-49).",
"In every take, copy each folder manifest row's name and version into the application manifest's packages member at the next submission (SPM-L0-49; MAN-13).",
"Prove the take: validate with kind library where the registrar is held, or list_library with installed otherwise (SPM-L0-49)."
],
"actions": [
"list_library",
"read_library_entry"
],
"page": "/cloud/guides/use-the-library/"
}
]
}