@astrale-domains/services 0.4.5 → 0.4.7

package/README.md

@@ -11,6 +11,26 @@ protocols behind neutral SDK Integrations and stores only admitted lifecycle evi
 - 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.
 - 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.
@@ -22,6 +42,157 @@ protocols behind neutral SDK Integrations and stores only admitted lifecycle evi
 - 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 characters, kept for the life of the environment: 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-beta` names `admin.astrale.ai` and keeps 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
@@ -75,13 +246,96 @@ health check. Cloudflare can automatically delete the generated certificate as s
 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 beta replacement serves at `https://services-v2.beta.astrale.ai` with the retained
-`https://services.beta.astrale.ai` issuer and signing key. Keep the original runtime and identity
-discovery available for existing installations. Adopt the replacement's public URL per instance
-before invoking its additive migration API; do not uninstall Services or replace the shared R1
-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.
+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.
+
+## Admin-hosted runtime
+
+The `admin-beta` Environment is the Services runtime of the Admin instance, the one that hosts
+publishers' deployments outside the instances that install them. It is a Worker of its own,
+`services-domain-admin-beta` at `https://services-admin.beta.astrale.ai`, 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 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`. `.env.admin-beta` 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.
+
+It retains the issuer `https://services.beta.astrale.ai` and its signing key, as services-v2 does.
+The Admin instance's Services are bound to that issuer, and the Kernel refuses an issuer change when
+it replaces an installed Domain (`issuer-changed`); neither the Admin Host's Kernel nor the CLI
+offers a consented issuer change yet. 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. The Admin instance moves to an issuer of its own when the
+canonical Admin-hosted runtime replaces this one through a consented issuer change; this Worker and
+its copy of the key are retired after that reinstall.
+
+Only the Admin instance installs this runtime; consumer instances keep the Services they pin.
+The operator sets it up once:
+
+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 the
+   Kernel refuses. Check as well that the Admin instance's Kernel issuer is admin-beta's
+   `SERVICES_DEPLOYMENT_KERNEL`; otherwise every deploy answers `hosting-unavailable`. Before the
+   first readable deploy, read the platform organisation's Identity id there and set it as
+   admin-beta's `SERVICES_PLATFORM_OWNER` var in a reviewed change to `astrale.config.ts`.
+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 environment uses, e.g. `openssl rand -base64 32` (32
+   random bytes, kept as their 44-character base64 text).
+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. Never leave that key at `.astrale/identity.json`, the development
+   Environment's default identity: `pnpm dev` would bind it to development Workers. 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, directly:
+   `astrale domain install https://services-admin.beta.astrale.ai --direct --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.
 
 ## Plain background Service starter
 
@@ -107,8 +361,8 @@ No tooling dependency is added to the Schema runtime or imported from the packag
 
 Copy `.env.example` to `.env.dev` and fill the Cloudflare values.
 
-`pnpm dev` watches and deploys the development Environment remotely. `pnpm dev beta`
-selects beta; `pnpm beta` and `pnpm prod` deploy once. These bootstrap Environments
+`pnpm dev` watches and deploys the development Environment remotely. `pnpm run deploy admin-beta`
+deploys the [Admin-hosted runtime](#admin-hosted-runtime) once. These bootstrap Environments
 are deliberately deploy-only: install the resulting URL on the intended Kernel explicitly.
 Stopping development leaves the remote Worker available. No local Worker or tunnel is started.
 
@@ -123,9 +377,21 @@ pnpm build
 pnpm package
 ```
 
-The deployed module named by `entry` must be present in `modules`. Module contents use one Base64
-string or bounded Base64 chunks when one string cannot cross the portable Value boundary; names are
-unique and secrets use environment-variable identifiers. Plain and revisioned artifacts are
+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.
 

package/dist/schema/index.d.ts

@@ -3,3 +3,5 @@ export type { ServicesDomain, ServicesSchema } from './schema.js';
 export { artifact, artifactModule, assetBundle, assetFile, deployServiceInput, deployServiceOutput, resourceLimits, revisionedDeployment, } from './modules/service/index.js';
 export type { ArtifactModule, AssetBundle, DeployServiceInput, DeployServiceOutput, ResourceLimits, } from './modules/service/index.js';
 export { CloudflareWorker, OwnService, Service, TraverseOwnedService, service_owned_by, } from './modules/service/index.js';
+export { ActForOrganization, CloudflareDeployment, Deployment, DeploymentLine, OwnDeployment, OwnLine, TraverseOwnedLine, TraverseOwnedLineDeployment, deploymentCommit, deploymentHosting, deploymentLabel, deploymentLifecycle, deploymentRecord, deploymentRejection, deploymentRequest, deploymentResponse, deploymentRetention, deploymentRetirement, deploymentSecretDigests, deploymentSecretRejection, deploymentSummary, deployment_on_line, expirePreviewsOutput, frozenConfiguration, lastCallsOutput, listedDeploymentSummary, line_owned_by, MAXIMUM_LAST_CALL_LABELS, MAXIMUM_PREVIEW_EXPIRY_WRITES, retireDeploymentOutput, unadmittedDeploymentSummary, } from './modules/deployment/index.js';
+export type { DeploymentHosting, DeploymentLifecycle, DeploymentLifecycleEvent, DeploymentRecord, DeploymentRejection, DeploymentRejectionReason, DeploymentRequest, DeploymentResponse, DeploymentRetention, DeploymentRetirement, DeploymentSecretDigest, DeploymentSecretRejection, DeploymentSummary, ExpirePreviewsResult, FrozenConfiguration, ListedDeploymentSummary, RetireDeploymentResult, UnadmittedDeploymentSummary, } from './modules/deployment/index.js';

package/dist/schema/index.js

@@ -1,3 +1,4 @@
 export { schema } from './schema.js';
 export { artifact, artifactModule, assetBundle, assetFile, deployServiceInput, deployServiceOutput, resourceLimits, revisionedDeployment, } from './modules/service/index.js';
 export { CloudflareWorker, OwnService, Service, TraverseOwnedService, service_owned_by, } from './modules/service/index.js';
+export { ActForOrganization, CloudflareDeployment, Deployment, DeploymentLine, OwnDeployment, OwnLine, TraverseOwnedLine, TraverseOwnedLineDeployment, deploymentCommit, deploymentHosting, deploymentLabel, deploymentLifecycle, deploymentRecord, deploymentRejection, deploymentRequest, deploymentResponse, deploymentRetention, deploymentRetirement, deploymentSecretDigests, deploymentSecretRejection, deploymentSummary, deployment_on_line, expirePreviewsOutput, frozenConfiguration, lastCallsOutput, listedDeploymentSummary, line_owned_by, MAXIMUM_LAST_CALL_LABELS, MAXIMUM_PREVIEW_EXPIRY_WRITES, retireDeploymentOutput, unadmittedDeploymentSummary, } from './modules/deployment/index.js';