Deployment
Deployment
Document deployment procedures supported by verified evidence.
Status: Partial implementation reference — Code-confirmed; operational validation pending
Last reviewed: 2026-10-19
Scope
Build artifacts, environments, release steps, validation and rollback where applicable. The source-confirmed baseline below covers part of this scope; remaining operational details are unknown.
Current implementation baseline
Each Worker’s .github/workflows/deploy.yml declares checks followed by a deploy job on eligible main-branch pushes using pnpm exec wrangler deploy. Read actual workflow steps: the inspected six workflows do not invoke application suites, despite job labels mentioning tests. Resources additionally runs OpenAPI validation, which generates a local artifact.
wrangler.jsonc identifies entrypoints, bindings and local overrides. Corpus and Events declare minute schedules; MCP declares a queue consumer, OAuth KV and a Durable Object migration. Configuration is not evidence of a successful deployment or environment isolation.
Evidence: Resources workflow, Registration workflow, testing strategy and lineage rollout. Database compatibility, coordinated contract publication and rollback across lineage changes require operator validation. No release command was run in this audit.
Structured-payload schema compatibility — decision open
The Corpus schema explicitly targets an empty D1 database; test setup creates that schema and initializes lineage in the test harness. This establishes an implemented clean-install starting point, not a demonstrated production installation or a supported-version matrix.
The supplied identity migration adds corpus_identity and its guards; the public archive migration adds archive certificates and prefix guards. The archive migration test source contains a case reconstructing a prior lineage-enabled fixture. That case was not executed for this documentation task and does not establish a complete payload upgrade from arbitrary earlier populated schemas. No reviewed execution artifact demonstrates such a general upgrade path. The existing schema reference also records that the operator helper’s backfill route is absent from the inspected router.
Acceptance decision remains open. The Corpus database/migration maintainer and release owner must identify the intended starting schemas and either accept a data-preserving path or explicitly approve which installations are unsupported. Named accountability, an approved support policy and a release-gate decision have not been established here. Do not apply the clean-install schema over populated data or infer support from migration filenames.
Evidence for a future compatibility decision must identify exact source and starting-schema revisions, retained data, payload-column/nullability/check/index/event-trigger changes, and isolated before/after checks of content, history, retry mappings, references/search projections, lineage and archive state. Include the applicable fencing and recovery/rollback prerequisites from the lineage runbook. A proposed gate is to accept that evidence, or an explicit exclusion policy and its consequences, before claiming support for affected existing installations; this document does not invent a blanket release-blocking policy. An unsupported-installation decision must state the affected schema states and operator guidance without implying permission to reset or discard data.
The original implementation report’s no-remote-change/no-automatic-migration statements remain historical statements about that task; they do not establish present deployment state. See the obligation handoff for the pending acceptance record.
