The atlas of abstractions: the forge as one typed object graph; see each abstraction's lifecycle, merge apps (schema + data), an idea garden for demos, one shell for all apps #6002

Owner, 2026-10-25: "the forge and its apps as a whole… this giant RBAC API surface. I love that and want to lean into it. The audit on the CRUD-L is really cool, but… we could see the lifecycle of abstractions… all the abstractions we have here could also merge, which means merging the schema and the data then dropping the old. Like the cs-engine and cs. Or even a collection of demo apps… the demos weren't for no reason, they were still valuable ideas. A new way to look at the objects in the forge… potentially that could help with the CI batching too." Also: "Vercel had something called micro frontends which let you bring multiple apps into one."

The idea: the forge is one typed object graph behind one RBAC surface.

• Its objects: people, orgs, repos, apps, issues, pulls, runs, flags, settings (#5943), boards (scratchpad), and each app's own data types.
• Every object has the same verbs (create, read, update, delete, list), the same rights rules and the same audit.
• Look at it as a living system: where abstractions are born, used, merged and retired.

Done when (staged):

1. The atlas, read-only. One page per object type (forge types, plus each app's declared schema), showing:

- Born: first commit or first row. - Use: CRUD-L counts per day, from the audit. - Who uses it: apps, routes, MCP tools, other types. - Size: rows and bytes. - Last touched, and its owners.

A whole-forge graph view (types as nodes, references as edges; a scratchpad board is a natural canvas for it). A lifecycle strip per abstraction: born → growing → stable → fading → merged/retired.

1. Merge two apps: a guided, reversible flow. Example: trevato/cs-engine into trevato/cs.

1. Map the schemas: the fields line up, with conflicts listed. 2. Dry-run a migration plan. 3. Copy the data into the target with ids kept as aliases. 4. Redirect routes and API calls. 5. Leave the old app read-only with a tombstone that links to the new home. 6. Drop it after a quiet period, or undo.

1. The idea garden, for demos: fold the many demo apps into one gallery app.

- Each demo becomes an object: its idea, a screenshot, its key code and the issues it inspired. - The demo's repo is archived, but the idea stays findable and forkable. "The demos weren't for no reason."

1. One shell, many apps (the micro-frontends idea): apps mount as modules inside the forge's shell. They share one sign-in, one nav, one settings model (#5943) and one design system (#5817), so the forge plus its apps feels like one product, while each app still deploys on its own.
2. Feed CI: the atlas's ownership map (which files belong to which abstraction or app) becomes the lane key for the merge queue (pipeline program, lever 2). Changes to unrelated abstractions never share a gate.

First pull: the atlas data for the forge's own types (from sqlite_master plus the audit), behind an admin-only page, and a cold-read check: a no-context agent can say what the three busiest and the three fading abstractions are.

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.