Commit graph

5 commits

Author SHA1 Message Date
Doxa Maps
be0a9efecf Token gates follow the auto engine: no token ships, and an explicit engine beats an available token
The build config no longer bakes a Mapbox token, and the default engine is 'auto' (Mapbox only when a
token is available). Two gates still assumed the old contract.

- check:nested-token: with the build config's token empty (the shipped default), no leaf and no bundle
  may carry a pk. token, and every leaf must carry the runtime engine ladder (EXPLICIT / HAS_TOKEN),
  so with no token it draws MapLibre, keyless. A builder who bakes their own token gets the original
  check. Fails on the pre-rebuild tree, which still has baked tokens.
- check:provider-switch: the Mapbox baseline is now ?provider=mapbox with a fake host token (its
  requests are aborted, never sent); the switch run adds ?provider=maplibre to the same token (an
  explicit engine must win); a third run requires the no-token default to make no Mapbox requests.
2026-09-26 03:37:53 +00:00
doxa-maps-88655c70
44ef31b2c6 Tooling reads the tree's name from the build config, in one place
The output tree's name has always been configurable (vite.doxa-maps-build-config.json "name"),
but 61 tooling files ignored it and hardcoded 'doxa-maps' (181 literals), so a rename would have
moved the build while the gates kept reading the old folder.

- internal/_tree-name.mjs reads it once (validated as one URL-safe path segment; falls back to the
  historical name) and exports TREE_NAME / TREE_NAME_RE; `node internal/_tree-name.mjs` prints it
  for shell scripts.
- A codemod rewrote 171 literals in internal/ to TREE_NAME; the regex literals, messages with
  backticks, atomic-public-swap.sh (fails loudly if the name cannot be read), build-lock.sh and
  vite.config.js (its duplicate readMfeName is gone) were done by hand.
- The name is unchanged: old and new tooling produce all 1408 files under public/ byte for byte.
  Code lines still naming the tree in internal/ + vite.config.js: 2, both intended (the helper's
  fallback, the private-repo-name pattern in public-hygiene-check).

This renames nothing visible; the eventual rename becomes a one-line config change.
2026-09-25 16:25:22 +00:00
doxa-maps-88655c70
1ddfde6b6b Make the two gates say where the tree name came from
Last tick I fixed a dead config read in check-composite-srcs and
check-nested-token, and logged the lesson as an anti-pattern whose advice was:
make the successful path observable — print what was READ, not just what was
used. I did not take my own advice, so this applies it.

Both gates printed "checked against public/doxa-maps/" whether the name came
from the build config or from the hardcoded fallback. Those two states were
indistinguishable in the output, which is precisely why a permanently-failing
read survived unnoticed: nobody was ever going to rename the tree, so the only
thing that could have exposed it was the output, and the output said nothing.

They now print the source. A green run reads "(tree name from
vite.doxa-maps-build-config.json)"; with the read broken it reads "(tree name
from built-in default (build config unreadable))". Negative-tested by pointing
the read at a nonexistent filename and confirming the line changes, then
restoring and confirming it changes back.

Also corrects a comment I got wrong yesterday. The note explaining the bug said
the gate "said vite.doxa-maps-build-config.json — the pre-rename project name",
which is the NEW name; my sed had rewritten the string inside the prose that
described the OLD one. It now names vite.1040-maps-build-config.json, which is
what was actually there. A correction note that misstates what it corrects is
worse than none, because the next reader takes it as the record.

Six gates pass.
2026-09-23 11:29:05 +00:00
doxa-maps-88655c70
0235b75394 Read the build config that exists, so two gates stop passing by coincidence
check-composite-srcs and check-nested-token-delivery both resolve the output
tree name from the build config, with a comment explaining why the fallback
matters: "Defaulting silently would make this gate check a directory the build
never writes."

Both named vite.1040-maps-build-config.json — the pre-rename project name. That
file does not exist. So the try ALWAYS threw, the catch ALWAYS fired, and the
tree name was ALWAYS the hardcoded default. The read was dead code, and the
gates have been correct only because the default happens to equal the config's
current name, which really is "doxa-maps".

The comment described an intent the code had stopped delivering, which is the
part worth fixing rather than the string. Rename the tree in the build config
and both gates would have walked public/doxa-maps while the build wrote
somewhere else, then SKIPped with "an absent tree is not evidence either way" —
silent, delayed, and the exact outcome that comment exists to prevent.

Proved the read now runs rather than assuming it: parsing
vite.doxa-maps-build-config.json succeeds and yields name "doxa-maps". Then
negative-tested by renaming the tree in the config — the gate now FOLLOWS it and
reports "SKIP — no built tree at public/renamed-tree-probe/", where before it
would have checked the wrong directory and reported PASS. Config restored,
re-verified green.

Seven gates pass, including both repaired ones.

Found by scanning _qa-cycle/CLAUDE.md, the oldest unread doc in the ideation
sweep (2026-07-12) and an inheritor's entry point. It carried the same stale
filename twice, once under the heading "Build config — ONE file", followed by
"Edit it, run bun run build, done" — pointing a reader at a file that is not
there. Corrected in that file too. A third occurrence sits inside a DONE card in
03-deployment-cycle describing a past state; that is a historical record and is
deliberately left alone.
2026-09-23 11:24:11 +00:00
doxa-maps
70df4f00f6 Gate that every shipped leaf carries its own map token
Some checks are pending
build-gate / build (push) Waiting to run
A cap-5 shell nests its children as iframes, and window.MAP_TOKEN does not cross
an iframe boundary — each frame is its own window. A nested map cannot inherit
the parent's token, so it works only because the child leaf carries its own baked
copy. Proven in a browser: all thirteen nested frames in the cap-5 shell hold a
real token, including a map two levels deep. That was a one-off run; this makes
it standing.

The existing smokes cannot catch this. Both inject window.MAP_TOKEN with
addInitScript before the page runs, which is right for what they test but means
the test supplies the thing under test. A user opening a shipped leaf has nothing
injecting a token for them.

Also asserts the reverse: no token may be compiled into a .js bundle. Bundles are
cached, SRI-pinned and reused across hosts, so a token baked into one cannot be
rotated without a rebuild and leaks into every embed.

Reads the built manifest rather than walking directories, so it checks the set
that actually ships. Counted 43 leaves, matching an independent filesystem count.
Negative-tested both directions: stripping a leaf's token and planting one in a
bundle each fail with the artifact named.
2026-09-22 07:56:34 +00:00