Idea
Ship the actual frontend GUI, fully interactive, on GitHub Pages — a live demo room that anyone can click through (ideally auto-running the coached "Run a sample coordination" playthrough). Zero backend, no SLIM node, no LLM: a pure static site people can try from the README/docs.
Why it's tractable
The demo content already exists — this is a packaging/build task, not new UI:
mycelium-frontend/src/mocks/fixtures.ts — realistic room / agent / memory / plan data.
mycelium-frontend/src/mocks/stream.ts (mockStream) — a scripted live negotiation replayed over SSE.
mycelium-frontend/src/components/room-tour.tsx + ?tour=1 — the coached playthrough.
mycelium-frontend/src/test/fake-event-source.ts — an in-browser EventSource stand-in.
MYCELIUM_UI_MOCK=1 / pnpm dev:mock already renders the whole UI with no backend.
The one real gap
GitHub Pages is pure static (no Node server), but the mock currently lives server-side, inside three route handlers:
src/app/api/[...path]/route.ts
src/app/api/events/stream/route.ts
src/app/api/rooms/[name]/messages/stream/route.ts
Route handlers can't exist in a static export, so the mock has to move into the browser. The mock logic already returns web-standard Response / ReadableStream, so this is a retarget, not a rewrite.
Tasks
Notes
Scoped to mycelium-frontend/ + a CI workflow. Low risk: new build target + a browser shim over existing fixtures; the real app / Docker path is unaffected. Rough estimate: a half-day spike to a working PoC. The fiddly parts are static-export quirks (dynamic routes, image optimization, basePath), not architecture.
Idea
Ship the actual frontend GUI, fully interactive, on GitHub Pages — a live demo room that anyone can click through (ideally auto-running the coached "Run a sample coordination" playthrough). Zero backend, no SLIM node, no LLM: a pure static site people can try from the README/docs.
Why it's tractable
The demo content already exists — this is a packaging/build task, not new UI:
mycelium-frontend/src/mocks/fixtures.ts— realistic room / agent / memory / plan data.mycelium-frontend/src/mocks/stream.ts(mockStream) — a scripted live negotiation replayed over SSE.mycelium-frontend/src/components/room-tour.tsx+?tour=1— the coached playthrough.mycelium-frontend/src/test/fake-event-source.ts— an in-browser EventSource stand-in.MYCELIUM_UI_MOCK=1/pnpm dev:mockalready renders the whole UI with no backend.The one real gap
GitHub Pages is pure static (no Node server), but the mock currently lives server-side, inside three route handlers:
src/app/api/[...path]/route.tssrc/app/api/events/stream/route.tssrc/app/api/rooms/[name]/messages/stream/route.tsRoute handlers can't exist in a static export, so the mock has to move into the browser. The mock logic already returns web-standard
Response/ReadableStream, so this is a retarget, not a rewrite.Tasks
window.fetch→ the existinghandleMock, andwindow.EventSource→ drivemockStreamthrough the fake-event-source. Reuse the existing fixtures verbatim.output: "export",images.unoptimized,basePath/assetPrefixfor the Pages subpath) switched by env, leaving theoutput: "standalone"Docker path untouched.generateStaticParamson/room/[name]to pre-render the demo room(s); gate the three API route handlers out of the export build (the shim means the browser never calls them).next build→ uploadout/viaactions/deploy-pages./room/sprint-plan?tour=1) so the playthrough auto-starts.Notes
Scoped to
mycelium-frontend/+ a CI workflow. Low risk: new build target + a browser shim over existing fixtures; the real app / Docker path is unaffected. Rough estimate: a half-day spike to a working PoC. The fiddly parts are static-export quirks (dynamic routes, image optimization, basePath), not architecture.