xoonya 3.1.17 → 3.2.0

package/PARTNER_READY_PATH.md

@@ -1,67 +0,0 @@
-# xoonya Partner-Ready Path
-
-Use this path when you want to evaluate `xoonya` as an external proof-side integration surface without relying on private milestone history.
-
-## What this path is for
-
-This is the shortest partner-facing route for teams that need to:
-
-- review the proof-side boundary after runtime execution
-- understand what belongs in `xoonya` versus `xytara`
-- confirm how proof-adjacent integrations stay narrow and reviewable
-- leave with one concrete demo path, one proof contract path, and one lightweight integration path
-
-## Recommended reading order
-
-1. Read `START_HERE.md`.
-2. Read `CARRIED_HANDOFF_DEMO.md`.
-3. Read `CROSS_RUNTIME_POSTURE.md`.
-4. Read `integrations/PROOF_INTEGRATION_PROCESS.md`.
-5. Read `COMPATIBILITY_NOTE.md` if you need the narrower legacy bridge posture.
-
-## Recommended first commands
-
-Run these from a cloned `xoonya` repository:
-
-```bash
-node examples/package_quickstart.js
-npm run verify:examples
-npm run verify:release-candidate
-node scripts/registry_cli.js validate-registration --example verifier
-node scripts/registry_cli.js promotion-readiness --integration partner.verifier.lattice_notary
-```
-
-## Recommended first surfaces
-
-- `/v1/release-center/summary`
-- `/v1/proof-center/summary`
-- `/v1/proof-center/result-package-handoff/summary`
-- `/v1/integrations/summary`
-- `/v1/integrations/promotion-readiness`
-
-## First success standard
-
-First success is not "expand proof scope until it acts like the runtime."
-
-First success is:
-
-1. receive one reviewable handoff from `xytara`
-2. inspect proof-side review posture
-3. emit one proof-native completion path
-4. validate one lightweight proof-adjacent integration boundary
-5. keep commerce, pricing, workflow, and settlement semantics outside the proof kernel
-
-## Boundary rule
-
-If an integration needs pricing, funding, workflow orchestration, or settlement logic to make sense, it belongs in `xytara`.
-
-If it can remain a narrow proof helper, registry reference, or verifier-facing addition, it can belong in `xoonya`.
-
-## Hand-off rule
-
-If an outside team leaves this path with only four references, they should be these:
-
-- `START_HERE.md`
-- `CARRIED_HANDOFF_DEMO.md`
-- `CROSS_RUNTIME_POSTURE.md`
-- `integrations/PROOF_INTEGRATION_PROCESS.md`

package/PUBLIC_DEMO_SCRIPT.md

@@ -1,79 +0,0 @@
-# xoonya Public Demo Script
-
-Use this script when you need a short external-facing walkthrough of `xoonya` that does not depend on milestone history.
-
-## Goal
-
-Show the proof side of the public stack in one compact flow:
-
-1. package is live
-2. proof center is understandable
-3. runtime handoff review is concrete
-4. proof-side integration posture is narrow and explicit
-
-## Recommended order
-
-### 1. Release posture
-
-Run:
-
-```bash
-xoonya-release --center --summary
-xoonya-release --candidate --summary
-```
-
-Or inspect:
-
-- `/v1/release-center/summary`
-- `/v1/release-candidate/summary`
-
-### 2. Proof center posture
-
-Inspect:
-
-- `/v1/proof-center/summary`
-- `/v1/proof-center/result-package-handoff/review/summary`
-
-Key sentence to say out loud:
-
-`xoonya` is the proof-native completion layer, not a second runtime.
-
-### 3. Public proof walkthrough
-
-Run:
-
-```bash
-node examples/partner_proof_walkthrough.js
-```
-
-Then, if you want the broader package tour:
-
-```bash
-node examples/package_quickstart.js
-```
-
-### 4. Partner adoption path
-
-Open:
-
-- `PARTNER_READY_PATH.md`
-- `integrations/PROOF_INTEGRATION_PROCESS.md`
-
-Key sentence to say out loud:
-
-Proof-adjacent integrations stay narrow and reviewable instead of absorbing commerce logic.
-
-### 5. Stack positioning
-
-Open:
-
-- `CARRIED_HANDOFF_DEMO.md`
-- `WHY_XYTARA_XOONYA.md`
-
-Key sentence to say out loud:
-
-`xoonya` receives carry from `xytara`, reviews it, and emits deterministic proof-native completion.
-
-## Good ending line
-
-`xoonya` is the public proof system: receive carry, review posture, emit proof, verify the final bundle.

package/SERVICE_CONTRACT.md

@@ -1,207 +0,0 @@
-# xoonya Service Contract
-
-This file freezes the public service contract for `xoonya`.
-
-## Public Routes
-
-Primary proof-model routes:
-
-- `GET /health`
-- `GET /openapi.json`
-- `GET /v1/openapi`
-- `GET /v1/openapi/summary`
-- `GET /asyncapi.json`
-- `GET /v1/asyncapi`
-- `GET /v1/asyncapi/summary`
-- `GET /cloudevents.json`
-- `GET /v1/cloudevents`
-- `GET /v1/cloudevents/summary`
-- `GET /v1/auth-profiles`
-- `GET /v1/auth-profiles/summary`
-- `GET /v1/identity-interop`
-- `GET /v1/identity-interop/summary`
-- `GET /v1/providers`
-- `GET /v1/providers/summary`
-- `GET /v1/frameworks`
-- `GET /v1/frameworks/summary`
-- `GET /v1/integration-matrix`
-- `GET /v1/integration-matrix/summary`
-- `GET /v1/major-rails`
-- `GET /v1/major-rails/summary`
-- `GET /v1/treasury`
-- `GET /v1/treasury/summary`
-- `GET /v1/erc8004`
-- `GET /v1/erc8004/summary`
-- `GET /v1/proof-bridge`
-- `GET /v1/proof-bridge/summary`
-- `GET /v1/external-proof-import`
-- `GET /v1/external-proof-import/summary`
-- `GET /v1/result-package-trust`
-- `GET /v1/result-package-trust/summary`
-- `GET /v1/event-systems`
-- `GET /v1/event-systems/summary`
-- `GET /v1/telemetry`
-- `GET /v1/telemetry/summary`
-- `GET /v1/provenance`
-- `GET /v1/provenance/summary`
-- `GET /v1/artifact-distribution`
-- `GET /v1/artifact-distribution/summary`
-- `GET /v1/shared-signals`
-- `GET /v1/shared-signals/summary`
-- `GET /v1/feature-control`
-- `GET /v1/feature-control/summary`
-- `GET /v1/adapter-certification`
-- `GET /v1/adapter-certification/summary`
-- `GET /v1/adapter-certification/:front_id`
-- `GET /v1/trust-portability-boundary`
-- `GET /v1/trust-portability-boundary/summary`
-- `GET /v1/trust-portability-boundary/:axis_id`
-- `GET /v1/signed-audit-provenance`
-- `GET /v1/signed-audit-provenance/summary`
-- `GET /v1/signed-audit-provenance/:surface_id`
-- `GET /v1/integrations`
-- `GET /v1/integrations/summary`
-- `GET /v1/integrations/snapshot`
-- `GET /v1/integrations/promotion-readiness`
-- `GET /v1/integrations/promotion-workflow`
-- `GET /v1/proof-center`
-- `GET /v1/proof-center/summary`
-- `GET /v1/proof-center/native-standard`
-- `GET /v1/proof-center/native-standard/summary`
-- `GET /v1/proof-center/native-hybrid-readiness`
-- `GET /v1/proof-center/native-hybrid-readiness/summary`
-- `GET /v1/proof-center/native-standardization`
-- `GET /v1/proof-center/native-standardization/summary`
-- `GET /v1/proof-center/native-conformance-mark`
-- `GET /v1/proof-center/native-conformance-mark/summary`
-- `GET /v1/proof-center/native-reference-implementations`
-- `GET /v1/proof-center/native-reference-implementations/summary`
-- `GET /v1/proof-center/native-atom-spec`
-- `GET /v1/proof-center/native-atom-spec/summary`
-- `GET /v1/proof-center/native-atom-conformance`
-- `GET /v1/proof-center/native-atom-conformance/summary`
-- `GET /v1/proof-center/native-anchor-profile`
-- `GET /v1/proof-center/native-anchor-profile/summary`
-- `GET /v1/proof-center/native-payload-profile`
-- `GET /v1/proof-center/native-payload-profile/summary`
-- `GET /v1/proof-center/native-line-rate-frame`
-- `GET /v1/proof-center/native-line-rate-frame/summary`
-- `GET /v1/proof-center/import-adapter`
-- `GET /v1/proof-center/import-adapter/summary`
-- `POST /v1/proof-center/import-adapter/review`
-- `POST /v1/proof-center/import-adapter/review/summary`
-- `POST /v1/proof-center/import-adapter/run`
-- `GET /v1/proof-center/governance`
-- `GET /v1/proof-center/governance/summary`
-- `GET /v1/proof-center/bridge`
-- `GET /v1/proof-center/bridge/summary`
-- `GET /v1/proof-center/bridge/profile-support`
-- `POST /v1/proof-center/governance/interpretation-validate`
-- `POST /v1/proof-center/governance/coordination`
-- `POST /v1/proof-center/governance/dashboard`
-- `POST /v1/proof-center/governance/operator-view`
-- `POST /v1/proof-center/governance/admin-view`
-- `POST /v1/proof-center/governance/dashboard-pack`
-- `POST /v1/proof-center/governance/workflow-pack`
-- `POST /v1/proof-center/governance/signoff-pack`
-- `POST /v1/proof-center/governance/disputes/summary`
-- `POST /v1/proof-center/governance/disputes/case-review`
-- `POST /v1/proof-center/governance/disputes/action`
-- `POST /v1/proof-center/governance/disputes/case-bundle`
-- `POST /v1/proof-center/governance/disputes/resolution-pack`
-- `POST /v1/proof-center/governance/console-pack`
-- `POST /v1/proof-center/governance/handoff-bundle`
-- `POST /v1/proof-center/governance/review-link`
-- `POST /v1/proof-center/bridge/receipt-wrap`
-- `POST /v1/proof-center/bridge/validator-verify`
-- `POST /v1/proof-center/bridge/receipt-ledger-handoff`
-- `POST /v1/proof-center/bridge/economic-handoff`
-- `POST /v1/proof-center/bridge/economic-conformance-pack`
-- `POST /v1/proof-center/bridge/operator-review-pack`
-- `POST /v1/proof-center/bridge/compatibility-pack`
-- `POST /v1/proof-center/bridge/workflow-pack`
-- `POST /v1/proof-center/bridge/admin-pack`
-- `POST /v1/events/canonicalize`
-- `POST /v1/events/hash`
-- `POST /v1/receipts/emit`
-- `POST /v1/proof-bundles/build`
-- `POST /v1/proof-bundles/verify`
-
-Compatibility routes:
-
-- `POST /validate`
-- `POST /v1/receipts/verify`
-- `POST /v1/receipts/inspect`
-- `POST /v1/proofs/verify`
-- `POST /v1/profiles/economic/verify`
-- `POST /v1/profiles/registry/verify`
-
-## Error-Shape Expectations
-
-Primary error posture:
-
-- invalid request payloads return `400`
-- unknown routes return `404`
-- unexpected server failures return `500`
-
-Expected error shapes:
-
-- validation-style failures:
-  - `{ "valid": false, "reason": "<message>" }`
-- not found:
-  - `{ "status": "not_found", "path": "<path>" }`
-- server failure:
-  - `{ "status": "error", "reason": "<message>" }`
-
-Compatibility routes may return proof/profile-specific verification payloads, but the top-level shape should still remain predictable.
-
-Interop note:
-
-- `GET /v1/identity-interop` exposes how native proof, attestation, and bridge surfaces map to `JWT`, `DID/VC`, and `SD-JWT VC` interop lanes without replacing canonical proof truth inside `xoonya`
-- `GET /v1/major-rails` exposes the Solana and Antelope/Proton XPR/Metal proof family as one practical settlement-evidence lane
-- `GET /v1/treasury` exposes treasury destination/accounting evidence continuity while keeping DAI/USDC and Monero reserve doctrine clearly internal
-- `GET /v1/external-proof-import` exposes the result, receipt, and proof-bundle import family as one builder-trust lane
-- `GET /v1/result-package-trust` exposes the carried result-package trust continuity posture as a first-class proof-side lane
-- `GET /v1/providers` exposes the OpenAI Codex and Claude/MCP family as first-class provider-origin proof lanes
-- `GET /v1/frameworks` exposes LangGraph, LangChain, AutoGen, and Semantic Kernel as first-class framework followthrough lanes
-- `GET /v1/integration-matrix` exposes the canonical public view across providers, frameworks, proof lanes, and registry-backed proof integrations
-- `GET /v1/telemetry` exposes the OpenTelemetry-aligned proof observability posture across review, verification, bridge, and proof event signals
-- `GET /v1/provenance` exposes the SLSA-aligned provenance posture for proof artifacts, release trust, and bundle followthrough confidence
-- `GET /v1/artifact-distribution` exposes OCI-style artifact distribution posture for proof bundles, handoff bundles, snapshots, and release artifacts
-- `GET /v1/shared-signals` exposes OpenID Shared Signals and CAEP-aligned review, bridge, import, and trust event exchange posture
-- `GET /v1/feature-control` exposes OpenFeature/OFREP-aligned rollout and review portability posture around role freeze, bridge, trust, and release gates
-- `GET /v1/adapter-certification` exposes the front-specific adapter certification contract and its machine-readable compatibility states
-- `GET /v1/trust-portability-boundary` exposes the bounded trust portability contract for identity, delegation, delivery, and settlement-linked followthrough
-- `GET /v1/signed-audit-provenance` exposes the signed audit and provenance surface map for selected evidence-bearing proof and release lanes
-
-## Final-Loop Verification
-
-The constitutional proof loop for `xoonya` is:
-
-1. canonicalize event
-2. hash event
-3. emit receipt
-4. build proof bundle
-5. verify proof bundle
-
-Bridge-side economic carry should use:
-
-1. pass deterministic runtime economics through `POST /v1/proof-center/bridge/economic-handoff`
-2. prefer the canonical `handoff_bundle` wrapper emitted by `xytara`
-3. review the preserved usage-meter and credit-spend consequence through `POST /v1/proof-center/bridge/economic-conformance-pack`
-4. keep proof itself minimal while preserving the economic handoff as a bounded bridge/export surface
-
-Normal result-package handoff should also accept carried economics when present:
-
-1. send the normal result-package `handoff_bundle`
-2. include `handoff_bundle.economic_consequence_handoff_bundle` when the transaction-side path was credit-backed and metered
-3. expect `POST /v1/proof-center/result-package-handoff/run` and review-summary surfaces to expose compact economic-conformance review data automatically
-4. omit that bundle entirely on direct-pay or non-metered paths without changing proof intake behavior
-
-This loop is exercised through:
-
-- package verification
-- example verification
-- service verification
-- conformance/adversarial vector verification
-- public `xoonya conformance` and `xoonya conformance --json` commands

package/TERMINOLOGY.md

@@ -1,55 +0,0 @@
-# xoonya Terminology
-
-This file freezes the public terminology used by `xoonya`.
-
-The goal is simple:
-
-- one public name for the repo
-- one stable set of proof terms
-- no private-lineage naming leakage
-
-## Public Name
-
-- repo name: `xoonya`
-- package name: `xoonya`
-- service name: `xoonya`
-
-Use `xoonya` only for this repo and its public proof product identity.
-
-## Preferred Proof Terms
-
-Use these terms consistently:
-
-- `Canonical Event Bundle`
-- `Receipt`
-- `Proof Bundle`
-- `Profiles`
-- `deterministic canonicalization`
-- `deterministic hashing`
-- `conformance vectors`
-- `adversarial vectors`
-
-## Terms To Avoid In Public Copy
-
-Avoid older private-lineage naming in release-facing docs unless explicitly discussing lineage.
-
-Avoid:
-
-- internal project names as product labels
-- multiple public names for the same proof object
-- receipt-first wording that hides the canonical event model
-
-## Cross-Repo Reference Rule
-
-If this repo needs to mention the other repo, use generic wording:
-
-- `the commerce repo`
-- `the commerce layer`
-
-Do not brand the other repo inside this repo's core public copy.
-
-## Naming Rule
-
-This repo should read like a self-contained public proof product.
-
-If wording does not strengthen that outcome, keep it generic.

package/WHY_XYTARA_XOONYA.md

@@ -1,43 +0,0 @@
-# Why xytara And xoonya
-
-The public stack is intentionally split because machine runtime and canonical proof should not collapse into one confused boundary.
-
-## xytara
-
-`xytara` handles the runtime side:
-
-- discover
-- quote
-- fund or spend
-- execute
-- inspect
-- export carry
-
-## xoonya
-
-`xoonya` handles the proof side:
-
-- receive carry
-- review preserved context
-- emit canonical proof artifacts
-- verify the final proof bundle
-
-## Why this matters
-
-If proof owns payment and settlement logic, it stops being a clean proof kernel.
-
-If runtime owns canonical proof semantics, it becomes harder to keep the proof boundary stable and reusable.
-
-The split preserves both:
-
-- runtime remains operational and economics-aware
-- proof remains deterministic and narrow
-
-## Public stack outcome
-
-Builders should think about the stack like this:
-
-1. `xytara` gets the work done
-2. `xoonya` makes the resulting evidence durable and reviewable
-
-That separation is the reason the stack can stay broad on the runtime side and disciplined on the proof side at the same time.

package/XNYA_CONFORMANCE_MARK.md

@@ -1,78 +0,0 @@
-# XNYA Conformance Mark
-
-`XNYA-compatible` is the compatibility mark for implementations that preserve the xoonya Native atom, payload, proof-envelope, and vector behavior exactly enough for deterministic machine evidence to remain portable.
-
-The mark is not an identity, auth, custody, transport-security, settlement, chain-finality, or external-provider truth claim.
-
-## Required Meaning
-
-An implementation may claim `XNYA-compatible` only when it can show:
-
-- the native atom magic is exactly `XNYA`
-- atom versions and fixed sizes match the published spec
-- payload and identity hash derivation match the published vectors
-- required native methods either verify or are explicitly declared unsupported
-- adversarial vectors fail with stable error codes
-- `algorithm: "none"` is rejected for production proof
-- anchor binding does not claim independent external chain or provider truth
-
-## Required Artifacts
-
-The following artifacts define the current conformance floor:
-
-- `XOONYA_NATIVE_PROOF_FORMAT.md`
-- `XOONYA_NATIVE_ATOM_SPEC.md`
-- `XOONYA_NATIVE_STANDARD_GOVERNANCE.md`
-- `XNYA_CONFORMANCE_MARK.md`
-- `vectors/conformance-vectors.json`
-- `vectors/adversarial-vectors.json`
-- `vectors/native-atom-vectors.json`
-- `vectors/native-payload-profile-vectors.json`
-
-## Required Checks
-
-At minimum, a compatible implementation must pass equivalent checks to:
-
-```bash
-xoonya first-run --verify-native --pretty
-xoonya conformance --json
-npm run verify:release-candidate
-npm run verify:service
-```
-
-Non-JavaScript implementations should publish deterministic pass/fail output against the same vector IDs, byte layouts, and error-code expectations.
-
-## Allowed Claim Classes
-
-`xnya_atom_compatible` means the implementation preserves `XNYA` atom bytes, lengths, versions, record types, hash derivation, and reject codes.
-
-`xnya_payload_profile_compatible` means the implementation preserves the `XNYP` binary payload profile: typed fields, canonical ordering, fixed-width integers, explicit unknown-field policy, and no loose JSON or float semantics.
-
-`xnya_native_proof_compatible` means registered native methods verify through the declared suite registry, reject `algorithm: "none"`, and keep signatures, anchors, and external references outside the atom core.
-
-`xnya_external_interop_compatible` means external proof envelopes are bound to canonical xoonya receipts without claiming issuer, DID, JWT, SD-JWT, chain, or partner-provider truth unless an external verifier is declared and bound.
-
-## Forbidden Claims
-
-Do not claim the mark if:
-
-- `XNYA` magic, fixed sizes, version semantics, or atom layout are changed
-- `algorithm: "none"` verifies as production proof
-- happy-path vectors pass but adversarial vectors are skipped
-- PQ/hybrid support is claimed without validators, vectors, downgrade tests, and deterministic error codes
-- external issuer, chain, finality, custody, or provider truth is claimed as xoonya-verified without a declared external verifier
-- the mark is used to imply login, session, wallet, custody, payment, transport, or regulatory compliance behavior
-
-## Extra Evidence Gates
-
-PQ/hybrid native verification requires non-experimental validators, suite-specific public-key rules, positive conformance vectors, adversarial downgrade vectors, and deterministic error codes.
-
-Live external framework-provider compatibility requires real external endpoints, auth boundaries, health checks, failure behavior, latency evidence, and live execution checks.
-
-New signature suites require suite-specific validators plus wrong-key, wrong-method, tamper, and downgrade vectors before they can move from registry/planned status to implemented status.
-
-## Governance
-
-The mark should stay tied to concrete artifacts, not brand aspiration. New public mark claims require docs, vectors, deterministic error codes, release-candidate checks, and service surfaces before public use.
-
-The reference implementation ships inside the `xoonya` npm package until external adoption or governance pressure justifies a separate standards repository.

package/XNYA_REFERENCE_IMPLEMENTATIONS.md

@@ -1,157 +0,0 @@
-# XNYA Reference Implementations
-
-`XNYA-compatible` needs independent implementations, not only one JavaScript package. This document defines how xoonya treats reference implementations without overclaiming maturity before vector parity exists.
-
-## Current Reference
-
-The current canonical reference implementation ships inside the `xoonya` npm package:
-
-- `proof_sdk.js` contains the canonical JavaScript helpers, validators, proof builders, and pack generators.
-- `vectors/` contains the positive and adversarial conformance inputs.
-- `bin/xoonya.js` exposes first-run and conformance checks.
-- `bin/xoonya-release.js` exposes public release and standardization artifacts.
-- `server.js` exposes the proof-center JSON surfaces.
-
-Required checks:
-
-```bash
-npm run verify:release-candidate
-npm run verify:all
-xoonya conformance --json
-xoonya first-run --verify-native --pretty
-```
-
-## Planned Independent References
-
-Python and Rust reference implementations are planned, but they are not public compatibility claims until they pass the same vector floor independently.
-
-Candidate names:
-
-- `xoonya-native-python`
-- `xoonya-native-rust`
-
-Each candidate must implement its own byte parser and verifier. Wrapping the JavaScript runtime is useful for demos, but it is not an independent reference implementation.
-
-Promotion evidence is checked separately from scaffold parity:
-
-```bash
-npm run verify:reference-promotion-gate
-```
-
-That verifier proves a complete candidate promotion packet can pass validation, while incomplete packets fail with deterministic rejection codes. The gate requires repository/package evidence, all required vector sets, deterministic error-code parity, independent parser evidence, native signature-suite crypto parity, cross-language round-trip evidence, conformance-mark review, forbidden-claim review, and no secret material.
-
-## Python Candidate Scaffold
-
-The Python candidate scaffold lives in `reference/python`.
-
-It currently covers:
-
-- XNYA atom v1 and v2 creation
-- XNYA atom parsing and verification
-- native atom adversarial reject codes
-- XNYP payload profile encoding and parsing
-- line-rate frame checksum verification
-- canonical event hash parity
-- receipt emission for external assertion, native digest, legacy OP_RETURN, and native anchored methods
-- proof-bundle build/verify parity for non-signed native methods
-- adversarial reason parity for non-signed proof-bundle checks
-- bounded hybrid-method awareness without yet claiming independent PQ/hybrid validator parity
-- optional Ed25519 native signed verification when the Python `cryptography` package is available
-- deterministic `native_signature_crypto_dependency_missing` when the optional crypto dependency is absent
-
-Run:
-
-```bash
-npm run verify:reference-python
-```
-
-This is vector-parity progress, not a full reference promotion. Python does not yet claim always-on native signature-suite cryptographic verification, secp256k1/P-256 parity, external method import, independent PQ/hybrid signature parity, or all native signed proof-bundle round-trip behavior.
-
-Optional Ed25519 crypto check:
-
-```bash
-npm run verify:reference-python-crypto
-```
-
-This command creates an isolated temporary Python virtual environment, installs `reference/python/requirements-optional.txt`, runs the same vector verifier, and requires `verified_signature_suite_count = 1`.
-
-Without the optional dependency, the default verifier still passes by proving the explicit dependency boundary.
-
-## Rust Candidate Scaffold
-
-The Rust candidate scaffold lives in `reference/rust`.
-
-It currently covers:
-
-- source-only package boundary for `xoonya-native-rust`
-- fixed-size `XNYA` atom constants
-- v1/v2 atom byte-length checks
-- deterministic atom parser error codes
-- `publish = false` until vector parity and promotion gates exist
-
-Run:
-
-```bash
-npm run verify:reference-rust-scaffold
-```
-
-This is a packaging and boundary guard only. It does not compile Rust in the
-current release path, does not run positive/adversarial vectors, and does not
-claim `XNYA-compatible` status for Rust.
-
-## Required Vector Floor
-
-An independent implementation must pass:
-
-- `vectors/conformance-vectors.json`
-- `vectors/adversarial-vectors.json`
-- `vectors/native-atom-vectors.json`
-- `vectors/native-payload-profile-vectors.json`
-
-The implementation must also produce stable reject reasons equivalent to the published deterministic error codes.
-
-## Required Behavior
-
-An implementation may claim `XNYA-compatible` only when it:
-
-- parses `XNYA` atoms exactly by byte layout and fixed size
-- preserves `XNYA` atom v1 and v2 domain separation
-- parses `XNYP` payload profiles without loose JSON, floats, or implicit type coercion
-- rejects unsupported or malformed native atoms with deterministic errors
-- rejects `algorithm: "none"` as a production proof method
-- verifies only implemented signature suites with suite-specific validators
-- treats PQ/hybrid methods as independently unverified until that runtime has its own validators and vector parity
-- binds external proof formats without claiming external issuer truth
-- binds anchor references without claiming external chain or provider finality truth
-
-## Promotion Gates
-
-Independent references become public reference implementations only after:
-
-1. A package or repository exists with public source, license, docs, and test commands.
-2. The candidate passes all positive and adversarial vector sets.
-3. The candidate emits deterministic errors that match the JavaScript reference.
-4. The candidate can generate artifacts verified by the JavaScript reference.
-5. The JavaScript reference can generate artifacts verified by the candidate.
-6. The candidate satisfies the `XNYA-compatible` mark without forbidden claims.
-7. The candidate passes `npm run verify:reference-promotion-gate` with promotion evidence that does not contain private keys, access tokens, credentials, or authorization material.
-
-## Non-Claims
-
-The reference implementation plan does not claim:
-
-- PQ or hybrid runtime validation
-- live external provider execution
-- identity, authentication, custody, transport, or settlement security
-- Rust vector parity or full Rust reference status
-- external issuer truth for JWT, DID/VC, SD-JWT VC, signed-envelope, or partner proofs
-- external chain or provider finality truth
-
-Those claims require separate validators, policies, and evidence.
-
-## Service Surface
-
-The machine-readable pack is exposed at:
-
-- `GET /v1/proof-center/native-reference-implementations`
-- `GET /v1/proof-center/native-reference-implementations/summary`