xoonya 2.0.0 → 2.2.0

package/RELEASE_NOTES.md

@@ -0,0 +1,28 @@
+# xoonya 2.2.0 Release Notes
+
+`xoonya` 2.2.0 is the public proof-spine program-complete line.
+
+Highlights:
+
+- direct one-line proof-side review with `xoonya-review`
+- release, comparison, adoption, scenario, and launch packs over HTTP and CLI
+- release-center, announcement-pack, and release-candidate surfaces for public launch readiness
+- canonical event, receipt, and proof-bundle model
+- bridge and governance surfaces for reviewable proof posture
+- stable runtime-to-proof followthrough
+- partner-ready onboarding and launch docs
+- clearer stack-positioning docs for why proof stays separate from runtime commerce
+
+Recommended first checks:
+
+1. `npm install xoonya`
+2. `xoonya-release --candidate --summary`
+3. `npm run verify:release-candidate`
+4. `node examples/partner_proof_walkthrough.js`
+5. inspect `/v1/release-candidate/summary` and `/v1/proof-center/summary` on the deployed service
+
+Recommended first docs:
+
+- `PROGRAM_COMPLETE_RELEASE.md`
+- `WHY_XYTARA_XOONYA.md`
+- `PARTNER_READY_PATH.md`

package/START_HERE.md

@@ -2,6 +2,8 @@
 
 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.
+
 ## 1. Understand The Role
 
 `xoonya` is the proof-side half of the public stack.
@@ -23,6 +25,17 @@ 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_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`
+
 ## 3. Verify The Whole Package
 
 Run:
@@ -39,6 +52,13 @@ For long-term product understanding, read:
 
 - [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/FINAL_CONTRACT.md)
 - [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/SERVICE_CONTRACT.md)
+- [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)
+- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
+- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PARTNER_READY_PATH.md)
 - [TERMINOLOGY.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/TERMINOLOGY.md)
 
 ## 5. If You Are Integrating From Outside
@@ -47,6 +67,7 @@ Continue with:
 
 - [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
 - [integrations/PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
+- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PARTNER_READY_PATH.md)
 - [COMPATIBILITY_NOTE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/COMPATIBILITY_NOTE.md)
 
 ## 6. Production Reading Rule
@@ -58,3 +79,10 @@ 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
+
+## 7. If You Are Operating The Closed Program
+
+Use:
+
+- [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)

package/WHY_XYTARA_XOONYA.md

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