xoonya 3.1.17 → 3.2.1

package/CARRIED_HANDOFF_DEMO.md

@@ -1,60 +0,0 @@
-# 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 +0,0 @@
-# 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 +0,0 @@
-# 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 +0,0 @@
-# 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.

package/FINAL_CONTRACT.md

@@ -1,445 +0,0 @@
-# xoonya Final Contract
-
-## Purpose
-
-`xoonya` is the neutral proof foundation for machine actions.
-
-It exists to make machine-action evidence:
-
-- deterministic
-- portable
-- minimal
-- verifiable
-- replayable
-- independent of payment rails, settlement systems, and workflow engines
-
-`xoonya` is not a commerce system, policy engine, or execution runtime.
-
-## Public Release Stance
-
-This product is being prepared as a first public release.
-
-That means:
-
-- prior proof formats are design history, not public obligations
-- useful earlier decisions may be preserved where they strengthen the final product
-- older helper shapes do not automatically become the public contract
-
-The public baseline should therefore be chosen for correctness, clarity, determinism, and extensibility, not for backward compatibility with prior private repos.
-
-## Product Boundary
-
-`xoonya` owns:
-
-- canonical event commitment rules
-- canonical hashing rules
-- receipt construction
-- proof bundle construction
-- receipt verification
-- proof bundle verification
-- conformance vectors
-- versioned proof schemas
-
-`xoonya` does not own:
-
-- pricing
-- balances
-- refunds
-- treasury logic
-- workflow semantics
-- task catalogs
-- execution orchestration
-- settlement orchestration
-- market rules
-- governance policy
-
-## Core Doctrine
-
-The proof model is layered.
-
-### Layer 1: Canonical Event Bundle
-
-This is the machine fact being committed.
-
-It is the canonical, deterministic representation of an externally consequential machine event.
-
-### Layer 2: Receipt
-
-This is the minimal commitment artifact.
-
-It proves that a specific identity committed to a specific canonical event commitment under a specific versioned receipt contract.
-
-### Layer 3: Proof Bundle
-
-This carries the richer proof context around the receipt:
-
-- anchors
-- attestation references
-- evidence references
-- batch inclusion material
-- metadata
-
-### Layer 4: Profiles
-
-Profiles are optional domain-specific overlays for things like:
-
-- economic handoff
-- registry lifecycle
-- compliance
-- industry-specific evidence rules
-
-Profiles must not mutate the base proof contract.
-
-## Non-Negotiable Invariants
-
-The following invariants must hold for all final versions.
-
-### 1. Deterministic canonicalization
-
-The same logical event must always produce the same canonical byte representation.
-
-No implementation may depend on:
-
-- locale
-- timezone
-- object insertion order
-- language-specific serializer behavior
-- non-canonical map ordering
-
-### 2. Deterministic hashing
-
-The same canonical event bytes must always yield the same commitment hash.
-
-Hashing must use explicit domain separation.
-
-### 3. Minimal receipt
-
-The receipt must stay small and stable.
-
-It must not absorb:
-
-- economics
-- payment semantics
-- execution transcript detail
-- attestation bodies
-- anchor proofs
-
-### 4. Optional anchoring
-
-Anchoring is optional.
-
-Proof validity must not depend on anchoring.
-
-Anchoring strengthens external assurance and chronology, but does not define whether the receipt is well-formed or verifiable.
-
-### 5. Single machine truth format
-
-There must be one machine-native proof contract.
-
-Human-readable renderings are views or encodings of the same proof objects, not separate proof protocols.
-
-### 6. Versioned stability
-
-Versions are explicit and strict.
-
-Older versions remain historically valid.
-
-New versions must not silently reinterpret older receipts.
-
-## Canonical Event Bundle v1
-
-The canonical event bundle is the fact layer.
-
-Its purpose is to represent an externally consequential machine event in a deterministic and portable way.
-
-### Required fields
-
-- `version`
-- `domain_id`
-- `sequence`
-- `actor_id`
-- `adapter_source`
-- `event_type`
-- `event_hash`
-
-### Optional fields
-
-- `timestamp_ns`
-- `parent_refs`
-- `capability_refs`
-- `attestation_ref`
-- `semantic_slots`
-
-### Rules
-
-- ordering is determined by explicit replay-safe fields, not by timestamps
-- timestamps may exist, but must not define event ordering
-- semantic slots are interpretation hints and must not change the event commitment semantics
-- attestation references are optional and external
-
-### Commitment rule
-
-The canonical event bundle commitment must be derived from the canonical serialized form of the full event bundle object, not from a hand-picked concatenation of selected fields.
-
-This is the preferred rule because it:
-
-- reduces hidden ambiguity
-- reduces implementation drift
-- makes conformance easier to test
-- makes schema evolution cleaner
-
-## Receipt v1
-
-The receipt is the minimal commitment artifact.
-
-### Purpose
-
-The receipt proves:
-
-- which proof contract version applies
-- which identity issued the commitment
-- which canonical event commitment is being committed
-- that the issuer signed or committed that event commitment
-
-### Required fields
-
-- `version`
-- `receipt_id`
-- `agent_identity`
-- `domain_id`
-- `sequence`
-- `event_commitment`
-- `signature`
-
-### Optional fields
-
-- `algorithm`
-
-### Rules
-
-- `receipt_id` must be deterministic or derivable in a stable way
-- `agent_identity` must be a stable identity reference, not a commerce-specific account handle
-- `event_commitment` must equal the canonical event bundle commitment
-- `signature` must verify against the exact commitment material defined by the contract
-
-### Explicit exclusions
-
-The receipt must not directly carry:
-
-- prices
-- balances
-- refunds
-- quote details
-- settlement details
-- anchor records
-- Merkle paths
-- attestation bodies
-- execution transcripts
-
-## Proof Bundle v1
-
-The proof bundle is the portable richer proof container.
-
-### Required fields
-
-- `ceb`
-- `receipt`
-
-### Optional fields
-
-- `anchors`
-- `attestations`
-- `evidence_refs`
-- `batch_refs`
-- `metadata`
-
-### Purpose
-
-The proof bundle is where richer proof and portability features live without bloating the receipt.
-
-This is the correct place for:
-
-- chain or ledger anchors
-- block references
-- batch roots
-- inclusion proofs
-- external evidence references
-- optional attestation references
-
-### Rules
-
-- the receipt remains valid without a proof bundle
-- the proof bundle must never alter the meaning of the receipt
-- all optional fields must be additive, not redefining
-
-## Attestation Relationship
-
-Attestation is separate from proof.
-
-`xoonya` may reference attestation material, commit to attestation hashes, and verify attestation-shaped adjuncts if needed, but attestation must remain conceptually separate from the receipt core.
-
-### Rule
-
-Attestation may be consumed.
-It must not become the receipt.
-
-## Profiles
-
-Profiles are optional structured overlays built on top of base proof primitives.
-
-Examples:
-
-- economic receipt profile
-- registry lifecycle profile
-- compliance profile
-
-### Profile rule
-
-Profiles may:
-
-- reference receipts
-- reference proof bundles
-- define domain-specific payload semantics
-- define domain-specific verification logic
-
-Profiles may not:
-
-- redefine base receipt meaning
-- redefine canonical event bundle meaning
-- create hidden alternate proof cores
-
-## Batching
-
-Batching is supported, but not part of the minimal receipt core.
-
-### Rule
-
-Multiple proof commitments may be compressed into a deterministic batch root.
-
-Batch-related material belongs in:
-
-- proof bundle
-- batch metadata
-- inclusion proofs
-- anchor references
-
-not in the base receipt itself.
-
-## Verification Contract
-
-Verification must produce deterministic outcomes.
-
-### Verification result fields
-
-- `ok`
-- `code`
-- `message`
-- optional `details`
-
-### Canonical failure classes
-
-- invalid schema
-- unsupported version
-- hash mismatch
-- signature mismatch
-- receipt mismatch
-- bundle mismatch
-- profile mismatch
-
-### Rule
-
-The same invalid input must fail the same way across conformant implementations.
-
-## Versioning Strategy
-
-### v1
-
-Freeze:
-
-- canonical event bundle v1
-- receipt v1
-- proof bundle v1
-- verification result contract v1
-
-### Future versions
-
-A new version is justified only when:
-
-- commitment semantics change
-- canonicalization semantics change
-- identity/signature semantics change in a breaking way
-- proof container semantics change in a breaking way
-
-New profiles do not require a new core proof version unless they change base semantics.
-
-## Conformance Requirements
-
-Any implementation claiming compatibility must pass:
-
-- canonicalization vectors
-- hashing vectors
-- receipt creation vectors
-- receipt verification vectors
-- proof bundle verification vectors
-- adversarial vectors
-
-### Adversarial vector classes
-
-- field ordering drift
-- null / absent field ambiguity
-- unicode normalization edge cases
-- timestamp representation drift
-- duplicate proof entries
-- wrong anchor references
-- wrong batch inclusion paths
-- signature mismatch
-- tampered metadata
-- version mismatch
-
-## Public API Direction
-
-The public API of `xoonya` should center on:
-
-- `canonicalizeEvent`
-- `hashEvent`
-- `emitReceipt`
-- `verifyReceipt`
-- `buildProofBundle`
-- `verifyProofBundle`
-
-Optional profile helpers may be added separately.
-
-## What Should Be Carried Forward From Earlier Proof Iterations
-
-Keep:
-
-- minimal commitment philosophy
-- strict domain separation
-- optional anchoring
-- proof envelope / bundle layering
-- additive profile concept
-- strong conformance vector discipline
-
-Do not freeze directly:
-
-- historical implementation names
-- historical version labels
-- exact old byte-count decisions as sacred
-- old rail-shaped assumptions
-
-## Final Product Position
-
-`xoonya` should become:
-
-- the neutral machine truth layer
-- the portable proof layer
-- the deterministic evidence layer
-
-It should be usable:
-
-- independently of `xytara`
-- independently of any chain
-- independently of any specific payment rail
-- independently of any specific runtime
-
-That independence is the foundation of the whole stack.