[0.30][Release] Close product, publication, and deployment evidence

[a19q3]

Summary

Close the end-to-end CellScript 0.30 product, publication, and deployment boundary for the frozen business corpus in #26. This issue prevents compiler-only or local-VM evidence from being presented as a complete release when builders, language services, browser artifacts, package identities, node admission, or deployment records still describe a smaller or different capability set.

The candidate release path may jump directly from 0.25 to 0.30. The 0.26b branch and unreleased 0.26 implementation record are development evidence and may be folded into 0.30 without a stable 0.26 publication.

Required product closure

Compiler and packages

• set the Cargo/package version only when the release-candidate compatibility contract is accepted;
• assign exact source-semantics, cache, metadata, constraints, typed-semantics, lowering, source-map, witness, output-plan, policy, and target-profile versions;
• enforce package-declared compiler requirements before source loading;
• resolve one canonical package graph with exact source, feature, edition, environment, chain, and deployment identities; and
• provide transactional interface, builder, lockfile, and deployment upgrade reports.

Builders and transaction construction

• generate complete typed TypeScript and Rust-facing builders for every [0.30][Acceptance] Build the canonical Rust-comparable CKB business corpus #26 entry;
• materialize complex typed parameters instead of requiring opaque pre-encoded bytes unless the ABI explicitly declares an opaque boundary;
• merge dynamic group indexes, output plans, shared witnesses, CellDeps, header dependencies, fees, capacity, and change through ProtocolBundle;
• preserve standard signing fields and reject post-signing mutation;
• validate the same roles, bounds, ordering, identities, and output correspondence enforced on chain; and
• expose deterministic transaction and evidence hashes.

Language services and browser product

• keep parser diagnostics, formatter, hover, completion, definition, semantic summaries, snippets, and syntax highlighting aligned with the accepted authoring surface;
• rebuild the metadata-only WASM compiler from the exact candidate source;
• pass the tracked gzip budget or introduce an accepted versioned product split rather than reusing a stale bundle;
• expose edition/profile/capability selection without presenting metadata-only output as an ELF; and
• keep the website, CLI, VS Code extension, docs, examples, and Registry surface on the same published compatibility boundary.

Artifact and deployment evidence

• independently validate exact candidate ELF and sidecars;
• reproduce CKB-VM and stateful acceptance from a clean source tree;
• run node dry-run/admission for the declared network and VM/hash-type contract;
• record code Cell, CellDep, Script, package, interface, artifact, deployment, chain, and confirmation identities;
• measure cycles, stack, code size, transaction size, witness bytes, and occupied capacity; and
• retain per-artifact and per-Script-group evidence when composing transactions.

Release-version policy

• 0.30 is an implementation branch until all required gates pass.
• No Cargo version or stable package is changed merely because the branch exists.
• A stable 0.26 tag is optional and must not be created solely for sequential numbering.
• If 0.26 is skipped, release notes must clearly identify 0.25 as the predecessor and list every compatibility-axis change absorbed from 0.26b.
• Preview4 and authoring1 retain their recorded meanings; accepted 0.30 semantics receive a new identity rather than silently redefining either.
• Existing Data1 deployments are not relabeled as VM2/Data2 artifacts.
• A failed or partial release gate leaves a development identity and cannot be published as capability-complete 0.30.

Implementation phases

Phase 0 — release manifest

• freeze the [0.30][Acceptance] Build the canonical Rust-comparable CKB business corpus #26 corpus and all required issue dependencies;
• enumerate every version and compatibility axis;
• decide and record whether stable 0.26 is skipped;
• define exact release artifacts, signing/publishing actors, networks, and evidence outputs; and
• make missing product or deployment evidence machine-readable.

Phase 1 — product parity

• complete builders, ProtocolBundle integration, CLI, LSP, VS Code, WASM, website, Registry, docs, and examples;
• add cross-consumer schema/version tests; and
• reject stale generated assets and stale compatibility summaries.

Phase 2 — clean candidate replay

• run dev, ci, and backend on the exact candidate;
• rebuild every generated artifact and require a clean tree;
• run the full [0.30][Acceptance] Build the canonical Rust-comparable CKB business corpus #26 simulator, CKB-VM, stateful, builder, signing, and differential corpus;
• reproduce pinned external dependencies and Rust references; and
• complete independent security reviews.

Phase 3 — release and deployment evidence

• run the applicable release gate with pinned CKB, SDK, Docker, RISC-V, WASM, Registry, and external-verifier dependencies;
• perform node dry-run/admission and the selected testnet/mainnet deployment workflow;
• verify confirmations and read back exact on-chain identities; and
• publish packages, editor/browser artifacts, documentation, and release records only after all identities agree.

Completion criteria

• All required [0.30][Acceptance] Build the canonical Rust-comparable CKB business corpus #26 corpus rows and dependency issues are complete.
• Compiler, packages, builders, CLI, LSP, VS Code, WASM, website, Registry, docs, and checker report one capability boundary.
• Generated builders cover complex parameters, dynamic roles, output plans, shared witnesses, and signing.
• Canonical package graph, compiler requirements, chain identity, build plan, and transactional upgrade behavior are enforced.
• Fresh browser and editor artifacts are rebuilt from the candidate and pass their budgets/checks.
• Exact candidate source, ELF, sidecars, fixtures, external dependencies, and Rust references are reproducible.
• dev, ci, backend, and applicable release gates pass from clean source.
• Node admission and selected-network deployment evidence are recorded with exact identities.
• Independent security review is complete and remaining exclusions are explicitly published.
• Stable version, tag, package publication, and release notes are created only after every prior item passes.

Non-goals

• treating a development branch name as a released version;
• reusing stale WASM, VSIX, builder, evidence, or deployment assets;
• using local CKB-VM execution as a substitute for node or chain evidence;
• publishing a stable 0.26 solely for numbering continuity; or
• claiming arbitrary Rust parity beyond the bounded [0.30][Acceptance] Build the canonical Rust-comparable CKB business corpus #26 portfolio.

Dependencies

• [Docs/strategy] Separate executable-surface closure from product capability completeness #14 for capability/product-completeness classification;
• [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 package graph, resolver, compiler requirements, build plans, chain identity, and upgrades;
• [0.30][Runtime] Complete typed bounded CKB transaction-view and syscall adapters #24 and [0.30][Security] Define cryptographic capability and authorization-domain contracts #25 for the new runtime and cryptographic contracts;
• [0.30][Acceptance] Build the canonical Rust-comparable CKB business corpus #26 for the frozen release corpus; and
• all semantic/runtime issues selected by that corpus.