Surface sparks in the web explorer

The spark

Can we add the Sparks structure to the web app within brain

What I think you're reaching for

The explorer already renders every other vault primitive — entities, concepts, questions, sources, mechanisms, calibration — but sparks are still text-only, living in index.md. The bet: sparks earn their value on re-entry, and a read-surface that shows them by status (and, eventually, by what new research now connects to them) is exactly the "pull on the good threads" half of the idea. Capture is solved; this is making the return visible.

Connections (held loosely)

• 2026-06-07-brain-as-add-capture-layer — this is the Resurface leg of that vision made concrete. That spark said the real ADHD compensation isn't better capture, it's better return; a web surface is where return becomes a place you can actually look.
• PRINCIPLES — compounding by composition: a spark is an existing primitive and the explorer already has the rendering seam (it reads through @brain/vault and renders markdown + wikilinks + backlinks). Adding sparks is exposing a verb you already have, not building a new one.
• Loosely — the read-only apps/web explorer and the sparks index.md re-entry surface are the two concrete homes this touches (both code/files, not wiki pages, so no forced link): the web view would be the richer, filterable version of that static index.

Where this could go

• A /sparks browser mirroring the existing entity/concept/question/source browsers — read through @brain/vault, grouped by status (seed · developing · graduated · dormant · dropped), with heat and created as sort keys. The cheapest, highest-value first cut; it just turns index.md into a live view.
• Live connections, not static text. Render a spark's "Connections (held loosely)" wikilinks as navigable links and compute backlinks — which threads, questions, or graduated pages ended up pointing back at it. The spark becomes a node in the same graph the rest of the explorer already walks.
• Recency/heat-weighted resurfacing — the harder, higher-value version: surface dormant sparks when newly-ingested wiki content connects to them, so the app pulls a forgotten thread back to you instead of waiting for you to remember it. That's the actual prosthetic.
• A schema question for @brain/vault: sparks are exempt from the "every claim cites a source" rule, so the reader needs a first-class spark type the explorer renders without expecting sources or claim-backlinks. Worth deciding before the browser, since it shapes the type.

A possible next move

This is a build task, not a research thread — it doesn't need /thread-create. The clean first move is a focused apps/web session adding the read-only /sparks browser (parse via @brain/vault, group by status), and defer resurfacing to a second pass. Or leave it to marinate until the next time you're in the web code.