xytara 3.1.0 → 3.1.2

package/PRODUCTION_MANUAL_CLOSEOUT_SEQUENCE.md

@@ -1,172 +0,0 @@
-# xytara Production Manual Closeout Sequence
-
-This is the final manual pack to take `xytara` from verified package to live production runtime.
-
-Follow this in order.
-
-## 1. Fill the three source-of-truth files
-
-Fill:
-
-- [.env.production.checklist](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xytara/.env.production.checklist)
-- private treasury source of truth: `your private treasury source-of-truth file outside the repos`
-- [EXECUTION_TARGETS.production.worksheet.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xytara/EXECUTION_TARGETS.production.worksheet.json)
-
-Optional helper:
-
-- maintain `your private treasury source-of-truth file outside the repos` as the only private treasury source of truth, then upload it to Render as `TREASURY_DESTINATIONS.production.json`
-
-Then create the real private files:
-
-- `.env.production`
-- Render Secret File: `TREASURY_DESTINATIONS.production.json`
-
-And either:
-
-- set `XYTARA_EXECUTION_TARGETS_JSON` directly in `.env.production`
-- or load the final execution-target JSON through your deployment secret system
-
-## 2. Required secrets and live values
-
-You must fill these before launch:
-
-- `XYTARA_CREDIT_BRIDGE_BEARER_TOKEN`
-- `XYTARA_ACCOUNT_AUTH_BEARER_TOKEN`
-- `XYTARA_CALLBACK_SIGNING_SECRET`
-- `XYTARA_CHECKOUT_WEBHOOK_SECRET`
-- `XYTARA_WALLET_REGISTRY_JSON`
-- `XYTARA_TREASURY_DESTINATIONS_PATH`
-- `XYTARA_BSV_TERANODE_MERCHANT_ADDRESS` or `XYTARA_BSV_TERANODE_MERCHANT_PAYMAIL`
-
-Conditional live-front secrets:
-
-- `XYTARA_L402_SHARED_SECRET` when `XYTARA_L402_ENABLED=true`
-- `XYTARA_BOLT_SHARED_SECRET` when `XYTARA_BOLT_ENABLED=true`
-- `XYTARA_MPP_SHARED_SECRET` when `XYTARA_MPP_ENABLED=true`
-
-Conditional BSV submit secrets:
-
-- `XYTARA_BSV_ARC_RPC_URL`, `XYTARA_BSV_ARC_URL`, or `XYTARA_BSV_TERANODE_RPC_URL` when arc submission mode is enabled
-- `XYTARA_BSV_ARC_RPC_API_KEY`, `XYTARA_BSV_ARC_API_KEY`, or `XYTARA_BSV_TERANODE_RPC_API_KEY` when arc submission mode is enabled
-
-## 3. Required production decisions
-
-Decide these explicitly:
-
-- persistent storage mode:
-  - `XYTARA_STATE_FILE` on durable disk
-  - or Supabase via `XYTARA_SUPABASE_URL` and `XYTARA_SUPABASE_SERVICE_ROLE_KEY`
-- launch payment fronts:
-  - `x402`
-  - hosted checkout
-  - `L402`
-  - `BOLT`
-  - `MPP`
-- launch execution posture:
-  - native-only
-  - provider-backed for selected lanes
-  - provider-backed as required via `XYTARA_EXTERNAL_EXECUTION_REQUIRED=true`
-- outbound network-family posture:
-  - leave `auto` for neutral dual-stack behavior
-  - prefer IPv6 where operator/provider infrastructure is IPv6-strong
-  - prefer IPv4 only when a provider or callback target still needs it
-
-## 4. Minimum real treasury setup
-
-In `your private treasury source-of-truth file outside the repos`, fill real `external_ref` values for every live rail you will claim, then upload that file to Render as `TREASURY_DESTINATIONS.production.json`.
-
-Minimum recommended launch set:
-
-- `bsv_teranode.external_ref`
-- `base.external_ref`
-- `usdc.external_ref`
-
-Optional additional rails:
-
-- `evm.external_ref`
-- `dai.external_ref`
-- `solana_payment.external_ref`
-- `xpr_payment.external_ref`
-- `antelope_payment.external_ref`
-- `monero.external_ref`
-
-## 5. Minimum real execution setup
-
-In `XYTARA_EXECUTION_TARGETS_JSON`, bind every provider-backed lane you intend to sell live.
-
-Minimum recommended launch bindings:
-
-- at least one `trust.verify` target if you want external proof/verification providers live
-- at least one `adapter.mcp.invoke` target if you want live third-party tool execution
-
-## 6. Production preflight
-
-Before public launch:
-
-1. start `xytara` with real `.env.production`
-2. run `npm run verify:production-readiness`
-3. inspect:
-   - `GET /v1/go-live`
-   - `GET /v1/go-live/summary`
-   - `GET /v1/capability-registry/execution-truth`
-   - `GET /v1/payment-fronts`
-   - `GET /v1/checkout/events/security`
-   - `GET /v1/l402/security` if enabled
-   - `GET /v1/bolt/security` if enabled
-   - `GET /v1/stripe-mpp/security` if enabled
-   - `GET /v1/settlement/bsv-teranode/readiness`
-
-Launch should not proceed until:
-
-- `settlement.submit` no longer depends on missing operator treasury/merchant values
-- every sold provider-backed lane has a real execution target
-- every enabled payment front shows ready security posture
-
-## 7. First live-money validation
-
-Run these in order:
-
-1. one direct `x402` paid execution
-2. one hosted-checkout funded execution or credit issuance flow
-3. one provider-backed execution if you are selling provider lanes
-4. one `L402` run if you are enabling `L402`
-5. one `BOLT` run if you are enabling `BOLT`
-6. one `MPP` run if you are enabling `MPP`
-
-For each run, inspect:
-
-- `GET /v1/payment-ledger`
-- `GET /v1/activity-ledger`
-- `GET /v1/deliveries`
-- `GET /v1/reconciliation-report`
-- `GET /v1/treasury-destinations/operator-pack`
-
-## 8. Launch truth
-
-After the above is complete, the remaining boundary is no longer package implementation.
-
-At that point, launch truth is:
-
-- payment-front-agnostic machine commerce runtime: yes
-- hosted and machine payment ingress: yes
-- autonomous execution/governance/proof spine: yes
-- provider-backed extensibility: yes
-- operator-controlled treasury truth: yes
-
-One careful phrasing rule remains:
-
-- market protocol and payment-front agnosticism strongly
-- market chain agnosticism with care unless you have real live treasury and settlement posture on every claimed chain
-
-## 9. May 2026 Teranode platform discontinuation
-
-The legacy Teranode web platform shutdown should be treated as an operator migration event, not as a reason to weaken the public `bsv_teranode` product contract.
-
-Use:
-
-- [BSV_TERANODE_PLATFORM_DISCONTINUITY_RUNBOOK.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/BSV_TERANODE_PLATFORM_DISCONTINUITY_RUNBOOK.md)
-
-Core rule:
-
-- preserve runtime settlement continuity through live ARC and observer endpoints
-- do not rely on the old dashboard remaining available after `2026-05-15`

package/PROGRAM_COMPLETE_RELEASE.md

@@ -1,63 +0,0 @@
-# xytara Program-Complete Release
-
-`xytara` is no longer an in-flight phase build. The public 10-phase program is complete, and this repository now represents a release-shaped machine-commerce runtime.
-
-## What is complete
-
-- the full phase program is closed
-- the default runtime path is stable
-- reusable credits and entitlements exist on the public spine
-- cross-repo handoff into `xoonya` is documented and runnable
-- operator and partner-facing docs now exist alongside the package
-- runtime durability is explicit instead of hidden
-- Supabase-backed durability is available when persistent disk is not
-
-## What this release means
-
-This release is the point where `xytara` should be evaluated as a public runtime and commerce surface, not as an unfinished internal roadmap.
-
-The recommended evaluation path is now:
-
-1. read `START_HERE.md`
-2. run `node examples/quickstart.js`
-3. run `node examples/partner_launch_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 runtime role quickly
-- run a first machine-commerce path locally
-- inspect release and launch posture through summary surfaces
-- understand partner adapter onboarding without private explanation
-- understand how proof-side followthrough continues into `xoonya`
-
-## Operator outcome
-
-An operator should now be able to:
-
-- inspect runtime durability explicitly
-- verify release-candidate posture quickly
-- onboard generic external builders without writing one-off handoff notes
-- point durability-sensitive adopters to the correct persistence path
-
-## Recommended live checks
-
-- `/v1/release-center/summary`
-- `/v1/release-candidate/summary`
-- `/v1/runtime/durability`
-- `/v1/adapter-partners/summary`
-
-## Release rule
-
-Do not describe this repository as “phase-complete but still basically internal.”
-
-The correct external posture is:
-
-- program complete
-- runtime public
-- partner-ready
-- proof-aware
-- operationally inspectable

package/PROGRAM_STATUS.md

@@ -1,57 +0,0 @@
-# xytara Program Status
-
-`xytara` is no longer in an active milestone-build posture.
-
-The public phase program is complete and the runtime 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:
-
-- transaction discovery, quoting, execution, and lifecycle inspection
-- release-center and phase-program inspection surfaces
-- production-facing adapter onboarding and third-party registration material
-- multi-rail settlement and continuity surfaces through the full 10-phase program
-- machine-readable closeout state 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 first-contact docs
-2. real integrations: wire 1-3 actual partner or internal use cases end to end
-3. operational hardening: improve observability, deployment metadata, and operator audit posture
-4. commercial packaging: prepare demos, launch collateral, and versioned release framing
-
-## Operator Checks
-
-For a quick terminal-state inspection, use:
-
-```bash
-xytara-release --phases --summary
-xytara-release --phase-10 --summary
-xytara-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/xytara/START_HERE.md)
-2. [README.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xytara/README.md)
-3. [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xytara/FINAL_CONTRACT.md)
-4. [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xytara/SERVICE_CONTRACT.md)
-5. [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xytara/PROGRAM_STATUS.md)
-6. [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xytara/CARRIED_HANDOFF_DEMO.md)

package/PUBLISH_PLAN.md

@@ -1,26 +0,0 @@
-# xytara Publish Plan
-
-This plan now supports the final synchronized major release: `3.0.0`.
-
-The intended release shape is:
-
-- frozen execution-truth, default-path, payment-rail-truth, and adapter-protocol-truth surfaces
-- stronger umbrella first-contact alignment to those frozen runtime truths
-- the final launch-grade runtime line after the clean `2.15.0` dress rehearsal
-
-1. Run `npm run verify:release-candidate`.
-2. Run `node examples/partner_launch_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/execution-truth/summary`
-   - `/v1/default-path/summary`
-   - `/v1/payment-rail-truth/summary`
-   - `/v1/adapter-protocol-truth/summary`
-7. Run the first public machine proof path.
-8. Treat the release as the synchronized `3.0.0` final launch-grade runtime cut.

package/RELEASE_CHECKLIST.md

@@ -1,16 +0,0 @@
-# xytara 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_launch_walkthrough.js`.
-3. Redeploy the service and verify:
-   - `/v1/release-center/summary`
-   - `/v1/announcement-pack/summary`
-   - `/v1/outreach-proof/summary`
-   - `/v1/runtime/durability`
-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 path.
-6. Only then publish the npm package.

package/SOFT_LAUNCH_KIT.md

@@ -1,47 +0,0 @@
-# xytara Soft Launch Kit
-
-Use this kit for the first small set of real external builder conversations.
-
-## Core message
-
-`xytara` is governed machine commerce for builders who need paid execution, reusable credits, and proof-aware followthrough.
-
-Use it when:
-
-- an agent or tool needs a paid capability path
-- repeat usage should use funded account balance instead of repeated manual payment
-- execution needs to stay inspectable and continue cleanly into proof review
-
-## First audiences
-
-1. `agent_builder`
-2. `adapter_author`
-3. `tool_or_marketplace_author`
-
-## First artifacts
-
-- `PARTNER_READY_PATH.md`
-- `/v1/release-center/summary`
-- `/v1/announcement-pack/summary`
-- `/v1/outreach-proof/summary`
-- `/v1/adapter-partners/summary`
-- `xytara-release --center --summary`
-- `xytara first-run --run-quote --account ACCOUNT_REF --pretty`
-
-## Outreach sequence
-
-1. send the short pitch and one matching first proof path
-2. point the audience to one artifact, not all artifacts
-3. watch which first path they actually try
-4. collect confusion on install, wording, and trust posture
-5. tighten before broader outreach
-
-## Watch closely
-
-- install friction
-- first-run confusion
-- adapter authoring confusion
-- promotion trust-model confusion
-- confusion between direct pay and funded-runtime paths
-
-The default generic external-builder handoff should now be `PARTNER_READY_PATH.md` rather than a free-form doc dump.

package/services/mcp-execution-target/DISCOVERY_REGISTRY_PLAYBOOK.md

@@ -1,141 +0,0 @@
-# xytara MCP Discovery Playbook
-
-This playbook is the shortest path to agent discovery for the public `xytara-mcp-executor` remote MCP server.
-
-For autonomous agents and listing platforms, the preferred machine-first doorway is the umbrella discovery index:
-
-- `https://www.naxytra.com/v1/agent-discovery-index`
-- `https://www.naxytra.com/v1/agent-discovery-index/summary`
-
-Canonical platform submission copy lives here:
-
-- [AGENT_DISCOVERY_INDEX_LISTING_COPY_2026-05-11.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/release/AGENT_DISCOVERY_INDEX_LISTING_COPY_2026-05-11.md)
-
-Operator checklist:
-
-- [AGENT_DISCOVERY_INDEX_SUBMISSION_CHECKLIST_2026-05-11.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/release/AGENT_DISCOVERY_INDEX_SUBMISSION_CHECKLIST_2026-05-11.md)
-
-## Public surfaces
-
-- Canonical machine entry:
-  - `https://www.naxytra.com/v1/agent-discovery-index`
-- Canonical summary entry:
-  - `https://www.naxytra.com/v1/agent-discovery-index/summary`
-- MCP remote entry:
-  - `https://xytara-mcp-executor.onrender.com/mcp`
-- Server card:
-  - `https://xytara-mcp-executor.onrender.com/server.json`
-- Well-known server card:
-  - `https://xytara-mcp-executor.onrender.com/.well-known/mcp-server.json`
-- Glama claim file:
-  - `https://xytara-mcp-executor.onrender.com/.well-known/glama.json`
-- Domain auth proof:
-  - `https://www.naxytra.com/.well-known/mcp-registry-auth`
-
-## Namespace
-
-Use the reverse-domain namespace backed by the public `naxytra.com` domain:
-
-- `com.naxytra/xytara-mcp-executor`
-
-## Required manual setup
-
-### 1. Publish the MCP registry auth proof on `naxytra.com`
-
-Set this umbrella env var and redeploy `naxytra.com`:
-
-```env
-NAXYTRA_MCP_REGISTRY_AUTH=<registry-auth-public-value>
-```
-
-That value should become visible at:
-
-- `https://www.naxytra.com/.well-known/mcp-registry-auth`
-
-## Recommended registry and platform rollout order
-
-### 1. Official MCP Registry
-
-- Home: `https://registry.modelcontextprotocol.io/`
-- Quickstart: `https://modelcontextprotocol.io/registry/quickstart`
-- Remote server guidance: `https://modelcontextprotocol.io/registry/remote-servers`
-- Authentication guidance: `https://modelcontextprotocol.io/registry/authentication`
-
-### 2. Glama
-
-- Discovery / hosting: `https://glama.ai/mcp/hosting`
-- Public copy should point at the canonical agent discovery index first, then the MCP remote URL.
-- Use the platform submission sheet in the agent discovery index listing copy doc for exact listing text.
-
-### 3. Smithery
-
-- Build and publish docs: `https://smithery.ai/docs/build/publish`
-- New listing flow: `https://smithery.ai/new`
-- Public copy should point at the canonical agent discovery index first, then the MCP remote URL.
-- Use the platform submission sheet in the agent discovery index listing copy doc for exact listing text.
-
-## Suggested publish flow
-
-### Official MCP Registry
-
-Follow the official login flow with domain auth backed by `naxytra.com`, then publish the local [server.json](./server.json) file.
-
-There is also an automated GitHub Actions workflow in the private `xytara` repository:
-
-- `.github/workflows/publish-mcp-executor.yml`
-
-For that workflow, add this GitHub secret:
-
-- `MCP_PRIVATE_KEY`
-
-The workflow expects the raw private key value used by:
-
-- `mcp-publisher login http --domain naxytra.com --private-key <secret>`
-
-### Glama
-
-Submit the remote server URL and server card:
-
-- remote URL: `https://xytara-mcp-executor.onrender.com/mcp`
-- server card: `https://xytara-mcp-executor.onrender.com/server.json`
-- claim file: `https://xytara-mcp-executor.onrender.com/.well-known/glama.json`
-
-### Smithery
-
-Use the same remote URL and card:
-
-- remote URL: `https://xytara-mcp-executor.onrender.com/mcp`
-- server card: `https://xytara-mcp-executor.onrender.com/server.json`
-
-## First validation checks
-
-Before publishing anywhere, confirm:
-
-```powershell
-Invoke-RestMethod https://xytara-mcp-executor.onrender.com/health | ConvertTo-Json -Depth 8
-Invoke-RestMethod https://xytara-mcp-executor.onrender.com/server.json | ConvertTo-Json -Depth 8
-Invoke-RestMethod https://xytara-mcp-executor.onrender.com/mcp | ConvertTo-Json -Depth 8
-Invoke-RestMethod https://www.naxytra.com/.well-known/mcp-registry-auth
-```
-
-## Minimum post-publish smoke test
-
-Use an MCP-capable client and check:
-
-1. `initialize`
-2. `tools/list`
-3. `tools/call` for `summarize`
-4. `tools/call` for `zones.lookup`
-5. `tools/call` for `catalog`
-6. `tools/call` for `reply.draft`
-7. `tools/call` for `json.validate`
-
-The remote server is still intentionally deterministic, but it is no longer a two-tool wedge. The public surface is now broad enough to give agents a cleaner first impression while staying easy to reason about.
-
-## Supporting evidence lanes
-
-If a registry, platform, or reviewer wants the broader trust/evidence set alongside the canonical machine entry, include:
-
-- `https://www.naxytra.com/v1/adapter-certification`
-- `https://www.naxytra.com/v1/trust-portability-boundary`
-- `https://www.naxytra.com/v1/signed-audit-provenance`