correct Step 6: the SPA auto-discovers a new plugin, no tab edit required

Step 6 told an author that surfacing a plugin means adding a TAB_DEFS entry and
a NAV_MODEL row. That overstates the work. The cap-5 SPA reads the built
manifest at runtime and auto-discovers every bundle that is neither curated nor
on the NOT_EXPERIMENTAL exclusion list, placing it in the Experimental folder
with its label and description from the manifest.

Verified in a browser rather than from the comment that claims it: the rail
rendered 11 rows - 6 curated, then 5 auto-discovered (all-people-groups,
country-posters, demo-map, doxa-vision-card, stack-demo), each carrying the
flask marker.

The manual edit is still documented, reframed as what it actually is: optional
promotion OUT of Experimental into the curated teaching order. Also recorded
the one-row-per-bundle rule and the fail-soft behaviour, and corrected the
closing summary, which omitted the new mount step and implied surfacing was
manual work.

docs/develop-a-plugin-and-see-it-live.md

@@ -133,12 +133,31 @@ Say "proven" ONLY for 1 & 3. Verify at `https://<platform>/plugin-assets/doxa-ma
 
 ## Step 6 — Surface it (make it discoverable)
 
-A plugin reachable only by direct URL isn't really "seen live." To put it where users navigate, add it as a
-**tab in the cap-5 SPA** (`plugin-designs/doxa-maps-spa/` — a `TAB_DEFS` entry + a `NAV_MODEL` row), then
-rebuild + republish. Now it's a tab in the flagship app.
+A plugin reachable only by direct URL isn't really "seen live." Good news: **you usually don't have to do
+anything.**
+
+**It is already surfaced — automatically.** The cap-5 SPA reads the built `manifest.json` at runtime and
+auto-discovers every bundle that is neither already placed in a curated section nor on the small
+`NOT_EXPERIMENTAL` exclusion list (the two shells, the template, and bundles that are nested *inside* another
+tab). Your plugin appears in the collapsible **Experimental** folder at the bottom of the rail, marked 🧪, with
+its label and description read from the manifest. No `TAB_DEFS` entry, no `NAV_MODEL` row, no code edit.
+
+> Verified 2026-09-21 in a browser: the rail rendered **11 rows — 6 curated, then 5 auto-discovered**
+> (`all-people-groups`, `country-posters`, `demo-map`, `doxa-vision-card`, `stack-demo`), each carrying the
+> 🧪 marker. Discovery is fail-soft: if the manifest is unreachable the folder stays empty and the curated
+> rail is unaffected — a discovery failure never takes down the app.
+
+**Promote it to a curated tab (optional).** The curated sections encode a deliberate teaching order, so a
+plugin graduates out of Experimental only when it earns a place in that order. That is the edit Step 6 used to
+describe as mandatory: add a `TAB_DEFS` entry plus a `NAV_MODEL` row in `plugin-designs/doxa-maps-spa/`, then
+rebuild + republish.
+
+**One rail row per BUNDLE, not per profile.** A bundle's profiles (gospel-resources ships four) are alternate
+views reached *inside* the pane. The rail is an onboarding ramp, not an inventory.
 
 ---
 
-**That's the whole path: author in `plugin-designs/` → `bun run build` → publish via the runbook → see it live
-→ surface it as a tab.** Deep dives: [tutorial.md](tutorial.md) · [how-to.md](how-to.md) ·
-[reference.md](reference.md) · [why.md](why.md).
+**That's the whole path: author in `plugin-designs/` → `bun run build` → prove it MOUNTS (`smoke:embeds`) →
+publish via the runbook → see it live → and it surfaces itself in the SPA's Experimental folder.** Only two
+of those six steps are edits you write: the plugin, and the optional promotion out of Experimental. Deep
+dives: [tutorial.md](tutorial.md) · [how-to.md](how-to.md) · [reference.md](reference.md) · [why.md](why.md).