@astrale-domains/services 0.4.9 → 0.5.0

package/README.md

@@ -1,767 +1,186 @@
 # Services
 
-`services.astrale.ai` owns provider-backed compute resources. It keeps provider
-protocols behind neutral SDK Integrations and stores only admitted lifecycle evidence in the graph.
+`services.astrale.ai` hosts Services: provider-backed compute an Identity owns. A Service is the
+stable identity of one origin in one environment. Every deploy adds an immutable deployment of it,
+and the Service's URL serves the one it currently points at, like a project and its deployments.
+Provider protocols stay behind a neutral SDK Integration, and the graph keeps only admitted
+lifecycle evidence.
 
 ## Model
 
-- `Service` records one opaque provider name, its owner-scoped stable `serviceKey`, deployment mode,
-  URL, lifecycle, provider digest, operation receipt, and exact cleanup locators.
-- `service_owned_by` connects each Service to its owning Identity and governs graph visibility.
-- Owners may be Shell users, local Kernel roots, or application/CI identities. Services requires only
-  the Kernel Schema; a Shell installation is not required to deploy. Ownership
-  remains exact-subject scoped, and existing Shell-user ownership edges remain valid.
-- a `DeploymentLine` is one `(origin, environment)`, named by its SDK fingerprint. `line_owned_by`
-  gives it to at most one organisation Identity, first come. Members and CI identities read the
-  line and its deployments through Kernel `extends_with` (`OwnLine`, `OwnDeployment`). A line is
-  never reassigned. Deleting its deployments, the organisation's Services or the organisation
-  itself leaves the line refused to every other organisation (`line-owned-elsewhere`). Only an
-  operator transfer moves the holder Edge.
-- the line Queries, `admitDeploymentLine` and the deployment Mutations run under the Services
-  Domain credential and trust the organisation they are given. Under a caller's credential the
-  Policies hide a foreign line, which would read as a free one. Their caller must first prove that
-  the requesting identity is that organisation or acts for it: `Identity.can` on `OwnLine` for a
-  held line, the identity itself or its `extends_with` for a registration.
-- each `Deployment` (`CloudflareDeployment`) sits on one line through `deployment_on_line` and is
-  visible to whoever holds that line. A deployment is recorded only while its organisation holds
-  the line. Its label must name the line, and its record must name the line's origin and
-  environment. [Real-Kernel proof](tests/kernel/README.md).
-- an operator deleting an organisation that holds lines deletes its `line_owned_by` Edges in the
-  same Mutation: the Kernel deletes a Node only together with every incident Edge. Its lines stay
-  registered with no holder and are refused to every organisation. A transfer is a root
-  `createEdge` of `line_owned_by` from the line to the new organisation; a line has one holder at
-  most ([Transfer a line](#transfer-a-line)).
-- secret values stay write-only at Cloudflare and never enter Astrale mutations or graph state.
-- schedules remain provider state; only the owner may read or replace them.
-- logs are remote evidence admitted by the Cloudflare Provider before a Workflow returns them.
-- the only admitted Worker service binding is the logical platform router; the provider resolves
-  it to the selected environment and callers cannot name arbitrary same-account Workers.
-- tenant Workers do not receive namespace dispatch authority. Inter-Service requests use public
-  ingress, including its retirement and private-route checks. Only the platform dispatcher and
-  candidate-readiness operator retain their respective native dispatch bindings.
-- the provider supplies `WORKER_URL` as the Service's canonical HTTPS URL to both candidate and
-  public Workers. It is reserved provider metadata, not a caller variable or secret. Applications
-  therefore keep one issuer even when requests arrive over HTTP or through a dispatcher alias.
-- `ASTRALE_BUILD_DIGEST` is reserved the same way: a Worker's build digest is bound by its host,
-  never by its author, so Services refuses it as a caller variable or secret on every deployment
-  path and in secret management.
-
-## Immutable deployments
-
-The Admin-hosted Services runtime hosts publishers' releases as immutable deployments, one per
-label, on the publisher's line. Three static `CloudflareDeployment` Methods serve them, and two
-instance Methods rotate one deployment's secrets; any authenticated identity of the Admin instance
-may call them. A Domain Worker serves every Kernel that
-installs it, but deployments are hosted for the Admin instance's Kernel alone
-(`SERVICES_DEPLOYMENT_KERNEL`): its graph is the line registry, while the deployments namespace and
-the routing KV are shared. Any other Kernel finds hosting unavailable before anything is read.
-
-- `deploy` takes a `DeploymentRequestV1`: the release's origin, environment, addressing, label,
-  build digest, frozen configuration, record fields, Worker bundle and the environment's current
-  secrets. It is a non-durable Action, never a Workflow, so no Execution, step result or journal
-  entry holds its input. Before any read it recomputes the build digest and the label, admits the
-  record with the SDK, and refuses a service binding, a router other than the logical
-  `admin-router`, a reserved binding name, or secrets other than exactly the declared ones. Only
-  the platform organisation (`SERVICES_PLATFORM_OWNER`) deploys on readable lines.
-- `deploy` then observes the line under the Services Domain credential and proves, on the caller's
-  own session, that the caller acts for the organisation it names (`OwnLine` on a held line,
-  `ActForOrganization` for a new one) before any Mutation. A new label is created under a graph
-  lease. The provider uploads it create-only, with `ASTRALE_BUILD_DIGEST`, `ASTRALE_SETTINGS` (router
-  binding `ROUTER`), a signing key Services generates for this deployment alone, and the request's
-  secrets. It adopts a script only when resuming a deployment the graph already held from an earlier
-  attempt, and only when the script's tags name the same artifact, line and key and this Kernel's
-  installation; any other script under the label is another deployment's, refused
-  `deployment-conflict`, and its secrets are never written. It checks that the uploaded version
-  itself serves before it activates the label through the routing KV `record:<label>`. The graph then records the deployment active with its key id, script etag and
-  a keyed HMAC-SHA256 digest of its secrets; no value, private key or version id is stored.
-- the same release again is the same label: `deploy` answers `reused`. Its secrets are the
-  environment's current values: when they match the recorded digests it answers `unchanged` and
-  writes nothing; otherwise it rewrites the changed values in place on that deployment alone and
-  answers `updated` (same script, URL, issuer and key, no new release). Every other deployment of
-  the line keeps its own secrets.
-- `setSecret({ name, value })` and `secrets({})` are instance Methods of one `CloudflareDeployment`.
-  `setSecret` rewrites one secret in place on that deployment only, and only a name its frozen
-  configuration declares (`secret-undeclared` otherwise); there is no `deleteSecret`, since a bound
-  name is part of the release, and the signing key never rotates. `secrets` lists the names its
-  script binds, never a value. Like `deploy`, any authenticated identity may call them, because a
-  publisher holds no `can_use` on Services' Functions and an `authorized` Method requires it of
-  every non-Root caller: before anything is read, the Kernel answers `OwnDeployment` for the caller
-  on its own session, and any other caller finds no such deployment (`DEPLOYMENT_NOT_FOUND`). If the
-  Admin instance ever grants publishers `can_use` on these Methods, they become `authorized` with
-  the `OwnDeployment` Policy instead. Both are non-durable Actions, so no Execution, step result or
-  journal entry holds a value.
-- a `setSecret` refusal is `{ kind: 'rejected', reason, message, retryAfter? }`.
-  `service-unavailable` with `retryAfter` (the deployment is being created, another operation
-  holds it, or the provider failed) is retried then; without `retryAfter` the deployment cannot be
-  rotated in place (its creation failed, it is retiring or retired, or the script under its label is
-  not the recorded one, which is the operator's to inspect), and the message says what can.
-- an in-place rewrite, by `deploy` or `setSecret`, runs under the deployment's graph lease. It
-  compares the values with the keyed digests and writes only the changed ones; it first forgets the
-  digests of the names it writes and records the new digests only once every write succeeded, so a
-  recorded digest always names the value last written. A provider failure answers
-  `service-unavailable` with `retryAfter`, and a rerun, with any values, converges. The script is
-  first checked to be the recorded one (code hash, artifact tag, key tag, installation tag); a
-  rewrite never touches another script. Workers for Platforms keeps the script's name, code hash,
-  tags and bindings across a secret write and mints a new provider version, which serves the new
-  value a few seconds later (OPS-2 X1): propagation is eventually consistent, and nothing records a
-  version id.
-- `hosting` returns the routing domain and how the caller's lines read (readable for the platform
-  organisation, opaque otherwise). `list` returns the deployments of the lines the caller holds. It
-  reads the held lines under the Services Domain credential, narrowed in the Query to the origin
-  and environment asked for, and keeps the lines a batched `Identity.can(OwnLine)` grants the
-  caller: a caller-mode read sees none of the lines a caller holds through `extends_with`
-  ([kernel#1138](https://github.com/astrale-os/kernel/issues/1138), the removal trigger of this
-  filter). One listing reads at most 16,384 matching held lines and fails beyond, so a listing
-  without an origin is bounded by the platform's held lines. A deployment whose stored record or
-  configuration this Services SDK no longer admits, for instance after a stricter decoder, is
-  still listed, from the facts Services owns, with its record exactly as stored (typed as JSON for
-  that row): the listing never fails on it, and the consumer admits the record itself. Deploy,
-  retain, retire, `setSecret`, `secrets` and `expirePreviews` fail closed on such a deployment
-  with an undeclared internal error (5000) and write nothing; `lastCalls` answers from its facts.
-- deleting a Service, or an instance and its Services, never addresses a publisher's deployment.
-
-Only a runtime whose Environment vars set `SERVICES_DEPLOYMENT_HOST` (the deployments' routing
-domain) hosts deployments; every other runtime answers `hosting-unavailable`. Such a runtime refuses
-to boot without `SERVICES_DEPLOYMENT_KERNEL` (the Admin Kernel's issuer URL),
-`SERVICES_SECRET_DIGEST_KEY` (at least 32 UTF-8 bytes, kept for the life of the data plane: the
-recorded digests depend on it), the `SERVICE_DEPLOYMENTS` dispatch binding to the environment's
-deployments namespace, and `CLOUDFLARE_SCHEDULE_KV_ID`, the routing KV that activates a label, and
-refuses a `SERVICES_PLATFORM_OWNER` that is not an Identity id. Hosting is declared once, by the
-Environment's `vars` in `astrale.config.ts`: the same vars decide the `SERVICE_DEPLOYMENTS` binding,
-and the configuration refuses a secrets file that sets a hosting var. [Real-Kernel
-proof](tests/kernel/README.md).
-
-### Retention and retirement
-
-A deployment is a `preview` until the registry Domain marks it `published`; only a preview expires.
-Four more `CloudflareDeployment` Methods manage what stays served. Retirement, retention and
-revival name a deployment by its label, script etag, artifact tag and configuration digest, never
-by a provider version id.
-
-- `retire` is the instance Method of the line holder's emergency stop. Any authenticated identity
-  may call it, because a publisher holds no `can_use` on Services' Functions and an `authorized`
-  Method requires it of every non-Root caller: before anything is read, the Kernel answers
-  `OwnDeployment` for the caller on its own session, and any other caller finds no such deployment
-  (`DEPLOYMENT_NOT_FOUND`). If the Admin instance ever grants publishers `can_use` on it, it becomes
-  `authorized` with the `OwnDeployment` Policy instead. It withdraws the deployment for good in two
-  phases. The graph records it `retiring` first, so no deploy reuses it; the same Mutation evicts
-  the operation lease of any operation writing the script, such as an in-place rewrite of its
-  secrets, which then records nothing. Then the routing KV gets the tombstone
-  `retirement:<label>` = `withdrawn`. The dispatcher
-  answers a label with a tombstone `DEPLOYMENT_RETIRED` (`410`) and keeps serving its
-  `deployment.json` from `record:<label>`, which stays. The first call answers `retiring` with
-  `retryAfterMs`. A call 65 seconds after the tombstone, once the dispatcher's retirement probe
-  answers `DEPLOYMENT_RETIRED`, deletes the script and its signing key and answers `retired`. A
-  withdrawn label is never served again: deploying the same release is refused
-  `deployment-retired`.
-- `retain` marks one preview `published`. Only the registry Domain's principal calls it, acting as
-  itself; it is the installed, unfrozen Domain whose origin is `SERVICES_REGISTRY_ORIGIN`. Services
-  reads the caller's Domain node by id under its own credential, which is why it requires read on
-  the Kernel's `Domain` Class; nothing the caller presents decides it. An authenticated caller
-  carries Identity ids but no Domain origin, and read on `Identity` does not reach a Domain's node.
-  Every instance that installs this Services version grants that read, so Services can read the
-  origin and frozen flag of each Domain installed there; only the Admin instance's hosting runtime
-  uses it. The requirement goes once the Kernel gives a handler its caller's Domain origin. A line
-  holder, or an identity acting for the registry, is refused `DEPLOYMENT_REGISTRY_ONLY`. The mark
-  is monotonic and idempotent, and it never undoes a retirement in progress: a preview marked after
-  its expiry started still retires, and a redeploy of the same release revives it.
-- `lastCalls` returns the last call of up to 100 labels the caller holds (as the Kernel answers
-  `OwnDeployment` on the caller's session), or any labels for the registry; an unknown label and
-  another organisation's both answer `DEPLOYMENT_LABEL_NOT_FOUND`. It reads the data points the dispatcher writes per admitted call, through the Analytics
-  Engine SQL API, and the last call recorded in the graph. A label nobody called reads `null`. It
-  reads only the facts Services recorded, so it answers for a listed deployment whose stored
-  record this SDK no longer admits.
-- `expirePreviews` is the registry's pass. A preview expires 30 days after its activation (its
-  creation, or its revival) or its last call, whichever is later; every activation records its
-  instant, and a pass refuses an active preview without one rather than expire it on its creation. The pass is a plan unless the runtime sets
-  `SERVICES_PREVIEW_EXPIRY=enforce` and the caller passes `apply: true`: it answers the `planned`
-  labels and retires none. Applied, it retires them in two phases with the tombstone `expired` and
-  answers `retired` and `pending` labels; the next pass completes the pending ones. Either way it
-  records later calls, so each preview's `expiresAt` follows its traffic. `limit` bounds the
-  deployment writes of one pass (64 by default), and retirements come first.
-
-An expired label revives. When the same owner deploys the same release (same label, so same
-artifact and configuration) again, the deployment resumes from `retired`. It is uploaded
-create-only with a new signing key, and the activation republishes the same `record:<label>`
-before it removes the `expired` tombstone. An instance that pins the label is served the same
-release digest at the same URL. A `withdrawn` tombstone is never removed.
-
-`SERVICES_REGISTRY_ORIGIN` and `SERVICES_PREVIEW_EXPIRY` (`plan`, the default, or `enforce`) are
-Environment vars of a hosting runtime, refused in a secrets file and refused without
-`SERVICES_DEPLOYMENT_HOST`. Without a registry origin no caller is the registry, and `retain` and
-`expirePreviews` are refused. `admin` and the frozen `admin-beta` name `admin.astrale.ai` and keep
-expiry a plan.
-Reading last calls needs the API token's Account Analytics Read permission. `pnpm
-provider:deployment-audit` lists the deployments namespace read-only
-([operator](providers/cloudflare/operator/README.md)).
-
-The View, CLI, and agent consumers read the named Service Queries directly; there is intentionally
-no list Function wrapping `listServicesQuery`. Deployment, secrets, schedules, logs, and deletion
-are Workflows because they coordinate admitted caller intent with external effects. Receiver Methods
-are authorized by the ownership Policy before their Workflows begin. `service-hosting`
-is the provider-neutral compute Integration contract. Cloudflare is its first Provider.
-
-`Service` declares seven abstract management contracts. `CloudflareWorker` owns their executable
-Methods (`setSecret`, `deleteSecret`, `secrets`, `setSchedule`, `schedules`, `logs`, `migrateIngress`, `delete`) and
-applies `OwnService` to each one. Workflow addresses are `CloudflareWorker.*`; abstract `Service.*`
-keys are not executable. A future provider Class must supply its own concrete declarations and
-implementations. Properties and ownership relationships retain their inherited meaning.
-
-## Operating hosted deployments
-
-### Recorded choices
-
-The deployment model left four choices open (decisions D12, D13 and D16 of the deployment and
-versioning spec, and the rule for deployment secrets). Services implements them as follows.
-
-| Choice | Implemented here |
-| --- | --- |
-| How a line reads in a deployment URL | Only the platform organisation (`SERVICES_PLATFORM_OWNER`) registers or deploys readable lines, which read `<readable>-<fingerprint>`, such as `agencies-staging-svkrguuhpcvmxxas`. Every other line is its 16-character fingerprint alone, derived from the origin and environment, never a stored UUID. A line keeps the addressing it was registered with, whoever holds it later: a deploy with the other addressing is refused `address-mismatch`, and a readable deploy for any other organisation `invalid-deployment`. |
-| Which deployment runs a Domain's crons | None. A hosted deployment's frozen configuration has no trigger, a Workers for Platforms script cannot own one, and the dispatcher's minute fan-out reads only the `cron:` keys of Services, which no deployment has. The spec's recommendation, crons on the deployment of the version the author designates (by default the highest stable one), needs the registry and is not implemented by the foundation. |
-| Where deployments live | In the Admin instance's Services, on a line held by the publisher's organisation, outside every instance that installs them. Uninstalling a Domain, deleting an instance or deleting its Services never touches them. The organisation is an Identity of the Admin instance that the deploy request names; a request that names none deploys for the caller itself. |
-| Deployment secrets | A deploy binds the environment's current secrets to the new deployment only; every other deployment keeps its own. A secret rotates in place on one deployment, which keeps its script, URL, issuer and key: by `setSecret`, or by deploying the identical release again. The signing key never rotates. |
-
-### Rotate a deployment's secrets
-
-Rotating a secret never creates a deployment. Two calls write a new value in place on one
-deployment, and on no other:
-
-- deploying the identical release again (same build and configuration) with the new value in the
-  environment's secrets: it is the same label, `deploy` answers `reused`, and its `secrets.state` is
-  `updated` when a value changed;
-- `setSecret` on the deployment, for one name its frozen configuration declares.
-
-A deployment is called by the `id` that `list` returns. Every call below runs on the Admin instance
-(`--admin`, or `--admin=<bookmark>`), as an identity that acts for the organisation holding the line
-(`--as <identity>` when it is not the bookmark's default), with an `astrale` CLI whose `call` takes
-`--admin` and `-d @file`. Put `key=value` params before `--admin`.
-
-```sh
-astrale call /:services.astrale.ai:class.CloudflareDeployment:list \
-  origin=agencies.example.com environment=staging --admin --json
-```
-
-`list` answers `{ "deployments": [...] }` with each deployment's `id`, `label`, `url`, `state` and
-declared `record`.
-
-Never pass a secret value in argv, where `ps` and shell history keep it. Write the input to a file
-that only you can read (`umask 077`, then your editor), outside the repository:
+- **`Service` / `CloudflareService`**: one `(origin, environment)`. Its `name` is the opaque
+  16-character fingerprint the SDK derives from them (`deploymentLine({ addressing: 'opaque' })`);
+  it is unique among Services and is the DNS label of `url`, `https://<name>.<routing domain>`.
+  `state` is `active`, or `deleting` while its deletion retires its deployments.
+- **`service_owned_by`**: every Service has exactly one owner, an Identity: a user, a group or a
+  service account. It is chosen once, when the first deploy creates the Service, and changes only
+  by `transfer`.
+- **`Deployment` / `CloudflareDeployment`**: one immutable release of a Service: one build with
+  its frozen configuration, served by one Workers for Platforms script at its own URL,
+  `https://<label>.<routing domain>`, where `label` is `<name>-<content16>`. It never changes code:
+  a new release is a new deployment. Its lifecycle is `deploying` → `active` → `retiring` →
+  `retired`, or `failed`; a retired deployment is never served again.
+- **`deployment_of`**: the Service a deployment is a version of. A deployment has no owner of its
+  own: it belongs to whoever owns its Service.
+- **`current_deployment`**: the deployment the Service's URL serves and its crons run on. Promoting
+  another deployment moves this Edge; a rollback is the promotion of an older one.
+
+Secret values stay write-only at Cloudflare and never enter a Mutation or the graph. Schedules
+are provider state. Logs are read from the provider when asked.
+
+## Owner and authority
+
+One Policy decides everything: `OwnService`, the subject is the owner of the Service. The Kernel
+evaluates it over the caller and every Identity the caller reaches through `extends_with`, with
+deny-wins. Nothing is selected at check time: a caller in no group reaches its own Services, a
+caller in three groups also reaches the Services of each.
+
+- A deploy that creates a Service makes the caller its owner, or the `owner` it names when the
+  caller is or acts as that Identity (`ActAs`).
+- A service account deploys a Service when it owns it, or when it is a member of the group that
+  owns it (`Group.assignMember` writes the `extends_with` Edge). A member has every right on every
+  Service of the group, deletion included.
+- `OwnDeployment` gives a deployment to the owner of its Service.
+
+Every Method is `authenticated`: a deployer's identities on the Admin instance hold no `can_use` on
+Services' Functions, which an `authorized` Method requires of every non-Root caller. Each handler
+asks the Kernel `Identity.can` for the caller on its own session before it reads anything: a caller
+who does not own the Service finds none (`SERVICE_NOT_FOUND`, `DEPLOYMENT_NOT_FOUND`), and a deploy
+of another owner's Service is refused `service-owned-elsewhere`. The day the Admin instance grants
+deployers `can_use` on these Methods, they become `authorized` with the Policy and the handler
+checks go.
+
+`list` reads Services under the Services Domain credential and keeps those the Kernel answers
+`OwnService` for, in batches: a caller-mode read does not reach the Identity end of
+`service_owned_by` for an owner the caller reaches through `extends_with`
+([kernel#1138](https://github.com/astrale-os/kernel/issues/1138)).
+
+## Methods
+
+Call them on the Admin instance (`astrale call ... --admin`).
+
+| Method | On | What it does |
+| --- | --- | --- |
+| `deploy` | `CloudflareService` (static) | Hosts one release (`DeploymentRequestV1`) as a deployment of the Service of its origin and environment, creating the Service on its first deploy, and by default (`promote` absent or `true`) makes the Service serve it. |
+| `hosting` | `CloudflareService` (static) | The routing domain Services and deployments are addressed under; names are always opaque. |
+| `list` | `CloudflareService` (static) | The deployments of the Services the caller owns, narrowed to an origin and environment when given, each with `current`. |
+| `promote` | `CloudflareService` | Points the Service at one of its active deployments, named by its label. |
+| `transfer` | `CloudflareService` | Gives the Service to another owner the caller is or acts as. |
+| `setSecret`, `secrets` | `CloudflareService` | Rewrites one declared secret of the current deployment in place; lists the names it binds, never a value. |
+| `setSchedule`, `schedules` | `CloudflareService` | Replaces or reads the Service's UTC cron set; each cron fires on the current deployment. |
+| `logs` | `CloudflareService` | Recent logs of the current deployment, or of one deployment named by `label`. |
+| `delete` | `CloudflareService` | Stops routing the Service, retires every deployment of it, then deletes it and frees its name. |
+| `retire` | `CloudflareDeployment` | Withdraws one deployment for good. The current deployment is never retired alone. |
+
+## Deploying
+
+`astrale-domain deploy <environment>` with the Astrale adapter calls `CloudflareService.deploy`.
+`deploy` is a non-durable Action: its input holds the environment's secrets, and no Execution, step
+result or journal entry keeps them.
+
+1. Before any read it recomputes the label from the Service name, the build digest and the frozen
+   configuration, recomputes the build digest from the uploaded bytes, admits the record with the
+   SDK, and refuses a service binding, a dispatch namespace, a router other than the logical
+   `admin-router`, a reserved binding name, or secrets other than exactly the declared ones.
+2. It reads the Service of the fingerprint under the Services Domain credential and proves the
+   caller's authority on the caller's own session: `OwnService` on an existing Service, `ActAs` on
+   the owner it names for a new one.
+3. A new label is created under a graph lease. The provider uploads it create-only with
+   `ASTRALE_BUILD_DIGEST`, `ASTRALE_SETTINGS`, a signing key generated for this deployment alone,
+   and the request's secrets; checks that the uploaded version serves its readiness paths; then
+   activates it through the routing KV `record:<label>`. The graph records it active with its key
+   id, script etag and keyed HMAC-SHA256 digests of its secrets.
+4. The same release again is the same label: `deploy` answers `reused`. Its secrets are compared
+   with the recorded digests: `unchanged`, or rewritten in place on that deployment alone,
+   `updated`.
+5. When it promotes, `current_deployment` moves to the deployment, fenced on what the Service
+   served, and the routing KV `current:<name>` names its label. A routing write that failed is
+   answered `service-unavailable`; deploying or promoting again converges.
+
+`WORKER_URL` and `ASTRALE_BUILD_DIGEST` are bound by the host, never by the author: Services refuses
+them as caller variables or secrets.
+
+## Routing and crons
+
+The Services dispatcher serves one routing domain:
+
+- `https://<label>.<routing domain>` serves that deployment: `record:<label>` activates it, and
+  `retirement:<label>` answers `DEPLOYMENT_RETIRED` (`410`).
+- `https://<name>.<routing domain>` serves the deployment `current:<name>` names, through the same
+  path, so a retired deployment is never served through its Service either.
+- Every minute the dispatcher reads the `cron:<name>` keys and posts each due cron to the current
+  deployment of that Service, at `https://cron.internal/__scheduled`.
+
+## Secrets
+
+Services never keeps a value. A deploy binds the request's secrets to the new deployment only;
+every other deployment keeps its own. `setSecret` rewrites one name the current deployment's frozen
+configuration declares, in place, under the deployment's graph lease: it compares the keyed
+digests, writes only changed values, forgets the digests of the names it writes first and records
+the new ones once every write succeeded. The provider serves a new value a few seconds later. A
+new name, or removing one, is a new release; the signing key never rotates.
+
+Never pass a secret value in argv. Write the input to a file only you can read, outside the
+repository:
 
 ```json
 { "name": "API_TOKEN", "value": "<the new value>" }
 ```
 
 ```sh
-astrale call "@$ID::services.astrale.ai:class.CloudflareDeployment.method.setSecret" \
+astrale call "@$SERVICE::services.astrale.ai:class.CloudflareService.method.setSecret" \
   --admin -d @rotate.json --json
 ```
 
-or pipe it from your secret manager on stdin (`read-new-secret` stands for the command that prints
-only the new value):
+Put the new value in the environment's secrets as well: the next deploy binds the values it
+carries.
+
+## Rollback and retirement
 
 ```sh
-read-new-secret | jq -Rs '{ name: "API_TOKEN", value: rtrimstr("\n") }' \
-  | astrale call "@$ID::services.astrale.ai:class.CloudflareDeployment.method.setSecret" \
-      --admin -d - --json
+astrale call /:services.astrale.ai:class.CloudflareService:list \
+  origin=agencies.example.com environment=production --admin --json
+astrale call "@$SERVICE::services.astrale.ai:class.CloudflareService.method.promote" \
+  label=$PREVIOUS_LABEL --admin --json
 ```
 
-`secrets` lists the names a deployment binds, never a value:
+`retire` withdraws one deployment in two phases: the first call records it `retiring` and writes
+its tombstone, and a call after `retryAfterMs` (once every dispatcher reads the tombstone, about 65
+seconds) deletes its script and key and answers `retired`.
 
 ```sh
-astrale call "@$ID::services.astrale.ai:class.CloudflareDeployment.method.secrets" --admin --json
+astrale call "@$DEPLOYMENT::services.astrale.ai:class.CloudflareDeployment.method.retire" \
+  --admin --json
 ```
 
-A refusal is the call's value (`"kind": "rejected"`); the two errors fail the call.
-
-| Reply | Meaning | Then |
-| --- | --- | --- |
-| `{ "name": "API_TOKEN" }` | The value is written, or was already the one served. Propagation is eventually consistent: the provider serves a new value about 4 s later. | Nothing. Calls in those seconds may still see the old value. |
-| `secret-undeclared` | The deployment's frozen configuration binds no such name. Nothing was written. | A new name is a new release: declare it and deploy. |
-| `service-unavailable` with `retryAfter` | The deployment is being created, another operation holds it, or the provider failed. | The same call again after `retryAfter`. A rerun converges, whatever an interrupted one wrote. |
-| `service-unavailable` without `retryAfter` | The deployment cannot be rotated in place: its creation failed, it is retiring or retired, or the script under its label is not the recorded one. `message` says which. | Deploy the release again after a failed creation. A retired deployment serves nothing. Ask the Services operator about a script that is not the recorded one. |
-| `DEPLOYMENT_NOT_FOUND` | The caller neither holds the deployment's line nor acts for its holder. Nothing was read. | Call as an identity of the organisation holding the line. |
-| `DEPLOYMENT_HOSTING_UNAVAILABLE` | The call reached a Kernel other than the Admin instance's, or the Services runtime there hosts no deployments (its Environment sets no `SERVICES_DEPLOYMENT_HOST`). | Call with `--admin`. If the Admin instance still answers it, ask the Services operator. |
-
-### A leaked secret
-
-A deploy never rewrites another deployment's secrets, so a leaked value stays bound to every
-deployment that still serves it until each one is rotated:
-
-1. Put the new value everywhere a deploy reads the environment's secrets from: the secrets file the
-   environment's adapter names (its `secrets` option, such as `.env.staging`) and every CI secret
-   store that deploys the environment. From then on, until step 5, no deploy may run with the old
-   value: an identical redeploy with it would write it back in place (`secrets.state: updated`).
-2. Rotate every deployment of that origin and environment that serves, with the input file above.
-   `list` shows a deployment only once it has served: a deployment still being created, or whose
-   creation failed, is not listed. The block reads the list on each run, so run it again until
-   every reply is `{ "name": ... }`. A deployment already rotated answers the same without writing
-   anything, and one that answered `service-unavailable` with `retryAfter` takes the rotation on a
-   later run.
-
-   ```sh
-   for ID in $(astrale call /:services.astrale.ai:class.CloudflareDeployment:list \
-     origin=agencies.example.com environment=staging --admin --json \
-     | jq -r '.deployments[] | select(.state == "active") | .id'); do
-     astrale call "@$ID::services.astrale.ai:class.CloudflareDeployment.method.setSecret" \
-       --admin -d @rotate.json --json
-   done
-   ```
-
-   An identical redeploy rotates only the deployment of the current release; older ones need
-   `setSecret`. Only `active` deployments rotate in place: a retiring or retired one answers
-   `service-unavailable` without `retryAfter`, so revoking the value at its source (step 5) is what
-   covers it. A deployment still being created, or whose creation failed, is step 3's.
-3. Take over every creation that a deploy started before step 1: that deploy may have read the old
-   value. Its deployment stays `deploying`, or `failed`, until a deploy records it active, so `list`
-   does not show it and `setSecret` refuses it; yet it serves as soon as its deploy has published
-   its record. Lease expiry alone does not stop that deploy. Activation checks only that the
-   deployment still holds the lease the deploy took, so a deploy that stalls past its lease, which
-   ends 10 minutes after it started, can still activate the deployment with the old value until
-   another deploy takes it over.
-
-   Find these deployments on the Admin instance (`ADMIN_INSTANCE` is its instance bookmark, as in
-   [Transfer a line](#transfer-a-line)). The query answers the deployments of the lines you hold or
-   act for, those still being created included. Keep the `label` of each one whose `state` is
-   `deploying` or `failed` and whose `record` names this origin and environment. When the answer
-   has a `page.next`, the same query with `--cursor <page.next>` reads the next page.
-
-   ```sh
-   astrale query --class /:services.astrale.ai:class.CloudflareDeployment --limit 100 --json \
-     -i "$ADMIN_INSTANCE"
-   ```
-
-   For each label, deploy its release again, identical (the same build and configuration; with
-   adapter-astrale, `astrale-domain deploy <environment>` from the same source), now that the
-   secrets file holds the new value. Repeat until it answers `deployed` for that label:
-   - while the stalled deploy's lease runs, it answers `service-unavailable` with `retryAfter`, the
-     end of that lease: deploy again then;
-   - once the lease has expired, it takes the deployment over, so the stalled deploy can no longer
-     activate it, and creates it with the current secrets, rewriting them on any script the stalled
-     deploy left;
-   - after a failed creation it retries with the current secrets; once the stalled deploy has
-     activated the deployment, it reuses it and rewrites its secrets in place
-     (`secrets.state: updated`).
-
-   A release that does not rebuild identically has another label and takes nothing over: the
-   stalled deployment keeps the value its deploy wrote until step 5 revokes it. Then run step 2's
-   block once more.
-4. Deployments in the platform dispatch namespace have no Services node, and neither `list` nor the
-   query shows them. They are the platform Domains deployed through adapter-cloudflare's namespace
-   mode: Shell, the Services runtime, Issues, ai-gateway, closing, grc, integrations and ui, each
-   once it has moved there. Rotate each one in place with the platform namespace's tooling, with
-   its operator file sourced
-   ([operator README](./providers/cloudflare/operator/README.md#operating-platform-deployments)): one
-   label and one declared name per run, the value read on stdin from a file that holds only the new
-   value, outside the repository and readable only by you.
-
-   ```sh
-   pnpm provider:platform-secret -- --label <label> --name API_TOKEN < new-value
-   ```
-
-   Or deploy its identical release again. A platform deploy that started before step 1 may have
-   read the old value too: once it has returned, rotate the deployment it made or reused. Admin is
-   not one of them: it runs on its own bootstrap Worker, and its secrets rotate through that
-   Worker's own deploy tooling. The Services runtime is one of them once the Admin instance runs on
-   a deployment of [`admin`](#admin-hosted-runtime); its identical redeploy is
-   `pnpm run deploy admin`, with the new value in `.env.admin`. Until that move it is the frozen
-   `admin-beta` Worker: put the new value in `.env.admin-beta` (and the same in `.env.admin`, which
-   keeps its values) and deploy it again with `pnpm run deploy admin-beta`, from the commit it was
-   last deployed from so that only its secrets change.
-5. Revoke the leaked value where it was issued once step 2's block answered `{ "name": ... }` for
-   every deployment and every redeploy of step 3 answered `deployed`, or at once when the leak
-   outweighs the failures of deployments not rotated yet.
-6. Delete `rotate.json` and `new-value`.
-
-### Transfer a line
-
-A line belongs to the first organisation that deploys on it. No Services Method moves it: an
-operator transfers it as the Admin instance's root, with one Mutation on its `line_owned_by` Edge.
-Its deployments stay on the line and keep serving. From that Mutation on, the new holder lists,
-rotates and deploys them, and the previous holder and its members no longer see them.
-
-1. Find the line and its holder on the Admin instance (`ADMIN_INSTANCE` is its bookmark,
-   `ADMIN_ROOT` its root identity, `LINE` the line's id):
-
-   ```sh
-   astrale query --class /:services.astrale.ai:class.DeploymentLine --limit 100 --json \
-     -i "$ADMIN_INSTANCE" --as "$ADMIN_ROOT"
-   astrale query "@$LINE" --edge /:services.astrale.ai:class.line_owned_by \
-     --direction outgoing --json -i "$ADMIN_INSTANCE" --as "$ADMIN_ROOT"
-   ```
-
-   Pick the line whose `origin` and `environment` are the ones to transfer. The first query reads
-   one page: when its answer has a `page.next`, more lines exist, and the same query with
-   `--cursor <page.next>` reads the next page.
-
-2. Write the Mutation. A held line moves in one atomic Mutation that deletes the current holder's
-   Edge and creates the new one; if the current holder is not the one named, nothing moves:
-
-   ```json
-   {
-     "preconditions": [],
-     "operations": [
-       {
-         "op": "edge.delete",
-         "edge": {
-           "class": "services.astrale.ai:class.line_owned_by",
-           "source": "@<line-id>",
-           "target": "@<current-holder-id>"
-         }
-       },
-       {
-         "op": "edge.create",
-         "class": "services.astrale.ai:class.line_owned_by",
-         "source": "@<line-id>",
-         "target": "@<new-organization-id>",
-         "props": {}
-       }
-     ]
-   }
-   ```
-
-   A line without a holder, after its organisation was deleted, takes the `edge.create` operation
-   alone. The Kernel refuses a second holder, so that form never moves a held line.
-
-3. Check the document offline, then apply it:
-
-   ```sh
-   astrale mutate --file transfer.json --dry
-   astrale mutate --file transfer.json -i "$ADMIN_INSTANCE" --as "$ADMIN_ROOT"
-   ```
-
-A readable line stays readable: give it only to the platform organisation, since any other one is
-refused on it. Changing `SERVICES_PLATFORM_OWNER` therefore means transferring every readable line
-to the new platform organisation. Deleting an organisation that holds lines leaves them without a
-holder (see [Model](#model)): their deployments keep serving, and nobody can list, rotate or deploy
-them until they are transferred.
-
-### Orphans
-
-A hosted deployment belongs to its line, never to the instances that install it: deleting or
-retiring an instance leaves it alone, and the orphan audit and reclaim of the
-[operator README](./providers/cloudflare/operator/README.md) never select it. What can be left over:
-
-| Situation | What holds | Then |
-| --- | --- | --- |
-| A deploy interrupted before activation | The graph keeps the deployment `deploying` under its lease, or `failed`, and `list` does not show it. An uploaded script serves nothing until its deploy publishes its record; one interrupted after that serves while the graph still says `deploying` or `failed`. Until another deploy takes it over, the interrupted deploy can still activate it, even after its lease expired. | Deploy the same release again. It resumes on the same label, takes over an expired lease, and adopts the uploaded script only if its tags name the same artifact, line, key and Admin Kernel, rewriting its secrets with the environment's current ones. |
-| A line whose organisation was deleted | No organisation holds it; every deploy on it is refused `line-owned-elsewhere`. Its deployments keep serving, and nobody can rotate them. | Transfer the line. |
-| A script under a label that is not the recorded one | `deploy` answers `deployment-conflict` and `setSecret` `service-unavailable` without `retryAfter`; nothing is written to it. | The operator compares its `astrale-artifact:`, `astrale-line:`, `astrale-key:` and `astrale-install:` tags with the deployment's record and key. |
-
-## Shared public ingress
-
-New Services use the environment's proxied wildcard DNS, wildcard Worker route and wildcard
-certificate. Services observes the expected dispatcher route and probes a never-registered hostname
-before uploading a Worker without an existing Custom Domain. It never creates a per-Service Custom
-Domain or certificate. Missing shared ingress is an operator provisioning issue; it is not repaired
-by consuming another certificate during a Service deployment.
-
-After activating routing, deployment waits for public dispatcher visibility with a bounded budget.
-This is separate from optional candidate application health checks. An uncertain activation retains
-the Service record and can be retried with the same owner-scoped service key.
-
-Existing exact Custom Domains and their immutable certificate locators are retained on ordinary
-updates. Detaching old hostnames is a separate migration, coordinated with Service operations;
-upgrading this Runtime does not perform that migration. A Service without an exact domain persists
-`tenantDomainState: 'absent'`.
-Deletion handles both placements and never removes shared ingress infrastructure.
-
-Cloudflare callers that must traverse same-zone public Worker routes need
-`global_fetch_strictly_public`. Audit existing callers before migrating their exact hostnames;
-explicit runtime flags retain their authored meaning. A rollback after creating wildcard Services
-must use a Runtime that understands explicit absent placement, not an older certificate-required
-implementation.
-
-### Migrating existing Services
-
-The owner calls `CloudflareWorker.migrateIngress` with an `action` (`detach`, `complete`, or
-`restore`) and a deterministic public health `probe`: a local GET `path`, expected successful
-`status`, and the exact response body's SHA-256 in `bodySha256`. The Workflow acquires the existing
-Service operation lease and verifies provider ownership, active dispatch, wildcard TLS and health
-before detaching the exact Custom Domain. It does not redeploy the Worker or alter its routing KV,
-secrets or schedules.
-
-After `detach`, observe real traffic for at least 30 minutes before calling `complete`. Until
-completion, the graph retains the previous domain and certificate locators with
-`tenantDomainDetachedAt`; completion clears them after provider cleanup and another successful
-health check. Cloudflare can automatically delete the generated certificate as soon as its Custom
-Domain is detached. `restore` recreates the exact domain, waits for active TLS and records the actual
-replacement certificate locator. A `pending` result requires a later retry; it is not completion.
-
-The consumer runtimes are frozen ([`frozen-environments.json`](./frozen-environments.json)): the
-original R1 runtime at `https://services.beta.astrale.ai`, which 1Pact instances pin and which
-serves that issuer's discovery and keys, `https://services-v2.beta.astrale.ai`, which retains that
-issuer and key, and production at `https://services.astrale.ai`. They keep serving the code they run
-today and no Environment deploys them. Do not uninstall Services or replace a runtime underneath
-installations that still use its Schema. An instance rollback must restore any detached domain
-before reinstalling the original endpoint, and must first be qualified with real retained Service
-data.
+`delete` marks the Service `deleting`, removes `current:<name>` and `cron:<name>`, and retires every
+deployment. It answers `deleting` with `retryAfterMs` until the last one is retired, then deletes
+the Service with its deployments in one Mutation and answers `deleted`. The name is then free
+again.
 
 ## Admin-hosted runtime
 
-The Admin-hosted runtime is the Services runtime of the Admin instance, the one that hosts
-publishers' deployments outside the instances that install them. Only the Admin instance installs
-it; consumer instances keep the Services they pin. It runs on the beta data plane the Admin
-instance's Services already manage. Its plain vars name the router Worker
-(`ASTRALE_ROUTER_WORKER`), the routing domain under which hosted deployments are addressed
-(`SERVICES_DEPLOYMENT_HOST`, served by the Services dispatcher), the Admin instance's Kernel, the
-only one it hosts deployments for (`SERVICES_DEPLOYMENT_KERNEL`, `https://admin.eu.beta.astrale.ai/api`),
-and the registry Domain (`SERVICES_REGISTRY_ORIGIN`). These vars are the only declaration of
-hosting: they also bind `SERVICE_DEPLOYMENTS`. Its secrets file must set
-`SERVICES_SECRET_DIGEST_KEY`, the key of each hosted deployment's secret digest, and the dispatch
-namespace and routing KV the runtime boots with. The runtime keys HMAC-SHA256 with the UTF-8 bytes
-of the digest key as written, never base64-decoded, so the configuration refuses, before any
-deployment effect, a file without them, a digest key shorter than 32 UTF-8 bytes, or a file that
-sets a hosting var. `SERVICES_PLATFORM_OWNER` is not set yet: until it names the platform
-organisation's Identity id on the Admin instance, every line is opaque and a readable deploy is
-refused.
-
-Two Environments deploy it:
-
-- **`admin`**, the canonical one. Every `pnpm run deploy admin` makes one immutable deployment of
-  the release in the platform dispatch namespace (`astrale-platform`), on the readable line
-  `services-admin-6ze5tudscrzgbrbv`, at `https://<label>.platform.astrale.ai`. The deployment is
-  its own issuer, signs with a key generated for it, and binds its candidate namespace
-  (`SERVICE_CANDIDATES`) and the deployments namespace (`SERVICE_DEPLOYMENTS`) at its create-only
-  upload, both derived from `CLOUDFLARE_DISPATCH_NAMESPACE`. Nothing is ever replaced in place: a
-  new release is a new URL, which the Admin instance moves to by a consented install. Redeploying
-  the same release reuses its deployment and rewrites only that deployment's secrets in place. Its
-  secrets file is `.env.admin`.
-- **`admin-beta`**, frozen (`providers/cloudflare/operator/provision/legacy/admin-beta.ts`). It is
-  a Worker of its own, `services-domain-admin-beta` at `https://services-admin.beta.astrale.ai`,
-  that retains the issuer `https://services.beta.astrale.ai` and its signing key, as services-v2
-  does, so the Admin instance installs it without an issuer change (OPS-3). The cost: a Worker built
-  from main holds the key that 1Pact's installations trust. Keep the key only in managed secret
-  storage and in this Worker's `ASTRALE_SIGNING_IDENTITY` secret. It changes only for a same-Schema
-  fix the Admin instance needs before it moves; everything else goes to `admin`. It is deleted from
-  this repository by D19, once the Admin instance runs on `admin` and OPS-6 retired the Worker.
-
-### Set up the frozen admin-beta runtime (OPS-3)
-
-The operator sets it up once, from a commit of `main` that carries the Services CT16 adoption
-(`bindings.dispatchNamespaces` and `settings.durableOptions` in the deployment configuration, with
-the tenant refusal) and pins an SDK release that carries the CT16 extension (R6a' or later). An
-admin-beta built without that adoption refuses every deploy of an adapter-astrale that carries it
-with `1003 FUNCTION_INPUT_INVALID`, and the move to `admin` over the deployments such a runtime wrote
-is refused with `4001 DATA_MIGRATION_REQUIRED` (see [OPS-5](#move-the-admin-instance-to-admin-ops-5)).
-
-1. Read what the Admin instance's Services are bound to, read-only:
-   `astrale introspect services.astrale.ai -i <admin-instance> --json`. Record `revision` and
-   `publication.identity.issuer`, and the frozen runtime whose `/.well-known/astrale/domain.json`
-   declares that revision: it is the rollback URL. Go on only if the issuer is
-   `https://services.beta.astrale.ai`; any other issuer makes step 6 an issuer change, which this
-   runtime does not take (use the [move to `admin`](#move-the-admin-instance-to-admin-ops-5)
-   instead). Check as well that the Admin instance's Kernel issuer is the
-   `SERVICES_DEPLOYMENT_KERNEL` var; otherwise every deploy answers `hosting-unavailable`. Before
-   the first readable deploy, read the platform organisation's Identity id there and set it as the
-   `SERVICES_PLATFORM_OWNER` var in a reviewed change.
-2. Create `.env.admin-beta` (mode 600) from `.env.example` with the beta data-plane coordinates the
-   Admin instance's Services manage today (account, token, dispatch namespace, routing domain
-   `svc.eu.beta.astrale.ai`, schedule KV, dispatcher, zone, Admin target) and a new
-   `SERVICES_SECRET_DIGEST_KEY` that no other data plane uses, e.g. `openssl rand -base64 32` (32
-   random bytes, kept as their 44-character base64 text; the configuration refuses fewer than 32
-   UTF-8 bytes). It is generated once here, copied unchanged into `.env.admin` at OPS-5, and never
-   regenerated: the recorded secret digests of every hosted deployment depend on it.
-3. Restore the retained `https://services.beta.astrale.ai` signing identity, the one services-v2 was
-   deployed with, from managed secret storage to `.astrale/services-beta-identity.json` (mode 600).
-   Never generate a key for this runtime: the frozen R1 Worker publishes the issuer's keys, so a new
-   key would never verify. Check that the issuer publishes the restored key:
-
-   ```sh
-   node --input-type=module -e '
-   const { readFileSync } = await import("node:fs")
-   const { kid, x } = JSON.parse(readFileSync(".astrale/services-beta-identity.json", "utf8"))
-   const issuer = "https://services.beta.astrale.ai"
-   const { jwks_uri } = await (await fetch(`${issuer}/.well-known/openid-configuration`)).json()
-   const { keys } = await (await fetch(jwks_uri)).json()
-   if (!keys.some((key) => key.kid === kid && key.x === x)) throw new Error("key not published")
-   console.log(`issuer publishes kid ${kid}`)
-   '
-   ```
-
-4. Deploy once with `pnpm run deploy admin-beta`. It creates only the `services-domain-admin-beta`
-   Worker and its route; nothing is installed. Do not run `pnpm provider:bootstrap` or a
-   `provider:route-*` command for this runtime: on the beta data plane they redeploy the shared
-   dispatcher and DNS routing that serve 1Pact's tenants (see the
-   [operator README](./providers/cloudflare/operator/README.md)).
-5. Rehearse step 6 first on a disposable instance whose Host runs the Admin Host's Kernel release and
-   whose Services are bound to the same issuer and revision as in step 1, with at least one Service.
-   The install must succeed and the Service must stay manageable (list, secrets, logs). Then install
-   the step 1 rollback URL there again: if the Kernel refuses it, step 6 is one-way, and that must be
-   recorded before step 6 runs.
-6. Install on the Admin instance only:
-   `astrale domain install https://services-admin.beta.astrale.ai --allow-identity-override -i <admin-instance>`.
-   The only consent is the identity override, because the origin `services.astrale.ai` differs from
-   the serving host; the issuer does not change. On any refusal, stop: never uninstall Services on
-   the Admin instance to get around it, which would drop the Service records it holds. Never repoint
-   Admin's catalog entry for `services.astrale.ai` at this runtime: consumer flows, 1Pact's among
-   them, install Services by origin through that entry.
-
-### Move the Admin instance to admin (OPS-5)
-
-OPS-5 is the production operation that moves the Admin instance's Services off the frozen
-`admin-beta` Worker onto a deployment of `admin`. Before acting, write a compatibility record and
-know the rollback path. Afterwards, verify the Admin instance and add an entry to the operations
-log. 1Pact's instances and every consumer instance are out of scope: they keep the Services they
-pin, and nothing here touches them.
-
-Preconditions:
-
-1. The Admin instance installs `admin-beta` (OPS-3), built with the Services CT16 adoption; its
-   rollback URL is `https://services-admin.beta.astrale.ai`.
-2. The Admin instance's Host runs a Kernel that lists installed releases and takes issuer consent
-   (astrale-os/kernel#1124, in a released Host image, OPS-4). An older Kernel refuses
-   `--allow-issuer-change` before any install, so the move waits.
-3. The operator's `astrale` CLI is a release with install by URL (astrale-os/cli#582) and issuer
-   consent (astrale-os/cli#583).
-4. This package pins an SDK release whose adapter-cloudflare deploys namespace mode with dispatch
-   namespace bindings and durable options (astrale-os/sdk#599, on the CT16 extension of
-   astrale-os/sdk#587), and the publishers' adapter-astrale passes `dispatchNamespaces: []`
-   (astrale-os/sdk#598).
-5. The platform namespace is provisioned (`pnpm provider:platform-bootstrap`, OPS-1) and the deploy
-   token may manage scripts in it.
-
-Steps:
-
-0. **Schema.** A move, and a rollback, is a Schema upgrade: the Kernel checks the data the Admin
-   instance stores against the Schema of the URL it installs. Read the installed `revision`
-   (`astrale introspect services.astrale.ai -i <admin-instance> --json`, as recorded at OPS-3
-   step 1) and, after step 2, the deployment's `schema.revision` in `services-admin.json`. Equal
-   revisions are the same Schema. Different revisions make the move a Schema upgrade: list what
-   changed in `services/schema/` between the OPS-3 commit and this one, and let the rehearsal
-   (step 3) decide. When admin-beta and `admin` are built from commits whose Services Schema is
-   the same (both with the CT16 adoption), only the compiled form can differ.
-1. **Secrets.** Create `.env.admin` (mode 600) as a copy of `.env.admin-beta`. The values must be
-   the same, the `SERVICES_SECRET_DIGEST_KEY` above all: the new deployment manages the same hosted
-   deployments, in the same dispatch namespace and routing KV, and their recorded secret digests
-   depend on that key. No signing identity file: the deploy generates the deployment's key.
-2. **Deploy.** From a clean checkout of `main`, with `CLOUDFLARE_ACCOUNT_ID` and
-   `CLOUDFLARE_API_TOKEN` of the platform account set, run
-   `pnpm run deploy admin --json > services-admin.json` (no `--`: pnpm passes it on literally and
-   `astrale-domain` refuses it as an unknown flag). Check that
-   `<url>/.well-known/astrale/release.json` serves the printed release digest and that
-   `<url>/.well-known/astrale/deployment.json` serves its record.
-3. **Rehearse** on a disposable instance whose Host runs the Admin Host's Kernel release, whose
-   Services pin `admin-beta`, with at least one Service and one hosted deployment: move it (step 4),
-   verify it (step 5), roll it back ([Rollback](#rollback-ops-5)) and move it forward again.
-4. **Move** the Admin instance:
-
-   ```sh
-   astrale domain install "$(jq -r .url services-admin.json)" \
-     --allow-issuer-change=services.astrale.ai -i <admin-instance> --json
-   ```
-
-   - The frozen Worker's issuer and the deployment's are not on one line, so consent names the
-     origin: a bare `--allow-issuer-change` covers only a new deployment of the same line, and the
-     install is refused without the origin.
-   - The replaced issuer keeps working while its in-flight work drains. Do not pass
-     `--revoke-previous`.
-   - If the Kernel refuses an installed dependent of Services, install Services together with a
-     compatible deployment of that dependent in one grouped command
-     (`astrale domain install <services-url> <dependent-url> …`); a refusal installs nothing.
-   - If the Kernel answers `4001 DATA_MIGRATION_REQUIRED` ("Schema change requires an explicit
-     data migration."), data the Admin instance stores does not fit the deployment's Schema, and
-     `reason.details.requirements` names each Class (an admin-beta built without the CT16 adoption
-     names `CloudflareDeployment` and `deployment_on_line`). The whole operation is refused: the
-     pin does not move, nothing activates and no data changes, although the deployment did receive
-     the install request. The Admin instance stays on admin-beta, which keeps answering. Fix
-     forward with an `admin` release whose Schema admits the stored data; this repository has no
-     data migration. `SCHEMA_UPGRADE_INCOMPATIBLE` (4002) and `SCHEMA_DEPENDENTS_INCOMPATIBLE`
-     have the same remedy.
-   - On any other refusal, stop. Never uninstall Services on the Admin instance.
-5. **Verify**, with reads only, then one hosted deploy:
-   - `astrale introspect services.astrale.ai -i <admin-instance> --json` names the new release,
-     pinned exactly, with the deployment URL as issuer;
-   - `astrale call /:services.astrale.ai:class.CloudflareDeployment:hosting -i <admin-instance> --json`
-     answers the hosting of `svc.eu.beta.astrale.ai`;
-   - the Services View lists the Admin instance's Services and their secrets names;
-   - a publisher's `astrale-domain deploy <environment>` of a Domain with the astrale adapter into
-     the Admin instance still makes, or reuses, its hosted deployment.
-6. **Point bootstrap discovery at the deployment.** Admin's bootstrap discovery for `services`
-   moves to this deployment's `release.json` (A11), and Admin is redeployed (OPS-7). Never repoint
-   Admin's catalog entry for `services.astrale.ai`: consumer flows install Services by origin
-   through it.
-
-A later release moves the same way: deploy `admin`, then install its URL, with the step 0 Schema
-check. Its issuer is another deployment URL on the same line, which the bare `--allow-issuer-change`
-covers by the consent rule (CT24); the host proof does not exercise that case, so pass
-`--allow-issuer-change=services.astrale.ai` if the CLI asks for the origin.
-
-#### Rollback (OPS-5)
-
-Reinstall the frozen Worker with consent. It still serves, because only OPS-6 retires it:
+Services are hosted for the Admin instance's Kernel alone: its graph is the registry of Service
+names, while the deployments namespace and the routing KV are shared. A Domain Worker serves every
+Kernel that installs it; any other Kernel finds hosting unavailable before anything is read.
 
-```sh
-astrale domain install https://services-admin.beta.astrale.ai \
-  --allow-issuer-change=services.astrale.ai --allow-identity-override -i <admin-instance> --json
-```
+The `admin` Environment sets the plain vars `ASTRALE_ROUTER_WORKER`, `SERVICES_DEPLOYMENT_HOST` (the
+routing domain) and `SERVICES_DEPLOYMENT_KERNEL` (the Admin Kernel's issuer URL). These vars are the
+only declaration of hosting and also bind `SERVICE_DEPLOYMENTS`. Its secrets file, `.env.admin`,
+sets `SERVICES_SECRET_DIGEST_KEY` (at least 32 UTF-8 bytes), `CLOUDFLARE_DISPATCH_NAMESPACE` and
+`CLOUDFLARE_SCHEDULE_KV_ID`; the configuration refuses a file without them or one that sets a
+hosting var.
 
-It serves only the legacy `domain.json`, and the origin it declares differs from its host, so the
-identity override applies as well. The Admin instance's Services records stay in its Kernel through
-a move and a rollback, and a rollback is a Schema upgrade too: it is admitted only while
-admin-beta's Schema admits the data written since the move. Once it does not, the Kernel refuses
-as in step 4 and the deployment stays installed; the remedy is then a new `admin` deployment that
-fixes forward, never a redeploy of admin-beta. If step 6 already repointed bootstrap discovery,
-repoint it back too.
-
-### Retire admin-beta (OPS-6)
-
-Once the Admin instance runs on `admin` and no installation on any Host pins
-`https://services-admin.beta.astrale.ai` (`astrale introspect services.astrale.ai` on each instance
-that installs Services), retire the `services-domain-admin-beta` Worker and its route
-`services-admin.beta.astrale.ai`, and delete its `ASTRALE_SIGNING_IDENTITY` secret, its copy of the
-services.beta key. Keep the issuer host `services.beta.astrale.ai` and the key itself: the frozen
-R1 and services-v2 Workers that 1Pact pins still sign with them. Then D19 deletes the frozen
-`admin-beta` Environment from this repository.
-
-### Before publishers deploy
-
-The Admin instance's graph is the registry of lines. Before the first publisher deploys:
-
-1. This runtime is installed on the Admin instance only, as above; that instance's Kernel issuer is
-   `SERVICES_DEPLOYMENT_KERNEL`; and `SERVICES_PLATFORM_OWNER` names the platform organisation before
-   its first readable deploy.
-2. Each publisher has an organisation on the Admin instance: an Identity, a Shell User for a single
-   publisher or a Shell Group otherwise. The first deploy of an origin in an environment gives that
-   line to the organisation it names, and only a [transfer](#transfer-a-line) moves it.
-3. Its members and CI identities are Identities of the Admin instance that act for it through
-   Kernel `extends_with`. A Shell Group's `assignMember` writes that Edge for each User or Group it
-   assigns. A caller that does not act for the organisation it names is refused before any write.
-4. The Admin instance's graph is backed up with the registry it holds: only it records who holds
-   each line, each deployment's record and its secret digests. A restore loses what happened after
-   its backup: lines registered since are free for the next organisation that deploys, and secret
-   digests may name values older than the ones served.
-
-## Plain background Service starter
-
-The package also ships an isolated scaffolding binary (the root import remains Schema-only):
-
-```sh
-npm exec --package @astrale-domains/services -- create-astrale-service my-worker
-cd my-worker
-npm install
-# Edit service.json and src/job.js for the existing business Domain.
-npm run deploy -- --instance development --as developer
-```
-
-The generator creates local source only and refuses an existing destination. It does not install
-dependencies, create/register accounts, grant permissions, set secrets, enable schedules or deploy.
-The generated project owns a plain HTTP/cron entry, an ES256 account session, a job implementation
-and build/deploy scripts. No Application, Schema, Publication, Domain signer or frontend is generated.
-Deployment calls the public Services API through the installed Astrale CLI and requires an explicit
-instance or URL. The project README explains account setup, secret custody, private cron and cleanup.
-No tooling dependency is added to the Schema runtime or imported from the package root.
+`pnpm run deploy admin` makes one immutable deployment of this release in the platform dispatch
+namespace. Deploying never installs: install the deployed URL with
+`astrale domain install <url> -i <instance>`. Operator tooling (platform namespace bootstrap,
+dispatcher, routing, audits) is described in
+[`providers/cloudflare/operator/README.md`](providers/cloudflare/operator/README.md).
 
 ## Domain development
 
-Services has no development Environment: the [Admin-hosted runtime](#admin-hosted-runtime) is the
-only one it hosts, and Services itself is developed against its tests (the fake Cloudflare account
-and the [real-Kernel suite](tests/kernel/README.md)). `pnpm run deploy admin` makes an immutable
-deployment of this release on the `admin` line of the platform namespace. Deploying never
-installs: installation is always a separate, explicit `astrale domain install <url> -i <instance>`
-on the intended Kernel. There is no watch mode: `astrale-domain dev` serves only direct-mode
-Environments.
-
-To validate without deploying:
+Services is developed against its tests: the fake Cloudflare account and the
+[real-Kernel suite](tests/kernel/README.md).
 
 ```sh
 pnpm typecheck
@@ -771,85 +190,3 @@ pnpm frontend:build
 pnpm build
 pnpm package
 ```
-
-The deployed module named by `entry` must be present in `modules`. Modules and assets carry
-`content: { encoding: 'identity' | 'gzip', decodedSize, contentBase64 }`; large encoded files use
-`contentBase64Chunks` instead, with each string bounded to 512 KiB. `decodedSize` is the exact original
-byte length. Compression changes transport only: provider uploads and deployment digests use the
-reconstructed bytes. Services validates complete gzip streams (including their checksum), exact sizes,
-and canonical Base64 before any graph or provider operation. Individual decoded files remain bounded
-to 7.5 MiB per module and 12 MiB per asset; all decoded deployment material shares a 32 MiB budget.
-
-The previous top-level `contentBase64` and `contentBase64Chunks` fields remain accepted and are
-explicitly deprecated. Roll out Services and install its new schema on consumer instances before
-publishing the compressed SDK adapter. Old SDK clients continue working against the new Services;
-new SDK requests are refused by an old schema without provider effects. The adapter never retries a
-deployment using a different wire representation after an uncertain outcome.
-
-Module names are unique and secrets use environment-variable identifiers. Plain and revisioned artifacts are
-distinct modes and cannot replace each other at one Service record. Five-field cron expressions are
-supported when `CLOUDFLARE_SCHEDULE_KV_ID` is configured.
-
-Plain deployments that omit `compatibilityFlags` use `nodejs_compat`,
-`nodejs_compat_populate_process_env`, and `global_fetch_strictly_public`. Public `fetch()` calls
-therefore traverse Cloudflare's public routes, including same-zone Astrale endpoints, instead of
-bypassing those routes for the zone's origin. This changes routing, not Kernel authorization.
-An explicitly supplied flags array replaces these defaults, including `[]`; low-level callers
-own that complete runtime configuration. Existing Workers change only on redeployment.
-
-Revisioned deployments require explicit runtime configuration and upload it unchanged to both the
-candidate and the serving Worker. Those exact flags participate in the deployment identity;
-Services must not inject defaults after its computation. The Cloudflare adapter already includes
-public-fetch routing in the generated configuration before building the artifact and its digest.
-
-SDK-authored Domains should deploy through `@astrale-os/adapter-astrale`, which projects the
-admitted Cloudflare artifact into the revisioned Services request and verifies the live Publication.
-Installation is never part of a deploy: install the deployed URL with
-`astrale domain install <url> -i <instance>` as its own step. Services never interprets or caches
-a Domain definition, Publication, Schema revision, issuer, or callable inventory. Manual callers likewise
-deploy provider compute first and then install with the same command.
-
-Revisioned deployments may request `readiness: { paths: ['/health'] }`. Services executes these
-bounded local GET paths through its private candidate dispatch binding and requires HTTP 200 before
-public promotion. It never follows redirects or reads the response body as Application metadata.
-For an existing Service, required checks need every retained secret supplied in the candidate
-configuration. Missing values fail before staging or promotion. A caller may explicitly request
-`readiness: { paths: ['/health'], required: false }` to preserve updates with Worker-only secrets:
-Services then retains those secrets on the serving Worker and returns
-`candidateReadiness: 'unavailable-retained-secrets'` without invoking the incomplete candidate.
-An executed, successful check returns `candidateReadiness: 'passed'`. Failed checks still refuse
-promotion even when `required` is false; this is not a fallback for broken candidates.
-Checks share a 30-second budget, shortened by invocation cancellation/deadline. A failed check leaves
-the public Worker unchanged and removes the newly owned candidate. Unchecked provider-only requests
-retain their existing contract.
-
-The updated Astrale adapter requests optional `/health` preflight automatically: SDK Workers
-initialize their Runtime before serving it. No Project option is needed. The adapter reports
-unavailable preflight explicitly and always verifies the public Publication, Bundle, and identity
-after deployment. Private preflight alone never proves complete product correctness.
-Provision and deploy the updated Services Runtime before using this adapter cohort. Older strict
-Services schemas reject the new field; the adapter must not retry without the safety check.
-
-An uncertain provider promotion is adopted only after observing its exact, non-secret attempt
-receipt alongside the artifact tag. Matching code alone is insufficient: Cloudflare's script ETag
-can remain unchanged when only secrets change. Services-owned operation leases serialize callers;
-operators making direct provider changes must coordinate with those operations. The code ETag is
-not a lock for concurrent configuration changes.
-
-If a Kernel interruption prevents recording a deployment outcome, the Service can remain busy
-until its retained operation lease expires (currently 30 minutes from acquisition or renewal).
-Retry the same deployment after the expiry reported in the rejection; it reuses the Service and
-provider identity. Do not clear the lease or create another Service to bypass an uncertain outcome.
-An operation without a recorded expiry needs operator inspection, not a guessed retry deadline.
-
-A definitively rejected update restores a previously ready Service only when the Provider observes
-the same serving script digest and tenant routing coordinates. The restoration is atomic and fenced
-by the current operation receipt; it restores the previous name and description and clears the
-rejected attempt. The deployment still returns a rejection, but the retained Service remains
-manageable. Failed creations, uncertain outcomes, mismatched observations, and unresolved previous
-attempts remain failed rather than claiming that the old deployment is ready. This verification adds
-no provider request to a successful deployment.
-
-For the complete live owner-management and non-owner-denial journey, see
-[remote acceptance](tests/remote/README.md). Run it against an isolated instance;
-ordinary unit tests do not prove callable admission or real provider telemetry.