syncScrollZoomToHost decided whether Mapbox should keep scrollZoom by sampling
the layout at 0, 1200 and 4000ms and then never asking again. That is a race,
not a sync: the cap-5 dashboard tab lazy-mounts on activation, so at every one
of those instants the scrollport ancestor had not reached its final height. The
map kept scrollZoom enabled and ate the wheel. Wheeling over the map moved the
grid 300px; wheeling below it moved 2611px. The cursor is over the map, so the
people-groups grid under the dashboard was unreachable.
The condition is layout-dependent, so observe layout instead of guessing when it
settles: a ResizeObserver on the map container, the scrollport that owns the page
scroll, and body, plus a resize listener. Every event that can flip the answer now
re-asks it.
verify-shell-scroll already measured this. It computed movedByMap for the gesture
over the map, then asserted only on movedTotal, which sums in a second gesture
below the map -- so it reported PASS at 2611px while the real gesture moved 300px.
It now asserts on the number it was built to measure. Worth remembering as its own
failure family: a gate that measures the right thing and grades a different
variable, which fails honestly but never on the condition it exists for.
The archived gallery resolved ASSETS as BASE + 'assets' — this PAGE's own
directory. That was correct only while the gallery WAS the root page, where the
two coincide. Since it moved to /__gallery it asked for /__gallery/assets/...
Measured on the built tree with the page at /__gallery/:
/__gallery/assets/vendor/vue/vue.global.prod.js ... 404
/doxa-maps/assets/vendor/vue/vue.global.prod.js ... 200
Every leaf page already agrees where assets live: a leaf at
/<tree>/<bundle>/<profile>/ bakes assetsBase "../../assets" -> /<tree>/assets.
So anchor to the tree root, which TREE_URL already names.
This degraded QUIETLY rather than blanking, which is why it outlived the move:
loadVue() falls back to the jsDelivr CDN, so the page kept working while
silently losing the portable / offline / no-CDN property the vendored copy
exists to provide. After the fix the built page loads Vue from
/doxa-maps/assets/vendor/vue/ and reports zero 4xx/5xx.
TREE_URL moves above ASSETS because ASSETS now depends on it; both are `var`,
so the old order would have yielded the string "undefined/assets" rather than
an error. Its explanatory comment moves with the declaration.
The dev server passes assetsBaseUrl explicitly, so this is the built-tree half
of the fix its comment already documents for dev.
A `position:fixed; inset:0` scrim is only viewport-relative while nothing
establishes a containing block for fixed descendants. VerticalTabsLayout sets
`contain:layout` on .vtl-content, so inside the cap-5 studio every such scrim
covered the CONTENT PANE instead. Measured at a 1280x900 viewport:
.dt-scrim / .modal-scrim / .lt-overlay ... 1024x793 @ (256,107)
captured by div.vtl-content [contain:layout]
256 is the rail width, 107 the header height — left uncovered and CLICKABLE
behind what still looks like a modal. The fix (library/utils/viewportScrim.js)
measures the real origin and subtracts it, rather than removing the shell's
contain, which is load-bearing for a different reason.
This adds the gate that keeps it fixed. A source grep cannot: every one of these
scrims greps as a correct inset:0, because the variable is the ANCESTOR, not the
declaration — and which ancestors exist depends on the HOST, not the component.
check:scrim-viewport:self-test reverts each scrim to plain inset:0 and requires
EVERY case to fail; a gate that cannot fail is worse than no gate, and this one
measures a property that looks fine in a screenshot either way. The self-test
also surfaced that .lt-overlay is captured TWICE — div.lt-root [transform] as
well — collapsing it to 233x30 rather than merely to the pane.
SemanticTreeLegend's .stl-export-backdrop is fixed the same way but marked as
NOT verified through the UI: it sits behind SHOW_EXPORT_BUTTON = false, so the
menu that owns it cannot be opened. Correct-if-enabled, not observed.
Five lanes had 465 insertions across 18 files sitting uncommitted, some for
15 minutes. That is the state that silently lost the shell-scroll fix earlier
today: a verified fix existed only in the working tree, a second agent's edit
to the same file overwrote it, and the reverted version got committed and
described as the fix.
Nothing here is finished and no card is being closed on it. This is a
snapshot so the work survives an overwrite, taken at a moment when every file
had been quiet 15s or more, so no agent was mid-write.
Verified coherent before staging rather than committed blind: template-literal,
mjs-parse, sfc-parse, no-orphan-gates, kpi-unit, composite-reg, script-flags,
quoted-scripts and backlog-status all PASS. check:synced-css fails on
PeopleGroupDetail.vue and doxa-simple-map.vue only -- the same two files and
the same counts as before the swarm started, both untouched by any agent, both
already carded.
Two untracked files included because both are load-bearing: internal/
check-facet-one-field.mjs is wired into package.json with a self-test, and
library/utils/viewportScrim.js is imported by DataTable, SemanticTreeLegend
and PosterDialog -- a shared helper for the modal-scrim fix rather than six
copies of the same workaround.
Two different agents broke the build the same way within ten minutes: a
backtick inside a // comment sitting inside a template literal of generated
browser JS. The backtick closes the literal and the parser reads prose as code,
so it fails hundreds of lines from the edit -- one break reported at :386 with
the cause in a comment above it.
check:template-literal did not catch either, and that is not a bug in it: it
scans backticks inside CSS comments, the shadow-CSS shape. A // comment inside
a generated-JS literal is a different grammar. Proven by controlled negative
test -- injecting a backticked term into a // comment in generate-tree.mjs, a
file that gate explicitly lists, left it reporting PASS while node --check
failed immediately. The rule was right; the implementation covered a narrower
case than the rule stated.
Nothing parsed the 70 .mjs build scripts. check:parse covers inline scripts in
built pages and check:sfc-parse covers .vue, so the scripts the build is made
of were the one unchecked surface.
Uses the parser rather than a wider regex. A backtick is legal inside a string,
a regex, a nested template, or a comment inside a template; a pattern precise
enough to catch the bad case would false-positive on the legal ones, and a gate
that cries wolf gets skipped -- worse than the gap. The parser already knows
all of that.
Parses, never imports: these scripts read files, spawn browsers and hit the
network at import time, and a syntax check must have no side effects.
Runs as build step 2, beside check:template-literal, so a broken script fails
in a second rather than after minutes of compilation.
The failure message points at the real cause rather than the reported line, and
tells the reader to grep for every instance in one pass -- node --check reports
only the first, and each rebuild to surface the next costs minutes, which is
how one of today's breaks was being fixed one at a time.
Negative-tested side by side: exit 1 with "SyntaxError: Unexpected identifier
'TREE'" at generate-tree.mjs:369, while check:template-literal reports PASS on
the same file in the same moment.
The gate could not pass on this box and it was not the product's fault. Three
defects, all in the gate:
Its default --url was localhost:5174 while `bun run dev` is `bun x vite`,
whose default is 5173, so the documented invocation failed with "is `bun x
vite` running?" against a dev server that WAS running.
It required a WebGL canvas on every map profile. This VPS has no GPU, so all
34 elements failed from an assertion the environment could never satisfy --
a gate that cannot pass, as useless as one that cannot fail, and it buried the
real finding underneath.
Removing that assertion was not enough: the map library still logs "Failed to
initialize WebGL", and every console error counted as a failure, so the same
environmental limit came back through another door.
Now 31 of 34 pass. GL noise is FILTERED, not suppressed -- the count prints on
every run ("3 WebGL page error(s) FILTERED — this box has no GPU"), because a
silent filter is indistinguishable from a gate that never looked, and this repo
has already shipped one of those. Anything that is not the GL-init message
still fails. EXPECT_CANVAS=1 on a machine with real GL filters nothing and
restores the canvas assertion.
Data 404s are now their own finding rather than a clause appended to the canvas
message, where they were only visible through a failure that was itself
environmental -- and where a map that painted fine would have hidden them.
That surfaced the real defect the gate exists to find: the archived /__gallery
page fetches a bare relative manifest.json, so it resolves against / instead of
/__gallery/. The studio at / is correct; it carries tree-base="/__plugin-gallery"
and smoke:studio passes in ~5s. Fixed separately.
Also corrects a usage comment that still said 5174 after the default changed --
the exact line someone copies verbatim.
Cards were being written with explanatory statuses -- "done — reconciled: …",
"blocked — Steps 1+3 DONE and re-verified…", "ready". The prose is valuable
and several of those strings carry measurements, but it made status
unqueryable: every count used status !== 'done', which is FALSE for
"done — reconciled: …", so finished cards kept counting as open.
Measured across the three phase backlogs: 130 of 395 cards carried a prose
status and 71 of those were already done. Reported open was 176 against a real
105. The P0 figure quoted every tick was 21; it was 14.
That is worse than an off-by-N because a backlog is a decision instrument. It
answers "what is left" and "is the rest human-gated", and inflating the open
count makes a drained board look stalled, which pushes toward manufacturing
work instead of holding honestly. The error also hides: every card reads
correctly to a human, because the prose says exactly what is true. Only the
aggregate is wrong.
Migration preserved every explanation in fields.status_detail -- 130 of 130,
none lost -- and normalised status to the enum. Six cards whose head-word was
not in the map were left alone and resolved by hand against reality rather than
guessed, since a wrong normalisation hides a card instead of counting it.
The gate does not require status_detail. Most cards need no explanation and
demanding one turns a real check into paperwork satisfied with filler.
Negative-tested: restoring one prose status fails by name and prints it.
The Driver named the sequence: Big Picture, UPG-100, Prayer Progress, Gospel
Resources. Tab 1 is the landing surface -- the first thing anyone opening the
product SPA sees, and the opening step of the onboarding ramp. That ordering
was held only by the order of entries in NAV_MODEL and by comments explaining
why, with nothing failing if someone reordered them.
Easy to break silently: NAV_MODEL is also where sections, badges and
narrow-screen flags live, so it gets edited for reasons unrelated to ordering,
and a row moved while adding a badge produces no error and a SPA that still
works. It just opens somewhere else. That file's own comments record Big
Picture once being painted twice in the rail, from a one-row section that
re-declared a row below.
Asserts the RENDERED rail, not the source array. Parsing NAV_MODEL was the
first attempt and returned an empty list -- the entries do not carry the id
shape I assumed, and a regex over a 300-line commented array is guesswork
either way. The rail is what the user sees and what the Driver described, and
a source parse could pass while a rendering bug shows something else.
Order, not membership: checking that four names are present would pass on a
rail that opens on Gospel Resources. Prefix-matched so a row may carry its
subtitle.
Negative-tested: swapping the first two expected entries fails by name and
prints want versus got for every row.
The gate caught one of the four things a baked composite must repeat. The
other three were left to luck, and one of them had already gone wrong: the
composite shipped mapbox-gl-rtl-text zero times while both leaf bundles
shipped it once, so Arabic, Hebrew and Persian labels rendered reversed in the
cap-5 shell. Arab World has 99 rows and Persian-Median 49, which makes that a
wrong name rather than a style issue.
Now compares createPinia, createAppI18n and installRtlTextPlugin alongside the
registerStrategies keys: whatever the leaf entry calls, the composite that
bakes its .vue must call too.
provide('profileModules') is deliberately excluded. It is the fifth side
effect and the only one that throws when missing, and it is also the only one
safe to omit, because a baked composite does not use ProfileLoader. Requiring
it would fail a composite that is correct. The rule is "repeat what silently
disappears", not "repeat everything".
Matched as calls -- name followed by "(" with the import line for that name
stripped first -- because an indexOf on the bare name reads the import instead
of the invocation, which is the trap that made the strategy parser return
nothing and report a confident empty result.
Negative-tested twice, and the first case reproduces the real historical bug:
removing installRtlTextPlugin() fails by name and prints both sides' lists;
removing createPinia() does the same. Pairs compared went 1 to 2.
.filter-dropdown was flex:1 1 160px with min-width:160px and max-width:240px
-- a range, not a width -- so flex-grow renegotiated the moment the selected
label appeared. The row grew 960 to 1294px and triggers reached 240px.
Not cosmetic. The selections row with Clear All sits underneath the filters,
so a filter that grows on selection re-flows the row below it and the band
stops being a fixed block. The stable width is what lets the centred stack
hold still.
Independently reproduced before gating rather than taken from the agent
report: 168px across all six triggers, identical after selecting the longest
option in each. The negative test then reproduced the broken widths
[240,240,240,184,171,219] -- the same array the original report cited, which
confirms that measurement was real.
Asserts the observable outcome, not the CSS. A grep for --dx-filter-w would
pass while a missing min-width:0 on the label still pushed the box open: as a
flex item without it the label is floored at min-content and refuses to
ellipsise. Both halves are needed, so the gate measures the width.
Selecting the LONGEST option is load-bearing. A short option fits inside the
old range too, so a probe that clicks the first option passes on a build that
still has the bug.
Two hosts, and an unmeasurable host fails rather than skips -- three defects
this week were invisible standalone and appeared only in the shell.
Negative-tested: restoring the flex range fails both hosts by name, naming the
before and after arrays and the total growth.
Sixteen source files from five agents, all verified against source gates
before commit: template-literal, sfc-parse, kpi-unit, composite-reg,
facet-cascade, one-palette, script-flags, no-public-binds, no-orphan-gates and
quoted-scripts all pass. public-hygiene reports 0 findings.
Colour. The choropleth ramp is now derived by interpolating the product's own
tokens (surface #f3f3f1 to accent #92b195) rather than adding a sixth grey, and
that fixes a pincer the earlier research had not named: on the old grey-to-black
ramp the navy dot and the white ring failed at OPPOSITE ends, so no fixed pin
colour could win. Worst-case dot contrast moves 1.13 to 7.29. Second-order
breaks fixed with it -- the country outline would have measured 1.08-1.82 as
white on the pale fill, so it is #6d766e at 2.59-4.34, and the legend swatch
border.
Religion colours no longer key by array index. colorFor takes no index at all;
colour comes from the registry by facet plus value. All 31 distinct live
religion labels now match the map, 0 mismatches. Tree-rail grey rows 142 to 0
against the live 2,107-row API.
Cascade. Clearing a parent facet now clears its descendants, in the selection
bus rather than in any component, because every clear path already funnels
through setFilter/clearFilters -- a component fix would have fixed one button
and left four. The hierarchy is derived from config.facetRail[].drill, so it
cannot drift from the tiers the rail renders. Place turned out to be three deep
(region, block, country), not two.
Rails. Tree rows wrapping 18/66 to 3/66; the tree rail is now the wider of the
two at 296 vs 264, with the map cell unchanged because both pairs sum to 560.
Also lands the shell scroll fix and the facet-cascade gate with its committed
fixture -- 73 sampled rows, no network, so the assertion that reproduces the
empty map runs on a fresh clone instead of silently skipping.
In the cap-5 shell the Region donut, country bars and Place tree rendered
entirely grey while the identical build was correct standalone. A cap-4
composite imports the sibling component directly
(dashboard-plus-grid.vue:18), which takes the COMPONENT and skips
research-dashboard/index.js -- the file that actually assembles the bundle:
Pinia, i18n, colour strategies, customElements.define. The composite
re-declares all of it by hand, a manual copy nothing keeps in sync, which is
how the strategies leg was lost. That file already documented this bypass for
i18n and fixed only that one leg.
It is silent by construction: getColorStrategy() falls back to language-family
for an unregistered mode instead of throwing, so the result is a plausible
wrong picture -- grey charts that read as a data problem rather than a wiring
one. Found by reading an image; every number passed.
The gate compares the leaf's registerStrategies keys against the composite's.
A composite registering nothing while its leaf registers nothing is fine: the
rule is about drift between two lists meant to agree. big-picture also bakes a
sibling and registers zero strategies, and that is correct -- neither it nor
people-groups-grid references colorFor, getColorStrategy or mapbox. A first
pass called it a second instance; measuring usage showed it is not one.
Four rounds to get working, each a real bug found by testing the wrong half:
- pre-stripping comments deleted 2,953 of 4,102 characters of
research-dashboard/index.js, including the call being searched for, so the
gate claimed "no composite bakes a sibling that registers strategies" --
a confident claim about the repo derived from parsing nothing. Not stripping
is also correct: the call is located by requiring "(", so a mention in prose
cannot match.
- indexOf('registerStrategies') found the IMPORT line first and brace-matched
its own braces.
- a non-greedy brace regex stopped at the first inner "}" and the key pattern
missed quoted path keys.
Every fix was verified against dashboard-plus-grid, which survives stripping,
and never against research-dashboard, which does not. A comparison needs both
halves asserted before any fix is believed.
Negative-tested: dropping doxa-region from the composite fails by name and
prints both lists.
A shared component declares the same selectors twice: once in a scoped <style>
block for when it is imported as a Vue child, and once in a useShadowStyles
literal for when it is mounted inside a shadow root, where scoped CSS does not
reach. Both are load-bearing and the standing rule is that they stay
identical. Nothing enforced it.
library/components/PeopleGroupDetail.vue disagreed with itself on eleven
properties, and the shadow copy is a coherent DARK theme under a light-only
rule: .detail-header background white vs #16213e, .image-container #f5f5f5 vs
#2d2d4e, and .people-group-name color #333 vs #fff -- white text, legible only
on the dark background, so fixing the background alone would make the name
invisible. Six importers; the dark hex reached four shipped bundles.
It was invisible because it is a two-host bug: the component looks correct in
whichever host you tested. Fourth of that shape this week.
Three findings while building this, each of which had the gate reporting
success about something it never compared:
- a loose /<style[^>]*>/ matched the words "<style scoped>" inside a JS
comment 43 characters before useShadowStyles( in SemanticTreeLegend.vue, then
ran to the next real </style> and swallowed the whole shadow literal into the
<style> text. Both maps read the same bytes, so that file could not fail on
any of its 51 apparent shared selectors. Anchored to line start, since an SFC
block starts at column 0. That also raised PeopleGroupDetail 8 -> 11.
- assigning m[sel] = props let the last declaration win, discarding every
property that appeared only in a base rule when a media query redeclared the
selector. Rules are merged now.
- comparing raw text reported comma-spacing as divergence: 5 findings for
doxa-simple-map of which 2 were formatting. Compared as property maps, so the
rule is about meaning.
Negative-tested by change rather than by exit code, which with pre-existing
failures proves nothing: fixing .detail-header takes PeopleGroupDetail 11 -> 10
and restoring it returns 11.
Standalone rather than in build:unlocked, because it fails on live defects
today.
The dashboard rendered "99% % UNREACHED" and "1% ADOPTED %". kpiText returns
k.value unchanged for kind:'pct' and that value already carries its percent
sign, while the labels in dashboard.config.js carried a second one.
Each half is correct alone. A label reading '% unreached' is a reasonable
label; a formatter returning a ready-formatted percentage is a reasonable
formatter. Only the composition is wrong, and neither file mentions the other,
which is why it was found by reading the rendered screenshot rather than by
reading either source.
check:kpi-unit asserts no kind:'pct' label contains a '%'. The value owns the
unit because it is produced by the formatter that knows the number; the label
says what is being measured.
Parses the config as text rather than importing it -- the research-dashboard
module graph reaches library/colors/_registry.js, which uses import.meta.glob
and throws under plain node. Text parsing keeps it hermetic enough for
build:unlocked. Comments are stripped first, because the config now documents
this defect right above the fixed line and a naive scan fails on the
explanation of the fix.
It also fails when it finds no pct entries at all, rather than printing a
green PASS: if the config is refactored so the parse stops matching, silence
would read as success forever.
Negative-tested: restoring either label fails by name with exit 1.
This gate's own header records fixing exactly this bug once already: it walked
plugin-designs one level deep, missed the shadow-CSS components under
<bundle>/src/components/, reported PASS, and the build broke with a misleading
Babel error far from the edit. The note ends "it was wrong about WHICH files,
which is the more dangerous failure because it reports success."
The other half of the list was never fixed. library/ stayed a hand-written
list of three .vue paths while 17 files under library/ carry a
useShadowStyles literal. Injecting a backtick into a CSS comment in
library/components/hints/PinHint.vue left this gate green AND check:sfc-parse
green -- so the documented failure mode was reachable in 36 unscanned files.
Now walks library/ the same way plugin-designs is walked: 47 files scanned
becomes 84. The injected backtick fails by name at PinHint.vue:236.
A hand-maintained file list decays silently, because nothing announces that a
new file should have been added to it. That is what makes this worse than a
wrong rule -- the rule was always right and was simply never shown the file.
The status line also hardcoded "+ 4 library/internal" and so under-reported
coverage while sounding precise. Counts are now derived from the file list.
Noting a wrong turn for the next reader: the first negative test used a plain
string replace and hit the first match at line 140, which is outside any
literal, so the gate correctly ignored it and I briefly read that as the fix
not working. PinHint has two literals; the target was in the second.
The dashboard aggregations module used to hold two private palettes the map
had never seen, and picked chart colours with
CATEGORICAL[i % CATEGORICAL.length]. Two failures came out of that: near-miss
regions (Africa #e74c3c in a chart, #ff2e2e on the map) and religion coloured
by array index. No religion key existed in the private table, so every
religion fell through to its position in a list sorted BY COUNT -- and counts
move when you cross-filter, so a religion changed colour as you filtered.
Islam and Hinduism swapped, Buddhism and Christianity swapped.
That is already fixed: both private palettes deleted, every hex now read from
the same strategy modules the map paints with. But the fix is a deletion plus
a convention, and nothing enforces a convention. The next person adding a
facet writes a lookup table because it is the obvious thing to do, and the
divergence returns with no error and no crash -- just two surfaces disagreeing
about what blue means.
Reads the BUILT bundles rather than the source because the registry discovers
strategies with import.meta.glob, which plain node cannot evaluate. That makes
it a test of the glob too: if the registry ever silently discovers nothing,
the bundles lose the palette and this fails, where a source-only check would
still pass.
Comments are stripped before scanning, because both consumer files describe
this defect at length in their headers and a naive scan matches the
documentation of the fix -- the same self-reference that made two gates report
on their own prose this week.
Negative-tested three ways: a reintroduced private palette, an [i % len]
lookup, and corrupting four of ten religion hexes in a built bundle, which
fails as a partial palette and names the missing hexes.
verify-shell-scroll.mjs was written and negative-tested, then left with no
package.json entry and no importer, so nothing could ever run it again. It
also defaulted to localhost:8899 -- an ad-hoc port from an earlier session --
so it failed with ERR_CONNECTION_REFUSED for anyone else and read as a broken
gate rather than a missing server. Now check:shell-scroll, defaulting to
BASE_URL or 127.0.0.1:4173 like every other browser gate, and listed in
verify-browser-all's GATES array.
check:no-orphan-gates fails any gate-shaped file in internal/ that nothing can
invoke. The repo carded this once already; it recurs because writing a gate
and registering one are separate acts and only the first feels like work.
Not every unreferenced file is a lost gate, so the rule is not "everything
must be wired": theme-flash-probe is a dated diagnostic for two fixed bugs,
worth keeping as a reproduction recipe. It now carries an @one-shot tag saying
so, which makes the author state which kind of thing they wrote.
Two self-referential defects in the first version of that gate, both from
reading evidence out of documentation:
- it cited theme-flash-probe.mjs in its own header as an example, then grepped
for importers, found itself, and declared the orphan reachable. The gate
written to catch orphans made an orphan pass by mentioning it. A gate must
never be its own witness, so it now excludes its own file.
- it matched @one-shot anywhere in prose, including its own paragraph
explaining the tag, and reported "1 tagged" when nothing had been tagged.
The tag must now be a marker at line start.
Negative-tested: removing check:shell-scroll from package.json fails by name.
The scroll fix itself is NOT done. contain:layout and .vtl-host overflow-y are
confirmed in the built bundle, and a real wheel gesture still moves the grid
0px with 2586px mounted and unreachable. The gate is what caught that; the
diff looked correct.
bun run appends arguments to the command string, so a script ending in an
inline # comment swallows them. Proven side by side:
"node argtest.mjs" bun run _t1 --self-test -> ["--self-test"]
"node argtest.mjs # a comment" bun run _t2 --self-test -> []
No error, no warning: the script runs in its default mode and exits 0.
Four scripts advertised a flag that could never arrive, and two of them are
--self-test. A --self-test IS the proof that a gate can fail, so running
check:facet-cascade --self-test printed the ordinary PASS and exited 0 --
which reads as "the negative test passed" when the negative test never ran.
The gate itself was fine: invoking node directly reverted the cascade and
failed 13 assertions correctly, including the real symptom (switching to
another language family leaves the map empty because the orphan still
filters). Only the invocation was broken, so the mechanism that certifies a
gate can fail was a gate certifying itself.
Each flag now gets a dedicated entry that hardcodes it, which also makes the
mode discoverable in bun run output instead of documented only in prose
nobody greps.
check:script-flags fails any script whose comment advertises a flag the
command cannot receive. Negative-tested: adding such a comment back fails by
name with exit 1.
serve used --bind 0.0.0.0, and every browser gate starts it. A live audit of
this box found nineteen publicly bound http.server processes on 4820-4970 plus
one on 8899, all rooted at public/, with curl to the box's public IP returning
200. Nobody noticed, because a listening socket produces no output and no
failure: the gate it served passed and the process outlived it.
The standing rule "keep the box closed" lived in prose. The behaviour lived in
a flag. Prose cannot constrain a flag, so the rule was never violated by a
decision -- only by a default nobody re-read.
Loopback is sufficient for the whole suite: verify-browser-all,
check:a11y-button-names, check:nav-reachable and smoke:share-all already
default to 127.0.0.1. The wide bind bought nothing.
check:no-public-binds fails any script with an explicit all-interface bind, a
bare vite --host, or an http.server with no --bind at all (its default is also
all interfaces, just less visible in review). It reads the repo rather than the
machine's live sockets, because a socket check would pass or fail on whatever
happens to be running and could not be fixed by editing anything here.
Negative-tested: restoring --bind 0.0.0.0 fails by name with exit 1.
The menu is position:fixed with viewport coordinates. That resolves against the
viewport only while nothing establishes a containing block for fixed
descendants. VerticalTabsLayout -- the cap-5 shell that hosts every plugin as a
tab -- sets contain:layout paint on .vtl-content, inside .vtl-main{left:256px}.
Measured at 1600x900, same component, two hosts:
standalone research-dashboard ...... dLeft=0 dTop=4 six of six
inside plugin-studio dashboard tab . dLeft=256 dTop=111 every one
256 is the rail width and 111 the header height. Reported as the menu landing
"in a random spot further down to the right"; it was never random.
An earlier probe measured six triggers at four viewport widths and passed, so
the card was closed while the bug was still there. Every number was accurate.
They were answers about a surface the user never looks at -- widening across
more widths could not have found it, because the variable was the host.
Fix measures the containing block instead of assuming it: a fixed probe at 0,0
inserted in the menu's own parent reports the origin the menu resolves against.
When nothing captures, that origin is 0,0 and the standalone numbers are
unchanged bit-for-bit.
Not fixed by dropping contain from the layout: it is load-bearing there,
stopping a rail collapse from reflowing a heavy mounted map.
check:fixed-anchoring measures both hosts and treats an unmeasured host as a
failure. Negative-tested: reverting the subtraction fails the studio host with
dLeft=256 while standalone still passes -- it fails exactly where the old probe
passed.
Also cards a second symptom of the same cause, not yet fixed: fixed-position
modal scrims written inset:0 stretch to the content pane instead of the
viewport, leaving the rail clickable behind an open modal.
A card was closed on an agent measurement while the bug was still visible to
the Driver, and the card had no field in which that disagreement could live.
The board said done and the product said broken, and nothing in the data knew.
Adds fields.verification (agent|human|both) plus verification_kind
(visual|state) and a conflict flag, back-filled across 179 closed cards, and
a gate that refuses an anonymous close.
The gate does not require human sign-off. Gating the board on human review was
tried and it stalled. What it forbids is losing the distinction, so the
question "which of these did a human actually look at?" stays answerable.
The visual/state split encodes the asymmetry the Driver named: human
verification is more reliable on visual bugs, agent verification on non-visual
ones. A headless probe reads geometry, not perception -- it can measure a menu
at dTop=4 and still be blind to it feeling wrong. So a visual card closed on
agent evidence is a hypothesis; a state card closed on agent evidence is a
result. The counts are reported separately.
Negative-tested three ways: stripping a tag, claiming human verification with
no quote, and marking a conflict card done each exit 1 by name.
The export carried its provenance comment above the header, and every spreadsheet
importer treats line one as the header — so the scope sentence became the column names
and the real header became the first data row. A single-column line above a sixty-eight
column table is what "glitched" looks like on screen.
Three other explanations were plausible and all three are wrong, measured before
anything changed: the file is comma-separated, not tab-separated, so the tabs in the
report were terminal rendering rather than bytes; the escaper is genuinely RFC-4180, and
embedded commas, quotes and newlines all survive a strict parser round trip; and
injection-prefixed cells were already neutralised. Only the position was wrong, and
chasing the other three would have produced churn and no fix.
The provenance line moves to the end rather than away. It records which filters produced
the file, which is the difference between a dataset and an anecdote, and a trailing
single-column row lands as one populated cell instead of destroying the column mapping.
The field counter that read line two moved with it — left alone it would have counted
the first data row, usually the same number, so it would have looked right and been
wrong.
A new check parses the export the way a spreadsheet would, which no existing gate did:
forty-six checks and not one read the file. It extracts the shipped escaper rather than
restating the rule, so it cannot agree with itself while the product disagrees.
Negative-tested by putting the comment back on top.
Pins keep their navy but gain a white ring and a radius that shrinks as you zoom out, so
neighbouring dots separate instead of merging into one blue mass. The Driver asked for
rings rather than clustering, explicitly to avoid more logic.
The top header no longer carries selection state. That belongs under the filter toggles,
in the second header, and nowhere else.
The filter menu is anchored to its trigger again. It had been moved to fixed positioning
to escape a scroller that was clipping it out of existence, and viewport coordinates go
stale in ways that put the menu somewhere unrelated to the box that opened it.
A gallery row now carries its identity as an attribute. A Vue key is a reconciliation
hint and is never rendered, so the smoke check read undefined and reported a broken deep
link on a page that works — measured zero occurrences of that attribute in both the
generator and the built page. Asserting on the visible label instead would have coupled
a machine check to display text.
That repaired gate immediately earned its keep: it caught the gallery asking for assets
one directory too deep. The relative asset base was correct while the gallery was the
root page and silently wrong once it moved aside for the studio, and the failure surfaced
as a JSON parse error rather than a 404, because an unknown path answers with HTML.
A bundle can be compiled and present on disk while its profiles never reach the
manifest, and nothing noticed: the leaf floor counts index.html recursively, so one
bundle losing every leaf while another keeps extras stays above the floor; the
embed-target check iterates what the manifest lists, so an omission is invisible to it;
and a bundle count passes too, because one bundle can be swapped for another and the
totals still match. Counting is not covering. The only way to see an omission is to
compare the manifest against the scanner rather than against itself.
The first version of this check cried wolf on its first real run. It reported key-cities
as missing — discovered with four profiles, absent from the manifest, and still absent
after a full rebuild, which made it look persistent and real. It is neither: the build
config gates that bundle by name and generate-tree filters on it, so the bundle is
legitimately discovered and legitimately unpublished. The scanner answers what exists;
the config answers what ships. Asserting the first against the manifest without
consulting the second asserts an invariant that was never true.
That failure mattered more than the bug it was chasing. A gate that reports a deliberate
configuration as a defect gets switched off, and a switched-off gate protects nothing —
so the check now reads the same config the build reads, and names the gated bundles in
its passing output so the exclusion stays visible rather than becoming folklore.
A manifest entry the scanner does not return is reported as a note rather than a
failure: stale build output heals on the next full build, while a missing plugin is
silently absent from the studio for everyone reviewing the product.
Negative-tested: removing any published bundle from the manifest fails with exit 1
naming it; restoring passes; the gated bundle never trips it.
Both shells declared a `title` prop. defineCustomElement maps every prop to an
attribute, and `title` already exists on every HTMLElement as the tooltip, so Vue warned
on every single mount that it would overwrite the native property. Harmless in effect —
nothing here wants a tooltip — but a warning repeated on every mount is where a real
error goes to hide, and this repo has already paid for that once when a thrown setup()
silently removed three buttons behind noise that looked ignorable.
Renaming the prop was safe because nothing outside ever set it: no host passes title=,
no profile-config reads it, and the value is only forwarded to the shared layout, which
is an ordinary Vue component rather than a custom element and so has no collision of its
own. Both shells carried the identical declaration — the same duplicate-implementation
pattern that earlier turned one resolver assumption into two separate outages — so both
were fixed together.
The studio smoke check now samples several tabs instead of only the first, and measures
node depth inside the mounted element rather than counting the slot's children. The old
check read one child for every pane whether the element rendered a full dashboard or
nothing at all, which is the "mounts is not works" trap its own header warns about. It
polls for content rather than sleeping a fixed interval, because a fixed wait either runs
too slow to use on every edit or marks a slow tab broken, and a gate that cries wolf gets
switched off.
Measured after: zero Vue warnings in the browser console.
check:embed-targets was already wired into package.json while the file it runs sat
untracked — so a fresh clone got a script that could not execute. It asserts that every
embed.iframe src in the manifest resolves to a file on disk, which is the load-bearing
check for the iframe deployment method: one of only two of the five that are proven.
That assertion matters more now than it did. The build stopped emitting a chooser page
per bundle, which took the recursive leaf count from sixty-three to forty-four, so the
coarse leaf floor no longer distinguishes "nineteen pages deliberately removed" from
"a partial wipe deleted real leaves". This gate does: it names the missing file and the
manifest path that pointed at it.
Negative-tested: hiding one leaf fails with exit 1 naming both the file and its JSON
path; restoring returns to a clean forty-three.
Checkpointing thirteen files of agent work that were sitting uncommitted while three
agents wrote to a live tree the Driver was watching through hot reload. Uncommitted work
is work at risk, and a tree being edited under an observer oscillates between states that
look like regressions and are really just partial saves.
The second capability-5 shell now mounts its tabs as real elements too, so no iframe
remains in either shell. It was the last holdout: eight tabs, all iframe mode, each
pointing at a hardcoded built-tree leaf that does not exist under the dev server.
The facet rail keeps its shape when a filter narrows it. Selecting one place took the
rail from sixty-six rows to twenty-one — forty-six rows deleted, none dimmed — so the row
a user was about to click vanished under the cursor, which is what "the buttons went
dead" actually was. Rows whose count falls to zero are now re-admitted at their original
slot and depth, dimmed and inert, which also restores the component's own promise to lose
nothing against the tree it replaced.
Expanding a branch and filtering by it are now separate, visible affordances: the whole
row filters, and expand is a real button with its own hit area and label. Rows that were
never clickable are unmistakably inert rather than silently ignored.
Three more facet axes reach the grid — affinity bloc, engagement status and primary
language — each verified to share a field with an existing prop rather than being mapped
on name resemblance. Two derived facets remain unmapped on purpose: they have no matching
row field, and mapping them would filter confidently to the wrong rows.
One commit shipped the requested change and a regression together: a base prefix applied
to an already-rooted URL 404'd all 29 studio tabs, and finding it took 32 minutes. The
root-cause analysis attributes the largest single share of that to there being no gate
that exercises the dev server at all — of 46 gate-ish scripts and 13 browser gates, none
did. The built manifest hands relative refs and the dev manifest hands rooted ones, so a
base-join bug is invisible to every build-time gate and fatal to every developer.
The check finishes in about four seconds against an already-running dev server, which is
the point: the full sweep costs about seventy-five, so it only ever gets run at the end
of a change, which is exactly how a regression rides along unnoticed. It activates one
tab rather than twenty-nine because a single mount already exercises the whole resolver
path — manifest fetch, script resolve, module load, define, mount. If the resolver is
wrong, the first tab fails like all of them.
It asserts the five things that have actually broken: that the root serves the studio and
not a staging page, that the element both mounts and registers, that the tab list is not
empty, that no request failed, and that the activated pane holds real content — because
an element can register and attach while its content never arrives, which is what a
missing API base looks like.
An unreachable dev server exits 2 rather than 1. Conflating "no server" with "broken
product" is how a gate earns a reputation for flakiness and gets switched off.
Negative-tested: removing the tree base makes it fail on the empty tab list, and an
unreachable URL exits 2; restoring returns to green.
The built leaf pages set window.MAP_APP_API_URL; the dev pages set only the Mapbox
token. Every dashboard in dev therefore fell back to a relative /api/people-groups/list,
which Vite answers with SPA-fallback HTML at HTTP 200 — so the fetch "succeeds", the
parse yields nothing, and the facet rail renders zero rows with no console error and no
error card. One studio sweep produced eight such requests. It reads as a broken
component and is really a missing global.
Both dev routes now read the value from the same build config the built leaves use, so
the two surfaces agree by construction rather than through a second hard-coded copy, and
each route resolves the token and the API base from a single config read so they cannot
disagree about their source. Measured after: the research dashboard renders 66 facet
rows and 216 table cells with zero 4xx.
There were THREE staging surfaces, not two. The repo-root index.html was Vite's default
dev entry, and its title was the line that kept reappearing in front of the Driver:
"doxa-maps · Embeddable JAMstack Maps · staging", above a bundle strip that loaded each
chosen map into the page itself. It is archived with its internal/staging.js, not
deleted, and git recorded both as renames so history follows.
Archiving is safe because it was never a build input: rollupOptions.input is built from
per-bundle JS entries, and the root HTML is referenced only on the dev branch. It was
also already unreachable — the dev plugin intercepts /, /index.html, a query-string
root and /__gallery, all measured returning the studio with no staging title before the
move, and measured again after. What remained was a file that would resurface the moment
the middleware changed.
The settled-tree leaf floor drops from 50 to 40 because the architecture changed, not
because the tree got sicker. That floor was set when the build also emitted a chooser
page per bundle; those 19 pages are deliberately gone, which takes a correct tree from
63 leaves to 44. Left at 50 the gate would fail on every correct build, and the cheapest
way to make it green again would be to restore the choosers — so a stale floor does not
protect the tree, it defends the old architecture. The floor still catches the
partial-wipe it was built for, and the load-bearing assertion is now that every
embed.iframe target resolves: 43 checked, 0 missing.
Prefixing a base onto an already-rooted URL 404'd all 29 studio tabs, and no existing
gate could have seen it: the built manifest hands relative refs, so concatenation is
correct there and the assumption is never exercised. Only the dev server hands rooted
refs, so the entire build-time suite passes green while every developer's studio is
broken. A product that has to work on ten laptops cannot be verified by the build alone.
The check discovers every shell that defines a resolve(ref) rather than naming them,
because the two capability-5 shells carried byte-identical implementations and one
latent assumption therefore produced two separate outages that had to be found
separately. A third shell copied from either is now caught on its first run.
It evaluates the shipped function against a stubbed host instead of re-implementing the
rule, so the gate cannot quietly agree with itself while the product disagrees.
Negative-tested: removing the rooted-ref guard fails 4 of 8 cases and reproduces the
exact double-slash path from the outage; restoring it returns to green.
EVERY TAB FAILED TO LOAD. Introducing tree-base for the dev server prefixed it onto
URLs that were already rooted, producing /__plugin-gallery//plugin-designs/<b>/index.js
and a 404 on all 29 tabs. Both capability-5 shells had byte-identical resolve()
implementations, so both carried the same defect; both now return an already-absolute
ref untouched and join through exactly one slash. The built tree hands relative refs
and keeps its base, so this is one rule for both trees rather than a dev-only branch.
THE STUDIO NO LONGER FRAMES ANYTHING. Map elements were nested in iframes pointing at
their standalone leaf pages, to dodge a one-shot customElements.define collision. That
collision cannot occur here: 19 bundles claim 19 distinct tags, none shared, and two map
elements were proven to coexist in one document with the first unaffected by the second.
Every pane now mounts the plugin's real custom element, which is what makes a row both
reviewable and nestable.
Panes keep two lifetimes, and the difference is the WebGL context budget rather than
taste. Light rows stay mounted so switching back is instant and state survives. Map rows
are destroyed on deactivate, because a hidden map holds its GPU context: the browser
caps live contexts, then silently reclaims the OLDEST, so a map visited ten tabs ago
would go blank with no error anywhere. getContext never returns null and contextlost
never fires on the new canvas, which is what makes that failure so hard to attribute.
The dev server serves a leaf route for one element with no chrome, and passes the tree
base to nested shells so they discover the live tree instead of a baked fallback.
THE DEV SERVER LANDED ON THE WRONG PAGE. `bun run dev` served only the staging
gallery at /, and had no route for a bundle leaf, so there was no URL at which the
capability-5 plugin studio could be seen at all. Opening / showed plugins wrapped in
per-bundle frames behind a wall of explanatory prose, which reads as "none of the
elements are working" when in fact the elements were fine and the page was a chooser.
/ now mounts <plugin-studio> directly: a 605-byte host page with no chrome and no
prose, the element filling the viewport, and the Mapbox token baked as the token
ladder's first rung so maps work without anyone appending ?tk=. The gallery is not
deleted — it still generates the built index and is load-bearing for the manifest —
it simply moves to an explicit /__gallery URL and stops being the landing surface.
tree-base is passed explicitly, without which the studio mounts EMPTY. It builds its
tab list by fetching <base>manifest.json and falls back to a path relative to its own
script URL, which in dev resolves to a file that does not exist. The dev server serves
the same manifest-shaped model on its own route, so dev now shows the same tab list as
production: 19 bundles, 30 profiles, five capability groups.
PLUGIN FRAMES SHOWED THE GALLERY. The studio nests map profiles in a lazy iframe
pointed at that profile's leaf page, and dev had no such page, so each frame fell
through to the SPA fallback and rendered / — the gallery, recursively, once per map
tab. A /__leaf/<bundle>/<profile> route now serves the dev equivalent of the built
tree's leaf: one element, its bundle entry, the token, and nothing else.
A backtick in live shadow CSS breaks the build exactly as one in a CSS comment
does, and check:template-literal only reads the comments. Proven both directions
last tick: the planted defect left that gate at pass while the build died with a
Babel stack trace pointing far from the edit.
The card concluded this was not achievable, on good evidence — three lookahead
heuristics were tried and reverted, scoring 98 and then 136 false positives on a
healthy tree, because the real terminator of a template literal is also a
backtick and no window of surrounding characters separates the two. The evidence
was right and the inference one step too strong. No heuristic works is not
nothing works, and the card named the answer in its last line: needs a tokenizer.
A parser does not guess where a literal ends; ending it is what parsing means.
Measured against the same tree the heuristics failed on: zero false positives
across 83 files. Splitting the SFC first means it sees exactly the script text
the build compiles, and using the parser the build reports errors from means its
verdict matches what actually breaks rather than approximating it.
Negative-tested with the exact case the other gate misses: a backtick planted in
live CSS passes check:template-literal and fails this one, naming the file and
the line that was edited rather than a stack trace somewhere else. That line
number is the point — the build was always the backstop, just an unhelpful one.
This gate's own header names the failure it exists to prevent — two artifacts
encoding one fact with nothing forcing agreement, where fixing one copy is not
fixing the fact. It then guarded exactly one artifact.
Measured: planting a claim that doxa-vision-card is the capability 1 exemplar
into documentation/reference.md passed both this gate and the exemplars gate.
That is precisely the error this file was written to catch, sitting one directory
outside its scan. doxa-vision-card ships an instances file with two entries, so
the classifier types it parameterized — capability 2, not 1.
The documentation folder states the tier correctly today, so this is not fixing a
live defect; it closes the hole that would let the same one recur unnoticed in a
second place. Negative-tested: the planted claim that used to pass now fails with
the file named, and removing it returns to green.
The same stale citation also lives in the plugin-designer skill, which is outside
this repo and so beyond any gate here. That half stays a Driver edit; the repo
now holds the checkable half.
I excluded smoke:share from the aggregate two ticks ago and the reason was wrong.
Every clause of it was true — the script takes required arguments, and its
gallery mode does need the vite dev server — but the conclusion did not follow. I
had tried exactly two invocations, bare and --plugin-gallery, and never --url,
which the script's own header documents first. It runs fine against the static
tree: 8 of 8 pass, each Share button reopening the correct custom element with a
live canvas.
That is the same shape I logged as an anti-pattern last tick, now found in my own
work: a not-applicable verdict is more durable than a wrong bug report, because
it closes the question. It cost the suite its highest-consequence surface for two
ticks. A share URL is the one artefact a partner pastes into an email, and it
fails silently.
It runs as smoke:share-all, carrying its own eight --url flags and --browser
chromium, since Firefox headless has no WebGL on this box and the default engine
stops. The eight leaves are the set derived by grepping for ShareButton, not a
guess. The simple-map case is the discriminating one: it shares to a different
leaf than the one opened, so the deep link is really being followed rather than
an SPA fallback rendering something plausible.
Two shell traps on the way. A VAR=x prefix does not apply to $VAR on the same
line, because the shell expands the argument before the assignment scopes to the
command, so the URLs came out with an empty base; deferring through sh -c fixes
it. And a glob in a block comment closed the comment early.
Every map image shipped data floating on an empty navy void — no coastlines, no
borders, no labels. Two cards had this blocked on the Driver adding origins to
the Mapbox token's allow-list, for four ticks.
It did not need the Driver. Measured both directions: a tile request with no
Referer returns 403, the same request with the doxa.life Referer returns 200,
and the style document returns 200 either way, which is why the map still booted
and every gate passed. The shot harness serves from 127.0.0.1 and so sent no
Referer at all. These are doxa.life's own documentation images, generated by its
own repo from its own token; the restriction exists to stop third parties burning
the Driver's quota, and it was blocking the owner.
Route interception looked like the careful way to scope it and silently does not
work — Chromium ignores a referer supplied through route.continue, so tiles still
403'd. Only the context-wide header applies, and that breaks same-origin iframes:
the iframe-host shot went from 187 elements to 15.
So it is opt-in per shot, and the predicate is architectural rather than
anecdotal: any surface that nests content in an iframe opts out. I set it for the
one shot that failed first, then watched both cap-5 shells collapse on the next
run, and generalised. Map leaves get their basemap; shells keep their content.
Verified by reading the images, not the file sizes — a size jump had already
misled me once this tick.
It showed an empty pane reading "Choose an element from the list." The README's
headline image for the highest capability level demonstrated nothing, and every
shot gate passed it, because freshness, distinctness and element counts are all
satisfied by an empty pane. The shot now selects the first rail row before
capturing, so the picture shows what the studio is for: a nested SPA rendering
inside the shell that lists every element by capability. The file went from 167KB
to just over a megabyte, in line with its sibling.
Found by reading the image, the same way the mobile error card was found
yesterday. Reading one picture has now caught two defects that eleven gates
passed.
Add check:shot-fonts. The studio labels each row with a capability emoji, and
this machine has no emoji-capable font, so all 28 rendered as tofu boxes in the
committed PNG. The markup is right and the product is fine in a real browser —
the shot machine could not draw it — so the fix is not to strip the emoji. The
gate asks fontconfig whether this system can render the glyphs the UI actually
uses, and names the font install rather than the markup.
It is deliberately not in build:unlocked: it reports an environment condition
that is currently true here, and a gate that always fails in the build makes the
build useless. Its first version also flagged the star this repo uses as a
comment marker, which every text font renders; the range is now narrowed to the
pictographic planes.
Two composites nested a child by tag and URL without a profile-config. Those
children do not render a component directly — their bundle entry mounts
ProfileLoader, which reads profile-config.profile to choose which view to load.
With none, the element still mounts and still reports its tag, so every
structural check said both children were present, while the loader rendered
"missing or invalid profile-config prop" where the map should be. The grid half
of each page worked, which is how it survived.
Found by reading a regenerated README screenshot, not by any gate. The mobile
screenshot showed an error card and an empty pane; the fixed one shows the real
research map with its data, controls and progress figures.
research-map-plus-grid was mine, shipped that way. stack-demo predates it and had
the same defect against research-dashboard. Both now pass the shape their own
generated leaf pages use, so nested and standalone mounts ask for the same thing.
check:composite-srcs now requires a profile-config on any child whose bundle
mounts ProfileLoader, derived from which entries import it rather than a list.
The first version of that check tested for the word and passed on its own
explanatory comment; it now matches the quoted attribute key, and a negative test
that mutates only the key fails as it should.
Also regenerates three derived artifacts that had drifted behind this flight's
changes: the library index, the capability exemplars table, and all twelve README
screenshots.
All seven browser gates were orphans: each had a script, and not one was invoked
by anything else. They were reachable only by someone who already knew the name
to type, which is exactly the person who does not need the list. This repo has
been bitten by this before — the Gate-1 acceptance test existed, worked, and was
invoked by nothing, so it could never report anything. An orphan gate is worse
than a missing one because it looks like coverage.
The data guards already solved this; verify-all.mjs says it plainly — a guard
nobody runs is documentation. That file has no reference to playwright or to the
built tree. It is the data half. This is the browser half.
Every gate listed here was run before it was listed, following the rule the
earlier audit set: listing a program you have not executed puts unvalidated
entries in the hand-off surface. All six pass, and the aggregate now runs them
end to end: capabilities, embeds, map paint, the Gate-1 chain, accessible names,
and phone navigation.
smoke:share is excluded on purpose and says so. It takes required arguments and
its gallery mode reads a registry only the vite dev server serves, so listing it
would make the suite fail for something that is not a defect.
Preconditions are asserted up front and exit 2, so a missing server reads as a
setup problem rather than six mystery failures.
Yesterday the cap-5 shell shipped unusable on a phone: the rail was an off-canvas
drawer, the toggle lived inside a header the shell does not render, and the only
other control sat inside the drawer itself at x:-244. Every tab but the one that
happened to open was unreachable, with no error and a page that painted fine.
That survived because it is an intersection bug. Header-off is correct, and an
off-canvas mobile drawer is correct; the defect exists only where they overlap.
So this checks the intersection directly — each cap-5 shell as it ships, at a
phone viewport — and asks whether any on-screen control opens the rail.
It then presses that control and requires the rail to arrive. Presence is not
function: a present-but-inert opener is the same dead end wearing a disguise, and
asserting only presence is how the original bug survived a card marked verified.
This is not covered by the accessible-name gate. Neither property implies the
other: the off-canvas button had a perfectly good name while being unreachable,
and reachability is geometry, not markup, so no source grep can answer it.
Negative-tested by re-creating the real bug — removing the floating opener makes
it fail naming that shell, while the header-bearing studio still passes.
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.
The desktop composite pairs the research dashboard with the grid. This is its
mobile sibling: the monolithic 7-tab research map on top, the same grid beneath,
stacked to scroll. Which one a shell shows is an aspect-ratio choice made at the
SPA level, so neither plugin knows about the other and both stay embeddable.
The grid's own search and filters are ON here. The desktop composite turns them
off because the dashboard header owns those controls and drives the grid through
props; the research map has no such header, so switching them off would leave the
grid with no way to be searched at all.
Composes its children by tag and bundle URL rather than importing their .vue
files. Importing the research map directly would bypass its bundle entry, which
is where its three bundle-private colour strategies, its profile registry, its
Pinia and i18n pair and the RTL text plugin are installed — and losing those is a
runtime defect in a green build, because a thrown setup() removes the subtree
with an empty error.
Add check:composite-srcs, which resolves every nested src against the built tree
and asserts every nested tag is registered. A wrong relative depth is a 404, and
the stack layout swallows a failed section on purpose so one broken child cannot
take the whole stack down — which means the cost of that resilience is a silently
empty band. Negative-tested both ways: breaking the depth and renaming a tag each
fail with the file and path named; restoring returns to pass.
deployment/src-tauri/.gitignore listed /target, /gen and Cargo.lock together
with reasoning that fits the first two. /target is 2GB of compiled output and
/gen is emitted by tauri-build on every compile -- both genuinely
regenerated. A lockfile is not build output: it is the RESOLUTION RECORD, the
only artifact that makes cargo build reproducible.
Cargo's rule splits on crate type -- commit for a binary, ignore for a
library -- and cargo metadata reports this crate as kinds=['bin']
(src/main.rs, no lib.rs). Checked with cargo rather than inferred from the
file layout.
The stakes are concrete: Cargo.toml pins nothing tighter than
tauri = { version = "2" }, while the lockfile pins 430 packages. Without it
an inheritor building next month resolves a different dependency tree than
the one that produced the shipped 64 MB binary, and method 5 is already
"built, not shot", so its build must at least be repeatable.
Verified before committing 109KB: cargo metadata --locked --offline succeeds,
so the lockfile is consistent with the manifest, and it contains zero local
paths or credentials.
check:tauri gains a fifth assertion -- Cargo.lock present AND TRACKED.
Tracked-ness is the point: the file sat on disk the whole time and was still
absent from every clone. Negative-tested against the real state, not a
simulation: the gate FAILED naming the file while it was untracked, and
passed once staged.
Makes the cheap half of last tick's P0 automatic. A folder rename had
rewritten three npm package names, so bun install failed in a fresh clone
while everything here passed -- the real packages were already in
node_modules from before the rename, making the breakage invisible to every
build and every gate.
Checks two things, offline, in milliseconds: the declared name resolves under
node_modules/, AND the installed package's own name field equals the declared
key. The first alone catches the capacitor case; the second catches a name
that resolves to a DIFFERENT package, which a path-only check would miss.
Together they detect the corrupted-name class without a network round-trip,
which is what lets it run on every build rather than in a nightly job nobody
watches.
It does not replace the clone test. A gate can only see what is IN the repo;
only a clone sees what the repo fails to do on a clean machine.
Negative-tested four ways: recreating the EXACT P0 (the three
@deployment/capacitor/* names) FAILS naming all three; a name that resolves
to a package whose own name differs FAILS; an absent node_modules SKIPs
honestly rather than passing or failing; an empty dependency list FAILS via
the vacuous guard. Wired into build:unlocked and confirmed running inside a
full build (17 declared, 17 verified, exit 0).
The repo is clean -- git grep over every tracked file returns zero /home/
paths. That is a real hand-off property: a clone works on any machine, which
is what "the path Doxa inherits" requires. But nothing enforced it. Proven by
experiment: a /home/lk10x/... line planted in internal/settled-tree-gate.mjs
passed check:public-hygiene, check:parse AND check:quoted-scripts. The tree
was clean by accident, not by construction.
This is the worst failure shape for a hand-off. An absolute path works
perfectly for whoever wrote it and breaks only on the inheritor's machine, so
no test run by its author can catch it. The sibling ideation tree already
paid that cost: two docs cite a workspace root that no longer exists, so a
reader following them silently finds nothing.
Not a flag on check:public-hygiene, which already detects these patterns but
walks a SERVED tree where node_modules never exists -- pointed at the repo
root it produced 1,427 findings, nearly all from node_modules/.vite. Its
scope is right for its job. This scans `git ls-files`, the set a clone
actually receives, which excludes node_modules and build output with no
ignore list to maintain.
Negative-tested three ways: the exact planted path that beat three other
gates now FAILS with file:line; a /Users/ path in a doc FAILS; a checkout
with too few tracked files FAILS rather than passing vacuously. Wired into
build:unlocked and confirmed running inside a full build (783 files, exit 0).
It then caught its own documentation -- my reference.md row quoted the
literal patterns as examples. Rewrote the example rather than allow-listing
the file, which would have blinded the gate to a real path in the repo's
largest doc.
deepFind returns the FIRST match and stops. Every count-based assertion needs
all of them -- how many rows, anchors, hints, canvases -- and because this
file offered no such helper, each ad-hoc probe hand-rolled its own shadow
walker. Across one session of verification work those produced four false
results:
a naive walker double-visited through nested roots: 48 cards for 24;
a single-level querySelector found 0 anchors where there were 155;
an .rd-row count included a detail panel sharing that class, so a correct
filter read as broken;
a bare "<script" prefix match counted the word scriptUrl in a comment and
flagged a valid file.
Two of those nearly became bug reports against working code. A missing helper
does not stop anyone writing the check; it moves the check somewhere nobody
reviews.
The seen-Set dedupe is the load-bearing part: a node reachable through two
roots must count once, which is the first failure above.
Backward compatible by construction -- the third parameter is APPENDED, so
callbacks taking (deepFind, arg) are untouched. Verified rather than assumed:
a (deepFind, arg) callback still resolves; deepFindAll returns 24 cards with
returned === distinct; share-roundtrip-smoke (a real consumer) still passes;
check:a11y-button-names and check:parse both pass.
The exemplars table was authoritative but ~60 rows, so correcting a wrong
citation still meant reading it and DECIDING which row to quote -- the exact
step where a wrong citation gets re-invented. Added a generated five-row
summary that answers "cite this" per tier by a stated rule, and named the two
known-wrong citations it replaces.
Both live in the /plugin-designer skill, which sits outside this repo and so
cannot be gated from here (a checker pointed at it would pass on this machine
and skip silently everywhere else). Measured: unified-research-dashboard as
the cap-4 reference names a bundle that DOES NOT EXIST -- it became
research-dashboard (cap-3) plus dashboard-plus-grid (cap-4). And
doxa-vision-card as the cap-1 example ships an instances.json with 2
instances, which makes it cap-2 parameterized by the project's own rule.
The first version of the rule picked stack-demo for cap-4. It satisfied the
rule perfectly -- name equals profile, shortest -- and was still the wrong
answer to hand someone, because big-picture is the canonical cap-4 composite
named in the Gate-1 chain. Added a demo/template deprioritisation and
recorded why: a reproducible rule is not automatically a good one, so check
what it actually selects.
All five picks now match the skill's own reference implementations, except
the two that were wrong.
The figure came from a loop that sampled only the first 30 leaf pages of a
41-item set, then got repeated as if measured. An exhaustive grep over
public/doxa-maps gives 41. Fixed here and in the 5x5 spec.
A sampled count that lands in a hand-off doc reads as measured, because a
plausible number invites no scrutiny. Counts stated in docs should come from
an exhaustive query.
Two of smoke's failures were the gate reporting a product decision. The
assertions date from when the root page embedded a live preview. Measured:
public/index.html has four occurrences of "profile-config" and all four are
escaped snippet and glossary text -- the gallery is a capability-sorted
navigation catalog that links to bundles and embeds none.
No coverage is lost, which is the only reason this is safe. The
generated-profile block asserts the same two things against a real leaf page
picked from the manifest, and that surface passes. 21 built leaf pages mount
with a profile-config at load. The shell copies were duplicates aimed at the
one surface that by design satisfies neither. Both counts are still REPORTED
in the shell log line, so a behaviour change stays visible.
My carded recommendation was to re-aim these at plugin-studio. That was
wrong and I checked before acting on it: the cap-5 studio leaf has exactly
one [profile-config] element at load -- its own host -- and zero nested
elements or live iframes. It mounts panes on activation. A load-time
assertion cannot see behaviour that starts on a click.
Negative-tested, after two invalid attempts. Rewriting the bundle src to a
404 makes smoke FAIL exit 1 on "imported no bundle that registered its
element". The first two attempts produced a green PASS for bad reasons -- one
edit never wrote, and the other removed an attribute from a JS-created
element while a bare static one remained -- so the mutation is now asserted
to have landed (before=1, after=0) before the result is believed.
