Stage onboarding-tester Path 2 on agent-delegable regtest payments

Revise ROADMAP item 9 and the INBOX Path-2 item: split the harness into
Stage 1 (Path 1, no payments, unblocked) and Stage 2 (Path 2, full
buyer-pays on regtest), gated on keysat's greenlit payment_providers:write
scope + network gate + sandbox flag. Drops the earlier 'operator
pre-connects' framing now that scoped agent connect on regtest is the plan.
This commit is contained in:
Keysat
2026-06-16 20:42:08 -05:00
parent 40f4af4191
commit 950cf48c06
2 changed files with 22 additions and 10 deletions
+21 -9
View File
@@ -160,7 +160,7 @@ for repos that have a contract; (c) confirm against a real Claude Design run wha
bundle actually contains and tune the Phase C distillation (the export internals are only
medium-confidence from research).
## 9. `onboarding-tester` — docs-only fresh-adopter agent ✅ BUILT (agent); harness pending
## 9. `onboarding-tester` — docs-only fresh-adopter agent ✅ BUILT (agent); harness pending (staged Path 1 → Path 2)
Built and live: `guides/onboarding-tester.md` + `adapters/claude/agents/onboarding-tester.md`. A
global adopter agent: given a **goal**, a **docs-corpus allowlist**, a **sandbox**, and
@@ -174,15 +174,27 @@ walkthrough only on a clean run) makes it both a docs-QA tool and a source of ag
**First instantiation — keysat SDK integration (harness lives in keysat, not here):** goal = gate
`proof-of-work` behind a keysat license end-to-end under the least-privilege `merchant-onboard`
scoped key (keysat shipped that role for this, commit `d5885d1`; covers catalog setup + manual
license issuance, but **not** payment-provider connect, which stays master-only by design — a
trust feature to surface, not a gap). Harness = two disposable containers (`keysat-server` fixture
booted fresh + `developer-sandbox` holding `proof-of-work`), master-key mints the scoped key, docs
corpus = keysat.xyz / docs.keysat.xyz / the four SDK package pages. **Pending:** build the harness +
first live run in a keysat session.
license issuance). Harness = two disposable containers (`keysat-server` fixture booted fresh +
`developer-sandbox` holding `proof-of-work`), master-key mints the scoped key, docs corpus =
keysat.xyz / docs.keysat.xyz / the four SDK package pages.
**Follow-ups (captured to `INBOX.md`):** (a) Path 2 — buyer-paid purchase demo (operator
pre-connects a BTCPay/Zaprite sandbox once, agent drives the rest); (b) a separate
operator-onboarding agent for the StartOS install journey.
**Staged build:**
- **Stage 1 — Path 1, no payments (do first, unblocked now):** catalog → tiers → manual license
issuance → SDK integration → offline verify, all under `merchant-onboard`. Cheapest honest
walkthrough; validates the agent + core integration docs before adding payment infra. **Pending:**
build the harness + first live run in a keysat session.
- **Stage 2 — Path 2, full buyer-pays on regtest (gated):** depends on keysat shipping
`payment_providers:write` (opt-in scope, never bundled into `merchant-onboard`) + a network gate
(scoped connect = regtest/testnet/signet only; mainnet master-only; fail-closed) + a daemon-level
sandbox-mode flag — **greenlit with the keysat dev 2026-06-16** (`plans/agent-payment-connect-scope.md`).
Then the harness adds a BTCPay regtest stack and the agent connects BTCPay (regtest) **and** drives
a test buyer payment end-to-end, zero master-key steps. Walkthrough labeled regtest; production
mainnet-connect stays the operator's one reserved step **by design** (a key that can repoint
settlement is a fund-redirection key — surface the boundary as a security feature).
**Other follow-up (captured to `INBOX.md`):** a separate operator-onboarding agent for the StartOS
install journey (stand up + run keysat from docs alone), vs. the developer SDK-integration journey
this agent covers.
## 7. Verify & correct the placement guide ✅ DONE (2026-06-15)