xoonya 3.0.1 → 3.1.0

package/.env.example

@@ -1,2 +1,2 @@
-XOONYA_HOST=127.0.0.1
-XOONYA_PORT=4310
+XOONYA_HOST=127.0.0.1
+XOONYA_PORT=4310

package/CARRIED_HANDOFF_DEMO.md

@@ -1,60 +1,60 @@
-# xoonya Carried Handoff Demo
-
-This is the shortest proof-side adoption story after the program closed.
-
-The goal is to take a carried result-package handoff from `xytara`, inspect it, and prove it.
-
-## 1. Generate The Handoff In xytara
-
-From the `xytara` repo root, run:
-
-```bash
-node examples/export_carried_handoff.js
-```
-
-That writes:
-
-```text
-examples/generated.carried-handoff.json
-```
-
-## 2. Review It In xoonya
-
-From the `xoonya` repo root, run:
-
-```bash
-xoonya-review --file ../xytara/examples/generated.carried-handoff.json --summary
-```
-
-This is the compact operator review path.
-
-## 3. Run The Proof-Side Example
-
-To run the same carried handoff through the proof SDK:
-
-```bash
-node examples/review_carried_handoff.js --file ../xytara/examples/generated.carried-handoff.json
-```
-
-## 4. Why This Matters
-
-This is the highest-signal end-to-end adoption path now:
-
-- runtime-side work ends in a portable handoff bundle
-- proof-side review is explicit and inspectable
-- proof-side continuation is deterministic instead of implicit
-
-## 5. Related Surfaces
-
-Review:
-
-- `POST /v1/proof-center/result-package-handoff/review`
-- `POST /v1/proof-center/result-package-handoff/review/summary`
-
-Run:
-
-- `POST /v1/proof-center/result-package-handoff/run`
-
-Guided CLI:
-
-- `xoonya-review --file ./handoff.json --summary`
+# xoonya Carried Handoff Demo
+
+This is the shortest proof-side adoption story after the program closed.
+
+The goal is to take a carried result-package handoff from `xytara`, inspect it, and prove it.
+
+## 1. Generate The Handoff In xytara
+
+From the `xytara` repo root, run:
+
+```bash
+node examples/export_carried_handoff.js
+```
+
+That writes:
+
+```text
+examples/generated.carried-handoff.json
+```
+
+## 2. Review It In xoonya
+
+From the `xoonya` repo root, run:
+
+```bash
+xoonya-review --file ../xytara/examples/generated.carried-handoff.json --summary
+```
+
+This is the compact operator review path.
+
+## 3. Run The Proof-Side Example
+
+To run the same carried handoff through the proof SDK:
+
+```bash
+node examples/review_carried_handoff.js --file ../xytara/examples/generated.carried-handoff.json
+```
+
+## 4. Why This Matters
+
+This is the highest-signal end-to-end adoption path now:
+
+- runtime-side work ends in a portable handoff bundle
+- proof-side review is explicit and inspectable
+- proof-side continuation is deterministic instead of implicit
+
+## 5. Related Surfaces
+
+Review:
+
+- `POST /v1/proof-center/result-package-handoff/review`
+- `POST /v1/proof-center/result-package-handoff/review/summary`
+
+Run:
+
+- `POST /v1/proof-center/result-package-handoff/run`
+
+Guided CLI:
+
+- `xoonya-review --file ./handoff.json --summary`

package/COMPATIBILITY_NOTE.md

@@ -1,27 +1,27 @@
-# xoonya Compatibility Note
-
-`xoonya` is a first public contract built from private lineage.
-
-That means the current public center of gravity is:
-
-- `Canonical Event Bundle`
-- `Receipt`
-- `Proof Bundle`
-
-Older compact receipt and profile helpers remain available because they are useful support breadth, not because the public contract is required to center on them.
-
-Current retained compatibility helpers include:
-
-- `createReceipt(...)`
-- `verifyReceipt(...)`
-- `createReceiptV2(...)`
-- `verifyReceiptV2(...)`
-- `createProofEnvelopeV1(...)`
-- `verifyProofEnvelopeV1(...)`
-- profile verification helpers
-
-Public guidance:
-
-- use the canonical event and proof-bundle flow first
-- treat retained compact helpers as compatibility/support utilities
-- do not model new integrations as if the older helper lineage were the only public proof contract
+# xoonya Compatibility Note
+
+`xoonya` is a first public contract built from private lineage.
+
+That means the current public center of gravity is:
+
+- `Canonical Event Bundle`
+- `Receipt`
+- `Proof Bundle`
+
+Older compact receipt and profile helpers remain available because they are useful support breadth, not because the public contract is required to center on them.
+
+Current retained compatibility helpers include:
+
+- `createReceipt(...)`
+- `verifyReceipt(...)`
+- `createReceiptV2(...)`
+- `verifyReceiptV2(...)`
+- `createProofEnvelopeV1(...)`
+- `verifyProofEnvelopeV1(...)`
+- profile verification helpers
+
+Public guidance:
+
+- use the canonical event and proof-bundle flow first
+- treat retained compact helpers as compatibility/support utilities
+- do not model new integrations as if the older helper lineage were the only public proof contract

package/CROSS_RUNTIME_POSTURE.md

@@ -1,77 +1,77 @@
-# xoonya Cross-Runtime Posture
-
-`xoonya` is intended to be reproducible across runtimes.
-
-The current reference implementation is Node.js, but the proof contract is designed so that:
-
-- canonical event normalization is explicit
-- hashing is deterministic
-- receipt derivation is deterministic
-- proof-bundle verification is deterministic
-
-## Current reference runtime
-
-- Node.js `>=18`
-
-## What is already explicit
-
-- canonical object ordering is defined by the proof implementation
-- event commitment is derived from canonical serialized event content
-- receipt IDs are derived from canonical receipt-signing material
-- proof-bundle verification checks deterministic structural invariants
-
-## Current publication artifacts
-
-- `vectors/conformance-vectors.json`
-- `vectors/adversarial-vectors.json`
-
-These vectors are intended to be reusable by future implementations in other runtimes.
-
-## Python candidate scaffold
-
-This repo now ships a Python candidate scaffold in `reference/python`.
-
-It is independent from the JavaScript implementation and can replay the XNYA atom, native atom adversarial, native payload profile, line-rate frame, canonical event, receipt, and non-signed proof-bundle vectors:
-
-```bash
-npm run verify:reference-python
-```
-
-This is not yet a full second reference implementation. It can verify Ed25519 native signed vectors when Python's optional `cryptography` package is installed; otherwise it proves the deterministic `native_signature_crypto_dependency_missing` boundary. It does not claim always-on native signature-suite cryptographic verification, secp256k1/P-256 parity, external proof import, or all native signed proof-bundle round-trip behavior.
-
-The crypto-enabled optional check is:
-
-```bash
-npm run verify:reference-python-crypto
-```
-
-That command creates a temporary isolated Python virtual environment, installs `reference/python/requirements-optional.txt`, and requires the Ed25519 native signed vector to verify.
-
-## Rust candidate scaffold
-
-This repo also ships a source-only Rust candidate scaffold in `reference/rust`.
-
-```bash
-npm run verify:reference-rust-scaffold
-```
-
-That check verifies packaged scaffold files, XNYA atom constants, deterministic parser error-code names, and the `publish = false` boundary. It does not compile Rust or claim vector parity yet.
-
-## Current limitation
-
-So the current cross-runtime posture is:
-
-- contract and vectors are published
-- Node.js reference behavior is enforced
-- Python atom/payload/frame, non-signed proof-bundle vector parity, and optional Ed25519 crypto-gated verification are implemented as a candidate scaffold
-- Rust source scaffold is packaged and boundary-checked, but not vector-verified
-- additional runtime implementations can now target the same vector sets
-
-## Final release expectation
-
-Before calling the proof product fully closed, future implementations should be able to replay the published vectors and reach the same outcomes for:
-
-- canonical event commitments
-- receipt IDs
-- proof-bundle verification
-- adversarial rejection reasons where contractually stable
+# xoonya Cross-Runtime Posture
+
+`xoonya` is intended to be reproducible across runtimes.
+
+The current reference implementation is Node.js, but the proof contract is designed so that:
+
+- canonical event normalization is explicit
+- hashing is deterministic
+- receipt derivation is deterministic
+- proof-bundle verification is deterministic
+
+## Current reference runtime
+
+- Node.js `>=18`
+
+## What is already explicit
+
+- canonical object ordering is defined by the proof implementation
+- event commitment is derived from canonical serialized event content
+- receipt IDs are derived from canonical receipt-signing material
+- proof-bundle verification checks deterministic structural invariants
+
+## Current publication artifacts
+
+- `vectors/conformance-vectors.json`
+- `vectors/adversarial-vectors.json`
+
+These vectors are intended to be reusable by future implementations in other runtimes.
+
+## Python candidate scaffold
+
+This repo now ships a Python candidate scaffold in `reference/python`.
+
+It is independent from the JavaScript implementation and can replay the XNYA atom, native atom adversarial, native payload profile, line-rate frame, canonical event, receipt, and non-signed proof-bundle vectors:
+
+```bash
+npm run verify:reference-python
+```
+
+This is not yet a full second reference implementation. It can verify Ed25519 native signed vectors when Python's optional `cryptography` package is installed; otherwise it proves the deterministic `native_signature_crypto_dependency_missing` boundary. It does not claim always-on native signature-suite cryptographic verification, secp256k1/P-256 parity, external proof import, or all native signed proof-bundle round-trip behavior.
+
+The crypto-enabled optional check is:
+
+```bash
+npm run verify:reference-python-crypto
+```
+
+That command creates a temporary isolated Python virtual environment, installs `reference/python/requirements-optional.txt`, and requires the Ed25519 native signed vector to verify.
+
+## Rust candidate scaffold
+
+This repo also ships a source-only Rust candidate scaffold in `reference/rust`.
+
+```bash
+npm run verify:reference-rust-scaffold
+```
+
+That check verifies packaged scaffold files, XNYA atom constants, deterministic parser error-code names, and the `publish = false` boundary. It does not compile Rust or claim vector parity yet.
+
+## Current limitation
+
+So the current cross-runtime posture is:
+
+- contract and vectors are published
+- Node.js reference behavior is enforced
+- Python atom/payload/frame, non-signed proof-bundle vector parity, and optional Ed25519 crypto-gated verification are implemented as a candidate scaffold
+- Rust source scaffold is packaged and boundary-checked, but not vector-verified
+- additional runtime implementations can now target the same vector sets
+
+## Final release expectation
+
+Before calling the proof product fully closed, future implementations should be able to replay the published vectors and reach the same outcomes for:
+
+- canonical event commitments
+- receipt IDs
+- proof-bundle verification
+- adversarial rejection reasons where contractually stable

package/EXAMPLE_PATHS.md

@@ -1,53 +1,53 @@
-# xoonya Example Paths
-
-These are the recommended public examples for `xoonya`.
-
-## Broad package tour
-
-Run:
-
-```bash
-node examples/package_quickstart.js
-```
-
-Use this when you want the widest proof-package walkthrough.
-
-## Cross-repo carried handoff review
-
-Run:
-
-```bash
-node examples/review_carried_handoff.js
-```
-
-Use this when you want the clearest carried runtime-to-proof path.
-
-## Partner proof walkthrough
-
-Run:
-
-```bash
-node examples/partner_proof_walkthrough.js
-```
-
-Use this when you want the shortest launch oriented proof story.
-
-## Proof review walkthrough
-
-Run:
-
-```bash
-node examples/proof_review_walkthrough.js
-```
-
-Use this when you want the compact result-package review path.
-
-## Integration boundary walkthrough
-
-Run:
-
-```bash
-node examples/integration_boundary_walkthrough.js
-```
-
-Use this when you want the narrow proof-integration boundary rather than the full package tour.
+# xoonya Example Paths
+
+These are the recommended public examples for `xoonya`.
+
+## Broad package tour
+
+Run:
+
+```bash
+node examples/package_quickstart.js
+```
+
+Use this when you want the widest proof-package walkthrough.
+
+## Cross-repo carried handoff review
+
+Run:
+
+```bash
+node examples/review_carried_handoff.js
+```
+
+Use this when you want the clearest carried runtime-to-proof path.
+
+## Partner proof walkthrough
+
+Run:
+
+```bash
+node examples/partner_proof_walkthrough.js
+```
+
+Use this when you want the shortest launch oriented proof story.
+
+## Proof review walkthrough
+
+Run:
+
+```bash
+node examples/proof_review_walkthrough.js
+```
+
+Use this when you want the compact result-package review path.
+
+## Integration boundary walkthrough
+
+Run:
+
+```bash
+node examples/integration_boundary_walkthrough.js
+```
+
+Use this when you want the narrow proof-integration boundary rather than the full package tour.