[0.30][Acceptance] Build the canonical Rust-comparable CKB business corpus

[a19q3]

Summary

Create the canonical CellScript 0.30 business-equivalence corpus. It turns the claim that CellScript is broadly comparable to hand-written Rust CKB contracts at the application layer into a finite, reproducible release contract with positive, adversarial, stateful, economic, and deployment evidence.

This issue owns the portfolio and its cross-feature composition. Individual language and runtime mechanisms remain owned by their existing issues. A scenario is admitted only when all mechanisms it needs work together through the same authoring, persistent-policy, builder, CKB-VM, and evidence paths promised for 0.30.

Required business families

Fungible asset

• authorized mint, transfer, bounded split, bounded merge, and burn;
• replay, missing/extra Cell, wrong amount, overflow, identity, and authorization failures;
• total-supply or transaction-local conservation policy; and
• one persistent policy identity across the complete lifecycle.

NFT or DOB

• mint with unique identity;
• metadata update and ownership transfer;
• capacity adjustment and burn; and
• duplicate identity, stale state, wrong Lock/Type, and unauthorized update rejection.

Order and AMM

• partial fill or partial order under one persistent order policy;
• variable-cardinality payment or asset inputs;
• settlement across interacting resource and Script groups;
• fee, reserve/accounting, slippage or price-bound checks;
• authenticated dependency or oracle identity; and
• cancellation, replay, output reordering, partial-settlement, and wrong-price failures.

Temporal

• absolute and relative timelock;
• vesting transition;
• typed epoch, timestamp, block-number, and Since handling;
• required header-dependency behavior; and
• cross-domain, missing-header, early-release, overflow, and boundary failures.

Authorization

• standard single-signature or maintained Lock integration;
• multisig creation, threshold change, proposal/spend, and cancellation;
• issuer authority and exact Script identity;
• post-signing mutation rejection; and
• copied-public-owner, wrong-message-domain, wrong-key, partial-signature, and replay failures.

Committed state

• authenticated witness opening;
• successor commitment construction;
• stale, malformed, wrong-root, wrong-index, and wrong-successor rejection; and
• shared witness-envelope composition with action arguments and output plans.

Multi-Script composition

• at least three independently built artifacts in one transaction;
• interacting Type and Lock groups with shared Cells, dependencies, or witnesses;
• ProtocolBundle role/index/witness/CellDep resolution and conflict reporting;
• per-group execution and error attribution; and
• exact package, interface, artifact, deployment, VM, ABI, and network identities.

External verifier

• one real protocol or cryptographic verifier invoked by exact identity through EXEC or SPAWN/WAIT;
• accepted and rejected protocol vectors;
• wrong dependency, hash, adapter, argument, applicability, statement, child status, and post-build substitution failures; and
• explicit trusted-external evidence without a compiler claim over verifier internals.

Reference and fixture contract

For every scenario where an equivalent maintained Rust implementation is practical:

• freeze the Rust source commit, toolchain, Cargo lock, target, profile, dependency identities, and build script;
• run both implementations against the same canonical serialized transaction fixtures;
• require equal accept/reject outcomes and attribute any differing error surface;
• bind fixture, source, ELF, sidecar, transaction, and measurement hashes in the report;
• measure complete transaction cycles and, where possible, isolate the principal Script group;
• report ELF size, stack, witness bytes, transaction size, occupied capacity, and dependencies; and
• keep counterexamples and regressions instead of narrowing the corpus after a failure.

A missing or unreachable pinned source invalidates reproducibility evidence. A matched cost row proves only its named scope and build profile.

Cross-feature composition rule

Support for feature A and feature B in separate compilation paths does not establish support for A and B together. Every required scenario must use the same 0.30 path promised to users, including persistent action selection, dynamic roles, complex payloads, authorization, external dependencies, and generated builders where applicable.

The anchor fixture is a coherent authenticated partial-fill order or settlement protocol combining:

• one persistent multi-action order policy;
• variable-cardinality asset or payment inputs;
• multiple resource and Script roles;
• an authenticated dependency or verifier;
• partial fill, cancel, and settle actions;
• generated construction and signing; and
• a stateful positive lifecycle plus adversarial mutations.

Evidence layers

Each corpus row must record separately:

• parser/type/IR acceptance;
• metadata and standalone-checker result;
• simulator result where applicable;
• CKB-VM result;
• stateful bookkeeping result;
• node dry-run/admission result for release candidates;
• builder and signing result;
• deployment identity and network scope;
• cycles and size measurements; and
• independent review status.

No lower evidence layer may be relabeled as a higher one.

Completion criteria

• Every required family has a frozen source and transaction-fixture inventory.
• The anchor composition fixture combines persistent policy, dynamic groups, multiple resources, and authenticated dependency behavior.
• Every positive lifecycle consumes outputs produced by earlier verified steps where state continuity matters.
• Every scenario has explicit adversarial mutations and stable expected outcomes.
• Matched Rust references are pinned, retrievable, reproducible, and run against identical fixtures.
• CellScript and Rust agree on every matched accept/reject outcome, or any intentional semantic difference is specified and separately accepted.
• Builders, signing, CKB-VM, stateful execution, and node admission agree on the exact candidate artifacts.
• Resource budgets are recorded and enforced without removing required checks.
• All issue dependencies required by the frozen corpus are complete.
• dev, ci, backend, and applicable release gates pass.
• Independent security review covers the anchor composition fixture and each new consensus-facing mechanism.

Non-goals

• a percentage estimate of all possible Rust contracts;
• one example per business name without cross-feature composition;
• changing fixtures to hide an outcome or cost regression;
• counting external verifier semantics as compiler-proved; or
• requiring unrestricted recursion, unbounded collections, raw syscalls, inline assembly, or a circuit DSL.

Dependencies

• [Candidate][Consensus runtime] Implement executable bounded Cell-group consumption #7 and [Candidate][Consensus runtime] Implement executable bounded output-plan correspondence #8 for variable-cardinality input and output lifecycles;
• [Architecture][Builder] Add an artifact-only multi-Script ProtocolBundle #9 through [Language/ABI] Bind runtime Script values to verified package interfaces #11 for ProtocolBundle, cross-Script roles, and exact handles;
• [Language/stdlib] Add typed CKB temporal and Since domains #12 and [Language design] Add explicit typed openings for digest-committed substate #13 for temporal and committed-state scenarios;
• [Toolchain][Workspace][P1] Replace member-loop builds and synthetic workspace locks with a canonical graph #15 through [Toolchain][Upgrade] Add a transactional package, interface, and deployment upgrade plan #20 for reproducible packages, chain identity, build plans, and upgrades;
• [Language design] Choose a stable surface for value generics and public API signatures #23 for stable public value-generic APIs;
• [0.30][Runtime] Complete typed bounded CKB transaction-view and syscall adapters #24 for typed CKB transaction views and runtime adapters; and
• [0.30][Security] Define cryptographic capability and authorization-domain contracts #25 for cryptographic and authorization-domain contracts.