bc1b035f6d
golden-path-check is the capability-1 element that IS the develop-a-plugin-and-see-it-live walk: authored from the documented 3-file minimum, built, published, and then reading the manifest it shipped beside. It was named in two reference docs and NOT in the golden-path document itself, so the one artifact that proves the path worked was missing from the page that teaches the path. Step 5 ended with "Done = the live site shows it, not a green build", which is the right instruction and leaves the reader with no reference point — they can only check their own plugin, and if it fails they cannot tell a mistake in their plugin from a broken platform. The self-test separates those two questions. Verified on the live catalog before writing it down, as an inheritor would: HTTP 200, zero console errors, and it reports 19 bundles, 28 profiles, 28 of 28 self-describing, this plugin listed = yes. Cross-checked by two independent measurements rather than trusting the element — the live bundle is byte-identical to local at 73,693 bytes, and fetching the live manifest directly gives the same 19 and 28 from a different path. The note also states what the self-test does NOT claim, because that is the way it could mislead. Its four rows are questions about the catalog's SHAPE, so it stays green even when bundle CONTENT is stale — my own fixes this flight changed bytes and not counts, and it reports identically on both trees. Freshness is check:catalog-currency's job, which compares every live bundle's bytes against the build. The doc now tells the reader to run both and says which answers what. The URL printed in the doc was fetched before committing: 200. Three separate gates this flight were failing because they navigated to a URL nobody had checked, and a doc that sends a reader to a 404 is the same defect with a slower feedback loop. |
||
|---|---|---|
| .. | ||
| architecture | ||
| assets | ||
| contributing | ||
| readme-images | ||
| screenshots | ||
| CONTRIBUTING.md | ||
| develop-a-plugin-and-see-it-live.md | ||
| explanation.md | ||
| how-to.md | ||
| README-embed-example.md | ||
| README-longform.md | ||
| README-SECTION-3-cli-commands.md | ||
| README.md | ||
| reference-capability-exemplars.md | ||
| reference-library-index.md | ||
| reference.md | ||
| slide-deck-outline.md | ||
| tutorial.md | ||
| why.md | ||
documentation/ — pick your path
"what is this?" "teach me" "how do I …?" "look it up" "all the detail"
│ │ │ │ │
why.md ──────────► tutorial.md ────► how-to.md ────► reference.md ───► architecture/
(2 min, 1 diagram) (first map) (task recipes) (tables) (contracts)
- why.md — the problem and the "map islands" idea. Start here.
- tutorial.md — build your first map, no jargon.
- how-to.md — recipes: embed, iframe, SPA, colors, CDN, mobile, tokens.
- reference.md — config fields, build scripts, the
profile-configcontract. - explanation.md — the model in 15 lines.
- architecture/ — the deep end: full contracts, the per-file catalog.
- README-embed-example.md — the drop-in README used when this bundler is embedded inside a host repo.
Nothing on the simple path is longer than a few minutes; everything complex lives in
architecture/, linked from where you'd need it.