xoonya 3.0.1 → 3.1.0

package/START_HERE.md

@@ -1,150 +1,159 @@
-# xoonya Start Here
-
-This is the shortest reliable path for understanding and using the public `xoonya` package in production-facing order.
-
-The phase program is now complete, so this file is the right starting point for a closed and release-shaped proof system rather than an in-flight milestone build.
-
-The product-side implementation, proof posture, and bounded hybrid verification work for the widened `3.0.0` finish line are now complete. The remaining step is the synchronized public `3.0.0` release cut, publish, deploy, and verification sequence documented in [NAXYTRA_3_0_0_RELEASE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/release/NAXYTRA_3_0_0_RELEASE_CONTRACT.md) and [PUBLISH_PLAN.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PUBLISH_PLAN.md).
-
-## 1. Understand The Role
-
-`xoonya` is the proof-side half of the public stack.
-
-Its job is to let a caller:
-
-1. receive the transaction-side handoff from `xytara`
-2. inspect review and run posture
-3. emit proof-native completion artifacts
-4. verify the final proof bundle
-
-For the full public quote -> execute -> prove path, start from:
-
-```text
-https://www.naxytra.com/v1/first-run-kit
-```
-
-Then run the local proof followthrough:
-
-```bash
-xoonya first-run --verify-native --pretty
-```
-
-If you want the frozen machine-readable proof-truth contract behind that flow, inspect:
-
-```text
-GET /v1/proof-truth
-GET /v1/proof-truth/summary
-```
-
-If you want the frozen machine-readable proof default-path contract behind that flow, inspect:
-
-```text
-GET /v1/default-path
-GET /v1/default-path/summary
-```
-
-If you want the frozen machine-readable followthrough claim boundary behind that flow, inspect:
-
-```text
-GET /v1/followthrough-truth
-GET /v1/followthrough-truth/summary
-```
-
-## 2. Run The Fastest Real Example
-
-Run:
-
-```bash
-node examples/package_quickstart.js
-```
-
-This is the fastest way to see the intended proof-side package story end-to-end.
-
-If you want the clearest cross-repo adoption path instead of the broad package tour, continue with:
-
-- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
-
-If you want the shortest neutral external-adoption bundle, continue with:
-
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [PUBLIC_DEMO_SCRIPT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PUBLIC_DEMO_SCRIPT.md)
-- [EXAMPLE_PATHS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/EXAMPLE_PATHS.md)
-- `node examples/partner_proof_walkthrough.js`
-
-## 3. Verify The Whole Package
-
-Run:
-
-```bash
-npm run verify:all
-```
-
-This is the production-confidence check for the published proof package surface.
-
-## 4. Read The Durable Contract
-
-For long-term product understanding, read:
-
-- [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/FINAL_CONTRACT.md)
-- [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/SERVICE_CONTRACT.md)
-- `GET /openapi.json`
-- `GET /asyncapi.json`
-- `GET /cloudevents.json`
-- `GET /v1/auth-profiles`
-- `GET /v1/identity-interop`
-- `GET /v1/providers`
-- `GET /v1/frameworks`
-- `GET /v1/integration-matrix`
-- `GET /v1/telemetry`
-- `GET /v1/provenance`
-- `GET /v1/artifact-distribution`
-- `GET /v1/shared-signals`
-- `GET /v1/feature-control`
-- `GET /v1/major-rails`
-- `GET /v1/treasury`
-- `GET /v1/erc8004`
-- `GET /v1/proof-bridge`
-- `GET /v1/external-proof-import`
-- `GET /v1/result-package-trust`
-- `GET /v1/event-systems`
-- `GET /v1/integrations`
-- [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_STATUS.md)
-- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATOR_START_HERE.md)
-- [OPERATIONS_RUNBOOK.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATIONS_RUNBOOK.md)
-- [PROGRAM_COMPLETE_RELEASE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_COMPLETE_RELEASE.md)
-- [WHY_XYTARA_XOONYA.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/WHY_XYTARA_XOONYA.md)
-- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [TERMINOLOGY.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/TERMINOLOGY.md)
-
-## 5. If You Are Integrating From Outside
-
-Continue with:
-
-- [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
-- [integrations/PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [COMPATIBILITY_NOTE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/COMPATIBILITY_NOTE.md)
-
-## 6. Production Reading Rule
-
-If you only remember one thing, remember this:
-
-The main public path is no longer "understand every proof helper first."
-
-It is:
-
-receive handoff -> inspect review posture -> confirm run posture -> emit and verify proof
-
-If you want the shortest CLI-first read of the package after install, use:
-
-- `xoonya start-here`
-- `xoonya release --summary`
-- `xoonya review --help`
-
-## 7. If You Are Operating The Closed Program
-
-Use:
-
-- [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_STATUS.md)
-- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATOR_START_HERE.md)
+# xoonya Start Here
+
+This is the shortest reliable path for understanding and using the public `xoonya` package in production-facing order.
+
+The phase program is now complete, so this file is the right starting point for a closed and release-shaped proof system rather than an in-flight milestone build.
+
+The product-side implementation, proof posture, and bounded hybrid verification work for the widened `3.0.0` finish line are now complete. The remaining step is the synchronized public `3.0.0` release cut, publish, deploy, and verification sequence documented in [NAXYTRA_3_0_0_RELEASE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/release/NAXYTRA_3_0_0_RELEASE_CONTRACT.md) and [PUBLISH_PLAN.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PUBLISH_PLAN.md).
+
+If you are arriving from the broader public discovery layer, the canonical entry points are:
+
+- https://www.naxytra.com/agents
+- https://www.naxytra.com/v1/agent-discovery-index
+- https://www.naxytra.com/.well-known/agent.json
+
+## 1. Understand The Role
+
+`xoonya` is the proof-side half of the public stack.
+
+Its job is to let a caller:
+
+1. receive the transaction-side handoff from `xytara`
+2. inspect review and run posture
+3. emit proof-native completion artifacts
+4. verify the final proof bundle
+
+For the full public quote -> execute -> prove path, start from:
+
+```text
+https://www.naxytra.com/v1/first-run-kit
+```
+
+Then run the local proof followthrough:
+
+```bash
+xoonya first-run --verify-native --pretty
+```
+
+If you want the frozen machine-readable proof-truth contract behind that flow, inspect:
+
+```text
+GET /v1/proof-truth
+GET /v1/proof-truth/summary
+```
+
+If you want the frozen machine-readable proof default-path contract behind that flow, inspect:
+
+```text
+GET /v1/default-path
+GET /v1/default-path/summary
+```
+
+If you want the frozen machine-readable followthrough claim boundary behind that flow, inspect:
+
+```text
+GET /v1/followthrough-truth
+GET /v1/followthrough-truth/summary
+```
+
+## 2. Run The Fastest Real Example
+
+Run:
+
+```bash
+node examples/package_quickstart.js
+```
+
+This is the fastest way to see the intended proof-side package story end-to-end.
+
+If you want the clearest cross-repo adoption path instead of the broad package tour, continue with:
+
+- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
+
+If you want the shortest neutral external-adoption bundle, continue with:
+
+- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
+- [PUBLIC_DEMO_SCRIPT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PUBLIC_DEMO_SCRIPT.md)
+- [EXAMPLE_PATHS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/EXAMPLE_PATHS.md)
+- `node examples/partner_proof_walkthrough.js`
+
+## 3. Verify The Whole Package
+
+Run:
+
+```bash
+npm run verify:all
+```
+
+This is the production-confidence check for the published proof package surface.
+
+## 4. Read The Durable Contract
+
+For long-term product understanding, read:
+
+- [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/FINAL_CONTRACT.md)
+- [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/SERVICE_CONTRACT.md)
+- `GET /openapi.json`
+- `GET /asyncapi.json`
+- `GET /cloudevents.json`
+- `GET /v1/auth-profiles`
+- `GET /v1/identity-interop`
+- `GET /v1/providers`
+- `GET /v1/frameworks`
+- `GET /v1/integration-matrix`
+- `GET /v1/telemetry`
+- `GET /v1/provenance`
+- `GET /v1/artifact-distribution`
+- `GET /v1/shared-signals`
+- `GET /v1/feature-control`
+- `GET /v1/adapter-certification`
+- `GET /v1/trust-portability-boundary`
+- `GET /v1/signed-audit-provenance`
+- `GET /v1/major-rails`
+- `GET /v1/treasury`
+- `GET /v1/erc8004`
+- `GET /v1/proof-bridge`
+- `GET /v1/external-proof-import`
+- `GET /v1/result-package-trust`
+- `GET /v1/event-systems`
+- `GET /v1/integrations`
+- [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_STATUS.md)
+- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATOR_START_HERE.md)
+- [OPERATIONS_RUNBOOK.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATIONS_RUNBOOK.md)
+- [PROGRAM_COMPLETE_RELEASE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_COMPLETE_RELEASE.md)
+- [WHY_XYTARA_XOONYA.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/WHY_XYTARA_XOONYA.md)
+- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
+- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
+- [TERMINOLOGY.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/TERMINOLOGY.md)
+
+## 5. If You Are Integrating From Outside
+
+Continue with:
+
+- [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
+- [integrations/PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
+- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
+- [COMPATIBILITY_NOTE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/COMPATIBILITY_NOTE.md)
+
+## 6. Production Reading Rule
+
+If you only remember one thing, remember this:
+
+The main public path is no longer "understand every proof helper first."
+
+It is:
+
+receive handoff -> inspect review posture -> confirm run posture -> emit and verify proof
+
+If you want the shortest CLI-first read of the package after install, use:
+
+- `xoonya start-here`
+- `xoonya release --summary`
+- `xoonya review --help`
+
+## 7. If You Are Operating The Closed Program
+
+Use:
+
+- [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_STATUS.md)
+- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATOR_START_HERE.md)

package/TERMINOLOGY.md

@@ -1,55 +1,55 @@
-# 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.
+# 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 +1,43 @@
-# 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.
+# 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.