settld 0.1.5 → 0.2.0

package/docs/ops/DISPUTE_FINANCE_RECONCILIATION_PACKET.md

@@ -0,0 +1,56 @@
+# Dispute Finance Reconciliation Packet
+
+This runbook generates a deterministic packet for dispute-driven settlement adjustments.
+
+## Purpose
+
+- Produce a finance-reviewable packet for one `SettlementAdjustment.v1`.
+- Include adjustment artifact + before/after wallet snapshots for payer/payee.
+- Attach deterministic checksums and optional Ed25519 signature.
+
+## Command
+
+```bash
+node scripts/ops/dispute-finance-reconciliation-packet.mjs \
+  --base-url http://127.0.0.1:3000 \
+  --tenant-id tenant_default \
+  --ops-token tok_finw \
+  --adjustment-id sadj_agmt_<agreementHash>_holdback \
+  --payer-agent-id <payerAgentId> \
+  --payee-agent-id <payeeAgentId> \
+  --out artifacts/finance/dispute-adjustment-packet.json
+```
+
+Optional signing:
+
+```bash
+node scripts/ops/dispute-finance-reconciliation-packet.mjs \
+  --base-url http://127.0.0.1:3000 \
+  --tenant-id tenant_default \
+  --ops-token tok_finw \
+  --adjustment-id sadj_agmt_<agreementHash>_holdback \
+  --payer-agent-id <payerAgentId> \
+  --payee-agent-id <payeeAgentId> \
+  --signing-key-file ./keys/finance-ops-ed25519.pem \
+  --signature-key-id finance_ops_k1 \
+  --out artifacts/finance/dispute-adjustment-packet.signed.json
+```
+
+## Packet contract
+
+- `schemaVersion`: `DisputeFinanceReconciliationPacket.v1`
+- `adjustment`: `SettlementAdjustment.v1` payload from `/ops/settlement-adjustments/{adjustmentId}`
+- `balances.payer/payee.before|after`: wallet snapshots for reconciliation
+- `checksums.packetHash`: canonical packet checksum (`sha256`)
+- `checksums.adjustmentHash`: checksum carried by adjustment artifact
+- `signature` (optional): Ed25519 signature over `checksums.packetHash`
+
+## Finance review workflow
+
+1. Generate the packet immediately after dispute verdict/adjustment application.
+2. Verify `checksums.adjustmentHash` matches the adjustment artifact.
+3. Verify `checksums.packetHash` and (if present) `signature`.
+4. Reconcile `before -> after` snapshots against expected adjustment kind:
+   - `holdback_release`: payer escrow decreases; payee available increases.
+   - `holdback_refund`: payer escrow decreases; payer available increases.
+5. Attach packet to incident/dispute record for immutable finance traceability.

package/docs/ops/KERNEL_V0_SHIP_GATE.md

@@ -21,7 +21,9 @@ Report output:
 ## CI enforcement
 
 1. `.github/workflows/tests.yml` runs `kernel_v0_ship_gate` on every `push` to `main`.
-2. `.github/workflows/release.yml` blocks release unless that same commit has a successful `kernel_v0_ship_gate` result from `tests.yml`.
+2. `.github/workflows/tests.yml` also runs `production_cutover_gate` on every `push` to `main`.
+3. `.github/workflows/release.yml` blocks release unless that same commit has successful `kernel_v0_ship_gate` and `production_cutover_gate` results from `tests.yml`.
+4. `.github/workflows/production-cutover-gate.yml` provides manual live-environment validation using `production_cutover_gate` GitHub Environment secrets.
 
 ## Included checks
 

package/docs/ops/MCP_COMPATIBILITY_MATRIX.md

@@ -20,9 +20,11 @@ Track real host compatibility evidence here. Update on every major host release
 
 | Host | Host Version | Transport | Status | Last Verified (UTC) | Evidence Link | Notes |
 |---|---|---|---|---|---|---|
-| Claude | TBD | stdio | TBD | TBD | TBD | |
-| Cursor | TBD | stdio | TBD | TBD | TBD | |
-| Codex | TBD | stdio | TBD | TBD | TBD | |
-| OpenClaw | TBD | stdio | TBD | TBD | TBD | |
-| Generic MCP host bootstrap path | local CI smoke | stdio | green | 2026-02-20 | `npm run test:ci:mcp-host-smoke` | Boots API + magic-link, generates runtime MCP env, runs `mcp:probe`, and calls `settld.about`; report at `artifacts/ops/mcp-host-smoke.json`. |
-| Generic MCP HTTP client | local repo test harness | HTTP bridge | green | 2026-02-20 | `node --test test/mcp-stdio-spike.test.js test/mcp-http-gateway.test.js test/mcp-paid-exa-tool.test.js test/mcp-paid-weather-tool.test.js test/mcp-paid-llm-tool.test.js test/demo-mcp-paid-exa.test.js` | 9/9 passing in local CI-style run |
+| Claude | local host-cert matrix harness | stdio | yellow | 2026-02-21 | `npm run test:ci:mcp-host-cert-matrix` | Validates host config write/idempotency for Claude MCP wiring; live interactive paid-tool validation in Claude desktop remains separate. |
+| Cursor | local host-cert matrix harness | stdio | yellow | 2026-02-21 | `npm run test:ci:mcp-host-cert-matrix` | Validates host config write/idempotency for Cursor MCP wiring; live interactive paid-tool validation in Cursor app remains separate. |
+| Codex | local host-cert matrix harness | stdio | yellow | 2026-02-21 | `npm run test:ci:mcp-host-cert-matrix` | Validates host config write/idempotency for Codex MCP wiring; live interactive paid-tool validation in Codex desktop remains separate. |
+| OpenClaw | local host-cert matrix harness | stdio | yellow | 2026-02-21 | `npm run test:ci:mcp-host-cert-matrix` | Validates host config write/idempotency for OpenClaw MCP wiring; live interactive paid-tool validation in OpenClaw app remains separate. |
+| Generic MCP host bootstrap path | local CI smoke | stdio | green | 2026-02-21 | `npm run test:ci:mcp-host-smoke` | Runs the MCP host smoke flow (API + magic-link + runtime bootstrap + MCP initialize/tools/list + `settld.about`) and writes `artifacts/ops/mcp-host-smoke.json`. |
+| Host config write matrix (Codex/Claude/Cursor/OpenClaw) | local CI smoke | config bootstrap | green | 2026-02-21 | `npm run test:ci:mcp-host-cert-matrix` | Verifies `scripts/setup/host-config.mjs` writes valid Settld MCP entries and remains idempotent across all supported hosts. |
+| Generic MCP HTTP client | local repo test harness | HTTP bridge | green | 2026-02-21 | `node --test test/mcp-stdio-spike.test.js test/mcp-paid-exa-tool.test.js test/mcp-paid-weather-tool.test.js test/mcp-paid-llm-tool.test.js test/x402-gateway-autopay.test.js` | 6/6 passing with paid-tool runtime metadata checks and x402 settlement header verification. |
+| MCP paid runtime policy metadata gate | local repo test harness | stdio + x402 gateway | green | 2026-02-21 | `node --test test/mcp-paid-exa-tool.test.js test/mcp-paid-weather-tool.test.js test/mcp-paid-llm-tool.test.js test/x402-gateway-autopay.test.js` | Paid MCP tools now fail-closed if `x-settld-policy-decision`, `x-settld-policy-hash`, `x-settld-decision-id`, settlement, or verification headers are missing. |

package/docs/ops/PRODUCTION_DEPLOYMENT_CHECKLIST.md

@@ -4,10 +4,23 @@ Use this checklist to launch and verify a real hosted Settld environment.
 
 ## Phase 0: Preflight
 
-1. Confirm branch protection includes `tests / kernel_v0_ship_gate`.
-2. Confirm release workflow is blocked unless ship gate is green.
-3. Confirm staging and production have separate domains, databases, secrets, and signer keys.
-4. Confirm required services are deployable: `npm run start:prod`, `npm run start:maintenance`, `npm run start:x402-gateway`.
+1. Confirm branch protection includes:
+   - `tests / kernel_v0_ship_gate`
+   - `tests / production_cutover_gate`
+   - `tests / offline_verification_parity_gate` (NOO-50)
+   - `tests / onboarding_policy_slo_gate`
+   - `tests / onboarding_host_success_gate`
+   - `tests / deploy_safety_smoke` (hosted baseline evidence path)
+2. Confirm release workflow is blocked unless NOO-50 and the kernel/cutover gates are green for the release commit.
+3. Confirm release workflow runs NOO-65 promotion guard and blocks publish lanes if `release-promotion-guard.json` verdict is not pass/override-pass.
+4. Confirm staging and production have separate domains, databases, secrets, and signer keys.
+5. Confirm required services are deployable: `npm run start:prod`, `npm run start:maintenance`, `npm run start:x402-gateway`.
+6. Configure GitHub Environment `production_cutover_gate` with:
+   - `PROD_BASE_URL`
+   - `PROD_TENANT_ID`
+   - `PROD_OPS_TOKEN`
+   - optional `PROD_PROTOCOL` (`1.0`)
+7. Require manual reviewers on `production_cutover_gate` before workflow secret access.
 
 ## Phase 1: Environment + secrets
 
@@ -74,6 +87,19 @@ This emits a machine-readable report at:
 
 4. Update `docs/ops/MCP_COMPATIBILITY_MATRIX.md` with pass/fail + date.
 
+5. Run clean-env onboarding host success gate:
+
+```bash
+npm run test:ops:onboarding-host-success-gate -- \
+  --base-url https://api.settld.work \
+  --tenant-id tenant_default \
+  --api-key "$SETTLD_API_KEY" \
+  --attempts 3 \
+  --min-success-rate-pct 90 \
+  --report artifacts/gates/onboarding-host-success-gate.json \
+  --metrics-dir artifacts/ops/onboarding-host-success
+```
+
 ## Phase 5: Paid call + receipt proof
 
 1. Run a paid demo flow:
@@ -90,11 +116,22 @@ npm run demo:mcp-paid-exa
 
 Ship only when all are true:
 
-1. Kernel v0 ship gate is green.
-2. Hosted baseline evidence is green.
-3. MCP compatibility matrix is green for supported hosts.
-4. Paid MCP run artifacts verify cleanly.
-5. Rollback runbook has been rehearsed.
+1. Kernel v0 ship gate, production cutover gate, and NOO-50 parity gate are green.
+2. Onboarding/policy SLO gate is green (`artifacts/gates/onboarding-policy-slo-gate.json`).
+3. Onboarding host success gate is green (`artifacts/gates/onboarding-host-success-gate.json`).
+4. Hosted baseline evidence is green.
+5. Go-live gate and launch cutover packet reports are present:
+   - `artifacts/gates/s13-go-live-gate.json`
+   - `artifacts/gates/s13-launch-cutover-packet.json`
+   - generated from a successful `go-live-gate` workflow run for the release commit
+6. NOO-65 promotion guard passes with required artifact binding (`artifacts/gates/release-promotion-guard.json`).
+7. MCP compatibility matrix is green for supported hosts.
+8. Paid MCP run artifacts verify cleanly.
+9. Rollback runbook has been rehearsed.
+
+Run the live environment cutover gate before opening traffic:
+
+`Actions -> production-cutover-gate -> Run workflow`
 
 ## Phase 7: Post-release
 

package/docs/ops/TRUST_CONFIG_WIZARD.md

@@ -1,33 +1,41 @@
 # Trust Config Wizard
 
-The Trust Config Wizard is a lightweight way to bootstrap SLA policy configuration for common autonomous workflows.
+Use this when you want to create an SLA policy config from a template.
 
-## What it provides
+## Fastest path for onboarding
 
-- Built-in SLA policy templates for `delivery` and `security` verticals.
-- Template rendering with override support for SLA and metrics fields.
-- A validation path for preflight checks before policy deployment.
+If you want a ready starter policy during host setup, run:
 
-## API endpoint
+```bash
+settld setup --yes --mode manual --host codex --base-url http://127.0.0.1:3000 --tenant-id tenant_default --api-key sk_live_xxx.yyy --profile-id engineering-spend --smoke
+```
 
-- `GET /ops/sla-templates`
-  - Scope: `ops_read`
-  - Optional query: `vertical=delivery|security`
-  - Response: `SlaPolicyTemplateCatalog.v1` template catalog
+This sets up host MCP config and applies a starter policy profile in one run.
 
-Example:
+## New policy wizard flow (template-based)
 
-```sh
-curl -sS "http://localhost:3000/ops/sla-templates?vertical=security" \
-  -H "x-proxy-ops-token: <ops_read_token>" | jq
+1. List templates:
+
+```bash
+npm run trust:wizard -- list --format text
 ```
 
-## CLI usage
+2. Preview one template:
 
-Run via npm script:
+```bash
+npm run trust:wizard -- show --template delivery_standard_v1 --format text
+```
+
+3. Render a policy config file:
 
-```sh
-npm run trust:wizard -- list --format json
+```bash
+npm run trust:wizard -- render --template delivery_standard_v1 --overrides-json '{"metrics":{"targetCompletionMinutes":60}}' --out ./policy.delivery.json --format json
+```
+
+4. Validate the same overrides:
+
+```bash
+npm run trust:wizard -- validate --template delivery_standard_v1 --overrides-json '{"metrics":{"targetCompletionMinutes":60}}' --format json
 ```
 
 Supported commands:
@@ -37,11 +45,16 @@ Supported commands:
 - `render --template <templateId> [--overrides-json <json>] [--out <path>] [--format json|text]`
 - `validate --template <templateId> [--overrides-json <json>] [--format json|text]`
 
-Example render command:
+## API endpoint
 
-```sh
-npm run trust:wizard -- render \
-  --template delivery_standard_v1 \
-  --overrides-json '{"metrics":{"targetCompletionMinutes":60}}' \
-  --format json
+- `GET /ops/sla-templates`
+  - Scope: `ops_read`
+  - Optional query: `vertical=delivery|security`
+  - Response: `SlaPolicyTemplateCatalog.v1`
+
+Example:
+
+```bash
+curl -sS "http://localhost:3000/ops/sla-templates?vertical=security" \
+  -H "x-proxy-ops-token: <ops_read_token>" | jq
 ```

package/docs/plans/2026-02-20-trust-os-v1-jira-backlog.md

@@ -0,0 +1,348 @@
+# Trust OS v1 (Jira-Ready Backlog)
+
+Date: 2026-02-20
+Owner: CEO / Product / Platform
+Release Name: `Trust OS v1`
+Release Objective: Ship a production-grade, rail-agnostic inter-agent trust kernel with deterministic policy enforcement, dispute/reversal handling, auditable receipts, and operator controls.
+
+## Scope Boundaries (v1)
+
+In scope:
+- Runtime decisions: `allow`, `challenge`, `deny`, `escalate`.
+- Request binding, policy hash pinning, deterministic evidence/receipt export.
+- Dispute lifecycle + arbitration verdict + automatic settlement/reversal outcome.
+- Operator inbox (approval/escalation controls).
+- One hardened rail adapter path.
+- Three starter vertical profiles.
+
+Out of scope:
+- Policy marketplace and monetization.
+- Full open discovery network.
+- Building a new wallet rail.
+
+## Program Milestones
+
+- Milestone M1 (Sprint 1): Enforcement core + request binding + receipt schema freeze.
+- Milestone M2 (Sprint 2): Dispute/reversal runtime + operator inbox MVP.
+- Milestone M3 (Sprint 3): Rail adapter hardening + profile system + release gate.
+
+## Epics
+
+- `STLD-E2401` Policy Runtime Enforcement
+- `STLD-E2402` Execution Binding + Evidence + Receipts
+- `STLD-E2403` Dispute Court + Reversal Engine
+- `STLD-E2404` Operator Inbox + Controls
+- `STLD-E2405` Rail Adapter Hardening
+- `STLD-E2406` Vertical Policy Profiles
+- `STLD-E2407` QA, Conformance, and Release Gates
+
+## Jira Ticket Backlog
+
+### Epic `STLD-E2401` Policy Runtime Enforcement
+
+#### `STLD-T2401`
+- Type: Story
+- Priority: P0
+- Summary: Implement canonical runtime policy decision point (`allow/challenge/deny/escalate`) for all paid action paths.
+- Owner: Backend Platform
+- Estimate: 5d
+- Dependencies: None
+- Acceptance Criteria:
+  - Every paid action path calls policy runtime before execution.
+  - Decision output includes `decision`, `reasonCode`, `policyHash`, `policyVersion`, `decisionId`.
+  - Deterministic decision output for same input and policy version.
+
+#### `STLD-T2402`
+- Type: Story
+- Priority: P0
+- Summary: Add stable reason code registry and API surface for denied/challenged/escalated actions.
+- Owner: Backend Platform
+- Estimate: 3d
+- Dependencies: `STLD-T2401`
+- Acceptance Criteria:
+  - Reason codes are schema-validated and documented.
+  - API responses expose reason code and remediation hints.
+  - CLI/SDK map reason codes consistently.
+
+#### `STLD-T2403`
+- Type: Story
+- Priority: P0
+- Summary: Enforce policy evaluation at MCP entry points and bridge paths.
+- Owner: MCP / Integrations
+- Estimate: 3d
+- Dependencies: `STLD-T2401`
+- Acceptance Criteria:
+  - MCP tool calls cannot bypass policy runtime.
+  - MCP responses return policy decision metadata.
+  - Integration tests cover allowed/challenged/denied flows.
+
+#### `STLD-T2404`
+- Type: Task
+- Priority: P1
+- Summary: Add policy decision metrics and latency SLO instrumentation.
+- Owner: DevOps / Observability
+- Estimate: 2d
+- Dependencies: `STLD-T2401`
+- Acceptance Criteria:
+  - Metrics emitted: decision count by type/reason, eval latency p50/p95.
+  - Dashboard and alert thresholds configured.
+
+### Epic `STLD-E2402` Execution Binding + Evidence + Receipts
+
+#### `STLD-T2410`
+- Type: Story
+- Priority: P0
+- Summary: Enforce request binding between authorization token and canonical request fingerprint.
+- Owner: Backend Platform
+- Estimate: 4d
+- Dependencies: `STLD-T2401`
+- Acceptance Criteria:
+  - Request mutation/replay attempts fail with deterministic error code.
+  - Fingerprint algorithm is stable and versioned.
+  - Test vectors added for strict and side-effecting modes.
+
+#### `STLD-T2411`
+- Type: Story
+- Priority: P0
+- Summary: Bind policy hash/version and request hash into settlement decision records.
+- Owner: Backend Platform
+- Estimate: 2d
+- Dependencies: `STLD-T2410`
+- Acceptance Criteria:
+  - Decision records include policy/version/request binding fields.
+  - Offline verifier validates these bindings.
+
+#### `STLD-T2412`
+- Type: Story
+- Priority: P0
+- Summary: Ship `ReceiptBundle.v1` export with deterministic manifest and verification output.
+- Owner: Protocol / Backend
+- Estimate: 4d
+- Dependencies: `STLD-T2411`
+- Acceptance Criteria:
+  - Receipt bundle includes decision, settlement, and verification artifacts.
+  - Bundle verifies offline with strict mode.
+  - Repeat export produces identical canonical hashes.
+
+#### `STLD-T2413`
+- Type: Task
+- Priority: P1
+- Summary: Add SDK helpers for receipt retrieval/export across JS and Python.
+- Owner: SDK
+- Estimate: 3d
+- Dependencies: `STLD-T2412`
+- Acceptance Criteria:
+  - JS and Python SDK expose receipt export APIs.
+  - SDK smoke tests cover end-to-end retrieval and verification.
+
+### Epic `STLD-E2403` Dispute Court + Reversal Engine
+
+#### `STLD-T2420`
+- Type: Story
+- Priority: P0
+- Summary: Implement dispute case state machine (`opened`, `evidence_collected`, `under_review`, `verdict_issued`, `closed`).
+- Owner: Backend Platform
+- Estimate: 4d
+- Dependencies: `STLD-T2411`
+- Acceptance Criteria:
+  - State transitions are deterministic and idempotent.
+  - Invalid transitions are blocked with stable error codes.
+  - Case timeline is append-only and signed.
+
+#### `STLD-T2421`
+- Type: Story
+- Priority: P0
+- Summary: Implement verdict application pipeline to trigger automatic release/refund/reversal outcomes.
+- Owner: Backend Platform
+- Estimate: 4d
+- Dependencies: `STLD-T2420`
+- Acceptance Criteria:
+  - Verdict maps to deterministic financial outcome.
+  - Reversal entries are balanced and idempotent.
+  - Duplicate verdict processing does not double-settle.
+
+#### `STLD-T2422`
+- Type: Story
+- Priority: P0
+- Summary: Add dispute APIs and SDK wrappers for open/attach evidence/issue verdict.
+- Owner: API + SDK
+- Estimate: 3d
+- Dependencies: `STLD-T2420`
+- Acceptance Criteria:
+  - APIs exposed with authz enforcement.
+  - SDK wrappers for JS/Python and MCP tool surface.
+  - Contract tests cover happy and failure cases.
+
+#### `STLD-T2423`
+- Type: Task
+- Priority: P1
+- Summary: Add dispute SLA timers and escalation triggers.
+- Owner: Backend Platform
+- Estimate: 2d
+- Dependencies: `STLD-T2420`
+- Acceptance Criteria:
+  - Time-window breaches emit escalation events.
+  - Alerts and dashboards for aging disputes.
+
+### Epic `STLD-E2404` Operator Inbox + Controls
+
+#### `STLD-T2430`
+- Type: Story
+- Priority: P0
+- Summary: Build operator inbox page for challenged/escalated actions with approve/deny actions.
+- Owner: Frontend
+- Estimate: 5d
+- Dependencies: `STLD-T2401`, `STLD-T2422`
+- Acceptance Criteria:
+  - Operators can view pending items with policy context and evidence refs.
+  - Approve/deny writes signed operator action events.
+  - Pagination/filtering by tenant and severity.
+
+#### `STLD-T2431`
+- Type: Story
+- Priority: P0
+- Summary: Implement emergency controls: pause agent, quarantine, revoke delegation, kill switch.
+- Owner: Backend + Frontend
+- Estimate: 4d
+- Dependencies: `STLD-T2430`
+- Acceptance Criteria:
+  - Emergency actions are auditable and idempotent.
+  - Paused/quarantined agents cannot execute paid actions.
+  - Recovery flow documented and tested.
+
+#### `STLD-T2432`
+- Type: Task
+- Priority: P1
+- Summary: Add operator decision audit export for finance and compliance.
+- Owner: Backend
+- Estimate: 2d
+- Dependencies: `STLD-T2430`
+- Acceptance Criteria:
+  - Export contains decision metadata, actor, timestamp, reason, linked receipt/case IDs.
+
+### Epic `STLD-E2405` Rail Adapter Hardening
+
+#### `STLD-T2440`
+- Type: Story
+- Priority: P0
+- Summary: Harden one production adapter lane (`x402 + Stripe` or `x402 + AWAL`) under Trust OS enforcement.
+- Owner: Integrations
+- Estimate: 5d
+- Dependencies: `STLD-T2403`, `STLD-T2412`, `STLD-T2421`
+- Acceptance Criteria:
+  - End-to-end flow uses adapter with Trust OS decisions.
+  - Settlement and receipts remain deterministic.
+  - Replay and mutation attacks are rejected in adapter path.
+
+#### `STLD-T2441`
+- Type: Task
+- Priority: P1
+- Summary: Add adapter conformance tests and CI gate.
+- Owner: QA / Integrations
+- Estimate: 2d
+- Dependencies: `STLD-T2440`
+- Acceptance Criteria:
+  - CI fails on adapter regressions.
+  - Conformance report artifact uploaded per run.
+
+### Epic `STLD-E2406` Vertical Policy Profiles
+
+#### `STLD-T2450`
+- Type: Story
+- Priority: P0
+- Summary: Implement profile schema and profile hashing/signing contract.
+- Owner: Protocol + Backend
+- Estimate: 3d
+- Dependencies: `STLD-T2401`
+- Acceptance Criteria:
+  - Profile schema supports limits, allowlists, approval tiers, dispute defaults, compliance toggles.
+  - Profile hash is embedded in decisions/receipts.
+
+#### `STLD-T2451`
+- Type: Story
+- Priority: P0
+- Summary: Add CLI commands: `settld profile init`, `validate`, `simulate`.
+- Owner: CLI
+- Estimate: 4d
+- Dependencies: `STLD-T2450`
+- Acceptance Criteria:
+  - `init` scaffolds profile manifest and rules.
+  - `validate` performs schema + semantic checks.
+  - `simulate` runs policy against provided scenarios and outputs deterministic results.
+
+#### `STLD-T2452`
+- Type: Story
+- Priority: P0
+- Summary: Ship three starter profiles: `engineering-spend`, `procurement`, `data-api-buyer`.
+- Owner: Product + Backend
+- Estimate: 3d
+- Dependencies: `STLD-T2451`
+- Acceptance Criteria:
+  - Profiles are packaged and documented.
+  - Simulation fixtures pass in CI.
+
+#### `STLD-T2453`
+- Type: Task
+- Priority: P1
+- Summary: Add profile docs and quickstart guides in MkDocs/GitBook.
+- Owner: Docs
+- Estimate: 2d
+- Dependencies: `STLD-T2452`
+- Acceptance Criteria:
+  - Docs include usage, simulation examples, and troubleshooting.
+
+### Epic `STLD-E2407` QA, Conformance, and Release Gates
+
+#### `STLD-T2460`
+- Type: Story
+- Priority: P0
+- Summary: Add security regression tests for replay, token mutation, bypass attempts, and unauthorized escalation actions.
+- Owner: QA / Security
+- Estimate: 3d
+- Dependencies: `STLD-T2410`, `STLD-T2431`
+- Acceptance Criteria:
+  - Automated test suite covers top abuse paths.
+  - CI blocks release on failures.
+
+#### `STLD-T2461`
+- Type: Story
+- Priority: P0
+- Summary: Add end-to-end deterministic test: challenge -> operator approve -> execute -> receipt -> dispute -> verdict -> reversal.
+- Owner: QA
+- Estimate: 3d
+- Dependencies: `STLD-T2422`, `STLD-T2430`
+- Acceptance Criteria:
+  - E2E test runs in CI and emits artifact traces.
+  - Idempotency and deterministic output asserted.
+
+#### `STLD-T2462`
+- Type: Task
+- Priority: P0
+- Summary: Enforce release gate checklist for Trust OS v1 (conformance, receipts, disputes, adapters, docs).
+- Owner: DevOps
+- Estimate: 2d
+- Dependencies: `STLD-T2460`, `STLD-T2461`, `STLD-T2441`, `STLD-T2453`
+- Acceptance Criteria:
+  - Release workflow blocks tag publish if any gate fails.
+  - Release artifact bundle includes proof of all required checks.
+
+## Sprint Plan (Suggested)
+
+### Sprint 1 (Weeks 1-2)
+- `STLD-T2401`, `STLD-T2402`, `STLD-T2403`, `STLD-T2410`, `STLD-T2411`, `STLD-T2460`
+
+### Sprint 2 (Weeks 3-4)
+- `STLD-T2412`, `STLD-T2420`, `STLD-T2421`, `STLD-T2422`, `STLD-T2430`, `STLD-T2431`
+
+### Sprint 3 (Weeks 5-6)
+- `STLD-T2440`, `STLD-T2441`, `STLD-T2450`, `STLD-T2451`, `STLD-T2452`, `STLD-T2461`, `STLD-T2462`, `STLD-T2453`
+
+## Release Exit Criteria (Trust OS v1)
+
+- Runtime policy enforcement is mandatory for all paid actions.
+- Request binding enforcement blocks replay/mutation attempts.
+- Receipt bundle export verifies offline in strict mode.
+- Dispute->verdict->financial outcome is deterministic and replay-safe.
+- Operator emergency controls are audited and tested.
+- One rail adapter path is production-hardened and conformance-gated.
+- Three vertical profiles are documented and simulation-tested.