feat: harden Registry lifecycle and reproduction

Author: a19q3

.github/workflows/ci.yml

@@ -20,11 +20,26 @@ jobs:
     name: Test
     runs-on: ubuntu-latest
     timeout-minutes: 45
+    services:
+      postgres:
+        image: postgres:17-alpine
+        env:
+          POSTGRES_DB: cellscript_registry_test
+          POSTGRES_USER: cellscript_test
+          POSTGRES_PASSWORD: cellscript_test_password
+        ports:
+          - 5432:5432
+        options: >-
+          --health-cmd "pg_isready -U cellscript_test -d cellscript_registry_test"
+          --health-interval 5s
+          --health-timeout 5s
+          --health-retries 10
     env:
       CARGO_INCREMENTAL: "0"
       CARGO_TARGET_DIR: /tmp/cellscript-ci-target
       CELLSCRIPT_BACKEND_SHAPE_REPORT: /tmp/cellscript-backend-shape/backend-shape-report.json
       CKB_SDK_RUST_REF: v5.1.0
+      REGISTRY_TEST_DATABASE_URL: postgresql://cellscript_test:cellscript_test_password@127.0.0.1:5432/cellscript_registry_test
     steps:
       - name: Check out repository
         uses: actions/checkout@v4

CHANGELOG.md

@@ -5,17 +5,20 @@
 - Complete the Registry's generalized artifact and chain-evidence path. Rust,
   C, JavaScript, and other CKB artifacts now keep explicit source, build,
   deployment, TCB, and copy-only identities instead of being presented as
-  CellScript dependencies. Reproducible profiles require two to sixteen
-  distinct builder reports bound to the signed environment, source, recipe,
-  executable, build log, and predecessor evidence before verification becomes
-  `verified`; deployment is rejected until that evidence exists. Add
+  CellScript dependencies. Reproducible profiles require P-256-signed reports
+  from two to sixteen policy-approved builders spanning the configured minimum
+  number of independent trust domains. Reports bind the signed environment,
+  source, recipe, executable, build log, builder identity, and predecessor
+  evidence before verification becomes `verified`; deployment is rejected
+  until that evidence exists. Add `cellc artifact reproduction-report` and
   `cellc artifact reproduction-evidence`, wallet-ready mainnet commitment
-  transaction intents, fixed Registry Type/attestor Lock configuration,
+  transaction intents, fixed Registry Type/commitment Lock configuration,
   Type-Script-indexed `CSREGv1` scans, and scheduled lifecycle reconciliation
-  that demotes spent attestations or stale deployment Cells without deleting
-  historical evidence. The chain path is implemented but remains
-  operationally disabled until the canonical mainnet Registry Type Script,
-  CellDep, and attestor Lock are deployed and configured.
+  that demotes spent commitments or stale deployment Cells without deleting
+  historical evidence. Both Script code CellDeps must be live and sufficiently
+  confirmed before the chain path becomes ready. The chain path is implemented
+  but remains operationally disabled until the canonical mainnet Registry Type
+  Script, commitment custody Lock, and both CellDeps are deployed and configured.
 - Harden the unified artifact Registry boundary: default discovery now hides
   pending/rejected releases and paginates by package coordinate; deployment
   records and admin recovery must match the immutable CKB `hash_type` and
@@ -53,9 +56,12 @@
   auth commands use `--wallet-signature`, with `--joyid-signature` retained as
   a visible compatibility alias, and the API adds the corresponding typed
   principal migration and signature verification. The compact chooser now
-  preserves the complete official twelve-wallet CKB directory: compatible CCC
-  signers connect directly, while the remaining wallets use the same verified
-  external-signature handoff instead of disappearing from the UI. Every entry
+  preserves the complete twelve-wallet CKB directory: compatible CCC CKB
+  signers connect directly, while other entries are explicitly labelled as
+  external links for importing a compatible `wallet-signature.json`; opening a
+  link is never represented as a wallet connection. The browser checks the
+  signature shape and principal binding before submission, while the API
+  remains authoritative for cryptographic verification. Every entry
   now uses the corresponding official Nervos wallet-directory SVG rather than
   an autogenerated letter mark or a runtime favicon. The chooser header no
   longer reserves space for a hidden back control, so its title, explanatory
@@ -147,7 +153,7 @@
   version-addressed static JSON, and the website require both Edition 2026 and
   the separate compatibility-profile hash, with no fallback reader for
   incomplete entries. Generic admin status changes cannot manufacture
-  `verified_build`, `deployed`, or `on_chain_attested` claims; those states
+  `verified_build`, `deployed`, or `on_chain_committed` claims; those states
   require the ordered evidence-promotion 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,

audits/0.23-deep-dive.md

@@ -487,7 +487,7 @@ flowchart TD
 const adminAllowed = ["source_published", "indexed_pending", "verified_build",
                      "deployed", "deprecated", "yanked", "quarantined"];
 
-// 0.23: 5 个（verified_build / deployed / on_chain_attested 移除 admin 权限）
+// 0.23: 5 个（verified_build / deployed / on_chain_committed 移除 admin 权限）
 const adminAllowed = ["source_published", "indexed_pending",
                      "deprecated", "yanked", "quarantined"];
 ```
@@ -501,7 +501,7 @@ stateDiagram-v2
     source_published --> verified_build: 0.23 evidence endpoint
     indexed_pending --> verified_build: 0.22 任意 / 0.23 仅 evidence endpoint
     verified_build --> deployed: 0.22 任意 / 0.23 仅 evidence endpoint
-    deployed --> on_chain_attested: 0.22 任意 / 0.23 仅 evidence endpoint
+    deployed --> on_chain_committed: 0.22 任意 / 0.23 仅 evidence endpoint
     source_published --> deprecated: 0.22 + 0.23
     indexed_pending --> deprecated: 0.22 + 0.23
     source_published --> yanked: 0.22 + 0.23
@@ -513,9 +513,9 @@ stateDiagram-v2
 **0.23 状态机含义**：
 
 - ✅ admin API 仍可达：`source_published` / `indexed_pending` / `deprecated` / `yanked` / `quarantined`
-- ✅ generic admin API **不可伪造**：`verified_build` / `deployed` / `on_chain_attested`
+- ✅ generic admin API **不可伪造**：`verified_build` / `deployed` / `on_chain_committed`
 - ✅ `POST /v1/admin/packages/:namespace/:name/versions/:version/promote`
-  已实现证据专用路径：`source_published|indexed_pending → verified_build → deployed → on_chain_attested`
+  已实现证据专用路径：`source_published|indexed_pending → verified_build → deployed → on_chain_committed`
 - ✅ 每一步校验 `source_hash` / `manifest_hash` / `compatibility_profile_hash`；部署证据必须引用 verified-build evidence hash，链上证明必须引用 deployed evidence hash
 - ✅ `package_version_evidence` 持久化 hash-addressed evidence，静态版本 JSON 与公共 evidence read API 同步公开链条
 

docs/CELLSCRIPT_PACKAGE_PROVENANCE_AND_DEPLOYMENT_IDENTITY.md

@@ -244,20 +244,22 @@ compiler version, and possibly type-id lineage.
 A deployment-bound package is what wallets and production builders should rely
 on when constructing real transactions.
 
-**On-chain-attested package.** A deployment claim has an explicit JoyID-rooted
-attestation or chain-indexed record. This is a stronger statement about who made
-the deployment claim, but it still does not replace source, build, deployment,
-and live-chain verification.
+**On-chain-committed package.** A sufficiently confirmed live mainnet Cell
+commits the exact Registry release/deployment tuple under the configured
+Registry Type Script and custody Lock. This is a current discoverability and
+integrity statement, not an attestation of source quality or authorship. It does
+not replace source, build, deployment, and live-chain verification.
 
 **Deprecated, yanked, or quarantined package.** Historical entries remain
 addressable for reproducibility, but default search and recommendation surfaces
 may suppress them. Quarantine is for abuse or high-risk packages; yanking is a
 maintainer action that preserves exact-pin warning metadata.
 
 The same source package version may have zero, one, or many deployment
-bindings. For example, `amm@1.2.0` may start as a source-only package, later
-gain a CKB testnet deployment, then eventually a CKB mainnet deployment. These
-are separate deployment records attached to the same source/package identity,
+bindings. For example, `amm@1.2.0` may start as a source-only package and later
+gain one or more CKB mainnet deployment bindings. Local or private tooling may
+track testnet deployments separately, but the public Registry accepts only
+mainnet deployment evidence. These are separate deployment records attached to the same source/package identity,
 not separate source packages.
 
 ```
@@ -1197,7 +1199,7 @@ source_published  -> direct URL and author dashboard visible
 indexed_pending   -> waiting for asynchronous verifier/indexer workers
 verified_build    -> build evidence accepted
 deployed          -> deployment facts attached and verified locally
-on_chain_attested -> feature-gated JoyID/chain-backed deployment attestation
+on_chain_committed -> sufficiently confirmed live Registry commitment Cell
 deprecated/yanked -> historical entry retained, default resolution suppressed
 quarantined       -> direct URL retained, default search suppressed
 ```
@@ -1730,9 +1732,9 @@ registry admission authority.
 |---|---|
 | JoyID-rooted publisher identity | `cellc auth capability create --principal-id <principal_id> --scope publish:ns/pkg --expires 90d --json > capability-payload.json` plus `cellc auth capability submit --payload capability-payload.json --joyid-signature joyid-signature.json` uses the CCC-backed JoyID flow, records `principal_type = joyid_ckb`, binds `principal_id` to a local publisher credential, and stores that credential in the OS keychain |
 | Scoped publisher credentials | Capability-style signing key with namespace/package/action scopes, expiry, revocation, nonce/origin checks, and CI-safe delegation |
-| Namespace/package ACL | Namespace owners, package maintainers, yanking authority, attestation authority, maintainer rotation, and source-location update permissions |
+| Namespace/package ACL | Namespace owners, package maintainers, yanking authority, commitment authority, maintainer rotation, and source-location update permissions |
 | Abuse controls | Separate static read path from write API; WAF/rate limits/body caps/hash dedup/bounded queues/quarantine/cooldown; fee/bond rules remain later policy hooks |
-| Entry visibility state machine | `source_published` -> `indexed_pending` -> `verified_build` -> `deployed` -> `on_chain_attested`; `deprecated`/`yanked`/`quarantined` suppress default search without deleting history |
+| Entry visibility state machine | `source_published` -> `indexed_pending` -> `verified_build` -> `deployed` -> `on_chain_committed`; `deprecated`/`yanked`/`quarantined` suppress default search without deleting history |
 
 ### Phase 0 — No Block on v0.12
 
@@ -1848,19 +1850,20 @@ Any failure in this chain causes fail-closed rejection.
 
 Namespace ownership is the core registry ACL. A namespace has owner principals;
 packages have maintainer principals; publisher credentials are scoped to
-actions such as `publish`, `yank`, `attest`, and `manage-maintainers`. The root
-publisher principal is `joyid_ckb`, while daily operations use delegated
+actions such as `publish`, `yank`, `commit`, and `manage-maintainers`. The root
+publisher principal is `joyid_ckb` or `ckb_secp256k1`, while daily operations use delegated
 publisher credentials that can expire and be revoked. The exact bootstrap
 policy for first namespace claim (review, cooldown, reserved namespaces, or
 later fee/bond hooks) is an ecosystem decision.
 
 ### Should reproducible build proofs or audit signatures be required before a package is considered production-ready?
 
-Phase 1 requires hash matching but not build attestations or audit signatures.
-Phase 2 adds optional publisher signatures and audit report hashes. Whether
-audit signatures become mandatory for production readiness is an ecosystem
-policy decision, not a toolchain enforcement decision. The toolchain should
-support the mechanism; the policy should be set by the community.
+Hash matching remains the baseline for generic artifacts. A release declaring
+a reproducible build additionally requires policy-approved, P-256-signed
+reproduction reports from independent trust domains before it becomes
+`verified` or can acquire deployment evidence. Security audit signatures remain
+policy-specific; when a release declares `security.status = audited`, the
+referenced audit report must at least be present and hash-bound.
 
 ### How should yanking, supersession, and maintainer rotation work?
 

docs/CELLSCRIPT_REGISTRY_PHASE1.md

@@ -6,9 +6,10 @@ surfaces described here are checked in on the current release line.
 
 The source-package production slice is deployed. Generic artifact,
 reproduction, deployment, and chain-index code is implemented, but a public
-`on_chain_attested` claim additionally requires operators to deploy and pin the
-canonical mainnet Registry Type Script, its CellDep, and the attestor Lock.
-Until all three identities are configured, commitment construction fails
+`on_chain_committed` claim additionally requires operators to deploy and pin
+the canonical mainnet Registry Type Script, commitment custody Lock, and both
+code CellDeps. Until all four configuration values are present and their Cells
+are live with the required confirmation depth, commitment construction fails
 closed and scheduled chain reconciliation remains disabled.
 
 The Registry indexes CKB ecosystem artifacts. A coordinate is
@@ -67,9 +68,12 @@ binary may be verified but have no deployment concept. A CKB executable may be
 verified and still undeployed. A previously chain-verified release may later be
 deprecated without rewriting its evidence.
 
-`on_chain_attested` is a current-state claim, not a permanent badge. Scheduled
+`on_chain_committed` is a current-state claim, not a permanent badge. Scheduled
 maintenance returns a spent commitment to `deployed` and a stale deployment to
-`verified_build`, while retaining every accepted evidence record for audit.
+`verification_status = verified` plus `deployment_status = undeployed`
+(projected as `verified_build`), while retaining every accepted evidence record
+for audit. Disabling the Registry Script configuration also clears current
+commitment pointers because the service can no longer re-observe them.
 
 ## Artifact Identity
 
@@ -228,17 +232,40 @@ environment and emit bounded reports:
 
 ```json
 {
-  "schema": "cellscript-reproduction-report-v1",
+  "schema": "cellscript-reproduction-report-v2",
   "builder_id": "builder-a",
+  "trust_domain": "independent-org-a",
+  "builder_public_key": "p256-spki:<base64-der>",
   "environment": "<exact signed environment>",
   "source_hash": "<CKB Blake2b-256>",
   "build_recipe_hash": "<CKB Blake2b-256>",
   "artifact_hash": "<CKB Blake2b-256>",
   "build_log_hash": "<CKB Blake2b-256>",
-  "generated_at": "2026-08-02T00:00:00Z"
+  "generated_at": "2026-08-02T00:00:00Z",
+  "signature": {
+    "algorithm": "p256-sha256",
+    "signature": "<base64url-fixed-signature>"
+  }
 }
 ```
 
+Generate each report next to the reproduced artifact and bounded build log:
+
+```bash
+cellc artifact reproduction-report acme/vault-lock@1.0.0 \
+  --artifact target/vault-lock \
+  --build-log reports/builder-a.log \
+  --builder-id builder-a \
+  --trust-domain independent-org-a \
+  --builder-key-id cap_<sha256-prefix> \
+  --builder-public-key 'p256-spki:<base64url-der>' \
+  --output reports/builder-a.json
+```
+
+The corresponding private key must be isolated per builder. Load it from that
+builder's OS keychain entry, or set
+`CELLSCRIPT_REPRODUCER_PRIVATE_KEY_PKCS8_B64` only in its CI environment.
+
 Create the operator promotion payload locally:
 
 ```bash
@@ -248,9 +275,14 @@ cellc artifact reproduction-evidence acme/vault-lock@1.0.0 \
   --output reproduced-build-promotion.json
 ```
 
-The CLI and API require two to sixteen distinct builder IDs and exact matches
-for the signed environment, source, recipe, and executable. The promotion also
-references the accepted `verified_build` evidence. A reproducible artifact
+The CLI verifies every report signature and requires distinct builder IDs,
+public keys, and trust domains. The API additionally requires each builder to
+match `REGISTRY_REPRODUCER_POLICY_JSON` and enforces its configured minimum
+trust-domain count. Both layers require exact matches for the signed environment,
+source, recipe, executable, and build log. The promotion also references the
+accepted `verified_build` evidence. Accepted evidence records the canonical
+policy SHA-256 and the threshold used for that decision, so later policy
+rotation cannot rewrite the historical trust boundary. A reproducible artifact
 stays `evidence_required`, and deployment admission fails, until
 `reproduced_build` evidence is accepted.
 
@@ -299,9 +331,10 @@ Type/Lock hashes, and a wallet-ready mainnet transaction intent. The wallet,
 not the Registry or CLI, completes capacity, inputs, change, fee, witnesses,
 signatures, and broadcast.
 
-The Registry accepts an on-chain attestation only after reading the live
-mainnet Cell and matching its exact data, configured attestor Lock, and
-configured Registry Type Script. Scheduled maintenance uses an exact Type
+The Registry accepts an on-chain commitment only after reading a sufficiently
+confirmed live mainnet Cell and matching its exact data, configured commitment
+Lock, and configured Registry Type Script. Readiness separately resolves and
+checks the Type and Lock code CellDeps. Scheduled maintenance uses an exact Type
 Script indexer query plus the `CSREGv1` prefix to discover commitments and
 reconcile their live lifecycle.
 
@@ -313,8 +346,10 @@ application's own Lock/Type Scripts, schemas, and replacement transactions.
 
 The website presents a single “Connect CKB wallet” entry. Its modal separates
 CCC-detected browser signers, which can connect immediately, from wallet
-directory entries, which open an official site and continue through the manual
-payload/signature path. A directory entry is never reported as connected.
+directory entries, which only open an external site and then require a
+compatible manually produced `wallet-signature.json`. A directory entry is a
+reference/import route, not proof that the wallet exposes a compatible message
+signing UI, and is never reported as connected.
 Network selection is not exposed because authorisation and deployment are
 mainnet-only.
 
@@ -324,8 +359,10 @@ never leave the wallet. Namespace ownership, capability scope, expiry,
 revocation, nonce consumption, idempotency, quotas, and audit events are
 enforced by the API.
 
-The submit form remains hidden until a wallet principal is connected or the
-publisher explicitly confirms that an active capability already exists.
+The submit form remains hidden until a direct signer is connected, a manual
+signature-import route is explicitly selected, or the publisher confirms that
+an active capability already exists. Manual payloads remain untrusted until
+the API verifies their principal binding and signature.
 
 ## Public Reads
 
@@ -378,8 +415,9 @@ that every artifact is installable.
   other mirror failures are audited and retried by verification sync, so an
   uncommitted release or deployment is never advertised as current.
 - State transitions append evidence; they do not mutate hash identity.
-- An unconfigured or partially configured Registry Type/Lock Script set cannot
-  produce a wallet transaction intent or current attestation.
+- An unconfigured, partially configured, spent, or insufficiently confirmed
+  Registry Type/Lock Script and CellDep set cannot produce a wallet transaction
+  intent or current commitment.
 
 ## Validation