History

Doxa Maps d0939c0492 library: one embedScript for the app shells, replacing four private copies DEDUP-AUDIT.md (measured today: 253 files, 31 cross-plugin duplicate clusters, 622 duplicated lines) ranks this tenth by raw cost and first by suitability. It is the only cluster where the copies are identical in code, close over nothing, and sit in two plugins with one owner between them. loadScriptOnce (13 lines) and whenTagDefined (11) were byte-identical between doxa-maps-spa and plugin-studio. deriveTreeBase (9) differed by ONE COMMENT LINE and not one character of code -- drift in the documentation of a shared function, which is its own argument for having one copy. They are one concern, not three: load a bundle's script once, wait for its custom element to register, and work out the tree base to load it from. That is what a capability-5 app shell does to nest another plugin, and both plugins here ARE the capability-5 shells. Any future shell needs the same three. Verbatim move: no parameterisation, no behaviour change, callers import instead of declaring. The comments travel with the code because each records a measurement -- particularly the one explaining why onload is not a usable success signal for a dev-server ES module. ONE BEHAVIOUR CHANGE, AND IT IS AN IMPROVEMENT: the _loaded cache is now shared. Two shells on one page previously kept separate caches and each loaded the same bundle; the second now reuses the first's promise. deriveTreeBase reads document.currentScript, so it is only valid AT MODULE EVALUATION TIME. The call sites did not move -- both entries still call it at module top level -- and the library file documents the constraint, because a later call silently returns '' and every nested bundle URL would break. Verified: both bundles build; each built file contains all three functions exactly once and still derives currentScript; check:sri, check:series-isolation, check:studio-rail and check:capability-derived all PASS. library/utils/embedScript.js is the build owner's under rule 5B. The plugin-designs and public/ changes are in the same commit because they import it -- landing them apart breaks the build in between.	2026-09-28 07:07:33 +00:00
..
dx-maps	library: one embedScript for the app shells, replacing four private copies	2026-09-28 07:07:33 +00:00
README.md	Rebuild the consumers main left stale (build owner, README rule 5)	2026-09-28 06:55:58 +00:00

Doxa Maps d0939c0492 library: one embedScript for the app shells, replacing four private copies

DEDUP-AUDIT.md (measured today: 253 files, 31 cross-plugin duplicate clusters,
622 duplicated lines) ranks this tenth by raw cost and first by suitability. It
is the only cluster where the copies are identical in code, close over nothing,
and sit in two plugins with one owner between them.

loadScriptOnce (13 lines) and whenTagDefined (11) were byte-identical between
doxa-maps-spa and plugin-studio. deriveTreeBase (9) differed by ONE COMMENT LINE
and not one character of code -- drift in the documentation of a shared function,
which is its own argument for having one copy.

They are one concern, not three: load a bundle's script once, wait for its custom
element to register, and work out the tree base to load it from. That is what a
capability-5 app shell does to nest another plugin, and both plugins here ARE the
capability-5 shells. Any future shell needs the same three.

Verbatim move: no parameterisation, no behaviour change, callers import instead
of declaring. The comments travel with the code because each records a
measurement -- particularly the one explaining why onload is not a usable success
signal for a dev-server ES module.

ONE BEHAVIOUR CHANGE, AND IT IS AN IMPROVEMENT: the _loaded cache is now shared.
Two shells on one page previously kept separate caches and each loaded the same
bundle; the second now reuses the first's promise.

deriveTreeBase reads document.currentScript, so it is only valid AT MODULE
EVALUATION TIME. The call sites did not move -- both entries still call it at
module top level -- and the library file documents the constraint, because a
later call silently returns '' and every nested bundle URL would break.

Verified: both bundles build; each built file contains all three functions
exactly once and still derives currentScript; check:sri, check:series-isolation,
check:studio-rail and check:capability-derived all PASS.

library/utils/embedScript.js is the build owner's under rule 5B. The
plugin-designs and public/ changes are in the same commit because they import it
-- landing them apart breaks the build in between.

2026-09-28 07:07:33 +00:00

dx-maps

library: one embedScript for the app shells, replacing four private copies

2026-09-28 07:07:33 +00:00

README.md

Rebuild the consumers main left stale (build owner, README rule 5)

2026-09-28 06:55:58 +00:00

README.md

public/ — the built output

This folder is GENERATED by bun run build; do not edit it by hand. It holds exactly one thing:

dx-maps/ — the output folder: 24 plugin bundles and 36 pages, self-contained. Copy this one folder to any web host (or open it from disk) and it works.
- dx-maps/index.html — the front page: the Plugin Studio, every plugin in one place.
- dx-maps/<plugin>/<plugin>.js — a plugin's bundle (a custom element; load it with a <script> tag).
- dx-maps/<plugin>/<page>/index.html — a ready-made page for one plugin view (embed it in an <iframe>).
- dx-maps/manifest.json — every plugin, page and embed snippet, machine-readable.
- dx-maps/assets/ — the data, fonts and images the plugins fetch at runtime.

The folder's name comes from name in vite.doxa-maps-build-config.json. Sources live in plugin-designs/, library/ and data/; rm -rf public/ && bun run build recreates all of this.