The cache spectrum, chosen on purpose: in-process snapshots, SQLite, the edge's own cache, and a global read-cheap config pushed to the edge in seconds; offered to apps #1138

From the owner: "Cloudflare has a cache that is like a whole dollar to write to but it's global in seconds with super cheap reads. That kind of dynamic caching is what we need, the whole spectrum, intelligently used. A sync engine could bring this together but it's probably still useful to have an edge like that — like the Vercel edge, which is the backend for their flags SDK."

The forge already stands on part of the spectrum: fragments carry etag and data-etag, the edge in front caches public pages, SQLite is the derived store. What is missing is the rung for small, read-everywhere, change-rarely data — flags, settings, the manifest, an app's config — and a deliberate choice, per kind of data, of which rung it lives on.

Done looks like:

• [ ] A config store for small read-mostly values: versioned, one write produces one new snapshot id; every forge process holds the current snapshot in memory and refreshes on a bus event within a second; reads are a map lookup. Writes are rare and say who and why (the decision ledger).
• [ ] An edge rung: the snapshot is published to the edge in front (Cloudflare KV or Workers assets where the forge runs behind Cloudflare; a signed static file at a stable URL where it does not), so the edge and apps read flags and config without touching the forge; publication within seconds of a write, and the snapshot id in every response header so a stale edge is visible.
• [ ] The spectrum, written down: which data lives in-process, which in SQLite, which on the edge, which in git; Cache-Control and ETag set by one helper per kind, never by hand on a route; the usage counter records cache hits by rung so the choice can be checked against reality.
• [ ] Apps get the same store through the forge token: GET /api/v1/apps/:slug/config with the snapshot id, and the same edge publication for their own flags.
• [ ] Tests: a write is visible to a second process within a second; the edge file carries the new id after publish; a stale-id response is detected; the per-kind helper sets the headers the table says.

Files I expect: src/core/config.ts (new), src/cloud/edge.ts (publication), src/http/respond.ts (one cache-header helper), docs/CACHE.md (the spectrum), the app template.

Parked by the crew: the check stayed red through 2 automatic tries (pull #1368 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check failed ("the board's forge strip > an admin reads All fine; a stuck run becomes a linked sentence; a non-admin sees nothing") and the decider saw no point in another try (pull #1496 closed).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check stayed red through 2 automatic tries (pull #1368 closed)
2. the check failed ("the board's forge strip > an admin reads All fine; a stuck run becomes a linked sentence; a non-admin sees nothing") and the decider saw no point in another try (pull #1496 closed)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Deferred behind the Later gate (#595): the cache spectrum waits behind /flow and Boards. Boards' usage and machine series (#1563, #1565) will show which reads are hot, which is the evidence needed to choose a cache rung.