fix: define registry as initial contract

Author: a19q3

CHANGELOG.md

@@ -11,11 +11,12 @@
   editions and older persisted schemas are rejected; no migration or
   compatibility reader is provided. Generated CKB entries also remove the
   raw-`CSARGv1` witness fallback, so Edition 2026 accepts the payload only
-  inside canonical `WitnessArgs.input_type`. The public registry contract is
-  hard-cut to publish protocol v2 and registry schema 2: signed entries,
-  persisted rows, CDN JSON, and the website all require Edition 2026 and the
-  compatibility-profile hash. The generic admin API can no longer manufacture
-  `verified_build` or `deployed` claims without an evidence-specific path. See the
+  inside canonical `WitnessArgs.input_type`. The not-yet-deployed public
+  registry is defined by one current contract: signed entries, the initial
+  database schema, CDN JSON, and the website all require Edition 2026 and the
+  compatibility-profile hash, with no fallback reader for incomplete entries.
+  The generic admin API can no longer manufacture `verified_build` or
+  `deployed` claims without an evidence-specific path. See the
   [0.23 development release notes](docs/releases/CELLSCRIPT_0_23_RELEASE_NOTES.md).
 - Complete the native-tooling cleanup: neutralize migration-era identifiers,
   remove tracked legacy traceback logs and cache exclusions, rename the native

docs/CELLSCRIPT_GATE_POLICY.md

@@ -54,8 +54,9 @@ ABI changes require the `backend` gate in addition to ordinary `dev` and `ci`
 coverage.
 
 The `ci` gate also typechecks, tests, and performs a Wrangler dry-run build of
-`services/registry-api`. This pins the publish-protocol/schema contract to the
-compiler-generated registry entry. It is local service coverage, not evidence
+`services/registry-api`. This pins the current publish contract and initial
+database/static-object shape to the compiler-generated registry entry. It is
+local service coverage, not evidence
 that Cloudflare, R2, Hyperdrive, Neon, DNS, or a production deployment works.
 
 The full gate reads `scripts/ckb_acceptance_pin.json` and rejects a CKB checkout

docs/CELLSCRIPT_PACKAGE_PROVENANCE_AND_DEPLOYMENT_IDENTITY.md

@@ -1093,7 +1093,7 @@ alongside `Cell.toml`, for audit and offline use:
 
 ```json
 {
-  "schema_version": 2,
+  "schema_version": 1,
   "name": "amm",
   "namespace": "cellscript",
   "versions": [
@@ -1122,9 +1122,10 @@ alongside `Cell.toml`, for audit and offline use:
 }
 ```
 
-The current Edition 2026 reader accepts only schema 2. The older schema-1
-shape described in the historical Phase 1 audit below is not a compatibility
-surface.
+This is the registry's initial Edition 2026 shape. The registry has not been
+deployed, so the original schema identifier is retained while the definition
+is updated in place. Every non-optional field shown above is required; readers
+do not fill in omitted `dependencies`, `status`, or `yanked` values.
 
 The `tag` field maps each version to a git tag in the source repository.
 This allows `cellc install` to clone the exact commit without needing
@@ -1181,9 +1182,9 @@ requires a stronger explicit flag such as `--allow-quarantined`. Default search,
 recommendations, and production-visible package lists only include entries that
 passed the required baseline checks.
 
-A mirrored `registry.json` version entry with no `status` is treated as
-`source_published`, not as verified. Public registry writes must emit an
-explicit status; legacy mirrors need explicit risk flags before direct install.
+A mirrored `registry.json` version entry with no `status`, `dependencies`, or
+`yanked` field is malformed. Public registry writes and offline mirrors emit
+the same complete entry shape.
 
 ### Installation Flow
 

docs/releases/CELLSCRIPT_0_23_RELEASE_NOTES.md

@@ -22,7 +22,7 @@ work until their implementation and evidence boundaries are complete.
 | Entry witness | `CSARGv1` is decoded only from canonical Molecule `WitnessArgs.input_type`. |
 | Failure mode | Raw payloads, malformed tables, absent `input_type`, wrong placement, and mismatched identities fail closed. |
 | Build identity | The resolved compatibility profile is bound into metadata, registry, lock, deployment, receipt, and builder records. |
-| Registry contract | Publish protocol v2 and registry schema 2 require Edition 2026 plus its compatibility-profile hash from CLI signature through API, database, CDN JSON, and website. |
+| Registry contract | The initial publish contract requires Edition 2026 plus its compatibility-profile hash from CLI signature through API, database, CDN JSON, and website. |
 | Tooling | CLI, LSP, WASM, website bindings, examples, and package tooling use the same edition contract. |
 | Native gate | Active test, fixture, evidence, and release tooling is Rust, shell, or Node; repository policy rejects Python source reintroduction. |
 
@@ -105,13 +105,14 @@ The 0.23 identity set is:
 | Compile receipt | edition and resolved compatibility profile |
 | Generated action builder | `cellscript-generated-action-builder-v0.23-edition-2026` |
 | Registry build record | edition and compatibility-profile hash |
-| `registry.json` / public publish | schema 2 / `cellscript-registry-publish-v2` |
+| `registry.json` / public publish | one required entry shape with explicit edition, profile hash, status, dependencies, and yank state |
 
 Consumers reject other identities. Rebuild the artifact and regenerate its
 metadata, lock/deployment records, receipt, and builder together.
 
-The registry boundary has no v1 reader or migration path. The write API checks
-the complete signed nested entry instead of accepting an untyped JSON object,
+The registry has not been deployed, so its initial contract and
+`0001_initial.sql` definition are updated in place. The write API accepts one
+complete signed nested entry instead of an untyped or incomplete JSON object,
 persists edition/profile as typed columns, and repeats them in the CDN object.
 Generic admin status changes may quarantine, yank, deprecate, or move an entry
 through indexing, but cannot label it `verified_build` or `deployed` without a
@@ -125,7 +126,7 @@ future evidence-specific promotion endpoint.
   accept only `"2026"`.
 - The playground worker and TypeScript declarations pass that edition into the
   WASM boundary and include it in compiler-output provenance.
-- Registry pages reject stale schema-1 fixture data and display each package
+- Registry pages reject incomplete fixture data and display each package
   version's edition and compatibility-profile hash.
 - Entry-witness reports, ABI reports, action plans, and generated builders
   expose canonical `WitnessArgs.input_type` placement.

docs/wiki/Tutorial-12-Phase1-Registry-End-to-End.md

@@ -66,14 +66,14 @@ source and build identity locally.
 
 ## Edition 2026 Registry Contract
 
-Public publishing uses `cellscript-registry-publish-v2` and registry schema 2.
-The signed payload contains one complete version entry, and the API checks that
+Public publishing uses the registry's single current publish contract. The
+signed payload contains one complete version entry, and the API checks that
 its namespace, package name, version, and source hash equal the outer signed
 identity. The entry must also contain:
 
 ```json
 {
-  "schema_version": 2,
+  "schema_version": 1,
   "versions": [{
     "edition": "2026",
     "compatibility_profile_hash": "<32-byte hex hash>"
@@ -84,8 +84,10 @@ identity. The entry must also contain:
 These are not website labels. `edition` identifies the selected language and
 CKB ABI rule bundle; `compatibility_profile_hash` binds the resolved details of
 that bundle. The API stores both as typed fields and exposes them in its static
-package-version JSON. Schema 1, a missing field, or a mismatched nested identity
-is rejected. There is no v1 migration or compatibility reader.
+package-version JSON. Missing `edition`, `compatibility_profile_hash`,
+`dependencies`, `status`, or `yanked`, an unknown schema identifier, or a
+mismatched nested identity is rejected. Because the registry has not been
+deployed, this is the initial shape rather than an upgrade or migration story.
 
 `source_published` means the signed source snapshot was admitted; it does not
 mean the build or deployment was verified. The generic admin endpoint cannot

proposals/evolving-dob/evolving-dob-profile-v1

@@ -130,12 +130,13 @@ path, idempotent publish, and admin-gated status transitions. The 0.23 work
 is to actually deploy it on `cellscript.dev` and to wire the frontend and CLI
 into the same trust model.
 
-The Edition 2026 contract slice is complete: publish protocol v2 and registry
-schema 2 are a hard cut across the Rust publisher/reader, API validation,
-Postgres schema, R2 package-version object, checked-in registry fixture, and
-website data model. There is no schema-1 compatibility path. Generic admin
-status changes cannot create `verified_build` or `deployed` claims; an
-evidence-specific promotion path remains production work.
+The Edition 2026 contract slice is complete across the Rust publisher/reader,
+API validation, initial Postgres schema, R2 package-version object, checked-in
+registry fixture, and website data model. The registry has not been deployed,
+so these surfaces are updated directly and accept one complete entry shape;
+there is no fallback reader for omitted fields. Generic admin status changes
+cannot create `verified_build` or `deployed` claims; an evidence-specific
+promotion path remains production work.
 
 ### Production Domains And Hosting
 

roadmap/CELLSCRIPT_0_23_ROADMAP.md

@@ -15,6 +15,10 @@ It intentionally does not use D1 as the primary database. Runtime state is
 stored in Neon Postgres through Cloudflare Hyperdrive, while immutable source
 snapshots and static registry read objects are stored in R2.
 
+This service has not been deployed. `migrations/0001_initial.sql` is therefore
+the authoritative initial database definition and is edited in place with the
+API contract; there is no deployed schema or compatibility reader to preserve.
+
 ## Implemented Boundaries
 
 - JoyID-rooted capability authorisation with `@joyid/ckb` `verifySignature`.
@@ -29,9 +33,10 @@ snapshots and static registry read objects are stored in R2.
 - Namespace claim cooldown for newly claimed namespaces by the same JoyID
   principal; invalid JoyID signatures do not consume principal quota.
 - Publish admission path for source packages.
-- Hard-cut `cellscript-registry-publish-v2` admission: the signed
-  `registry_entry` must use registry schema 2, contain exactly the published
-  version, and bind Edition 2026 plus its compatibility-profile hash.
+- Single-shape `cellscript-registry-publish-v1` admission: the signed
+  `registry_entry` must contain exactly the published version and explicitly
+  bind Edition 2026, its compatibility-profile hash, dependencies, status, and
+  yank state.
 - Namespace owner ACL check before publish admission.
 - P-256 capability-signature verification for daily publish payloads.
 - One-time signed nonce consumption for capability creation, capability
@@ -201,7 +206,7 @@ cellscript-registry-auth-v1 / authorize_capability
 Daily publish signs the canonical JSON form of:
 
 ```text
-cellscript-registry-publish-v2 / publish
+cellscript-registry-publish-v1 / publish
 ```
 
 The API rejects a publish unless:
@@ -211,7 +216,7 @@ The API rejects a publish unless:
 - the capability scope covers `publish:namespace/package`;
 - the namespace exists and is active;
 - the capability principal owns the namespace;
-- the signed nested registry entry is schema 2, names the same package/version
+- the signed nested registry entry uses the current schema, names the same package/version
   and source hash, and records `edition = "2026"` plus a 32-byte
   `compatibility_profile_hash`;
 - the signed manifest hash is present;
@@ -244,9 +249,9 @@ https://registry.cellscript.dev/packages/:namespace/:name/versions/:version.json
 
 The route is served from R2 and sets short CDN cache headers. It does not
 require Hyperdrive or the write store, so ordinary package reads stay isolated
-from authenticated write-path dependencies. Its JSON object is also schema 2
-and repeats `edition` and `compatibility_profile_hash` at the top level so
-consumers do not need to trust an untyped nested blob.
+from authenticated write-path dependencies. Its JSON object repeats `edition`
+and `compatibility_profile_hash` at the top level so consumers do not need to
+trust an untyped nested blob.
 
 CLI publish has two supported signing shapes:
 

services/registry-api/README.md

@@ -3,9 +3,9 @@ import type { SignChallengeResponseData } from "@joyid/ckb";
 export const AUTH_PROTOCOL = "cellscript-registry-auth-v1";
 export const AUTH_ACTION = "authorize_capability";
 export const AUTH_REVOKE_CAPABILITY_ACTION = "revoke_capability";
-export const PUBLISH_PROTOCOL = "cellscript-registry-publish-v2";
+export const PUBLISH_PROTOCOL = "cellscript-registry-publish-v1";
 export const PUBLISH_ACTION = "publish";
-export const REGISTRY_SCHEMA_VERSION = 2;
+export const REGISTRY_SCHEMA_VERSION = 1;
 export const CELLSCRIPT_EDITION = "2026";
 export const DEFAULT_REGISTRY_ORIGIN = "https://api.registry.cellscript.dev";
 export const DEFAULT_STATIC_REGISTRY_ORIGIN = "https://registry.cellscript.dev";

services/registry-api/src/domain.ts

@@ -5,6 +5,7 @@ import {
   type CapabilityAuthorisationPayload,
   type PublishPayload,
   type RegistryEntryStatus,
+  type RegistryIndexEntry,
 } from "./domain";
 
 export type NamespaceStatus = "active" | "review_pending" | "reserved" | "rejected" | "quarantined";
@@ -47,7 +48,7 @@ export interface PackageVersionRecord {
   capability_key_id: string;
   principal_type: string;
   principal_id: string;
-  registry_entry: Record<string, unknown>;
+  registry_entry: RegistryIndexEntry;
   snapshot_hash: string;
   direct_url: string;
   created_at: string;