Problem
The README's only public face is ~130 lines of prose: zero screenshots, zero GIF, zero demo. A search on Hacker News (Algolia) for "octoscode" returns no relevant hits. For a visual product, the first rung of the discovery funnel is "see it in 10 seconds" — and right now nobody can.
The unusual asset this repo already owns: apps/web/scripts/mock-ui-server.mjs is a deterministic fixture (no real agent, no credentials) that renders the full UI. A public playground built on it has near-zero operational and safety cost, where competitors must build sandboxes.
Proposal
- README screenshots (low risk, immediate): 2-3 real captures (connect gate, active session with a code block, settings) at the top of the README, maintained as part of release docs.
- Public playground (owner decision): serve the mock fixture behind a read-only or ephemeral instance with a "try the UI" link in the README and
docs/getting-started.md. The mock server already ships auth-mode switches (see playwright.config.ts webServer env usage).
- Optionally: a short GIF showing prompt → streaming → approval flow.
This is the "be seen" half of the visibility gap (the "be needed" half is tracked separately, e.g. attention channel issue).
Problem
The README's only public face is ~130 lines of prose: zero screenshots, zero GIF, zero demo. A search on Hacker News (Algolia) for "octoscode" returns no relevant hits. For a visual product, the first rung of the discovery funnel is "see it in 10 seconds" — and right now nobody can.
The unusual asset this repo already owns:
apps/web/scripts/mock-ui-server.mjsis a deterministic fixture (no real agent, no credentials) that renders the full UI. A public playground built on it has near-zero operational and safety cost, where competitors must build sandboxes.Proposal
docs/getting-started.md. The mock server already ships auth-mode switches (seeplaywright.config.tswebServer env usage).This is the "be seen" half of the visibility gap (the "be needed" half is tracked separately, e.g. attention channel issue).