xoonya 2.10.0 → 2.12.0

package/README.md

@@ -237,28 +237,28 @@ Current built-in methods:
 
 - `legacy-opreturn-v1` verifies the compatibility OP_RETURN receipt path.
 - `detached-assertion-v1` accepts an explicit detached assertion after canonical receipt checks; cryptographic verification is expected to happen outside this helper.
-- `xoonya-native-sha256-v1` verifies Xoonya's native deterministic digest format.
-- `xoonya-native-signed-v1` verifies Xoonya's native signed proof envelope with Ed25519, secp256k1, and P-256 implemented through the explicit suite registry. Other suites stay registry-only until validators exist.
-- `xoonya-native-anchored-v1` verifies Xoonya's native anchor-binding proof envelope for chain, batch, finality, content-hash, or external attestation refs. It verifies the binding, not the external provider or chain truth itself.
+- `xoonya-native-sha256-v1` verifies xoonya's native deterministic digest format.
+- `xoonya-native-signed-v1` verifies xoonya's native signed proof envelope with Ed25519, secp256k1, and P-256 implemented through the explicit suite registry. Other suites stay registry-only until validators exist.
+- `xoonya-native-anchored-v1` verifies xoonya's native anchor-binding proof envelope for chain, batch, finality, content-hash, or external attestation refs. It verifies the binding, not the external provider or chain truth itself.
 - `jwt-assertion-v1` accepts compact JWT assertion envelopes after canonical receipt checks; JWT signature, issuer, and audience verification remain external to this helper.
 - `did-vc-v1` accepts DID/VC proof envelopes after canonical receipt checks; DID resolution and VC proof validation remain external to this helper.
 - `sd-jwt-vc-v1` accepts SD-JWT VC disclosure envelopes after canonical receipt checks; issuer, holder binding, and disclosure verification remain external to this helper.
 - `signed-envelope-v1` accepts generic signed envelopes after canonical receipt checks; envelope-specific signature verification remains external to this helper.
 - `partner-proof-envelope-v1` accepts partner-specific proof envelopes after canonical receipt checks; partner verifier policy remains external to this helper.
 
-`algorithm: "none"` is not a registered verification method and does not verify. External proof methods are first-class registry entries, but Xoonya does not pretend to replace their own cryptographic verifier stacks. The proof core checks the canonical receipt, method registration, and method boundary; issuer-specific validation stays with the relevant JWT, DID/VC, SD-JWT VC, signed-envelope, or partner verifier.
+`algorithm: "none"` is not a registered verification method and does not verify. External proof methods are first-class registry entries, but xoonya does not pretend to replace their own cryptographic verifier stacks. The proof core checks the canonical receipt, method registration, and method boundary; issuer-specific validation stays with the relevant JWT, DID/VC, SD-JWT VC, signed-envelope, or partner verifier.
 
-### Xoonya Native Proof Format
+### xoonya Native Proof Format
 
-Xoonya Native is the optional native proof/result/attestation format direction for machine proof. It is not a replacement for JWT, OAuth, OIDC, DID/VC, or SD-JWT VC. Those remain interoperability lanes.
+xoonya Native is the optional native proof/result/attestation format direction for machine proof. It is not a replacement for JWT, OAuth, OIDC, DID/VC, or SD-JWT VC. Those remain interoperability lanes.
 
-The native standard is Xoonya's own fixed-size hot-path commitment atom, cold-path proof envelope, semantic-free core bytes, and deterministic validation. The current implemented native methods are `xoonya-native-sha256-v1`, `xoonya-native-signed-v1`, and `xoonya-native-anchored-v1`. The signed native method verifies Ed25519, secp256k1, and P-256 today and keeps PQ/hybrid suites in the registry until their validators are implemented, so the standard stays agnostic without overclaiming. The anchored native method binds receipts to declared anchor/finality/attestation refs without claiming the external system has been independently verified by Xoonya.
+The native standard is xoonya's own fixed-size hot-path commitment atom, cold-path proof envelope, semantic-free core bytes, and deterministic validation. The current implemented native methods are `xoonya-native-sha256-v1`, `xoonya-native-signed-v1`, and `xoonya-native-anchored-v1`. The signed native method verifies Ed25519, secp256k1, and P-256 today and keeps PQ/hybrid suites in the registry until their validators are implemented, so the standard stays agnostic without overclaiming. The anchored native method binds receipts to declared anchor/finality/attestation refs without claiming the external system has been independently verified by xoonya.
 
-The atom ladder is treated as native Xoonya design, not a runtime dependency: `xoonya-native-atom/v1` is the 58-byte classical commitment atom, `xoonya-native-atom/v2` is the 70-byte PQ-horizon identity commitment candidate, and `xoonya-native-atom/v3-contingency` stays reserved for a future digest-family shift only if the underlying hash assumptions materially change.
+The atom ladder is treated as native xoonya design, not a runtime dependency: `xoonya-native-atom/v1` is the 58-byte classical commitment atom, `xoonya-native-atom/v2` is the 70-byte PQ-horizon identity commitment candidate, and `xoonya-native-atom/v3-contingency` stays reserved for a future digest-family shift only if the underlying hash assumptions materially change.
 
-The canonical Xoonya Native atom magic is `XNYA`. No other magic value is part of the Xoonya Native atom standard. The formal atom spec ships inside the `xoonya` package first; a separate standards repo can be extracted later if external governance needs it.
+The canonical xoonya Native atom magic is `XNYA`. No other magic value is part of the xoonya Native atom standard. The formal atom spec ships inside the `xoonya` package first; a separate standards repo can be extracted later if external governance needs it.
 
-XNYA atom conformance now includes stable machine-readable reject codes and adversarial vectors. Passing only the happy-path vectors is not enough to claim Xoonya Native compatibility.
+XNYA atom conformance now includes stable machine-readable reject codes and adversarial vectors. Passing only the happy-path vectors is not enough to claim xoonya Native compatibility.
 
 The native payload profile is now explicit: `xoonya-native-payload-profile/v1` uses the binary `XNYP` magic and typed fields with deterministic ordering, fixed-width integer encoding, unknown-field policy checks, and no floats or loose JSON semantics. The optional `xoonya-native-line-rate-frame/v1` wraps an existing 58-byte or 70-byte `XNYA` atom with a 2-byte checksum for transport fast rejection; it does not change the atom and does not claim signature, encryption, custody, settlement, or external finality truth.
 
@@ -285,9 +285,9 @@ Legacy compact receipt and profile helpers are still available during alignment:
 - `verifyReceiptV2(...)`
 - `createProofEnvelopeV1(...)`
 - `verifyProofEnvelopeV1(...)`
-- `createXoonyaNativeAtomV1(...)`
-- `createXoonyaNativeAtomV2(...)`
-- `verifyXoonyaNativeAtom(...)`
+- `createxoonyaNativeAtomV1(...)`
+- `createxoonyaNativeAtomV2(...)`
+- `verifyxoonyaNativeAtom(...)`
 - `createEconomicReceiptProfileV1(...)`
 - `verifyEconomicReceiptProfileV1(...)`
 - `createRegistryProfileV1(...)`

package/RELEASE_NOTES.md

@@ -1,11 +1,9 @@
-# xoonya 2.10.0 Release Notes
-
-`xoonya` 2.10.0 is the release-hygiene and standard-boundary polish line for current-release-only package notes and stronger release-candidate packaging checks.
+`xoonya` 2.12.0 is the proof-release truth line for aligned npm, GitHub, website, code, documentation, and public-copy surfaces.
 
 Highlights:
 
-- keeps `RELEASE_NOTES.md` scoped to the current release so npm and GitHub release notes do not read like a rolling changelog
-- adds a release-candidate guard that fails when package release notes contain prior release headings or drift from the package version
-- preserves the XNYA-compatible conformance mark, native reference implementation boundaries, external proof import boundaries, and PQ/hybrid design gate
-- keeps the canonical `https://naxytra.com/xoonya` public product URL and single Naxytra website positioning intact
-- prepares the synchronized Naxytra 2.10.0 line for a cleaner npm, GitHub, website, and post-deploy verification pass
+- normalizes visible `xoonya`, `xytara`, and `naxytra` product references to the lowercase convention across package docs, native-standard copy, CLI release surfaces, server routes, and verifier call sites
+- preserves XNYA-compatible conformance, native reference implementation boundaries, external proof import boundaries, trust-portability surfaces, and the PQ/hybrid design gate
+- keeps `RELEASE_NOTES.md` scoped to the current release so npm and GitHub release notes stay clean
+- keeps the canonical `https://naxytra.com/xoonya` public product URL and single naxytra website positioning intact
+- verifies the lowercase convention through the release candidate, full package verifier, umbrella pre-deploy gates, and clean-consumer release smoke

package/XNYA_CONFORMANCE_MARK.md

@@ -1,6 +1,6 @@
 # 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.
+`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.
 
@@ -50,7 +50,7 @@ Non-JavaScript implementations should publish deterministic pass/fail output aga
 
 `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.
+`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
 
@@ -60,7 +60,7 @@ Do not claim the mark if:
 - `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
+- 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

package/XNYA_REFERENCE_IMPLEMENTATIONS.md

@@ -1,6 +1,6 @@
 # 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.
+`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
 

package/XOONYA_NATIVE_ATOM_SPEC.md

@@ -1,4 +1,4 @@
-# Xoonya Native Atom Specification
+# xoonya Native Atom Specification
 
 Status: formal spec pack active
 
@@ -6,9 +6,9 @@ Spec version: `xoonya-native-atom-spec/v1`
 
 ## Decision
 
-The canonical Xoonya Native atom magic is `XNYA`.
+The canonical xoonya Native atom magic is `XNYA`.
 
-No other magic value is part of the Xoonya Native atom standard. Implementations that use a different discriminator are separate formats and must not claim Xoonya Native atom compatibility.
+No other magic value is part of the xoonya Native atom standard. Implementations that use a different discriminator are separate formats and must not claim xoonya Native atom compatibility.
 
 `XNYA` is four bytes, not three, because a fixed 4-byte ASCII discriminator is easier to index, validate, debug, and defend than a shorter clever header.
 
@@ -18,7 +18,7 @@ The native atom spec ships inside the `xoonya` package first.
 
 This is intentional:
 
-- there is one public website and one Xoonya package surface today
+- there is one public website and one xoonya package surface today
 - the verifier implementation and conformance vectors live beside the spec
 - builders should not need another repo to understand the native proof path
 
@@ -26,11 +26,11 @@ A separate standards repo can be created later if external adoption, independent
 
 ## Atom Purpose
 
-The Xoonya Native atom is a fixed-size commitment record.
+The xoonya Native atom is a fixed-size commitment record.
 
 It answers:
 
-> Which typed machine identity committed to which payload hash under which frozen Xoonya Native version line?
+> Which typed machine identity committed to which payload hash under which frozen xoonya Native version line?
 
 It does not contain:
 

package/XOONYA_NATIVE_PROOF_FORMAT.md

@@ -1,4 +1,4 @@
-# Xoonya Native Proof Format
+# xoonya Native Proof Format
 
 Status: design contract active
 
@@ -6,11 +6,11 @@ Version: `xoonya-native-proof/v1`
 
 ## Purpose
 
-Xoonya Native is the optional native proof format for Xoonya proof, result, attestation, and handoff artifacts.
+xoonya Native is the optional native proof format for xoonya proof, result, attestation, and handoff artifacts.
 
 It is not a generic login token, bearer token, wallet credential, or replacement for JWT, OAuth, OIDC, DID/VC, or SD-JWT VC. Those remain useful interoperability lanes.
 
-Xoonya Native exists for a different job:
+xoonya Native exists for a different job:
 
 - preserve machine evidence without runtime lock-in
 - preserve deterministic replay truth
@@ -20,7 +20,7 @@ Xoonya Native exists for a different job:
 
 ## Native Design Carry-In
 
-Xoonya Native keeps the useful design substance and expresses it directly as Xoonya. The durable invention is the split between:
+xoonya Native keeps the useful design substance and expresses it directly as xoonya. The durable invention is the split between:
 
 - a fixed-size hot-path commitment atom
 - a variable-size cold-path proof envelope
@@ -35,11 +35,11 @@ The strongest long-term posture is:
 - keep the native core as a commitment primitive, not a signature or credential container
 - put signatures, credentials, attestations, anchors, settlement refs, and ZK artifacts in envelopes or profiles
 - keep external formats as interop lanes
-- let Xoonya Native be the format agents choose when they want byte-stable proof rather than broad web credential compatibility
+- let xoonya Native be the format agents choose when they want byte-stable proof rather than broad web credential compatibility
 
 ## Doctrine
 
-- Xoonya remains method-agnostic.
+- xoonya remains method-agnostic.
 - Native proof is first-class but optional.
 - External proof and credential formats stay supported as registry methods or integration lanes.
 - The native format optimizes for deterministic machine proof, not human web sessions.
@@ -63,7 +63,7 @@ It does not contain signatures, timestamps, prices, settlement references, custo
 
 The payload or intent bytes carry deterministic machine meaning.
 
-For current Xoonya this is represented by `canonical_event`. For a future formal atom line, this should become a fixed binary or tightly canonicalized payload profile where every field order, integer width, unknown-field rule, and replay rule is specified.
+For current xoonya this is represented by `canonical_event`. For a future formal atom line, this should become a fixed binary or tightly canonicalized payload profile where every field order, integer width, unknown-field rule, and replay rule is specified.
 
 JSON may remain a public SDK and service convenience, but the native standard should not depend on loose JSON interpretation for the hot path.
 
@@ -87,13 +87,13 @@ Profiles are versioned independently.
 
 ### L4: Runtime And Policy Consumers
 
-Xytara, agent runtimes, settlement systems, operator dashboards, and partner verifiers consume Xoonya evidence. They must not redefine the atom byte layout.
+xytara, agent runtimes, settlement systems, operator dashboards, and partner verifiers consume xoonya evidence. They must not redefine the atom byte layout.
 
 ## Native Atom Version Ladder
 
 ### `xoonya-native-atom/v1`
 
-Canonical Xoonya Native byte identity: `XNYA`.
+Canonical xoonya Native byte identity: `XNYA`.
 
 Purpose: classical minimal identity and payload commitment.
 
@@ -122,7 +122,7 @@ Use when:
 
 ### `xoonya-native-atom/v2`
 
-Canonical Xoonya Native byte identity: `XNYA`.
+Canonical xoonya Native byte identity: `XNYA`.
 
 Purpose: PQ-horizon identity anchoring while preserving the same fixed commitment philosophy.
 
@@ -155,7 +155,7 @@ This is not an implementation target.
 
 It is a contingency line only if SHA-256 or the prevailing digest assumption changes materially. A future v3 should stay fixed-length and deterministic, most likely by moving to a different digest family with explicit domain separation. It should not introduce runtime negotiation inside the core.
 
-## Current Xoonya Object Model
+## Current xoonya Object Model
 
 ### `canonical_event`
 
@@ -260,8 +260,8 @@ Native anchored proof material:
 
 Important boundary:
 
-- Xoonya verifies that the receipt and event commitment bind to the declared anchors.
-- Xoonya does not independently assert that an external chain, settlement provider, or attestation issuer is truthful.
+- xoonya verifies that the receipt and event commitment bind to the declared anchors.
+- xoonya does not independently assert that an external chain, settlement provider, or attestation issuer is truthful.
 - External finality or provider verification remains a higher layer.
 
 ## Native Payload Profile
@@ -296,7 +296,7 @@ Canonical rules:
 - floats, null, undefined, functions, and symbolic values are not supported
 - payload hash is SHA-256 over `xoonya:payload-profile:v1:` plus canonical profile bytes
 
-This gives Xoonya a durable standard-grade payload path while keeping richer JSON, CBOR, DID/VC, JWT, or partner evidence envelopes available as external or higher-layer profiles. If deterministic CBOR is later needed, it should be a separate profile with its own vectors and reject rules, not a silent change to this binary profile.
+This gives xoonya a durable standard-grade payload path while keeping richer JSON, CBOR, DID/VC, JWT, or partner evidence envelopes available as external or higher-layer profiles. If deterministic CBOR is later needed, it should be a separate profile with its own vectors and reject rules, not a silent change to this binary profile.
 
 Reference vectors ship at `vectors/native-payload-profile-vectors.json`.
 
@@ -329,13 +329,13 @@ Design-gated future extension.
 
 This should provide stronger-crypto or PQC-sensitive proof lanes if production need appears. It should not become the default until there is a real reason.
 
-The current rule is strict: `xoonya-native-hybrid-v1` remains design-gated until runtime validators, public key formats, conformance vectors, adversarial vectors, and deterministic error codes exist. Xoonya may expose readiness and promotion criteria for this method, but must not claim PQC or hybrid verification before those artifacts are real.
+The current rule is strict: `xoonya-native-hybrid-v1` remains design-gated until runtime validators, public key formats, conformance vectors, adversarial vectors, and deterministic error codes exist. xoonya may expose readiness and promotion criteria for this method, but must not claim PQC or hybrid verification before those artifacts are real.
 
 Before promotion, any proof bundle that directly asks the current verifier to accept `xoonya-native-hybrid-v1` must fail with the deterministic reason `native_hybrid_design_gated`. Hybrid-looking native signatures also must not verify through an external assertion method; those downgrade attempts fail as `signature_method_mismatch`.
 
 ## Crypto And Identity Support Boundary
 
-Xoonya Native supports cryptographic ecosystems by committing to their canonical identity or proof material. It does not become those ecosystems.
+xoonya Native supports cryptographic ecosystems by committing to their canonical identity or proof material. It does not become those ecosystems.
 
 Cleanly supported above the atom:
 
@@ -351,7 +351,7 @@ Cleanly supported above the atom:
 
 Important boundary:
 
-- Xoonya Native provides commitments and proof binding.
+- xoonya Native provides commitments and proof binding.
 - It does not provide encryption, forward secrecy, access control, custody, or transport security.
 - Those systems remain external layers.
 
@@ -365,13 +365,13 @@ External methods remain first-class:
 - `signed-envelope-v1`
 - `partner-proof-envelope-v1`
 
-For these methods, Xoonya checks canonical receipt shape, registration, and method boundary. Method-specific cryptographic verification stays with the relevant verifier stack unless and until a verifier is added behind that method.
+For these methods, xoonya checks canonical receipt shape, registration, and method boundary. Method-specific cryptographic verification stays with the relevant verifier stack unless and until a verifier is added behind that method.
 
 ## External Proof Import Adapter
 
 Implemented version: `xoonya-external-proof-import-adapter-v1`
 
-The import adapter is the bridge between external proof envelopes and Xoonya proof bundles.
+The import adapter is the bridge between external proof envelopes and xoonya proof bundles.
 
 It accepts registered external proof methods:
 
@@ -385,7 +385,7 @@ It accepts registered external proof methods:
 It then emits:
 
 - a canonical import event
-- a Xoonya receipt bound to the selected method
+- a xoonya receipt bound to the selected method
 - a proof bundle
 - bundle verification
 - an import review that states the external-verifier boundary
@@ -412,7 +412,7 @@ The adapter verifies:
 - the method is registered and importable
 - the external proof material is present
 - the material hash matches `declared_hash_sha256` when supplied
-- the import material is deterministically bound into a canonical Xoonya event
+- the import material is deterministically bound into a canonical xoonya event
 - the emitted receipt and proof bundle verify structurally
 
 The adapter does not claim:
@@ -424,26 +424,26 @@ The adapter does not claim:
 - partner policy truth
 - external issuer correctness
 
-Those remain the job of the relevant external verifier. Xoonya's job is to bind the external proof into replayable proof continuity without pretending to own another ecosystem's trust root.
+Those remain the job of the relevant external verifier. xoonya's job is to bind the external proof into replayable proof continuity without pretending to own another ecosystem's trust root.
 
 ## Competitive Positioning
 
-Xoonya Native should be positioned as deterministic machine evidence, not as a universal identity credential.
+xoonya Native should be positioned as deterministic machine evidence, not as a universal identity credential.
 
 Compared with JWT/JWS:
 
 - JWT wins for broad web compatibility and signed JSON claims.
-- Xoonya Native wins when a machine needs fixed validation rules, replayable proof bundles, and no ambiguity about canonical evidence bytes.
+- xoonya Native wins when a machine needs fixed validation rules, replayable proof bundles, and no ambiguity about canonical evidence bytes.
 
 Compared with DID/VC:
 
 - DID/VC wins for rich identity and credential ecosystems.
-- Xoonya Native wins when the primary artifact is a compact machine receipt or proof root rather than a human credential.
+- xoonya Native wins when the primary artifact is a compact machine receipt or proof root rather than a human credential.
 
 Compared with chain-specific proofs:
 
 - chain-specific proofs win for native settlement proof on that chain.
-- Xoonya Native wins when proof must cross runtimes, chains, settlement rails, and credential systems.
+- xoonya Native wins when proof must cross runtimes, chains, settlement rails, and credential systems.
 
 The unique claim is not "better than everything." The unique claim is:
 
@@ -466,13 +466,13 @@ Commercial and legal protection should be handled explicitly:
 
 - preserve authorship and publication history through tagged releases and checksummed specs
 - use clear Apache-2.0 implementation licensing where intended
-- maintain trademark/brand usage rules for the Xoonya name and native conformance marks
+- maintain trademark/brand usage rules for the xoonya name and native conformance marks
 - get qualified IP counsel before relying on patent, trademark, or defensive-publication strategy
 
 ## Standardization Steps
 
 1. Keep `xoonya-native-sha256-v1` as the implemented deterministic method.
-2. Publish the XNYA atom ladder as Xoonya Native design, without forcing the current SDK to expose raw atoms prematurely.
+2. Publish the XNYA atom ladder as xoonya Native design, without forcing the current SDK to expose raw atoms prematurely.
 3. Keep `xoonya-native-signed-v1` behind the existing method registry with Ed25519 verification implemented first.
 4. Maintain the signature suite registry and only mark suites as verified when validators exist.
 5. Keep conformance vectors for native signed proof.

package/XOONYA_NATIVE_STANDARD_GOVERNANCE.md

@@ -1,10 +1,10 @@
-# Xoonya Native Standard Governance
+# xoonya Native Standard Governance
 
 Status: active governance note
 
 ## Purpose
 
-This document defines how Xoonya Native evolves without losing its standard value.
+This document defines how xoonya Native evolves without losing its standard value.
 
 The goal is not to create a format for novelty. The goal is to preserve a small deterministic machine-evidence primitive that can survive runtime churn, identity-system churn, settlement-rail churn, and cryptographic migration.
 
@@ -20,7 +20,7 @@ The phrase `XNYA-compatible` should mean:
 - it does not redefine a published version line
 - it follows the public mark rules in `XNYA_CONFORMANCE_MARK.md`
 
-Implementations that use a different magic value, different field ordering, different hash derivation, or soft-forked validation behavior are not Xoonya Native atom implementations. They are separate formats.
+Implementations that use a different magic value, different field ordering, different hash derivation, or soft-forked validation behavior are not xoonya Native atom implementations. They are separate formats.
 
 ## Registry Policy
 
@@ -76,7 +76,7 @@ Before promoting a native feature:
 
 Current public claim:
 
-> Xoonya Native provides deterministic machine evidence with native digest, Ed25519 signed proof, and anchor-binding proof support, plus a formal XNYA atom spec for fixed-size commitment records.
+> xoonya Native provides deterministic machine evidence with native digest, Ed25519 signed proof, and anchor-binding proof support, plus a formal XNYA atom spec for fixed-size commitment records.
 
 Not current public claims:
 
@@ -90,7 +90,7 @@ Not current public claims:
 
 ## Current Conformance Surface
 
-The current Xoonya Native atom conformance surface is:
+The current xoonya Native atom conformance surface is:
 
 - `GET /v1/proof-center/native-conformance-mark`
 - `GET /v1/proof-center/native-conformance-mark/summary`
@@ -114,6 +114,6 @@ Use practical protection layers:
 - checksummed spec artifacts
 - public conformance vectors
 - Apache-2.0 implementation licensing where intended
-- clear Xoonya name and conformance-mark usage
+- clear xoonya name and conformance-mark usage
 
 Patent, trademark, or defensive-publication strategy should be reviewed with qualified IP counsel before being relied on.

package/bin/xoonya-release.js

@@ -52,10 +52,10 @@ const {
   summarizeReleaseCandidatePack
 } = require("../lib/release_candidate");
 const {
-  buildXoonyaNativeConformanceMarkPack,
-  summarizeXoonyaNativeConformanceMarkPack,
-  buildXoonyaNativeReferenceImplementationPack,
-  summarizeXoonyaNativeReferenceImplementationPack
+  buildxoonyaNativeConformanceMarkPack,
+  summarizexoonyaNativeConformanceMarkPack,
+  buildxoonyaNativeReferenceImplementationPack,
+  summarizexoonyaNativeReferenceImplementationPack
 } = require("../proof_sdk");
 const {
   buildPhaseProgramPack,
@@ -855,13 +855,13 @@ function main() {
   } else if (history) {
     payload = buildReleaseHistory();
   } else if (nativeConformanceMark && summary) {
-    payload = summarizeXoonyaNativeConformanceMarkPack();
+    payload = summarizexoonyaNativeConformanceMarkPack();
   } else if (nativeConformanceMark) {
-    payload = buildXoonyaNativeConformanceMarkPack();
+    payload = buildxoonyaNativeConformanceMarkPack();
   } else if (nativeReferenceImplementations && summary) {
-    payload = summarizeXoonyaNativeReferenceImplementationPack();
+    payload = summarizexoonyaNativeReferenceImplementationPack();
   } else if (nativeReferenceImplementations) {
-    payload = buildXoonyaNativeReferenceImplementationPack();
+    payload = buildxoonyaNativeReferenceImplementationPack();
   } else if (phases && summary) {
     payload = summarizePhaseProgramPack();
   } else if (phases) {

package/index.js

@@ -3,6 +3,8 @@
 module.exports = {
   ...require("./proof_sdk"),
   ...require("./integrations/registry"),
+  ...require("./lib/verification_service_pack"),
+  ...require("./lib/trust_portability_pack"),
   ...require("./lib/release_pack"),
   ...require("./lib/release_manifest"),
   ...require("./lib/release_center"),

package/lib/release_history.js

@@ -10,6 +10,30 @@ function buildReleaseHistory() {
     current_version: packageJson.version,
     release_track: "public_release",
     history: [
+      {
+        version: "2.12.0",
+        channel: "public_release",
+        maturity_posture: "proof_release_truth",
+        headline: "proof-release truth line aligning verification services, trust portability, and public release-coherence surfaces",
+        milestone_refs: [
+          "proof_release_truth_bundle",
+          "verification_service_public_surface",
+          "trust_portability_public_surface",
+          "public_release_surface_alignment"
+        ]
+      },
+      {
+        version: "2.11.0",
+        channel: "public_release",
+        maturity_posture: "brand_convention_aligned",
+        headline: "lowercase-brand-convention release aligning npm, GitHub, website, code, native-standard docs, and public-copy surfaces",
+        milestone_refs: [
+          "lowercase_product_name_convention",
+          "native_standard_copy_alignment",
+          "server_and_verifier_surface_alignment",
+          "synchronized_2_11_release_prep"
+        ]
+      },
       {
         version: "2.10.0",
         channel: "public_release",
@@ -26,7 +50,7 @@ function buildReleaseHistory() {
         version: "2.9.0",
         channel: "public_release",
         maturity_posture: "public_polish",
-        headline: "public-polish release with canonical Naxytra product URLs while preserving XNYA native-standard claim boundaries",
+        headline: "public-polish release with canonical naxytra product URLs while preserving XNYA native-standard claim boundaries",
         milestone_refs: [
           "canonical_naxytra_product_url",
           "standalone_product_domain_guard",