xoonya 2.0.0 → 2.2.0

package/CARRIED_HANDOFF_DEMO.md

@@ -0,0 +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`

package/EXAMPLE_PATHS.md

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

package/FINAL_CONTRACT.md

@@ -17,13 +17,13 @@ It exists to make machine-action evidence:
 
 ## Public Release Stance
 
-This product is being prepared as a first public release from private lineage.
+This product is being prepared as a first public release.
 
 That means:
 
-- prior internal proof formats are design history, not public obligations
-- useful lineage may be preserved where it strengthens the final product
-- historical private helper shapes do not automatically become the public contract
+- 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.
 
@@ -409,7 +409,7 @@ The public API of `xoonya` should center on:
 
 Optional profile helpers may be added separately.
 
-## What Should Be Carried Forward From Older Proof Lineage
+## What Should Be Carried Forward From Earlier Proof Iterations
 
 Keep:
 
@@ -422,7 +422,7 @@ Keep:
 
 Do not freeze directly:
 
-- historical internal names
+- historical implementation names
 - historical version labels
 - exact old byte-count decisions as sacred
 - old rail-shaped assumptions

package/OPERATIONS_RUNBOOK.md

@@ -0,0 +1,50 @@
+# xoonya Operations Runbook
+
+Use this runbook for the normal post-program proof-side operating posture.
+
+## Daily checks
+
+Run:
+
+```bash
+xoonya-release --center --summary
+xoonya-release --candidate --summary
+```
+
+Inspect:
+
+- `/v1/release-center/summary`
+- `/v1/release-candidate/summary`
+- `/v1/proof-center/summary`
+
+## Proof-side confidence checks
+
+Run:
+
+```bash
+npm run verify:examples
+npm run verify:release-candidate
+```
+
+## Handoff review checks
+
+Keep these ready:
+
+- `/v1/proof-center/result-package-handoff/review/summary`
+- `CARRIED_HANDOFF_DEMO.md`
+- `PARTNER_READY_PATH.md`
+- `PUBLIC_DEMO_SCRIPT.md`
+
+## If an outside team asks “what belongs here?”
+
+Point them to:
+
+1. `START_HERE.md`
+2. `PARTNER_READY_PATH.md`
+3. `integrations/PROOF_INTEGRATION_PROCESS.md`
+
+## Boundary rule
+
+If a question depends on payment, funding, settlement, or workflow orchestration, move it back to `xytara`.
+
+If it depends on reviewable proof carry and deterministic proof emission, it can stay in `xoonya`.

package/OPERATOR_START_HERE.md

@@ -0,0 +1,67 @@
+# xoonya Operator Start Here
+
+This is the shortest path for an operator who needs to evaluate `xoonya` after the 10-phase program has already closed.
+
+## 1. Confirm Terminal Program State
+
+Run:
+
+```bash
+xoonya-release --phases --summary
+xoonya-release --phase-10 --summary
+```
+
+Or inspect:
+
+- `GET /v1/phases/summary`
+- `GET /v1/phases/phase-10/gate/summary`
+- `GET /v1/phases/phase-10/completion/summary`
+
+## 2. Confirm Release Posture
+
+Run:
+
+```bash
+xoonya-release --center --summary
+xoonya-release --candidate --summary
+```
+
+These are the fastest checks for "is the proof package live, coherent, and publish-shaped?"
+
+## 3. Exercise The Proof Path
+
+Run:
+
+```bash
+node examples/package_quickstart.js
+```
+
+For direct handoff review, also run:
+
+```bash
+xoonya-review --file ./handoff.json --summary
+```
+
+## 4. Verify Confidence
+
+Run:
+
+```bash
+npm run verify:all
+npm run verify:release-candidate
+```
+
+For the compact day-two operator path, also read:
+
+- `OPERATIONS_RUNBOOK.md`
+
+## 5. Choose The Next Workstream
+
+After the program is closed, the next useful work is one of:
+
+- productization
+- real carried-handoff integration
+- operational hardening
+- launch and release packaging
+
+If you only pick one, pick a real integration and keep the docs/productization work close behind it.

package/PARTNER_READY_PATH.md

@@ -0,0 +1,67 @@
+# 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/PROGRAM_COMPLETE_RELEASE.md

@@ -0,0 +1,52 @@
+# xoonya Program-Complete Release
+
+`xoonya` is no longer an in-flight proof milestone. The public 10-phase program is complete, and this repository now represents a release-shaped proof system.
+
+## What is complete
+
+- the full phase program is closed
+- the canonical proof model is stable
+- runtime-to-proof followthrough is documented and runnable
+- proof-center, bridge, and governance surfaces are present
+- operator and partner-facing docs now exist alongside the package
+- proof-side integration posture is explicit and narrow
+
+## What this release means
+
+This release is the point where `xoonya` should be evaluated as a public proof system, not as an unfinished internal proof kernel.
+
+The recommended evaluation path is now:
+
+1. read `START_HERE.md`
+2. run `node examples/package_quickstart.js`
+3. run `node examples/partner_proof_walkthrough.js`
+4. inspect `CARRIED_HANDOFF_DEMO.md`
+5. inspect `PARTNER_READY_PATH.md`
+
+## Public outcome
+
+An external builder should now be able to:
+
+- understand the proof-side role quickly
+- review one carried runtime handoff
+- emit and verify proof-native completion
+- understand the narrow proof-integration boundary without private guidance
+
+## Recommended live checks
+
+- `/v1/release-center/summary`
+- `/v1/proof-center/summary`
+- `/v1/proof-center/result-package-handoff/review/summary`
+- `/v1/integrations/promotion-readiness`
+
+## Release rule
+
+Do not describe this repository as “proof support that still needs the rest of the roadmap.”
+
+The correct external posture is:
+
+- program complete
+- proof public
+- handoff-ready
+- narrow by design
+- reviewable by default

package/PROGRAM_STATUS.md

@@ -0,0 +1,57 @@
+# xoonya Program Status
+
+`xoonya` is no longer in an active milestone-build posture.
+
+The public phase program is complete and the proof system now sits in terminal closeout posture:
+
+- `current_phase: "program_closed"`
+- `completed_phase_count: 10`
+- `active_phase_count: 0`
+- Phase 10 decision: `ready_for_program_closeout`
+
+## What Exists Now
+
+The live package now includes:
+
+- proof-side review, run, and verification surfaces
+- release-center and phase-program inspection surfaces
+- cross-runtime handoff and proof-integration guidance
+- proof continuity and governance surfaces through the full 10-phase program
+- machine-readable terminal closeout instead of an indefinitely open final phase
+
+## Best Next Work
+
+The highest-value next work is no longer "add more phases."
+
+It is:
+
+1. productization: tighten onboarding, examples, install paths, and proof adoption docs
+2. real integrations: wire real carried handoff bundles from `xytara` or external systems
+3. operational hardening: improve operator audit posture, telemetry, and deployment checks
+4. commercial packaging: prepare demos, launch collateral, and versioned release framing
+
+## Operator Checks
+
+For a quick terminal-state inspection, use:
+
+```bash
+xoonya-release --phases --summary
+xoonya-release --phase-10 --summary
+xoonya-release --center --summary
+```
+
+Or inspect the live HTTP surfaces:
+
+- `GET /v1/phases/summary`
+- `GET /v1/phases/phase-10/completion/summary`
+- `GET /v1/phases/phase-10/gate/summary`
+- `GET /v1/release-center/summary`
+
+## Recommended Reading Order
+
+1. [START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/START_HERE.md)
+2. [README.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/README.md)
+3. [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/FINAL_CONTRACT.md)
+4. [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/SERVICE_CONTRACT.md)
+5. [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PROGRAM_STATUS.md)
+6. [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)

package/PUBLIC_DEMO_SCRIPT.md

@@ -0,0 +1,79 @@
+# 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/PUBLISH_PLAN.md

@@ -0,0 +1,14 @@
+# xoonya Publish Plan
+
+1. Run `npm run verify:release-candidate`.
+2. Run `node examples/partner_proof_walkthrough.js`.
+3. Run `npm pack --dry-run --json` and confirm the package contents.
+4. Publish with `npm publish --access public`.
+5. Redeploy the live service surfaces.
+6. Verify:
+   - `/v1/release-candidate/summary`
+   - `/v1/release-center/summary`
+   - `/v1/announcement-pack/summary`
+   - `/v1/outreach-proof/summary`
+   - `/v1/proof-center/summary`
+7. Run the first public proof-side review path.

package/README.md

@@ -12,6 +12,8 @@ It exists to make machine evidence:
 
 This repo is the proof-side half of the final two-repo public stack. It focuses on canonical events, receipts, proof bundles, and verification. It does not own pricing, catalogs, workflow orchestration, payment rails, or settlement policy.
 
+The 10-phase public program is now complete. `xoonya` is in terminal closeout posture rather than active milestone build posture.
+
 ## Start Here
 
 If you are new to the proof-side package, use this order:
@@ -21,6 +23,25 @@ If you are new to the proof-side package, use this order:
 3. run `npm run verify:all`
 4. use [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/FINAL_CONTRACT.md) and [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/SERVICE_CONTRACT.md) as the durable public contract
 
+If you are evaluating the post-program operating posture, read:
+
+- [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PROGRAM_STATUS.md)
+- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/OPERATOR_START_HERE.md)
+- [OPERATIONS_RUNBOOK.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/OPERATIONS_RUNBOOK.md)
+- [PROGRAM_COMPLETE_RELEASE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PROGRAM_COMPLETE_RELEASE.md)
+- [WHY_XYTARA_XOONYA.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/WHY_XYTARA_XOONYA.md)
+
+If you want one concrete cross-repo adoption story, start with:
+
+- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/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_public/naxytra/xoonya/PARTNER_READY_PATH.md)
+- [PUBLIC_DEMO_SCRIPT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PUBLIC_DEMO_SCRIPT.md)
+- [EXAMPLE_PATHS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/EXAMPLE_PATHS.md)
+- `node examples/partner_proof_walkthrough.js`
+
 If you are integrating from outside the stack, also read:
 
 - [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
@@ -37,12 +58,73 @@ The intended production-facing proof path is now:
 
 The rest of this README explains the broader route ladder, but the public starting posture should now be understandable from that one proof-side path.
 
-For explicit runtime-economics carry, the bridge now also accepts a canonical `handoff_bundle` wrapper from `xytara` so the economic consequence seam stays contract-shaped across the two repos instead of being reassembled ad hoc by callers.
+For a direct one-line proof-side review of a carried handoff bundle, use the bundled CLI:
+
+```bash
+xoonya-review --file ./handoff.json --summary
+```
+
+For release-grade adoption posture, inspect:
+
+- `GET /v1/release-pack`
+- `GET /v1/release-pack/summary`
+- `GET /v1/release-pack/comparison`
+- `GET /v1/release-pack/comparison/summary`
+- `GET /v1/release-pack/adoption`
+- `GET /v1/release-pack/adoption/summary`
+- `GET /v1/release-pack/scenarios`
+- `GET /v1/release-pack/scenarios/summary`
+- `GET /v1/release-pack/launch`
+- `GET /v1/release-pack/launch/summary`
+- `GET /v1/release-manifest`
+- `GET /v1/release-manifest/summary`
+- `GET /v1/release-notes`
+- `GET /v1/release-notes/summary`
+- `GET /v1/release-center`
+- `GET /v1/release-center/summary`
+- `GET /v1/release-history`
+- `GET /v1/release-history/summary`
+- `GET /v1/phases`
+- `GET /v1/phases/summary`
+- `GET /v1/phases/phase-1`
+- `GET /v1/phases/phase-1/summary`
+- `GET /v1/publish-plan`
+- `GET /v1/publish-plan/summary`
+- `GET /v1/ecosystem-entry`
+- `GET /v1/ecosystem-entry/summary`
+- `GET /v1/launch-narrative`
+- `GET /v1/launch-narrative/summary`
+- `GET /v1/outreach-proof`
+- `GET /v1/outreach-proof/summary`
+- `GET /v1/announcement-pack`
+- `GET /v1/announcement-pack/summary`
+- `GET /v1/release-candidate`
+- `GET /v1/release-candidate/summary`
+- `xoonya-release --summary`
+- `xoonya-release --comparison --summary`
+- `xoonya-release --adoption --summary`
+- `xoonya-release --scenarios --summary`
+- `xoonya-release --launch --summary`
+- `xoonya-release --manifest --summary`
+- `xoonya-release --notes --summary`
+- `xoonya-release --center --summary`
+- `xoonya-release --history --summary`
+- `xoonya-release --phases --summary`
+- `xoonya-release --phase-1 --summary`
+- `xoonya-release --ecosystem --summary`
+- `xoonya-release --narrative --summary`
+- `xoonya-release --outreach-proof --summary`
+- `xoonya-release --announcement --summary`
+- `xoonya-release --candidate --summary`
+
+These surfaces package the current proof-side value story, first-contact proof-review CLI path, proof-center posture, handoff/review/governance surfaces, and integration breadth into one machine-readable launch boundary.
+
+For explicit runtime-economics carry, the proof-side handoff boundary now also accepts a canonical `handoff_bundle` wrapper from `xytara` so the economic consequence seam stays contract-shaped across the two repos instead of being reassembled ad hoc by callers.
 
 That same carried bundle can now also ride inside the normal result-package handoff path:
 
 - if `xytara` sends `handoff_bundle.economic_consequence_handoff_bundle`
-- `xoonya` will validate it through the existing bounded bridge logic
+- `xoonya` will validate it through the existing bounded handoff logic
 - normal result-package review and run surfaces will expose compact economic-conformance review data automatically
 - direct-pay or non-metered handoffs remain unaffected
 
@@ -229,6 +311,8 @@ Primary proof-model routes:
 - `POST /v1/proof-center/result-package-handoff/review/operating-interface-run`
 - `POST /v1/proof-center/result-package-handoff/review/operating-integration`
 - `POST /v1/proof-center/result-package-handoff/review/operating-integration-carry`
+
+When `xytara` sends `handoff_bundle.economic_consequence_handoff_bundle`, `xoonya` now preserves a compact `economic_audit_summary` inside review output so proof-side operators can see the linked `account_ref`, `usage_meter_ref`, `credit_spend_ref`, `usage_units`, `pricing_band`, `payment_ref`, `settlement_ref`, `settlement_txid`, `settlement_finality_status`, `treasury_receipt_ref`, `proof_ref`, and `conformance_pack_ref` without re-deriving the carry by hand.
 - `POST /v1/proof-center/result-package-handoff/review/operating-integration-run`
 - `POST /v1/proof-center/result-package-handoff/review/operating-path`
 - `POST /v1/proof-center/result-package-handoff/review/operating-path-carry`

package/RELEASE_CHECKLIST.md

@@ -0,0 +1,16 @@
+# xoonya Release Checklist
+
+1. Run `npm run verify:release-candidate`.
+2. Confirm `npm pack --dry-run --json` includes the public docs and both CLI entrypoints.
+3. Run `node examples/partner_proof_walkthrough.js`.
+3. Redeploy the service and verify:
+   - `/v1/release-center/summary`
+   - `/v1/announcement-pack/summary`
+   - `/v1/outreach-proof/summary`
+   - `/v1/proof-center/summary`
+4. Confirm the program-complete docs are packaged:
+   - `PROGRAM_COMPLETE_RELEASE.md`
+   - `WHY_XYTARA_XOONYA.md`
+   - `PARTNER_READY_PATH.md`
+5. Run the first public proof-side review path.
+6. Only then publish the npm package.