xytara 3.1.0 → 3.1.2

package/GO_LIVE_OPERATOR_PACK.md

@@ -1,412 +0,0 @@
-# xytara Go-Live Operator Pack
-
-This pack turns the current runtime truth into an exact launch checklist.
-
-Runtime surfaces to inspect alongside this document:
-
-- `GET /v1/go-live`
-- `GET /v1/go-live/summary`
-- `GET /v1/capability-registry/execution-truth`
-- `GET /v1/capability-registry/commercialization-summary`
-- `GET /v1/payment-protocols/strategy`
-- `GET /v1/checkout/events/security`
-- `GET /v1/l402/security`
-- `GET /v1/bolt/security`
-- `GET /v1/stripe-mpp/security`
-- `GET /v1/network-transport`
-
-It answers four questions:
-
-1. what is already sellable now
-2. what becomes sellable after operator/provider wiring
-3. which values must be filled before live money and execution
-4. what the first real production validation sequence should be
-
-The widened treasury rails now use one centralized operator path:
-
-- [REAL_PAYMENT_SETUP.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/REAL_PAYMENT_SETUP.md)
-- your private treasury source of truth outside the repos
-
-## 1. Current Capability Truth
-
-Current package truth from the runtime:
-
-- total public tasks: `32`
-- `native_live`: `30`
-- `provider_live`: `0` until real execution targets are configured
-- `operator_inputs_pending`: `1`
-- `provider_wiring_required`: `1`
-
-### Sellable Now
-
-These are currently classified as `native_live` and `sellable_live_now`:
-
-- `trust.verify`
-- `trust.handoff.emit`
-- `trust.handoff.validate`
-- `receipt.validate`
-- `execution_receipt.handoff.emit`
-- `execution_receipt.handoff.validate`
-- `receipt_ledger.handoff.emit`
-- `receipt_ledger.handoff.validate`
-- `runtime.emit`
-- `runtime.anchor`
-- `runtime.emit_anchor`
-- `jobs.quote`
-- `jobs.reserve`
-- `jobs.commit`
-- `jobs.release`
-- `credits.preview`
-- `credits.apply`
-- `a2a.negotiate`
-- `a2a.commit`
-- `a2c.session.open`
-- `a2c.pack.preview`
-- `policy.simulate`
-- `identity.attest.preview`
-- `identity.registry.link`
-- `registry.register`
-- `registry.pack.bundle`
-- `anchoring.submit`
-- `anchoring.pack.preview`
-- `zones.list`
-- `admission.preview`
-
-### Operator-Enabled After Config
-
-These are not blocked by missing platform code. They are blocked by missing live bindings or operator values:
-
-- `settlement.submit`
-  - state: `operator_inputs_pending`
-  - requires:
-    - non-mock BSV settlement runtime mode
-    - merchant address or paymail
-    - real treasury destinations
-- `adapter.mcp.invoke`
-  - state: `provider_wiring_required`
-  - requires:
-    - at least one real execution target in `XYTARA_EXECUTION_TARGETS_JSON`
-
-## 2. Public Sale Posture
-
-Use these rules in go-to-market copy:
-
-- `native_live` tasks can be marketed as self-serve live operations
-- `provider_wiring_required` tasks can be marketed as integration-backed or operator-enabled lanes
-- `operator_inputs_pending` lanes can be marketed as available after treasury/operator setup, not as already-live rails
-
-Shortest honest commercial posture:
-
-- machine-native payment access: `x402`
-- human-friendly money-in: hosted checkout through an external fiat storefront
-- native runtime/governance/proof operations: live now
-- external adapter/provider execution: live when bound through execution targets
-- native BSV settlement: live when merchant and treasury inputs are configured
-- additional payment fronts like `L402` and BOLT-style UTXO/SPV flows can be added through explicit adapter/payment-front bindings without changing the runtime core
-
-## 3. Exact Values To Fill
-
-## 3.1 Runtime Persistence
-
-Choose one:
-
-- `XYTARA_STATE_FILE=<persistent-disk-path>`
-- `XYTARA_SUPABASE_URL=<real-url>`
-- `XYTARA_SUPABASE_SERVICE_ROLE_KEY=<real-service-role-key>`
-
-## 3.2 Payment Verification
-
-Set:
-
-```env
-XYTARA_PAYMENT_VERIFICATION_MODE=local_signed
-XYTARA_PAYMENT_MAX_AGE_SECONDS=300
-XYTARA_WALLET_REGISTRY_JSON=[{"wallet_id":"<wallet-id>","secret":"<wallet-secret>","account_id":"<account-id>"}]
-```
-
-Minimum rule:
-
-- every live payment source needs a real `wallet_id`
-- every live payment source needs a real shared `secret`
-- `account_id` must map to the account you actually want credited/executed
-
-## 3.3 Operator Secrets
-
-Set:
-
-```env
-XYTARA_CREDIT_BRIDGE_BEARER_TOKEN=<real-secret>
-XYTARA_ACCOUNT_AUTH_BEARER_TOKEN=<real-secret>
-XYTARA_CALLBACK_SIGNING_SECRET=<real-secret>
-XYTARA_CHECKOUT_WEBHOOK_SECRET=<real-secret>
-```
-
-If you are enabling the `L402` ingress, also set:
-
-```env
-XYTARA_L402_ENABLED=true
-XYTARA_L402_SHARED_SECRET=<real-secret>
-```
-
-If you are enabling the `BOLT` ingress, also set:
-
-```env
-XYTARA_BOLT_ENABLED=true
-XYTARA_BOLT_SHARED_SECRET=<real-secret>
-```
-
-If you are enabling the `MPP` ingress, also set:
-
-```env
-XYTARA_MPP_ENABLED=true
-XYTARA_MPP_SHARED_SECRET=<real-secret>
-```
-
-## 3.4 Rate Limiting
-
-Keep enabled unless you have an equivalent upstream control:
-
-```env
-XYTARA_RATE_LIMIT_ENABLED=true
-XYTARA_RATE_LIMIT_WINDOW_MS=60000
-XYTARA_RATE_LIMIT_MAX_REQUESTS=600
-```
-
-## 3.5 Treasury Destinations
-
-Create:
-
-- `TREASURY_DESTINATIONS.production.json`
-
-Start from:
-
-- private treasury source of truth: `your private treasury source-of-truth file outside the repos`
-
-Point to it with:
-
-```env
-XYTARA_TREASURY_DESTINATIONS_PATH=./TREASURY_DESTINATIONS.production.json
-```
-
-What to fill in `external_ref`:
-
-- `bsv_teranode`: your real BSV address or paymail
-- `evm`: your real Ethereum mainnet treasury address
-- `base`: your real Base treasury address
-- `solana_payment`: your real Solana receiving address
-- `xpr_payment`: your real XPR account name
-- `metal_payment`: your real Metal account/address
-- `antelope_payment`: your real Antelope account name
-- `hedera_hbar`: your real Hedera account id
-- `kaspa_kas`: your real Kaspa address
-- `polkadot_dot`: your real Polkadot address
-- `digibyte_dgb`: your real DigiByte receiving address
-- `constellation_dag`: your real Constellation receiving address
-- `usdc`: your real USDC receiving address on the intended chain
-- `dai`: your real DAI receiving address on the intended chain
-- `monero`: only if you intentionally enable the internal privacy reserve
-
-## 3.6 Native BSV Settlement
-
-Set at minimum:
-
-```env
-XYTARA_BSV_TERANODE_NETWORK=mainnet
-XYTARA_BSV_TERANODE_SETTLEMENT_RUNTIME_MODE=observe
-XYTARA_BSV_TERANODE_MERCHANT_ADDRESS=<real-bsv-address-or-paymail>
-```
-
-Preferred neutral aliases are also supported:
-
-```env
-XYTARA_BSV_NETWORK=mainnet
-XYTARA_BSV_SETTLEMENT_RUNTIME_MODE=observe
-XYTARA_BSV_MERCHANT_ADDRESS=<real-bsv-address-or-paymail>
-```
-
-If you want live ARC submission:
-
-```env
-XYTARA_BSV_SETTLEMENT_RUNTIME_MODE=arc
-XYTARA_BSV_ARC_RPC_URL=<real-arc-url>
-XYTARA_BSV_ARC_RPC_API_KEY=<real-api-key>
-```
-
-For the May 2026 Teranode platform shutdown, do not rely on the dashboard staying available after cutover. Use:
-
-- [BSV_TERANODE_PLATFORM_DISCONTINUITY_RUNBOOK.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/BSV_TERANODE_PLATFORM_DISCONTINUITY_RUNBOOK.md)
-
-## 3.7 Provider-Backed Execution Targets
-
-Use:
-
-```env
-XYTARA_EXTERNAL_EXECUTION_REQUIRED=true
-XYTARA_EXECUTION_TARGETS_JSON=[...]
-```
-
-Minimum example:
-
-```json
-[
-  {
-    "target_id": "provider_trust_verify_primary",
-    "task_ref": "trust.verify",
-    "endpoint_url": "https://provider.example.com/execute/trust-verify",
-    "provider": "provider_example",
-    "auth_token": "replace-with-real-bearer-token",
-    "timeout_ms": 10000,
-    "enabled": true
-  },
-  {
-    "target_id": "provider_mcp_invoke_primary",
-    "task_ref": "adapter.mcp.invoke",
-    "tool_name": "zones.lookup",
-    "endpoint_url": "https://provider.example.com/mcp/invoke",
-    "provider": "provider_example",
-    "auth_token": "replace-with-real-bearer-token",
-    "timeout_ms": 10000,
-    "enabled": true
-  }
-]
-```
-
-Fastest production-ready path:
-
-- deploy [services/mcp-execution-target/README.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/services/mcp-execution-target/README.md) as a separate web service
-- use its `/execute` route as the `endpoint_url`
-- start with `tool_name = "zones.lookup"` and `tool_name = "summarize"`
-- for broader agent utility, add `tool_name = "catalog"`, `tool_name = "reply.draft"`, and `tool_name = "json.validate"`
-
-Binding rule:
-
-- use `task_ref` when a whole capability lane maps to one provider endpoint
-- use `tool_name` when `adapter.mcp.invoke` should dispatch per tool
-- use `integration_id` when the provider is chosen by integration family
-
-## 3.8 Optional L402 Front Binding
-
-If you want an L402-compatible lane live at launch, fill:
-
-- [L402_BINDINGS.production.worksheet.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/L402_BINDINGS.production.worksheet.json)
-
-Binding rule:
-
-- treat L402 as a payment front into `xytara`
-- do not fork execution or proof behavior for it
-- map successful L402 verification into the same execution authorization or credits issuance posture as other fronts
-
-## 3.9 Optional BOLT / UTXO-SPV Front Binding
-
-If you want a BOLT-style or UTXO-SPV-verifiable lane live at launch, fill:
-
-- [BOLT_BINDINGS.production.worksheet.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/BOLT_BINDINGS.production.worksheet.json)
-
-Binding rule:
-
-- treat BOLT/UTXO-SPV as a payment and settlement-proof front into `xytara`
-- keep runtime execution/governance/proof centralized
-- explicitly map quote binding, payment acceptance, and settlement-proof continuity
-
-## 4. Hosted Checkout Path
-
-Recommended first money-in posture:
-
-1. An external fiat storefront sells API packs or subscriptions through a hosted checkout provider
-2. Paddle webhook normalizes purchase state
-3. anonymous runtime adapter converts entitlement to internal authorization/credits
-4. `xytara` executes and meters
-5. `xoonya` carries proof/review/handoff
-
-Hard requirements for this lane:
-
-- idempotent webhook handling
-- refund and chargeback reversal posture
-- adapter bearer auth
-- one real end-to-end paid execution test
-
-## 5. First Production Validation Sequence
-
-Run this in order:
-
-1. Fill `.env.production` from [.env.production.template](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/.env.production.template)
-2. Create `TREASURY_DESTINATIONS.production.json`
-3. Start `xytara` with persistent runtime storage
-4. Run `npm run verify:production-readiness`
-5. Hit:
-   - `GET /v1/capability-registry/execution-truth`
-   - `GET /v1/capability-registry/commercialization-summary`
-6. Confirm:
-   - `settlement.submit` is no longer `operator_inputs_pending`
-   - provider-backed lanes show configured targets
-7. Run one direct machine-native payment flow through `POST /x402/commands/execute`
-8. Confirm:
-   - `payment-ledger`
-   - `activity-ledger`
-   - `deliveries`
-   - `reconciliation-report`
-   - `treasury-summary`
-9. Run one hosted checkout flow through the external fiat storefront
-10. Confirm:
-    - purchase intent paid
-    - authorization or credits issued
-    - downstream execution created
-11. If launching optional permissionless fronts:
-    - validate L402 gateway or BOLT/SPV gateway verification
-    - confirm those fronts still land in the same `activity-ledger`, `payment-ledger`, and proof surfaces
-    - proof/handoff visible
-
-## 6. Operator Inspection Surfaces
-
-Use these every day after launch:
-
-- `GET /v1/capability-registry/execution-truth`
-- `GET /v1/capability-registry/execution-truth/summary`
-- `GET /v1/capability-registry/commercialization-summary`
-- `GET /v1/payment-protocols/strategy`
-- `GET /v1/payment-fronts`
-- `GET /v1/l402`
-- `GET /v1/bolt`
-- `GET /v1/l402/security`
-- `GET /v1/bolt/security`
-- `GET /v1/stripe-mpp`
-- `GET /v1/stripe-mpp/security`
-- `GET /v1/network-transport`
-- `GET /v1/activity-ledger`
-- `GET /v1/payment-ledger`
-- `GET /v1/reconciliation-report`
-- `GET /v1/deliveries`
-- `GET /v1/treasury-destinations`
-- `GET /v1/treasury-destinations/operator-pack`
-- `GET /v1/settlement/bsv-teranode`
-- `GET /v1/settlement/bsv-teranode/readiness`
-
-## 7. Industry-Aligned Product Rule
-
-Build and market the package this way:
-
-- protocol-first for agents: `x402`, `MCP`, `A2A`, `A2C`
-- hosted checkout for humans and procurement-friendly money-in
-- native runtime/governance/proof as first-party strengths
-- provider-backed execution where outside tools or enterprise systems must actually perform work
-- treasury and settlement treated as operator truth, not marketing copy
-
-This fits the current industry direction:
-
-- MCP is becoming a standard tool/data access layer
-- A2A is emerging as a standard inter-agent collaboration layer
-- x402 and adjacent machine-payment patterns fit pay-per-call and machine-native commerce
-- hosted checkout remains important for human procurement and compliance-friendly SaaS sales
-
-## 8. Honest Launch Conclusion
-
-You do not need to reduce the vision.
-
-You do need to launch with execution truth.
-
-Today that means:
-
-- most of the package is already self-serve live from the runtime's point of view
-- `settlement.submit` needs real treasury and merchant configuration
-- `adapter.mcp.invoke` needs real provider targets
-- once those are filled, the package can honestly support the product posture you want

package/L402_BINDINGS.production.worksheet.json

@@ -1,30 +0,0 @@
-{
-  "_notes": [
-    "Fill this privately if you want to bind an L402-compatible payment front into xytara.",
-    "This worksheet is for operator planning and adapter binding, not for public distribution.",
-    "Use the final values to configure your L402 gateway/proxy and map it into xytara's execution and proof surfaces."
-  ],
-  "binding_id": "l402_primary",
-  "enabled": false,
-  "front_protocol": "l402",
-  "settlement_family": "bitcoin_lightning",
-  "auth_family": "macaroon",
-  "gateway_base_url": "",
-  "gateway_auth_token": "",
-  "gateway_verify_path": "/verify",
-  "gateway_invoice_create_path": "/invoice",
-  "gateway_access_issue_path": "/access",
-  "supported_task_refs": [
-    "trust.verify",
-    "adapter.mcp.invoke"
-  ],
-  "account_id": "",
-  "treasury_ref": "",
-  "reporting_ref": "",
-  "callback_signing_mode": "hmac_sha256",
-  "notes_for_runtime_mapping": [
-    "Bind L402 to xytara as a payment front, not as a separate execution system.",
-    "Use xytara execution/proof/governance after payment verification succeeds.",
-    "Map successful L402 payment/access issuance to either direct execution authorization or credits issuance."
-  ]
-}

package/OPERATIONS_RUNBOOK.md

@@ -1,115 +0,0 @@
-# xytara Operations Runbook
-
-Use this runbook for the normal post-program operating posture.
-
-## Daily checks
-
-Run:
-
-```bash
-xytara-release --center --summary
-xytara-release --candidate --summary
-```
-
-Inspect:
-
-- `/v1/release-center/summary`
-- `/v1/release-candidate/summary`
-- `/v1/capability-registry/execution-truth`
-- `/v1/capability-registry/execution-truth/summary`
-- `/v1/capability-registry/commercialization-summary`
-- `/v1/go-live`
-- `/v1/go-live/summary`
-- `/v1/runtime/durability`
-- `/v1/checkout/events/security`
-- `/v1/l402/security`
-- `/v1/bolt/security`
-- `/v1/stripe-mpp/security`
-- `/v1/network-transport`
-- `/v1/activity-ledger/summary`
-- `/v1/reconciliation-report`
-- `/v1/deliveries`
-- `/v1/settlement/bsv-teranode`
-
-For callback-backed deliveries, also inspect:
-
-- `/v1/deliveries`
-- callback delivery status, retry posture, and last error fields on delivery records
-
-For native settlement progression, also inspect:
-
-- settlement status and finality on `/v1/settlement/bsv-teranode`
-- readiness on `/v1/settlement/bsv-teranode/readiness`
-- whether records are progressing without manual submit/refresh intervention
-
-For launch-surface truth, also inspect:
-
-- which capabilities are `native_live`
-- which capabilities are `provider_live`
-- which capabilities are still `provider_wiring_required` or `operator_inputs_pending`
-- which capabilities are truly `self_serve_live_now` versus `operator_enabled_after_config`
-- which launch blockers are still preventing the first real money flow
-- what the current top-priority operator closeout action is
-
-## Runtime durability checks
-
-Healthy durability should show:
-
-- `enabled: true`
-- recoverable posture present
-- no active persistence blocker
-
-If you use hidden-account grants, credits, entitlements, or usage meters, durability is not optional.
-
-## Release confidence checks
-
-Run:
-
-```bash
-npm run verify:examples
-npm run verify:release-candidate
-npm run verify:production-readiness
-```
-
-`verify:production-readiness` now expects:
-
-- non-demo payment verification
-- real wallet registry entries
-- real operator bearer tokens
-- treasury destinations file with real landing references
-- callback signing secret
-- hosted checkout webhook secret
-- `L402` shared secret when the `L402` ingress is enabled
-- `BOLT` shared secret when the `BOLT` ingress is enabled
-- `MPP` shared secret when the `MPP` ingress is enabled
-- write-path rate limiting enabled
-- execution targets configured and validated whenever live capabilities require provider-backed execution
-- non-mock native settlement runtime mode
-
-## Partner-facing checks
-
-Keep these ready:
-
-- `PROGRAM_COMPLETE_RELEASE.md`
-- `PARTNER_READY_PATH.md`
-- `PUBLIC_DEMO_SCRIPT.md`
-- `CARRIED_HANDOFF_DEMO.md`
-
-## If durability looks wrong
-
-Check in this order:
-
-1. `/v1/runtime/durability`
-2. persistence configuration
-3. the most recent persisted timestamp
-4. whether the last real grant/write advanced persistence state
-
-## If an external adopter asks “where do I start?”
-
-Point them to:
-
-1. `START_HERE.md`
-2. `PARTNER_READY_PATH.md`
-3. `PUBLIC_DEMO_SCRIPT.md`
-
-Do not send a raw dump of all docs first.

package/OPERATOR_START_HERE.md

@@ -1,63 +0,0 @@
-# xytara Operator Start Here
-
-This is the shortest path for an operator who needs to evaluate `xytara` after the 10-phase program has already closed.
-
-## 1. Confirm Terminal Program State
-
-Run:
-
-```bash
-xytara-release --phases --summary
-xytara-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
-xytara-release --center --summary
-xytara-release --candidate --summary
-```
-
-These are the fastest checks for "is the package live, coherent, and publish-shaped?"
-
-## 3. Exercise The Runtime Path
-
-Run:
-
-```bash
-node examples/quickstart.js
-```
-
-This remains the fastest package-level execution story.
-
-## 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 partner/internal 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/OUTREACH_MESSAGES.md

@@ -1,19 +0,0 @@
-# xytara Outreach Messages
-
-Use these as the first sendable messages for the first external builder wave.
-
-## Public launch post
-
-`xytara is live. It is a machine-commerce spine for builders who need quote, pay, execute, inspect, and continue into proof without stitching together separate systems. Start with /v1/release-center/summary or run xytara-release --center --summary.`
-
-## Agent builder intro
-
-`If you need a real paid capability path for agents, xytara now gives you quote, pay, execute, inspect, and proof-aware followthrough on one public spine. Best first step: run xytara-run once, then inspect /v1/release-center/summary.`
-
-## Adapter partner intro
-
-`If you build tools or integrations, xytara now has a public third-party adapter starter, promotion path, and partner path. You can copy the minimal starter, validate it locally, inspect promotion workflow, and see what still blocks broader trust.`
-
-## Runtime team intro
-
-`If your runtime results currently stop at logs, xytara gives you a machine-commerce path that can continue into proof review cleanly. Best first check: /v1/outreach-proof/summary and xytara-release --outreach-proof --summary.`

package/OUTREACH_START_HERE.md

@@ -1,36 +0,0 @@
-# xytara Outreach Start Here
-
-Use this when you are ready to send the first small external builder wave.
-
-## First assets
-
-- `PARTNER_READY_PATH.md`
-- `/v1/release-center/summary`
-- `/v1/soft-launch/summary`
-- `/v1/adapter-partners/summary`
-- `/v1/outreach-proof/summary`
-- `/v1/outreach-copy/summary`
-- `/v1/outreach-targets/summary`
-
-## First commands
-
-- `xytara-release --center --summary`
-- `xytara-release --soft-launch --summary`
-- `xytara-release --adapter-partners --summary`
-- `xytara-release --outreach-copy --summary`
-- `xytara-release --outreach-targets --summary`
-
-## First rule
-
-Do not send the whole stack story to everyone.
-
-Pick one target group, one proof path, and one first artifact.
-
-The default neutral first artifact is `PARTNER_READY_PATH.md`.
-
-## First wave
-
-1. `agent_builders`
-2. `adapter_authors`
-3. `tool_and_marketplace_authors`
-4. `proof_aware_runtime_teams`