App launcher and standalone Gadget use mode

I’ve built a frontend-only prototype that introduces a dedicated Apps launcher and standalone mode for Gadgets, using only existing capabilities in the current Cloudflare OS architecture. The change is substantial (~2,900 insertions, 33 files including tests and plan), so per the CONTRIBUTING guidelines, I’m opening this Issue rather than submitting a PR.

The prototype repurposes / as a launcher surface showing recent apps and apps from pinned workspaces, with a “Create with AI” entry point. The composer moves to /new. The /apps route serves as a catalog of accepted (non-provisional) Gadgets, while /apps/:workspaceId/:workpieceId opens a minimal, focused runtime for a specific workpiece, similar to #fullscreen but canonical and role-gated. Drafts and inaccessible workpieces fail closed. Edit with AI and Activity controls appear only after live authorization confirms owner/build access; cached roles never unlock them. The /outputs route remains as a redirect for compatibility.

This isn’t a rename of Outputs...more so a shift in framing, “Apps” reflects user intent (running something), while “Outputs” reflects system provenance. The goal is to separate use from build without altering backend APIs or deployment models and workspaces/chat remain the builder’s environment.

The implementation reuses existing primitives: AuthenticatedApi.listOutputs(), the /outputs catalog, multi-Gadget workspaces, use-role rendering, and bookmarkable routes. It adds focused tests for catalog behavior, exact routing (including workpiece ID 0), role downgrades, action denial, activity arrival, stale state, localStorage resilience, and cleanup. All tests pass. The prototype has been visually exercised in production (briefly).

Given that the Outputs index landed in August 2026 (commit 69c39d5, MR cloudflare/developers/gadgets!271), and no public issue or PR matches this design, I figured I'd at least open an issue and see if this would be a fit directionally to pair with Outputs

If this is welcome, what’s the appropriate next step? Should this become an issue for internal tracking, a narrower design proposal, or an explicitly invited contribution?

Start by reviewing the existing /outputs catalog, AuthenticatedApi.listOutputs(), multi-Gadget workspaces, use-role rendering, and current route handling. The issue describes a broad prototype rather than a bounded task; a maintainer would need to define the accepted scope and success criteria before implementation can be considered done.

Written by the indexing model from the issue text.