xytara 3.1.0 → 3.1.2

package/XYTARA_AUTONOMOUS_ENTRY_MODEL.md

@@ -1,124 +1,124 @@
-# 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
+# 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 +1,84 @@
-# 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.
+# 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.