## Ideas carried over from `oscartbeaumont/devtools-rspc`

That repo held the original `devtools.specta.dev` concept — a hosted devtools UI for rspc procedures. It's being deleted, so this comment captures everything that was open there (17 issues, all still open) as future reference.

Original issue numbers are kept per item so the thinking is traceable.

### Observability core

- **Logs per procedure** — attach logs to the procedure invocation that produced them, rather than a flat global stream. (#9)
- **Metrics** — break down slow queries by arguments, show p50/p99, and surface the argument shapes that are actually slow instead of just an aggregate. (#10)
- **Capture regular logs** — the big open question: can we substitute stdout/stderr for the process so anything using `println!`/`eprintln!` shows up in the UI? Considerations noted:
  - Redirecting stderr from inside the process ([SO answer](https://stackoverflow.com/questions/54429389/how-to-redirect-stderr-from-inside-the-process-in-rust), [gag-rs](https://github.com/Stebalien/gag-rs/tree/master))
  - Is `gag` thread safe? If not, what's the safe alternative?
  - Also capture panics via a panic hook.
  - Can we still recover module information from the caller? (#12)
- **Track Tokio tasks** — can we query tasks created by a procedure and show their information (state, duration, spawned-at) in the UI? (#16)
- **Inspect plugins** — inspect mounted plugins and their state. Maybe an optional `DebugState` trait that plugins can implement to expose something useful. (#17)

### UI and navigation

- **Command K menu** — global command palette. (#13)
- **Keyboard shortcuts** — proper keybind layer alongside the palette. (#14)
- **Search and filter** — filter by time range, severity, free-text string, module, etc. Should work across logs, metrics and procedures. (#11)
- **404 page** — 404 route for the web app. (#3)

### Integrations

- **Tauri Specta support** — "if we're gonna develop this we may as well go crazy." First-class support for Tauri + Specta rather than only plain rspc servers. (#8)

### Accounts, access and persistence

- **Login with GitHub** — detect that the GitHub Student pack bonus has been activated, and record users in the DB for future reference. (#4)
- **Authentication** — an auth story good enough that you can leave devtools enabled in prod: a UI to gate access, plus the same gating in the open-source plugin. Possibly allow whitelisting GitHub users/orgs, though that would require holding a private key — flagged as maybe not worth it. (#7)
- **Billing** — ~$10/year via Stripe for access. (#2)
- **Demo mode** — use it with no account, so people can evaluate before signing up. (#6)
- **Save** — persist connection URIs, detect the active crate and allow saving queries, and back up saved work to KV against the logged-in account. (#5)
- **Offline mode** — cache the licence so you can work on the go; changes might need CRDTs to merge cleanly. (#15)

### Marketing/web

- **SEO** — general meta tags, `favicon.ico`, OpenGraph tags, `noscript` fallback. (#1)

### Notes for whoever picks this up

The theme running through the original repo was that this was going to be a **product** (billing, accounts, hosted service) wrapped around a **plugin** that you could leave enabled. This issue's framing is narrower — tools for testing endpoints, agent-friendly — so worth deciding explicitly whether the commercial/hosted layer is still in scope or whether this becomes a pure library/dev-server feature. A few of the above collapse or disappear depending on that answer (billing, demo mode, offline mode, save/backup).

The technical questions that still need resolving regardless are in #12 (stdout/stderr capture, thread safety, panic hooks) and #17 (`DebugState` trait shape) — those constrain the plugin's API surface early.

<sub>Generated on _MrBeast_ using _opencode-go/deepseek-v4.1-flash_ in _ses_e3c247456ffdeN7l3T5w5PW2UM_</sub>