xytara 3.1.16 → 3.2.0

package/XYTARA_ADAPTER_PROTOCOL_TRUTH_MODEL.md

@@ -1,75 +0,0 @@
-# xytara Adapter And Protocol Truth Model
-
-For `3.0.0`, `xytara` must be both protocol-usable and adapter-extensible.
-
-But it also has to stay honest about what kind of front each surface actually is.
-
-## Core Rule
-
-There are three different truths:
-
-1. first-party default entry fronts
-2. built-in supported but nondefault protocol breadth
-3. partner or adapter-extension surfaces
-
-They must not be collapsed into one vague “supported everywhere” claim.
-
-## Launch Defaults
-
-The frozen protocol-entry posture is:
-
-- `mcp` is the primary default tool front
-- `a2a` is a first-party supported negotiation/settlement front
-- `a2c` is a first-party supported session/tooling front
-
-## Built-In Supported Breadth
-
-The current built-in supported bridge breadth includes:
-
-- `acp`
-- `grpc`
-- `mqtt`
-- `kafka`
-- `nats`
-- `ros2`
-- `webhook_event_bus`
-
-These may be supported and inspectable without being promoted into the main default path.
-
-## Partner And Adapter Extension Truth
-
-Third-party or staging fronts are part of the product surface, but they are not launch defaults.
-
-They can be:
-
-- discoverable
-- reviewable
-- staging-registered
-- promotion-ready
-
-They must not be described as first-party default protocol truth until their promotion state supports it.
-
-## Provider-Live Discipline
-
-Where a front depends on provider-bound execution depth, `xytara` must only claim the bindings listed in:
-
-- `GET /v1/adapter-depth`
-- `GET /v1/providers`
-- `GET /v1/providers/journeys`
-
-This is especially important for `mcp`-backed provider paths.
-
-## Machine-Readable Surfaces
-
-- `GET /v1/adapter-protocol-truth`
-- `GET /v1/adapter-protocol-truth/summary`
-- `GET /v1/adapter-protocol-truth/:profile_id`
-
-## Launch Standard
-
-For `3.0.0`, the public claim is truthful only if:
-
-- default fronts are callable and documented as defaults
-- supported nondefault bridge fronts are clearly marked as such
-- partner and staging fronts stay explicitly bounded
-- unlisted provider or tool depth is never implied

package/XYTARA_AUTONOMOUS_ENTRY_MODEL.md

@@ -1,124 +0,0 @@
-# XYTARA Autonomous Entry Model
-
-`xytara` needs one public surface that answers the shortest serious outside-agent question:
-
-1. how do I call this from where I already am?
-2. how do I pay in the best supported way for my situation?
-3. how do I know the runtime path, treasury claim boundary, and full catalog scope are real?
-
-This model freezes that answer for the pre-`3.0.0` strengthening pass.
-
-## Core Idea
-
-`xytara` already had the pieces:
-
-- `XT1` for runtime execution truth
-- default-path truth across CLI, browser, chat, API, and service-to-service entry
-- payment-front truth across `x402`, credits, hosted checkout, `l402`, and `bolt`
-- treasury-destination truth with explicit public-claim discipline
-- full catalog truth across families, lifecycle stages, and market classes
-
-The autonomous-entry model pulls those into one public contract so an outside caller does not have to reconstruct the product from scattered documents and routes.
-
-## What It Freezes
-
-The public machine-readable surfaces are:
-
-- `GET /v1/autonomous-entry`
-- `GET /v1/autonomous-entry/summary`
-- `GET /v1/autonomous-entry/:profile_id`
-
-Those surfaces freeze:
-
-- outside-agent entry profiles
-- ultra-minimal execution loops
-- supported payment breadth
-- treasury landing breadth in public-safe form
-- protocol breadth for real-time autonomous invocation
-- full catalog exposure counts and family visibility
-
-## Outside-Agent Entry
-
-The model treats these as first-class caller shapes:
-
-- CLI / terminal
-- chat window / assistant tool calling
-- browser / hosted checkout
-- direct API
-- service-to-service / evented systems
-
-Each profile points to:
-
-- preferred protocol fronts
-- preferred payment fronts
-- one-line starting path
-- runtime surface
-- proof handoff surface
-
-## Payment Breadth
-
-The model intentionally exposes the supported breadth we already have:
-
-- `x402` as the default machine-native front
-- account credits as the default repeat-use front
-- hosted checkout as the human/browser money-in front
-- `l402` as an optional permissionless front
-- `bolt` / UTXO-SPV as an optional alternative front
-
-It keeps one important rule intact:
-
-- callable payment fronts may be real before every treasury landing rail is publicly claimable
-
-## Treasury Landing Breadth
-
-The model makes treasury breadth visible without exposing private treasury details.
-
-Publicly safe information includes:
-
-- how many live public landing rails are actually claimable
-- which rails are only readiness templates
-- whether operator activation is still needed before stronger public live-landing claims are honest
-
-It does **not** expose:
-
-- real destination refs
-- custody refs
-- provider refs
-- private reserve wiring
-
-## Ultra-Minimal Loops
-
-The model freezes these minimal public loops:
-
-- quote-safe first contact
-- funded credits-first runtime execution
-- direct `x402` machine execution
-- optional permissionless execution fronts when enabled
-
-This is the practical answer to “what is the least work needed for a serious outside caller to begin?”
-
-## Full Catalog Exposure
-
-The model also keeps the long-built operation surface visible by linking back to:
-
-- full family counts
-- lifecycle-stage counts
-- market-class counts
-- operation-family visibility
-
-So this is not just a payments wrapper. It is a compressed entry surface for the actual machine-commerce engine.
-
-## Claim Boundary
-
-The autonomous-entry model is meant to strengthen real outside usability before `3.0.0`, not to create new overclaim.
-
-The hard rule remains:
-
-- only claim specific live treasury landing rails when those destinations are explicitly configured and allowed
-
-Everything else can be exposed as:
-
-- callable now
-- supported now
-- optional now
-- readiness-only until configured

package/XYTARA_DEFAULT_PATH_MODEL.md

@@ -1,84 +0,0 @@
-# xytara Default Path Model
-
-`xytara` is supposed to feel immediate from whatever surface the caller is already using.
-
-For `3.0.0`, that means the public runtime story cannot only exist as separate lane packs. It needs one frozen answer to:
-
-- how a caller discovers work
-- how they quote before irreversible spend
-- how they pay using the posture that fits their surface
-- how they execute without switching stacks
-- how the deliverable comes back where they already are
-- how the result remains proof-ready for `xoonya`
-
-## Core Rule
-
-All supported public entry surfaces must converge on one runtime spine:
-
-`discover -> quote -> fund -> execute -> deliver -> prove -> inspect`
-
-Surface-specific ergonomics are allowed.
-Surface-specific truth models are not.
-
-## Supported Surface Families
-
-The frozen `3.0.0` default-path model covers:
-
-- CLI and terminal
-- direct API
-- browser and hosted checkout
-- chat window and agent runtime
-- service-to-service and automation
-
-## What Changes Across Surfaces
-
-What may change:
-
-- the first entrypoint
-- the payment front
-- whether the caller receives output in stdout, JSON, callback form, or hosted workflow form
-
-What must not change:
-
-- quote-first safety
-- runtime execution truth
-- delivery truth
-- result-package and proof-handoff posture
-- operator inspection and reconciliation continuity
-
-## Runtime And Proof Split
-
-`xytara` owns:
-
-- quote and payment admission
-- execution
-- delivery
-- runtime lifecycle
-- settlement/reconciliation linkage
-- proof-ready handoff artifacts
-
-`xoonya` owns:
-
-- proof semantics
-- verification truth
-- review and governance followthrough
-
-So the default path must end with a stable `xytara -> xoonya` handoff, not a dead-end runtime response.
-
-## Public Machine-Readable Surfaces
-
-- `GET /v1/default-path`
-- `GET /v1/default-path/summary`
-- `GET /v1/default-path/:surface_id`
-
-## Launch Standard
-
-For `3.0.0`, this model is considered real only if:
-
-- each listed surface has a callable first path
-- each listed surface can produce or inspect a quote before irreversible spend
-- each listed surface can execute through the shared runtime engine
-- each listed surface can return or expose the deliverable without breaking the runtime truth model
-- each listed surface can continue into proof-ready followthrough
-
-That is the minimum bar for a truthful universal machine-engine claim.

package/XYTARA_EXECUTION_TRUTH_MODEL.md

@@ -1,171 +0,0 @@
-# xytara Execution Truth Model
-
-Status: active closeout contract
-
-Version: `xytara-execution-truth-model/v1`
-
-## Purpose
-
-This document freezes the runtime-side execution-truth model for `xytara`.
-
-It answers the closeout question:
-
-> What is the canonical hot-state fact model that `xytara` owns before proof followthrough moves into `xoonya`?
-
-The answer is:
-
-- `xytara` owns the runtime-side truth of quote, payment, execution, delivery, settlement linkage, treasury linkage, and proof handoff
-- `xoonya` owns proof semantics, proof verification semantics, and native proof truth
-
-## Core Doctrine
-
-`xytara` execution truth is not one isolated blob.
-
-It is a linked runtime-side object model:
-
-1. `quote`
-2. `transaction`
-3. `receipt`
-4. `delivery`
-5. `settlement`
-6. `proof_handoff`
-
-These objects together form the canonical `xytara` fact spine.
-
-## Object Roles
-
-### 1. Quote
-
-The quote is the priced pre-execution offer.
-
-It binds:
-
-- account
-- amount
-- currency
-- capability scope
-- adapter/settlement posture
-
-It must exist before irreversible paid execution.
-
-### 2. Transaction
-
-The transaction is the primary hot-state execution record.
-
-It carries:
-
-- payment state
-- settlement state
-- treasury state
-- execution state
-- timing
-- remediation state
-
-This is the main runtime object for "what happened."
-
-### 3. Receipt
-
-The receipt is the runtime completion record with a proof pointer.
-
-It carries:
-
-- execution summary
-- payment/settlement/treasury mirrors
-- timing
-- remediation
-- `proof_ref`
-
-It is not the proof core.
-
-It is the runtime-side completion artifact that points into proof followthrough.
-
-### 4. Delivery
-
-The delivery record captures:
-
-- where the result went
-- whether it was direct or callback-driven
-- callback retry/queue/failure state
-- output and proof refs
-
-This is part of runtime truth, not a proof-side side note.
-
-### 5. Settlement
-
-Settlement truth is linked to execution truth, but it is not identical to execution success.
-
-`xytara` must preserve:
-
-- settlement reference
-- mode
-- adapter
-- binding hash
-- finality posture where available
-
-without collapsing execution success into chain finality or treasury consequence.
-
-### 6. Proof Handoff
-
-`xytara` emits proof-compatible facts and references.
-
-That handoff includes:
-
-- `receipt.proof_ref`
-- `receipt.execution_summary`
-- `transaction.execution.results_by_task_id`
-- `delivery.proof_ref`
-
-`xoonya` then owns proof review, verification, continuity, and governance followthrough.
-
-## Layer Sequence
-
-The frozen runtime sequence is:
-
-1. quote
-2. pay or authorize
-3. execute
-4. deliver
-5. settle and reconcile
-6. hand off into proof followthrough
-
-This sequence may run synchronously or asynchronously, but the truth model does not change.
-
-## Non-Negotiable Invariants
-
-The following invariants define the closeout standard:
-
-1. Quote precedes irreversible paid execution.
-2. Transaction is the canonical hot-state execution record.
-3. Receipt is the runtime completion record, not the proof core.
-4. Delivery truth remains first-class and inspectable.
-5. Settlement truth remains linked but distinct from execution success.
-6. Treasury consequence remains reconstructible from runtime artifacts.
-7. `xytara` emits proof-compatible facts without redefining `xoonya` proof semantics.
-
-## Public Surfaces
-
-The machine-readable execution-truth surface is:
-
-- `GET /v1/execution-truth`
-- `GET /v1/execution-truth/summary`
-
-Supporting public surfaces include:
-
-- `GET /v1/capability-registry/execution-truth`
-- `GET /v1/lifecycle-continuity`
-- `GET /v1/deliveries`
-- `GET /v1/revenue-launch/paths`
-- `GET /v1/providers/journeys`
-- `POST /v1/transaction-center/result-packages/export`
-
-Proof followthrough boundary:
-
-- `https://xoonya.onrender.com/v1/proof-center/result-package-handoff/run`
-
-## Closeout Meaning
-
-For `3.0.0`, this model means:
-
-- the execution side is no longer only implied by multiple adjacent artifacts
-- the runtime-side fact model is explicit and frozen
-- outside builders and operators can understand where execution truth ends and proof truth begins

package/XYTARA_PAYMENT_RAIL_TRUTH_MODEL.md

@@ -1,68 +0,0 @@
-# xytara Payment And Rail Truth Model
-
-For `3.0.0`, `xytara` needs a payment story that is both broad and honest.
-
-That means one public rule:
-
-- payment fronts can be callable and live
-- settlement families can be runtime-ready
-- but a specific treasury landing rail is only a public live claim when it is explicitly configured and allowed
-
-## Core Distinction
-
-There are two different truths:
-
-1. payment and execution truth
-2. treasury landing claim truth
-
-The first answers:
-
-- can the caller quote?
-- can they pay through a supported front?
-- can the work execute right away?
-- can the result continue into proof followthrough?
-
-The second answers:
-
-- which exact rail can we publicly say is already a live landing destination?
-
-Those are related, but they are not the same.
-
-## Launch Defaults
-
-The frozen `3.0.0` default posture is:
-
-- machine-native default front: `x402`
-- repeat-use default front: `account_credits`
-- human/browser default front: hosted checkout
-- optional permissionless fronts: `l402`, `bolt`
-- native settlement center: `bsv_teranode`
-
-## Claim Discipline
-
-`xytara` may publicly claim:
-
-- callable payment fronts
-- funded runtime execution
-- proof-ready followthrough
-- supported settlement families
-
-`xytara` must not publicly claim:
-
-- a specific rail as live treasury landing truth unless `public_claim_allowed` is true for that rail
-- operator-only custody or landing refs on public surfaces
-- adapter-ready fronts as first-party launch defaults
-
-## Machine-Readable Surfaces
-
-- `GET /v1/payment-rail-truth`
-- `GET /v1/payment-rail-truth/summary`
-- `GET /v1/payment-rail-truth/:profile_id`
-
-## Why This Matters
-
-This keeps the `3.0.0` claim clean:
-
-- we can truthfully say users can pay through multiple comfortable fronts
-- we can truthfully say execution and proof followthrough are real
-- we do not overclaim live treasury landing breadth where real operator configuration is still the deciding factor