@stellar-agent-services/dev-mcp 0.1.0 → 0.1.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stellar-agent-services/dev-mcp",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "MCP server for coding agents building on Provider Standard v1: spec rules, docs, manifest validation and unpaid provider checks. It never pays.",
   "type": "module",
   "license": "MIT",
@@ -32,11 +32,11 @@
   },
   "dependencies": {
     "@modelcontextprotocol/sdk": "1.32.1",
-    "@stellar-agent-services/protocol": "0.1.0",
-    "@stellar-agent-services/verifier": "0.1.0",
+    "@stellar-agent-services/protocol": "0.1.1",
+    "@stellar-agent-services/verifier": "0.1.1",
     "zod": "3.25.76"
   },
   "devDependencies": {
-    "@stellar-agent-services/provider-kit": "0.1.0"
+    "@stellar-agent-services/provider-kit": "0.1.1"
   }
 }

package/repository/IMPLEMENTATION_PLAN.md

@@ -7,12 +7,15 @@ Job Recovery, delivered and piloted within one 30-day Instaward sprint.
 - **Source of truth:** Instawards SOW "Stellar Agent MCP" (submitted 29.09.2026, $4,000, 30 days).
 - **Background:** `stellar-agent-search/docs/provider-network-phase-2.md` and `issues/P3-23-provider-network-phase-2.md`.
 - **Network:** Stellar **testnet** for the whole build. Mainnet is a later, separate decision (see [Open decisions](#10-open-decisions)).
-- **Status:** Week 3. The protocol package, the Provider Kit (library, gateway mode, durable SQLite queue, CLI)
-  and the payment client (core, `stellar-pay` CLI and a minimal web approval page) work end to end on testnet.
-  Job Recovery is complete in code, reconciliation and the ledger clock included; the recorded testnet demo is
-  still to do. The verifier is complete in code: checks C1–C7 with on-chain payment proofs, receipts, badges and
-  `validation_response`, and `provider-kit request-validation` asks for it. A first testnet receipt and Validation
-  Registry record are next.
+- **Status (2026-11-06):** the core packages are released at 0.1.0. The kit, client, recovery and C1–C7 verifier
+  are implemented. This checkout adds fail-closed enforcement of configured verification restrictions [V1].
+  Sample approval/payment and recovery demos are recorded with screenshots and on-chain proofs in `evidence/`.
+  [The recordings and proofs are public](https://algorialabs.github.io/stellar-agent-services/); live verification
+  runs and badges are documented in [receipt evidence](evidence/receipts/README.md). Permanent sample
+  registration, an anchored Validation Registry response and the independent pilot remain.
+  Newer implementation notes report testnet discovery implemented in `stellar-agent-search`;
+  the pilot must confirm the full discovery-to-result path. See [SOW closeout](docs/sow-closeout.md) for the
+  handoff and [readiness evidence](evidence/readiness.md) for checks and public release/CI references.
 
 ---
 
@@ -35,12 +38,13 @@ Job Recovery, delivered and piloted within one 30-day Instaward sprint.
 
 ### 1.1 Inconsistencies in the SOW, and the reading we plan against
 
-The SOW gives different numbers in different sections. We plan against the reading that satisfies all of them.
+The SOW gives conflicting numbers. The working interpretation below still needs Chapter Lead agreement; it
+does not literally satisfy D3's phrase "three independent providers".
 
 | Topic | What the SOW says | We plan for |
 | --- | --- | --- |
 | Providers | "two independent providers" (objective, W4, evidence). "three independent providers" (D3). "not more than two" (out of scope). "three working provider integrations" (W4 output). | **3 integrations = our sample provider + 2 independent providers** |
-| Users | "five users" (D3, W4 output). "two users" (objective, W4 work, evidence). "not more than five" (out of scope). | **5 completed user flows** (this also covers "two") |
+| Users | "five users" (D3, W4 output). "two users" (objective, W4 work, evidence). "not more than five" (out of scope). | **5 distinct users**, each completing the flow |
 | Where it lives | "add … to Stellar Agent Search" | Phase 2 of Stellar Agent Search, built in this repo. Discovery stays in `stellar-agent-search`. |
 
 > Action: confirm this reading with the Ambassador Chapter Lead before the sprint starts.
@@ -383,9 +387,9 @@ The sprint start date is still TBD; day 1 is the date the SOW is signed.
 - [x] Payment client, first working version: approval screen, caps, signing, journal.
   - [x] Core, local-key signer and `stellar-pay` CLI (approval prompt, caps, journal, on-chain check).
   - [x] Minimal web approval page (`apps/wallet`), for the D1 video.
-- [ ] One successful testnet payment flow, recorded (tx link, screenshots, short video).
+- [x] One successful testnet payment flow, recorded ([video, screenshots and RPC proof](evidence/d1/README.md)).
   - [x] Testnet tx links.
-  - [ ] Screenshots and the short video.
+  - [x] Screenshots and the short video, captured 2026-11-06; public publication remains outstanding.
 - [ ] Start pilot outreach: shortlist 4–5 candidate providers and 6–7 users.
 
 **Exit:** spec published, approval-before-payment video, testnet tx link.
@@ -429,7 +433,8 @@ existing Python API becomes a paid service through gateway mode.
   - `payment_uncertain`
   - reconciliation: automatic after every sweep, and `provider-kit reconcile` (`--dry-run`, `--rpc`)
   - the response-loss drill
-  - [ ] Record the recovery demo on testnet: one interrupted job, recovered, with exactly one on-chain transfer.
+  - [x] Record the recovery demo on testnet: one interrupted job, recovered, with exactly one on-chain transfer
+    ([video, screenshots and bounded event scan](evidence/d2/README.md), 2026-11-06).
 - [x] Payment client recovery: resume from the journal, never re-sign.
 - [x] Payment client: treat `409 request_in_progress` on create-job and while polling as "ask again later".
 - [x] A ledger clock, shared by reconciliation and the kit: an on-success job's deadline from its payment's
@@ -439,14 +444,19 @@ existing Python API becomes a paid service through gateway mode.
 - [x] `verifier`: checks C1–C7, conformance levels, receipt, badges, and the no-payment `check` command
   (docs/verification.md). Paid checks prove payments on chain by the signed nonce, and that refused payments never
   landed; receipts are stored under their own SHA-256, the on-chain `response_hash`.
-- [ ] Validation Registry publishing: `request-validation` (provider) and `validation_response` (verifier) on testnet.
+  - [x] Capture live testnet verification receipts and earned badges; retain failed and skipped checks honestly
+    ([results](evidence/receipts/README.md)). Bounded polling now lets the same uncertain job reconcile [J13].
+- [x] Validation Registry publishing: `request-validation` (provider) and `validation_response` (verifier) on testnet.
   - [x] `verifier publish`: `validation_response` through the Stellar CLI keychain, after checking the request, the
     receipt and the `response_uri`; the request document is defined in docs/verification.md.
   - [x] `provider-kit request-validation`: the request document as a protocol type, JSON Schema and test vectors;
     the command checks the registration, the signer and the validator, then the owner's wallet signs it (or the
     Stellar CLI keychain, with `--source`).
-  - [ ] Run both on testnet for the sample provider: the first receipt and Validation Registry record.
-- [ ] Discovery integration, option (a) from §5.7, in `stellar-agent-search`.
+  - [x] Run both on testnet for registered Oracle sample agent 163; C1–C7 passed, score 100, receipt anchored
+    ([confirmed registration, request and response](evidence/validation/README.md), 2026-11-06).
+- [x] Testnet direct-registry discovery and manifest service matching reported implemented in `stellar-agent-search`
+  ([DX phase 4](docs/dx-improvements.md#phase-4-from-nothing-to-live-dev-launch-status)).
+- [ ] Confirm the released discovery path, price/network information and validation-derived badges during the pilot.
 - [ ] Pilot providers start integrating: send them the guide and template.
 
 **Exit:**
@@ -456,9 +466,11 @@ existing Python API becomes a paid service through gateway mode.
 ### Week 4: Pilot and evidence (D3)
 
 - [ ] Two independent providers live: each verified, each with at least one paid call.
-- [ ] Five users complete find → approve → pay → receive, and at least one runs a recovery.
+- [ ] Five distinct users complete find → approve → pay → receive, and at least one runs a recovery.
 - [ ] Fix pilot-blocking issues and record them in the pilot report.
-- [ ] Evidence page, demo videos, payment references, validation records, pilot report.
+- [x] Sample approval/payment and recovery videos, screenshots and payment references captured.
+- [x] Publish the evidence page, videos, payment references, anchored receipt and registry records.
+- [ ] Add the completed independent pilot report after real participant sessions.
 
 **Exit:** every row of the SOW §6.1 evidence table is linked from `evidence/README.md`.
 
@@ -485,8 +497,8 @@ existing Python API becomes a paid service through gateway mode.
 - [x] A client without `Idempotency-Key` and `Job-Token` → provider-generated id and token, one charge.
 - [x] A challenge whose amount, payTo, asset or network differs from the manifest → the client refuses to sign.
 - [x] A failed spending-limit check → the payment is blocked (fail closed).
-- [ ] A lost response → recovery returns the stored result, with one on-chain transfer. (Provider side and the
-  client's `recover()` are tested offline; the on-chain demo is Week 3.)
+- [x] A lost response → recovery returns the stored result, with one on-chain transfer. Provider/client behavior
+  is tested offline, and [the recorded testnet demo](evidence/d2/README.md) includes a complete bounded transfer scan.
 - [x] An uncertain settlement is decided from the transaction carrying the job's nonce: another job's equal
   transfer never counts, and "not settled" comes only after the expiration ledger closed and the whole window
   was searched. An RPC outage, a window older than the RPC's history, or a ledger still to come leave the job
@@ -541,8 +553,8 @@ everywhere.
 | --- | --- | --- | --- |
 | 1 | ~~Payment client design (§5.6)~~ **Decided 2026-10-21:** docs/payment-client.md | Berkin | W1 day 2 |
 | 2 | SOW provider/user counts reading (§1.1) | Berkin + Ambassador Chapter Lead | Before sprint start |
-| 3 | Testnet discovery approach (§5.7) | Berkin | W2 |
+| 3 | **Implemented per DX phase 4:** direct Identity Registry scan on testnet; confirm the released flow in the pilot | Berkin | Pilot |
 | 4 | Testnet-only evidence accepted, or a final mainnet run | Berkin + Ambassador Chapter Lead | W2 |
-| 5 | npm scope for publishing (placeholder `@stellar-agent-services/*`) | Berkin | W2 (first publish) |
+| 5 | **Released 2026-11-02:** `@stellar-agent-services/*` and `create-stellar-service`, version 0.1.0 | Berkin | Done |
 | 6 | ~~Provider Standard v1 freeze~~ **Decided 2026-10-21, frozen as drafted, except the URL:** `Job-Token` header, manifest path, `maxTimeoutSeconds` range, the URL for the schema `$id` and problem `type` values (`algorialabs.github.io/stellar-agent-services`), plus CORS as SHOULD [J17] | Berkin | W1 |
 | 7 | Shared ERC-8126/8196 conventions: score direction, tags, hashing, policy extensions (docs/erc-compatibility.md) | Berkin + ERC-8126/8196 Stellar team | W1 for hashing, W3 for validation records |

package/repository/README.md

@@ -18,12 +18,14 @@ payment side:
 | [`examples/paid-service`](examples/paid-service) | Sample provider and template for pilot providers |
 | [`examples/python-upstream`](examples/python-upstream) | An existing Python API made a paid service with gateway mode |
 
-**Status:** Week 3 of the plan. A paid call works end to end, from a provider (library or gateway mode, with a
-durable job queue) to the payment client's CLI and web page. Job Recovery is complete in code: providers decide
-uncertain payments from on-chain data ([docs/job-recovery.md](docs/job-recovery.md)). The verifier runs every check
-(C1–C7), proves payments on chain, and issues receipts, badges and Validation Registry responses
-([docs/verification.md](docs/verification.md)). The plan is in
-[IMPLEMENTATION_PLAN.md](IMPLEMENTATION_PLAN.md). Development runs on Stellar **testnet**.
+**Status (2026-11-06):** the core packages are released at 0.1.0. The kit, payment client, recovery and verifier
+are implemented. [Sample payment/recovery evidence is public](https://algorialabs.github.io/stellar-agent-services/),
+and live verification receipts and badges are captured in [evidence/](evidence/README.md). Permanent sample
+registration, an anchored validation response and the independent pilot remain. This checkout
+also enforces configured verification policies through an application-trusted source [V1]. The
+[SOW closeout guide](docs/sow-closeout.md) lists the remaining acceptance work, and
+[readiness evidence](evidence/readiness.md) records checks and release references. The full build history is in
+[IMPLEMENTATION_PLAN.md](IMPLEMENTATION_PLAN.md). Development and pilot evidence use Stellar **testnet**.
 
 To offer a service, start with [`npm create stellar-service`](packages/create-stellar-service), then:
 

package/repository/docs/client-integration/README-AI.md

@@ -54,6 +54,7 @@ itself can supply it. (The design doc's smart-account row, and erc-compatibility
 | --- | --- |
 | `packages/payment-client/src/strategies.ts` | `Signer`, `PaymentMethod`, `SignedPayload`, `ExpectedPayment`, `Confirmation` |
 | `packages/payment-client/src/client.ts` | `PaymentClient`: the flow that calls the strategies (`quote`, `pay`, `payOnce`, `confirm`, `methodFor`, `checkLimits`) |
+| `packages/payment-client/src/verification.ts` | Application-trusted evidence source and subject/freshness checks [V1] |
 | `packages/payment-client/src/local-key-signer.ts` | Built-in signer: `createEd25519Signer` from `@x402/stellar` |
 | `packages/payment-client/src/x402-exact-stellar.ts` | Built-in method, id `x402-exact-stellar` |
 | `packages/payment-client/src/onchain.ts` | `rpcConfirmPayment`, `checkTransfer`, `TransactionReader`. Reuse them in your `confirm()`. |
@@ -131,6 +132,13 @@ These hold for every adapter. Don't re-implement them in an adapter.
 | CG9 | The method named in `sending` confirms, against the journaled terms, never the receipt. A transaction that already confirmed another job, a missing method or a method that throws gives "not confirmed" with a reason `[J16]`. | `confirm()` | "confirms against the approved payment, not the provider's receipt", "does not confirm a job whose receipt reuses another job's transaction", "does not confirm a recovered payment whose method is no longer installed", "does not confirm a payment whose method throws while checking it" |
 | CG10 | `recover()` never calls `createPayload()`. | `recover()` | "recovers a lost response without paying again" |
 
+CG4 includes configured verification restrictions [V1]. The application installs `verificationSource`, not the
+signer or payment method. Evidence must match the approved manifest hash, URL, payee, network and agent id and
+remain within its validity window. No source, an outage or a missing required metric blocks signing. See
+`test/verification.test.ts` and [the design](../payment-client.md#verification-source). `minVerificationScore`
+retains ERC-8196's maximum-risk semantics; it is not the higher-is-better receipt score. Recovery does not read
+verification evidence.
+
 Journal on the happy path: `intent, approved, sending, settled, result`. When the wallet doesn't sign:
 `intent, approved, refused`.
 

package/repository/docs/client-integration/README.md

@@ -39,6 +39,7 @@ don't build those rules again.
 | --- | --- |
 | The price is checked | The payment request must match the price, payee and network the service published. |
 | Limits are checked | Per-payment and daily limits, plus your wallet's own budget, before anything is signed. |
+| Verification gates apply | Configured risk/level limits require fresh evidence from an application-trusted source; missing evidence blocks signing. |
 | The user approves | Every payment, or only those above an amount the user chose. |
 | One signature per job | Even when a wallet popup is slow or the user clicks twice. |
 | Saved before sending | A journal entry is written before the payment leaves, so a crash never leads to paying twice. |

package/repository/docs/dx-improvements.md

@@ -7,9 +7,13 @@ repository, why, and how it was checked. A phase is added here when it lands.
 | --- | --- | --- |
 | 1 | [`provider-kit try`](#phase-1-provider-kit-try): the first paid call in one command | Done |
 | 2 | [`provider-kit init --openapi`](#phase-2-provider-kit-init---openapi): the gateway config from an OpenAPI document | Done |
-| 3 | [`npm create stellar-service`, and how agents see you](#phase-3-npm-create-stellar-service-and-how-agents-see-you): a ready project in one command, and what search sees | Done, in review |
-| 4 | [From nothing to live: `dev`, `launch`, `status`](#phase-4-from-nothing-to-live-dev-launch-status): no wallet until launch, one approval page, verification without a hand-off | Done, in review |
-| 5 | [Mainnet, and the checks before a release](#phase-5-mainnet-and-the-checks-before-a-release): a mainnet project, CI that rehearses the npm publish, daily live checks, releases from a tag | Done, in review |
+| 3 | [`npm create stellar-service`, and how agents see you](#phase-3-npm-create-stellar-service-and-how-agents-see-you): a ready project in one command, and what search sees | Released in 0.1.0 |
+| 4 | [From nothing to live: `dev`, `launch`, `status`](#phase-4-from-nothing-to-live-dev-launch-status): no wallet until launch, one approval page, verification without a hand-off | Released in 0.1.0 |
+| 5 | [Mainnet, and the checks before a release](#phase-5-mainnet-and-the-checks-before-a-release): a mainnet project, CI that rehearses the npm publish, daily live checks, releases from a tag | Released in 0.1.0 |
+
+Release status was checked on 2026-11-06. The sections below retain their implementation-time validation and
+limits; [readiness evidence](../evidence/readiness.md) records newer checks. Live SOW evidence and the independent
+pilot remain outstanding; see [SOW closeout](sow-closeout.md).
 
 Before these phases, the owner's transactions (the USDC trustline, 8004 registration, validation requests) moved
 from a key in the CLI to the developer's own wallet, approved on a page the CLI opens

package/repository/docs/payment-client.md

@@ -175,7 +175,7 @@ How to build, test and submit an adapter, and what we and the integrator each ne
 | `allowedContracts` / `blockedContracts` | The asset contract (USDC SAC) | USDC only |
 | `maxValuePerTx`, `maxValuePerDay` | In the asset's base units, not a native value | 0.10 / 1.00 USDC |
 | `validAfter`, `validUntil` | ERC-8196 | now / +30 days |
-| `minVerificationScore` | ERC-8196, read through a risk-source interface once a Stellar ERC-8126 exists | unset |
+| `minVerificationScore` | ERC-8196 name: maximum allowed provider risk score (0–100, lower is safer), from a trusted source | unset |
 | `stellar.asset` | The one asset the limits apply to | USDC |
 | `stellar.payees` | `{ allow?, block? }` lists of `payTo` addresses, since the real payee is an argument of `transfer` | unset |
 | `stellar.minProviderLevel` | The lowest `provider-standard-v1` conformance level a payee must have | unset (pilot) |
@@ -185,6 +185,36 @@ How to build, test and submit an adapter, and what we and the integrator each ne
 Out of the box, every payment asks for approval, which is what the SOW requires. Paying without a prompt is
 something the owner turns on.
 
+### Verification source
+
+The core enforces configured `minVerificationScore` and `stellar.minProviderLevel` at quote time and again before
+signing [V1]. Missing or invalid evidence blocks the payment, including when the configured limit is zero. When
+both limits are unset, no verification read is needed.
+
+`PaymentClientOptions.verificationSource` is application-trusted code implementing:
+
+```ts
+interface VerificationSource {
+  read(subject: VerificationSubject): Promise<ProviderVerification | undefined>;
+}
+```
+
+The subject contains `network`, `payTo`, `manifestUrl`, `manifestSha256` (RFC 8785 canonical JSON) and optional
+`agentId`. The result repeats those fields and adds RFC 3339 `checkedAt` and `expiresAt`, plus optional
+`riskScore` (0–100, lower is safer) and `level` (0–3). The core rejects a different subject, a future check, expired
+evidence or an invalid metric. Each configured restriction requires its own metric.
+
+The source authenticates the evidence: trusted validator selection, registry reads, receipt hashes and the
+validity period it accepts. Its network calls must have deadlines. A raw receipt, a provider's badge or a score
+copied from a manifest is not an authenticated source. No built-in registry/risk-source adapter exists yet.
+
+`minVerificationScore` preserves ERC-8196's maximum-risk meaning despite its name (erc-compatibility.md T4).
+Do not compare it directly with the Provider Standard receipt's higher-is-better `score`.
+
+The web page and CLI do not install a source. Their default policies leave both restrictions unset; importing a
+policy that sets them blocks new payments until a source is installed. Recovery remains available without a
+verification read, because collecting a paid result never requires another payment [J11], [J13].
+
 ### Journal (ERC-8196 hash-chained audit trail)
 
 - One entry per step: `intent`, `approved` or `refused` (with the policy rule that refused), `sending`,
@@ -216,8 +246,10 @@ something the owner turns on.
 7. On `202`, or if the connection drops: check-status, then get-result, never paying again, at the pace the
    provider's `Retry-After` sets. A `409 request_in_progress` means the provider holds the payment and is still
    settling it: the client keeps polling, and hands the job back for `recover()` if settlement outlasts
-   `followSeconds`. A job the provider marks `payment_uncertain` comes back at once: only the provider's
-   reconciliation resolves it ([job-recovery.md](job-recovery.md#reconciliation)), so polling doesn't.
+   `followSeconds`. By default a job marked `payment_uncertain` comes back at once. With
+   `followPaymentUncertain: true`, the client keeps reading that same job within `followSeconds`, at the
+   provider's `Retry-After` pace, while provider reconciliation decides its payment from the chain [J13].
+   It never signs or submits another payment while waiting [J11]. `provider-kit try` enables this bounded wait.
 
 ## Sprint plan
 

package/repository/docs/provider-standard.md

@@ -607,6 +607,10 @@ Verification results are published to the Stellar 8004 Validation Registry. See
 
 The checks are listed in [verification.md](verification.md).
 
+- **[V1]** Clients SHOULD enforce any verification requirements configured by their owner before signing. Evidence
+  should come from a trusted source, match the approved manifest, payee and network, and be within that source's
+  validity window. Missing, unreadable or unverifiable evidence should block a payment that requires it.
+
 ## 9. Versioning and extensions
 
 - Changes inside v1 only add optional fields. `standard` stays `stellar-agent-services/provider@1`.

package/repository/docs/sow-closeout.md

@@ -0,0 +1,67 @@
+# SOW closeout and pilot handoff
+
+Reviewed on 2026-11-06 against the [source SOW](https://docs.google.com/document/d/1kIJ5nkwIVaXqHqcNHwuI5JN0Ap6g86wzncMQya6Kv88/edit)
+and this checkout. The [implementation plan](../IMPLEMENTATION_PLAN.md) records the build; this page records the
+remaining acceptance work. Prepared templates are not evidence of completed pilot work.
+
+## Readiness
+
+| Area | Available | Still needed for SOW acceptance |
+| --- | --- | --- |
+| D1 | Standard, client, spending controls, publicly hosted approval/limit-block video, screenshots and payment proof | Chapter Lead review |
+| D2 | Kit, guide, stable Oracle sample, all C1–C7 passed, anchored receipt/five badges, recovery and payment proofs | Chapter Lead review |
+| D3 | Scaffolder and onboarding guide | Independent integrations, user flows, findings/fixes and completed pilot report |
+| Distribution | Six npm packages at 0.1.0 and a successful public release | A later release for the changes in this checkout |
+| Discovery | Newer implementation notes report testnet registry scanning and manifest service matching | Confirm the released discovery path in the pilot and show the complete find-to-result flow |
+
+Public release and CI references, and local check results, belong in [readiness evidence](../evidence/readiness.md).
+The latest observed daily live workflow failed its paid testnet call; do not treat ordinary CI as a live payment
+proof. A trusted registry/risk-source adapter remains application integration work; configured verification limits
+now block new payments unless a trusted source can satisfy them [V1].
+
+## Acceptance decisions for the owner
+
+The source SOW conflicts: D3 says three independent providers and five users, while the objective and evidence
+section say two providers and two users; its exclusions cap providers at two. The working target is the sample
+plus two independent providers, and five distinct pilot users. This interpretation still needs Chapter Lead
+agreement. Five flows by one person do not establish five users.
+
+Also confirm that testnet evidence is accepted. Record the agreement and sprint start date in the pilot report;
+the SOW's submission date does not establish the sprint deadline.
+
+## Completed reference deployment and evidence
+
+The [sample runs on the existing Oracle A1 VM](../deploy/d2/oracle/README.md), with separate process, user,
+loopback port, SQLite data and HTTPS origin. No new cloud resources were allocated. Its public testnet owner
+is separate from the existing mainnet Logo Maker wallet. The mainnet manifest hash remained unchanged.
+
+The sample is registered as testnet agent 163. [Registry evidence](../evidence/validation/README.md) includes
+confirmed registration, request and response transactions, the request document, receipt hash and on-chain
+score/tag. All C1–C7 checks passed. The project-operated validator is separate from the provider and disposable
+payer; it is not an independent auditor. Signing keys stay in local Stellar CLI secure storage.
+
+Review these completed reference artifacts:
+
+1. [D1 approval, spending block, payment and result recording](../evidence/d1/README.md).
+2. [Registered sample receipt and five badges](../evidence/receipts/README.md), with failures/skips from historical runs preserved.
+3. [D2 same-job recovery recording and bounded single-transfer proof](../evidence/d2/README.md) [J11], [J13], [J16].
+4. [Linux client before/after evidence](../evidence/d2/oracle-clean-client.json): npm 0.1.0 returned uncertainty;
+   its original job later reconciled. The unreleased polling fix completed a distinct testnet call and
+   confirmed its transfer. This does not claim a scheduled CI rerun or an independent clean-host integration.
+5. [Public evidence page](https://algorialabs.github.io/stellar-agent-services/) and [publication checks](../evidence/publication.json).
+
+The [Oracle runbook](../deploy/d2/oracle/README.md) records maintenance and rollback. For another provider,
+follow the [setup guide](provider-setup-guide.md), use its own public payout, and have its owner sign registry
+steps in their wallet. Never deploy an owner signing key. Mainnet proof remains deferred until funded;
+all completed reference payments and registry records are explicitly testnet.
+
+## Run the independent pilot
+
+Use [the pilot checklist](../evidence/pilot/README.md) and [report template](../evidence/pilot/report.md). Recruit
+providers who control their own code, payout wallet and deployment. Have them follow the guide from a clean
+environment; record assistance and blockers. Each provider needs a real paid testnet service call and its own
+linked evidence. Capture discovery, approval, payment and result for each user; at least one demonstrates recovery.
+
+Resolve blocking issues, retain before/after observations and rerun only affected flows. Submit the evidence index
+with completed videos, receipts, transaction references, registry records and report, then request Chapter Lead
+acceptance against SOW §6.2.

package/repository/docs/standard/README-AI.md

@@ -30,9 +30,9 @@ pays one) that follows Provider Standard v1.
 | Any other language or stack | **Native**: implement §3–§12 | §3–§12, §13 |
 | Agent, wallet or app that pays providers | **Client** | §14, [packages/payment-client](../../packages/payment-client) |
 
-The packages are npm workspaces in this repository and are not yet published to npm. Clone the repository and
-run `npm install && npm run build`. Then build inside it, copy `examples/paid-service`, or link a package into
-another project with `npm install <repo>/packages/provider-kit`.
+The packages are published on npm from 0.1.0. Use `npm create stellar-service`, or install the package you need.
+For unreleased changes, clone this repository and run `npm install && npm run build`. Then build inside it,
+copy `examples/paid-service`, or link a package with `npm install <repo>/packages/provider-kit`.
 
 ## 2. Kit path (TypeScript)
 
@@ -486,6 +486,8 @@ npx stellar-pay pay http://localhost:8787/.well-known/stellar-agent-services.jso
 - Unpaid create-job → `402`. Compare the challenge with the approved manifest, and refuse to sign on any mismatch
   `[P7]`.
   - Show the price, recipient, network and `charge` before approval `[S3]`.
+- Enforce configured verification limits from trusted evidence matching the approved manifest, payee and network
+  `[V1]`. Missing, unreadable or expired evidence blocks a payment requiring verification. Recheck before signing.
 - Sign once. Send the paid request with the same id, token and input.
 - `429` / `503` from create-job: wait `Retry-After` plus jitter, then send the identical request again `[Q8]`.
   - On a paid request, send the same `PAYMENT-SIGNATURE`.
@@ -608,4 +610,5 @@ Errors, identity and extensions:
 - **I1** The 8004 registration lists the manifest under `stellar-agent-services`.
 - **I2** `provider.agentId` is that registration's id.
 - **I3** `payTo` equals `get_agent_wallet(agentId)`.
+- **V1** Clients SHOULD enforce configured verification requirements from trusted, matching, current evidence before signing.
 - **X1** Extra fields go in `extensions` with reverse-DNS keys, and clients ignore unknown ones.

package/repository/docs/verification.md

@@ -178,6 +178,8 @@ The test payer pays for one job of the target service (`--service`, or the cheap
 3. Every job view is checked: the job id is the `Idempotency-Key` (§5.2), `charge` is the manifest's (§3.2),
    `charged` fits the state (§5.6), `200` once finished and otherwise `202` with `Retry-After`, plus `Location` on
    create-job [J8], output only when it may be shown [J14], and a receipt whose terms are the payment's (§5.7).
+   A `payment_uncertain` job is polled within the same bounded follow period while the provider reconciles it
+   from the chain [J13]. Polling only reads the original job [J11]; unresolved uncertainty earns no paid check.
 4. The job must succeed (§5.6), charged, with output that matches `outputSchema` [S1].
 5. The receipt's transaction must have succeeded, carry the payment the verifier signed, and move exactly the
    price from the payer to `payTo` [J16]. The response that settled SHOULD carry `PAYMENT-RESPONSE` [P10].

package/repository/examples/paid-service/README.md

@@ -11,6 +11,15 @@ their template.
 Jobs are kept in SQLite (`JOB_DB_PATH`, default `./jobs.sqlite`), so a paid job survives a restart: stop the
 server while a report is queued, start it again, and the report runs.
 
+Set `HOST=127.0.0.1` when a reverse proxy on the same server supplies HTTPS. The default is `0.0.0.0`, which also
+works inside a container. [The Oracle testnet deployment](../../deploy/d2/oracle/README.md) uses loopback and
+a separate persistent job store beside an existing mainnet service.
+
+`text-stats` admits one on-success job at a time and refuses excess work before payment [Q2], [Q3]. This is
+deliberately conservative for the shared testnet facilitator. A live verification run at the former default of
+four concurrent jobs encountered settlement errors; its receipt is retained in
+[the verification evidence](../../evidence/receipts/README.md).
+
 Run it with `npx provider-kit dev -- npm start` in this directory, after `npm install && npm run build` at the
 repository root: with `PAY_TO` empty, `dev` makes a throwaway testnet account to be paid to, so you need no wallet yet
 (or run `PAY_TO=G... npm start` with an account of yours). `.env.example` lists the settings; they are public values

package/repository/llms.txt

@@ -16,7 +16,7 @@
 
 ## Standard
 
-- [Provider Standard v1](https://raw.githubusercontent.com/AlgoriaLabs/stellar-agent-services/main/docs/provider-standard.md): The normative spec: manifest, services, payment, jobs, capacity, errors, identity, conformance levels. Rule ids M, S, P, J, Q, E, I, X
+- [Provider Standard v1](https://raw.githubusercontent.com/AlgoriaLabs/stellar-agent-services/main/docs/provider-standard.md): The normative spec: manifest, services, payment, jobs, capacity, errors, identity, conformance levels. Rule ids M, S, P, J, Q, E, I, V, X
 - [Standard reference for AI coding agents](https://raw.githubusercontent.com/AlgoriaLabs/stellar-agent-services/main/docs/standard/README-AI.md): The spec as an implementation reference: paths, constants, the create-job algorithm, headers, states, a rule index, common mistakes
 - [Standard summary for people](https://raw.githubusercontent.com/AlgoriaLabs/stellar-agent-services/main/docs/standard/README.md): What the standard does and why, without the detail
 - [Test vectors](https://raw.githubusercontent.com/AlgoriaLabs/stellar-agent-services/main/packages/protocol/test-vectors/README.md): Known-answer tests for an implementation in any language: canonical JSON, binding hashes, headers, manifests, challenges, job states, errors
@@ -56,6 +56,7 @@
 
 ## Optional
 
+- [SOW closeout](https://raw.githubusercontent.com/AlgoriaLabs/stellar-agent-services/main/docs/sow-closeout.md): Readiness, remaining acceptance work, testnet deployment and evidence handoff
 - [Contributing](https://raw.githubusercontent.com/AlgoriaLabs/stellar-agent-services/main/CONTRIBUTING.md): How changes are made: the spec first, then the kit, client and verifier
 - [ERC compatibility](https://raw.githubusercontent.com/AlgoriaLabs/stellar-agent-services/main/docs/erc-compatibility.md): How the standard lines up with ERC-8126 (agent verification) and ERC-8196 (agent authenticated wallet)
 - [Developer experience improvements](https://raw.githubusercontent.com/AlgoriaLabs/stellar-agent-services/main/docs/dx-improvements.md): What each phase of the developer-experience work changed for providers, and how it was checked

package/repository/packages/payment-client/README.md

@@ -36,6 +36,7 @@ The main entry point runs in Node and the browser. Journal storage depends on wh
 | `src/x402-exact-stellar.ts` | The built-in payment method: x402 `exact` on Stellar, the only one Provider Standard v1 allows |
 | `src/conformance.ts` | Checks that every signer and payment-method adapter must pass (`./conformance` entry point) |
 | `src/policy.ts` | Spending policy with ERC-8196 field names; `checkPolicy()` fails closed |
+| `src/verification.ts` | Application-trusted verification source; binds evidence to the approved manifest, payee, network and validity window [V1] |
 | `src/journal.ts` | Append-only, hash-chained journal; job tokens kept apart in a `SecretStore` |
 | `src/file-storage.ts` | Journal and job-token storage in files (`./node` entry point) |
 | `src/browser-storage.ts` | Journal and job-token storage in IndexedDB (`./browser` entry point) |
@@ -67,9 +68,31 @@ Job Recovery: start the provider with `DRILL_LOSE_RESPONSE=1 REPORT_DELAY_SECOND
 then run the `stellar-pay recover <job-id> --dev` command it prints. `stellar-pay jobs` and
 `stellar-pay journal verify` show the journal.
 
+`followPaymentUncertain: true` optionally follows an uncertain job within `followSeconds` while the provider
+reconciles it [J13]. It only reads the original job and never pays again [J11]. The default returns uncertainty
+immediately, so a UI can offer manual recovery. `provider-kit try` enables the bounded wait.
+
+## Verification policy
+
+Configured verification limits are checked at `quote()` and again at `pay()`, before signing [V1]. Install a
+`verificationSource` in `PaymentClientOptions` to supply authenticated evidence. Without a source, or when it
+returns missing, stale, mismatched or unreadable evidence, a payment requiring verification is blocked.
+
+- `minVerificationScore` keeps ERC-8196's name and meaning: the **maximum allowed risk score**, 0–100, lower is
+  safer. It compares with the source's `riskScore`, not a receipt's higher-is-better conformance score.
+- `stellar.minProviderLevel` is the minimum Provider Standard §8 level, 0–3.
+- Even a configured value of zero requires evidence. Leaving both fields unset requires no source.
+- Sources are trusted application code. They must authenticate validators and receipt/registry data, bind the
+  answer to the requested subject, set `checkedAt` and `expiresAt`, and bound their network calls. Never use a
+  provider's own claims as proof. No built-in registry/risk-source adapter is supplied yet.
+- Recovery collects an already paid job without consulting the source or signing again [J11], [J13].
+
+See [the design](../../docs/payment-client.md#verification-source) for the interface and trust boundary.
+
 ## Not done in the PoC
 
-- `minVerificationScore` and `stellar.minProviderLevel` are stored but not enforced.
+- No built-in Validation Registry or ERC-8126 risk-source adapter. Configured verification limits fail closed
+  until the application supplies its own trusted source.
 - The wallet secret is a plain file (mode 600). Testnet only.
 - No MCP server yet.
 - Only the built-in signer and method. Adapters for other wallets come later, each in its own package.

package/repository/packages/provider-kit/README.md

@@ -306,7 +306,9 @@ GDJB…XA3O (payTo) received 0.01 USDC.
 - **Testnet only.** A provider on Mainnet is refused before anything is signed.
 
 `--json` prints the outcome as JSON on standard output (the job, its status, the payment and the output) and the
-steps on standard error. It exits 0 only when the job succeeded and its payment is confirmed. If the answer to the paid request is lost, it
+steps on standard error. It exits 0 only when the job succeeded and its payment is confirmed.
+When the provider returns `payment_uncertain`, it polls that same job within the follow deadline, without
+signing or sending another payment [J11], [J13]. If the answer to the paid request is lost, it
 says the payment may have gone through and never calls it unpaid: your provider decides it from the chain
 [J13]. If the testnet DEX has no USDC for sale, nothing is paid: try again later, or pay with `stellar-pay` from a
 test wallet of your own, funded at [faucet.circle.com](https://faucet.circle.com) (setup guide §6).

package/repository/packages/verifier/README.md

@@ -50,6 +50,10 @@ Every check that ran passed.
 Exit codes: `0` every check that ran passed, `1` a check or the command failed, `2` a usage error. `--json` prints
 the report, or the receipt, on standard output. `watch` runs until SIGINT or SIGTERM, then exits `0`.
 
+The paid checks poll an uncertain job within their existing follow deadline, allowing the provider to reconcile
+it from the chain [J13]. They read the original job and never sign or send another payment while waiting [J11].
+Unresolved uncertainty is skipped and earns no paid check.
+
 As a library:
 
 ```ts