xytara 3.1.0 → 3.1.2

package/START_HERE.md

@@ -4,7 +4,7 @@ This is the shortest reliable path for understanding and using the public `xytar
 
 The phase program is now complete, so this file is the right starting point for a closed and release-shaped runtime rather than an in-flight milestone build.
 
-The product-side implementation and treasury activation work for the widened `3.0.0` finish line are now complete. The remaining step is the synchronized public `3.0.0` release cut, publish, deploy, and verification sequence documented in [NAXYTRA_3_0_0_RELEASE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/release/NAXYTRA_3_0_0_RELEASE_CONTRACT.md) and [PUBLISH_PLAN.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/PUBLISH_PLAN.md).
+The synchronized `3.0.0` launch line shipped and is live. The current public line is the synchronized security and stability release described in [RELEASE_NOTES.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/RELEASE_NOTES.md); operator write surfaces fail closed and payment acceptance defaults to signed verification, so configure the operator tokens and a wallet registry before expecting paid or operator flows to work.
 
 ## 1. Understand The Role
 

package/SUPABASE_RUNTIME_STATE_SETUP.md

@@ -1,61 +1,61 @@
-# xytara Supabase Runtime State Setup
-
-Use this when `xytara` runs on infrastructure without persistent disk, such as a free Render service.
-
-## What This Solves
-
-This keeps runtime economics state durable across restart:
-
-- external credit grants
-- entitlements
-- credit spends
-- usage meters
-- hidden-account economics carry
-
-## 1. Create The Table In Supabase
-
-Run this SQL:
-
-```sql
-create table if not exists public.xytara_runtime_state (
-  state_key text primary key,
-  snapshot jsonb not null,
-  persisted_at_iso timestamptz not null default now()
-);
-```
-
-## 2. Configure xytara
-
-Set these environment variables on the deployed service:
-
-```text
-XYTARA_SUPABASE_URL=https://<project-ref>.supabase.co
-XYTARA_SUPABASE_SERVICE_ROLE_KEY=<service-role-key>
-XYTARA_SUPABASE_STATE_TABLE=xytara_runtime_state
-XYTARA_SUPABASE_STATE_KEY=default
-XYTARA_STATE_SNAPSHOT_INTERVAL_MS=5000
-```
-
-If `XYTARA_SUPABASE_URL` and `XYTARA_SUPABASE_SERVICE_ROLE_KEY` are set, `xytara` will use Supabase-backed runtime persistence instead of local file snapshots.
-
-## 3. Verify Runtime Durability
-
-Inspect:
-
-- `GET /v1/runtime/durability`
-
-Expected direction:
-
-- `storage_mode: "supabase"`
-- `remote_reachable: true`
-- `remote_table_ready: true`
-- `snapshot_exists: true` after the first persisted mutation
-
-## 4. Verify The Real Economics Path
-
-1. issue a hidden-account grant
-2. confirm balance and entitlements exist
-3. restart or redeploy `xytara`
-4. confirm the same hidden account still has balance and entitlements
-5. spend once
-6. confirm usage meter and spend history survive another restart
+# xytara Supabase Runtime State Setup
+
+Use this when `xytara` runs on infrastructure without persistent disk, such as a free Render service.
+
+## What This Solves
+
+This keeps runtime economics state durable across restart:
+
+- external credit grants
+- entitlements
+- credit spends
+- usage meters
+- hidden-account economics carry
+
+## 1. Create The Table In Supabase
+
+Run this SQL:
+
+```sql
+create table if not exists public.xytara_runtime_state (
+  state_key text primary key,
+  snapshot jsonb not null,
+  persisted_at_iso timestamptz not null default now()
+);
+```
+
+## 2. Configure xytara
+
+Set these environment variables on the deployed service:
+
+```text
+XYTARA_SUPABASE_URL=https://<project-ref>.supabase.co
+XYTARA_SUPABASE_SERVICE_ROLE_KEY=<service-role-key>
+XYTARA_SUPABASE_STATE_TABLE=xytara_runtime_state
+XYTARA_SUPABASE_STATE_KEY=default
+XYTARA_STATE_SNAPSHOT_INTERVAL_MS=5000
+```
+
+If `XYTARA_SUPABASE_URL` and `XYTARA_SUPABASE_SERVICE_ROLE_KEY` are set, `xytara` will use Supabase-backed runtime persistence instead of local file snapshots.
+
+## 3. Verify Runtime Durability
+
+Inspect:
+
+- `GET /v1/runtime/durability`
+
+Expected direction:
+
+- `storage_mode: "supabase"`
+- `remote_reachable: true`
+- `remote_table_ready: true`
+- `snapshot_exists: true` after the first persisted mutation
+
+## 4. Verify The Real Economics Path
+
+1. issue a hidden-account grant
+2. confirm balance and entitlements exist
+3. restart or redeploy `xytara`
+4. confirm the same hidden account still has balance and entitlements
+5. spend once
+6. confirm usage meter and spend history survive another restart

package/TERMINOLOGY.md

@@ -1,50 +1,50 @@
-# xytara Terminology
-
-This file freezes the public terminology used by `xytara`.
-
-The goal is:
-
-- one public name for the repo
-- one stable commerce vocabulary
-- no private-lineage naming leakage
-
-## Public Name
-
-- repo name: `xytara`
-- package name: `xytara`
-- service name: `xytara`
-
-Use `xytara` only for this repo and its public commerce identity.
-
-## Preferred Commerce Terms
-
-Use these terms consistently:
-
-- `catalog`
-- `task`
-- `workflow`
-- `task set`
-- `quote`
-- `payment`
-- `execute`
-- `deliver`
-- `inspect`
-- `operator`
-- `adapter`
-- `settlement profile`
-- `lifecycle`
-
-## Cross-Repo Reference Rule
-
-If this repo needs to mention the other repo, use generic wording:
-
-- `the proof repo`
-- `the proof layer`
-
-Do not brand the other repo inside this repo's core public copy.
-
-## Naming Rule
-
-This repo should read like a self-contained public commerce product with an explicit proof boundary.
-
-If wording does not strengthen that outcome, keep it generic.
+# xytara Terminology
+
+This file freezes the public terminology used by `xytara`.
+
+The goal is:
+
+- one public name for the repo
+- one stable commerce vocabulary
+- no private-lineage naming leakage
+
+## Public Name
+
+- repo name: `xytara`
+- package name: `xytara`
+- service name: `xytara`
+
+Use `xytara` only for this repo and its public commerce identity.
+
+## Preferred Commerce Terms
+
+Use these terms consistently:
+
+- `catalog`
+- `task`
+- `workflow`
+- `task set`
+- `quote`
+- `payment`
+- `execute`
+- `deliver`
+- `inspect`
+- `operator`
+- `adapter`
+- `settlement profile`
+- `lifecycle`
+
+## Cross-Repo Reference Rule
+
+If this repo needs to mention the other repo, use generic wording:
+
+- `the proof repo`
+- `the proof layer`
+
+Do not brand the other repo inside this repo's core public copy.
+
+## Naming Rule
+
+This repo should read like a self-contained public commerce product with an explicit proof boundary.
+
+If wording does not strengthen that outcome, keep it generic.

package/WHY_XYTARA_XOONYA.md

@@ -1,63 +1,63 @@
-# Why xytara And xoonya
-
-The public stack is intentionally split into two repos because runtime commerce and canonical proof have different operating constraints.
-
-## xytara
-
-`xytara` owns the transaction-side path:
-
-- discover
-- preview or quote
-- fund or spend
-- execute
-- inspect
-- export carry
-
-It is the right place for:
-
-- payment posture
-- credits and entitlements
-- settlement visibility
-- adapter registration and promotion
-- operator-facing runtime state
-
-## xoonya
-
-`xoonya` owns the proof-side path:
-
-- receive handoff
-- review preserved context
-- emit proof-native completion
-- verify the final bundle
-
-It is the right place for:
-
-- canonical event shape
-- receipts
-- proof bundles
-- narrow proof-adjacent integrations
-- reviewable proof followthrough
-
-## Why the split matters
-
-If commerce and proof are collapsed together, one side usually becomes muddy:
-
-- the runtime becomes too rigid
-- or the proof layer absorbs workflow and settlement semantics it should not own
-
-This split keeps both sides legible:
-
-- `xytara` stays execution and economics aware
-- `xoonya` stays canonical and proof aware
-
-## What builders get
-
-Builders do not need to choose between “commerce first” and “proof first.”
-
-They can:
-
-1. run the machine path in `xytara`
-2. export or carry the result
-3. complete the proof path in `xoonya`
-
-That is the public stack story.
+# Why xytara And xoonya
+
+The public stack is intentionally split into two repos because runtime commerce and canonical proof have different operating constraints.
+
+## xytara
+
+`xytara` owns the transaction-side path:
+
+- discover
+- preview or quote
+- fund or spend
+- execute
+- inspect
+- export carry
+
+It is the right place for:
+
+- payment posture
+- credits and entitlements
+- settlement visibility
+- adapter registration and promotion
+- operator-facing runtime state
+
+## xoonya
+
+`xoonya` owns the proof-side path:
+
+- receive handoff
+- review preserved context
+- emit proof-native completion
+- verify the final bundle
+
+It is the right place for:
+
+- canonical event shape
+- receipts
+- proof bundles
+- narrow proof-adjacent integrations
+- reviewable proof followthrough
+
+## Why the split matters
+
+If commerce and proof are collapsed together, one side usually becomes muddy:
+
+- the runtime becomes too rigid
+- or the proof layer absorbs workflow and settlement semantics it should not own
+
+This split keeps both sides legible:
+
+- `xytara` stays execution and economics aware
+- `xoonya` stays canonical and proof aware
+
+## What builders get
+
+Builders do not need to choose between “commerce first” and “proof first.”
+
+They can:
+
+1. run the machine path in `xytara`
+2. export or carry the result
+3. complete the proof path in `xoonya`
+
+That is the public stack story.

package/XT1_EXECUTION_TRUTH_STANDARD.md

@@ -1,78 +1,78 @@
-# XT1 Execution Truth Standard
-
-Status: active runtime standard
-
-Version: `xt1/v1`
-
-## Purpose
-
-`XT1` is the coined public name for the canonical `xytara` runtime-side execution-truth standard.
-
-It is the `xytara` counterpart to `xoonya`'s `XNYA` native proof primitive.
-
-Where `XNYA` names the compact proof-side commitment family, `XT1` names the hot-state runtime fact spine that exists before proof review and followthrough move into `xoonya`.
-
-## What XT1 Covers
-
-`XT1` freezes the canonical `xytara` object sequence:
-
-1. `quote`
-2. `transaction`
-3. `receipt`
-4. `delivery`
-5. `settlement`
-6. `proof_handoff`
-
-Together these objects form the canonical runtime transcript and fact layer for:
-
-- priced intent
-- payment and authorization
-- execution
-- delivery
-- settlement linkage
-- treasury linkage
-- proof handoff
-
-## Doctrine
-
-`XT1` means:
-
-- `xytara` owns runtime-side execution truth
-- `xytara` emits proof-compatible facts
-- `xytara` does not redefine `xoonya` proof validity
-- execution success, settlement finality, and proof validity remain distinct
-
-## Relationship To Existing Surfaces
-
-`XT1` is not a second competing model.
-
-It is the coined public standard name for the already-frozen `xytara` execution-truth model documented in:
-
-- [XYTARA_EXECUTION_TRUTH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/XYTARA_EXECUTION_TRUTH_MODEL.md)
-
-Machine-readable surfaces:
-
-- `GET /v1/xt1`
-- `GET /v1/xt1/summary`
-- `GET /v1/execution-truth`
-- `GET /v1/execution-truth/summary`
-
-The `xt1` routes are the named standard alias.
-
-The `execution-truth` routes remain the descriptive runtime alias.
-
-## Invariants
-
-`XT1` preserves these invariants:
-
-- quote precedes irreversible paid execution
-- transaction is the canonical hot-state execution record
-- receipt is the runtime completion record, not the proof core
-- delivery truth remains first-class and inspectable
-- settlement truth remains linked but distinct from execution success
-- treasury consequence remains reconstructible from runtime artifacts
-- proof handoff remains explicit at the `xytara -> xoonya` boundary
-
-## Public Meaning
-
-For `3.0.0`, `XT1` means the runtime side now has a public, coined, stable standard name rather than only a descriptive contract.
+# XT1 Execution Truth Standard
+
+Status: active runtime standard
+
+Version: `xt1/v1`
+
+## Purpose
+
+`XT1` is the coined public name for the canonical `xytara` runtime-side execution-truth standard.
+
+It is the `xytara` counterpart to `xoonya`'s `XNYA` native proof primitive.
+
+Where `XNYA` names the compact proof-side commitment family, `XT1` names the hot-state runtime fact spine that exists before proof review and followthrough move into `xoonya`.
+
+## What XT1 Covers
+
+`XT1` freezes the canonical `xytara` object sequence:
+
+1. `quote`
+2. `transaction`
+3. `receipt`
+4. `delivery`
+5. `settlement`
+6. `proof_handoff`
+
+Together these objects form the canonical runtime transcript and fact layer for:
+
+- priced intent
+- payment and authorization
+- execution
+- delivery
+- settlement linkage
+- treasury linkage
+- proof handoff
+
+## Doctrine
+
+`XT1` means:
+
+- `xytara` owns runtime-side execution truth
+- `xytara` emits proof-compatible facts
+- `xytara` does not redefine `xoonya` proof validity
+- execution success, settlement finality, and proof validity remain distinct
+
+## Relationship To Existing Surfaces
+
+`XT1` is not a second competing model.
+
+It is the coined public standard name for the already-frozen `xytara` execution-truth model documented in:
+
+- [XYTARA_EXECUTION_TRUTH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/XYTARA_EXECUTION_TRUTH_MODEL.md)
+
+Machine-readable surfaces:
+
+- `GET /v1/xt1`
+- `GET /v1/xt1/summary`
+- `GET /v1/execution-truth`
+- `GET /v1/execution-truth/summary`
+
+The `xt1` routes are the named standard alias.
+
+The `execution-truth` routes remain the descriptive runtime alias.
+
+## Invariants
+
+`XT1` preserves these invariants:
+
+- quote precedes irreversible paid execution
+- transaction is the canonical hot-state execution record
+- receipt is the runtime completion record, not the proof core
+- delivery truth remains first-class and inspectable
+- settlement truth remains linked but distinct from execution success
+- treasury consequence remains reconstructible from runtime artifacts
+- proof handoff remains explicit at the `xytara -> xoonya` boundary
+
+## Public Meaning
+
+For `3.0.0`, `XT1` means the runtime side now has a public, coined, stable standard name rather than only a descriptive contract.

package/XYTARA_ADAPTER_PROTOCOL_TRUTH_MODEL.md

@@ -1,75 +1,75 @@
-# 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
+# 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