Files
platform/todo/backburner/resurrect-projects-apps.md
T
pastilhasandClaude Fable 5 887f702c05 todo: resurrect projects/apps, with the archaeology attached
the idea is not settled. the card exists so the history is not dug out
twice: user apps were born 2026-02-27 as a publishing system that made a
personal app a first-class workspace panel, /projects was its authoring
surface, and both went a day apart at the end of july — 1440 deletions.

the part worth knowing before rebuilding: the app registry used to be
mutable at runtime, registerApp keyed on email/slug, and the note left
where it stood argues well against it. the plugin system solved the same
problem afterwards by generating at build time, so the first question is
whether a user app is just a plugin with a different author.

nothing on disk was ever touched.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-25 03:58:56 +00:00

102 lines
5.0 KiB
Markdown

---
id: backburner/resurrect-projects-apps
title: "Resurrect Projects/Apps"
theme: backburner
status: open
created: 2026-08-25
date_source: stated
order: 3
---
**Resurrect Projects/Apps.** The idea is not settled — this card exists so the archaeology is not done
twice. Everything below was read out of git on 2026-08-25.
## What existed
Two features, one cluster, removed a day apart.
**User apps — born `fd4d77a3`, 2026-02-27:** *"user app publishing system — build, serve, and use
personal apps in workspace panels."* You wrote an app, published it, and it appeared as a **first-class
workspace panel** beside Terminal and Chat. `/api/apps` (298 lines) built and served it; `/api/app-serve`
served the built output; `/api/dev-server` (314 lines) plus a websocket proxy ran it live; a shared
`html-rewrite.ts` made both viewable through the platform's own origin.
**`/projects` — the authoring surface.** A list screen and a project screen, a 244-line list panel, a
**612-line preview panel**, a publish dialog. Projects had a *type*, a *template*, and
`hasBackend` / `hasAuth` flags — so it was scaffolding as well as hosting. A `projects` table, and
`proj-meta` / `proj-layout` / `proj-terminals` / `proj-host-terminals` branches in the dashboards
endpoint.
## Why each went
**`/projects`, `5a1e3d7e`, 2026-07-30.** Not a design failure — a scheduling one:
> Being retired, so it is deleted rather than fixed — it had both defects dashboards just had (edit
> dropping `?selected=`, an abandoned edit following you onto the next item) and repairing them was
> work for something on its way out.
**Apps, `188b45c1`, 2026-07-31.** The rest of the cluster, **1,440 deletions**: `/api/apps`,
`/api/app-serve`, `/api/dev-server` and its websocket proxy, `html-rewrite`, the Preview panel, the
UserApp panel and header, `useUserApps`, `/settings/apps`, `getUserProjectsDir`, `getUserAppsDir`, the
`ProjectType` and `ProjectDefinition` types, and the `dev-server` websocket provider.
**Nothing on disk was touched.** Both commits say so explicitly. Whatever was under `Projects/` is still
there.
## The interesting part: the App Registry used to be dynamic
This is the piece worth understanding before rebuilding anything. Alongside the compiled-in apps:
```tsx
const { registerApp } = useAppRegistry(apps);
const { apps: userApps, email } = useUserApps();
registerApp(`${email}/${app.slug}`, {
name: app.name,
icon: resolveIcon(app.icon),
component: createUserAppPanel(app.slug),
header: createUserAppHeader(app.name, resolveIcon(app.icon)),
});
```
Keyed per user, with the icon resolved from a **string name** at runtime (`utils/resolve-icon.ts`, 116
lines — also deleted).
**That capability is gone, and the argument against it is good.** The note left where it stood:
> there is no `registerApp` any more because nothing ever called one, and a registry that can be added
> to at runtime is a registry whose contents depend on what has mounted so far.
Today `seedAppRegistry` writes the registry once, before anything renders, from 17 static meta lists.
**So the constraint to design around, rather than re-litigate: user apps need to reach the registry
without making it mutable at runtime.** The plugin system — which arrived *after* this was deleted —
already solved a version of exactly this by generating `Plugins.gen` at build time and mounting plugin
routers at boot. Any resurrection should start by asking whether a user app is just a plugin with a
different author, rather than a second mechanism beside it.
## What survived, and is still working
**`dev-proxy`** (`/api/dev-proxy/5173/…` → `127.0.0.1:5173`). The reasoning in its header is worth
reading before rebuilding the dev-server half — it explains why neither obvious approach works:
`http://localhost:5173` resolves on the *viewer's* machine, and `http://<server>:5173` is mixed content
inside an https page. So the bytes must arrive over the platform's own origin. It costs no certificate,
no proxy-host entry, and no open port, and it lets a dev server stay bound to loopback.
Its stated limit: the app believes it is at `/` and is not. Absolute paths are rewritten on the way out,
which covers Bun's dev server and ordinary relative assets, but not an app that builds URLs in ways the
rewrite cannot see.
## Open questions, if this is picked up
1. **Is a user app a plugin?** The app store, the plugin manifest, `ownerOnly`, sidecars and
`Plugins.gen` all landed after this was removed. Rebuilding a parallel mechanism would be the
expensive mistake.
2. **What is the scaffolding half worth?** Templates, `hasBackend`, `hasAuth` — the agent can now write
an app from a prompt, which may make a template picker the least valuable part of what was lost.
3. **Multi-user changes the shape.** The old key was `${email}/${slug}`, written when the platform was
effectively single-user. Whose apps appear in whose dock is now a permissions question, not a
namespacing one.
4. **Does it need its own theme?** It is in `backburner` because the idea is not settled. If it becomes
real it is bigger than one card.