diff --git a/INBOX.md b/INBOX.md index 0d7da85..42bc6a3 100644 --- a/INBOX.md +++ b/INBOX.md @@ -53,5 +53,5 @@ Example: - [ ] (recap-relay) [idea][P2] add gemini 3.5 to model selection, need to have research agent check which models are available (stable versions) and the correct model name — via matrix, 2026-06-16 - [ ] (new:personal-website) [project][P2] Develop personal website — host on Start9 Pages, served on clearnet via StartTunnel; build HTML site, use Claude Design for styling, gather design inspiration — 2026-06-16 - [ ] (ten31-database) [bug][P2] error message in email capture tab on email sync status — via matrix, 2026-06-16 -- [ ] (keysat) [feature][P3] Onboarding-tester Path 2 — buyer-paid purchase demo: operator pre-connects a BTCPay/Zaprite sandbox once (master-only by design), then the onboarding-tester agent drives the full buyer-pays-Bitcoin purchase path downstream under the merchant-onboard scoped key. Extends the Path 1 manual-issuance harness; produces the fuller commercial "all it took was X, Y, Z" walkthrough for the website, 2026-06-16 +- [ ] (keysat) [feature][P3] Onboarding-tester Path 2 — full buyer-pays walkthrough on regtest. GATED on keysat shipping `payment_providers:write` (opt-in scope, never bundled into merchant-onboard) + network gate (scoped connect = regtest/testnet/signet only, mainnet master-only, fail-closed) + daemon-level sandbox-mode flag (greenlit with the keysat dev 2026-06-16; see plans/agent-payment-connect-scope.md). Then: harness stands up a BTCPay regtest stack + a sandbox-flagged keysat instance, grants the agent merchant-onboard + payment_providers:write, and the agent connects BTCPay (regtest) AND drives a test buyer payment that activates a license — entire chain agent-done, zero master-key steps. Walkthrough must be labeled regtest; production mainnet-connect stays the operator's one reserved step BY DESIGN (frame as security feature). Build AFTER Path 1 (no-payments) ships, since the BTCPay-regtest stack is the bulk of the new infra, 2026-06-16 - [ ] (standards) [agent][P3] Operator-onboarding agent — sibling to onboarding-tester for the *operator* journey (stand up + run keysat from docs alone: sideload/registry install on StartOS, configure, issue first license), vs. the developer SDK-integration journey onboarding-tester already covers. Needs its own clean room (a clean StartOS service-install, not a generic VPS, since the s9pk can't run on a vanilla Linux box), 2026-06-16 diff --git a/ROADMAP.md b/ROADMAP.md index c20f042..dd45ded 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -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)