xoonya 2.1.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/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

@@ -1,12 +1,14 @@
 # xoonya Publish Plan
 
 1. Run `npm run verify:release-candidate`.
-2. Run `npm pack --dry-run --json` and confirm the package contents.
-3. Publish with `npm publish --access public`.
-4. Redeploy the live service surfaces.
-5. Verify:
+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`
-6. Run the first public proof-side review path.
+   - `/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)
@@ -63,6 +84,10 @@ For release-grade adoption posture, inspect:
 - `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`
@@ -84,6 +109,8 @@ For release-grade adoption posture, inspect:
 - `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`

package/RELEASE_CHECKLIST.md

@@ -2,9 +2,15 @@
 
 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`
-4. Run the first public proof-side review path.
-5. Only then publish the npm package.
+   - `/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.

package/RELEASE_NOTES.md

@@ -1,6 +1,6 @@
-# xoonya 2.1.0 Release Notes
+# xoonya 2.2.0 Release Notes
 
-`xoonya` 2.1.0 is the public proof-spine release-candidate line.
+`xoonya` 2.2.0 is the public proof-spine program-complete line.
 
 Highlights:
 
@@ -10,10 +10,19 @@ Highlights:
 - 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. inspect `/v1/release-candidate/summary` on the deployed service
+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)