# Inbox — cross-project capture buffer Raw, untriaged ideas and bugs for **any** repo, captured from anywhere so they stop scattering into phone notes. `/capture` appends here; `/triage`, run inside a project, drains that project's items into its `AGENTS.md` (`## Current state`) or `ROADMAP.md`. This buffer is upstream of every repo's ROADMAP — nothing here is owned or scheduled until triaged. **Line format** — one item per line: ``` - [ ] (project) [type][Pn] note — optional context, YYYY-MM-DD ``` - `project` — the target repo's folder name (e.g. `relay`), or `standards` for this repo, or `?` if unsure. For an idea that would be a **brand-new repo** (no folder exists yet), use `new` — or `new:working-name` if you have a name in mind. - `type` — `bug` | `feature` | `idea` | `skill` | `agent` | `project` | `chore` (`project` = a potential new repo; handled by the new-repo bootstrap, not `/triage`). - `Pn` — priority `P0` (drop-everything) … `P3` (someday). Default `P2` if unspecified. - `[ ]` unchecked = untriaged; `/triage` removes items once they're routed. Example: ``` - [ ] (relay) [bug][P1] health-check probes the wrong port after the bind refactor — found while testing, 2026-06-14 ``` --- ## Items - [ ] (standards) [feature][P2] API automation for Gitea in /new-project — automate the currently-manual Gitea create/publish gate via the Gitea API, 2026-06-14 - [ ] (new:embedded-links-reader) [project][P2] Embedded-links reader & summarizer — give the app an article/blog URL; it scrapes the links the author embedded (the ones you don't want to visit in the moment), reads them, and summarizes them, 2026-06-14 - [ ] (new:portfolio-scraper) [project][P2] Portfolio-company scraper — tracks portfolio companies for podcasts, social tweets, founder appearances, news, etc. and delivers a digest via email or another interface, 2026-06-14 - [ ] (recap-relay) [chore][P3] AGENTS.md endpoint list mis-describes POST /relay/analyze as "{ transcript, … } → topic sections JSON". The actual route (server/routes/analyze.js) takes a free-form { prompt: string } and returns the standard envelope { result: { text } }; "topic sections JSON" is only what the recap-app caller asks for in its prompt. Fix the request-shape wording to { prompt } — surfaced resolving Recaps' Daily Digest synthesis contract (Q4), 2026-06-15 - [ ] (keysat) [chore][P2] Design-contract cleanup from the 2026-06-16 design-checker audit — full detail in keysat ROADMAP "Design (contract conformance)" + design/DESIGN.md. (1) Fix 3 blockers (code violates the contract's named "never" rules on live CTAs): (a) gold-as-fill on admin `.featured-pill-toggle.on` (licensing-service-startos/licensing-service/web/index.html:418) → navy fill or gold border+text; (b) gold-as-fill on admin `#tier-banner-cta` upgrade button (web/index.html:537-542) → navy primary; (c) primary buy CTA pill radius 999px (keysat-xyz-landing/index.html:384-385) → r-md 8px. (2) Structural: consolidate the 4 surfaces' inlined CSS-variable copies onto canonical design/brand/palette.css (import it, drop private copies). (3) Token gaps (tokenize-vs-snap): 14px landing card radius; wordmark letter-spacing 0.30 vs 0.28em (add letterSpacing.wordmark token); semantic badge text one-offs (#205c47/#7a5814/#8a2828); hardcoded syntax-highlight hex → var(); admin #f6f1e7 off-token. Re-run design-checker after to confirm, 2026-06-16 - [ ] (ten31-signal-engine) [chore][P2] Run full-eval on the signal engine folder — the full evaluation suite (evaluator, security-auditor, exerciser, doc-auditor, spec-checker), 2026-06-16 - [ ] (standards) [idea][P2] run janitor agent on all projects — via matrix, 2026-06-16 - [ ] (keysat) [chore][P2] does the keysat registry need to save every iteration of new versions of keysat software as we upgrade it? research agent needs to investigate — via matrix, 2026-06-16- [ ] (keysat) [chore][P2] Adversarial review of keysat- what vulnerabilities, customer complaints, feature gaps, might a new user find. — via matrix, 2026-06-16 - [ ] (keysat) [chore][P2] run spec-checker agent for listing to start9 community registry — via matrix, 2026-06-16 - [ ] (keysat) [chore][P2] review website for any drift/inconsistencies (doc-auditor), review GitHub for any sensitive information in historical commits (revealed info), review website and consider adding specific example of how to add licensing to existing software (for example this is a good way to test the dry run of a new user just using documentation... we could give an agent the proof-of-work software and see if they can just add a license paywall in front of it before they can use it in one shot) — via matrix, 2026-06-16 - [ ] (recap) [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 - [ ] (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 - [ ] (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