Commit graph

2 commits

Author SHA1 Message Date
Doxa Maps
d314c44043 internal/ keeps the reason and drops the speaker: no gate quotes or cites the Driver
Every reference to the Driver in internal/ is reworded the same way as in
library/: the reason stays, the speaker and the quote go, an open decision
reads "provisional, pending a product decision", and agent names and decision-
sheet rows are dropped. Where a gate printed the word, its message now names
the reviewer or the ruling instead.

Three spots were code, not comments, and changed with their callers:
- the element census's allowlist field `driver` is now `ruling`, in the gate
  and both presets (same validation: match, ruling, date and card required);
- check:i18n-never-translated's DRIVER-GATED marker is DECISION-PENDING, in
  the entries and in the regex that counts them (its output is otherwise
  byte-identical);
- the package.json description of the census says "ruling".

public-hygiene-check keeps its two patterns for the word: they are what keep
it out of the served folder.
2026-09-29 05:26:25 +00:00
Doxa Maps
01a1a7f2ad Twenty-four warnings about an overwrite that was the whole point
The console showed 24 Vue warnings, 8 each for "profileModules", "appI18n"
and "Symbol(pinia)" — "already provides property with key … inherited from its parent
element. It will be overwritten with the new value." They come from a composite mounting
child custom elements: Vue's CE layer lets a child app inherit its parent ELEMENT's
provides, and app.provide() warns on any key already reachable.

ALL THREE MUST BE THE CHILD'S OWN, so neither silencing the warning nor honouring it by
not providing would have been right. profileModules is the plugin's own .vue glob — a
child rendering its parent's components is a different and worse bug. pinia is
per-instance so two embeds on one page never bleed store state. And the i18n instance is
the one ProfileLoader drives from THIS element's profile-config, which is the whole of
the permanently-English fix from earlier today. Inheriting any of the three would be the
regression, not the warning.

So the shadow is made DELIBERATE at the line that does it. provideOwn() writes to the
app's own provides when the key is already reachable and uses the public app.provide()
when it is not, so the ordinary path is untouched. pinia needs the other shape: its
symbol is module-private, so it can only be provided by app.use(), and the key cannot be
named — withoutInheritedProvides() hides the inherited chain for the duration of the
install and restores it in a FINALLY, so a throwing install cannot leave an element
unable to see its parent.

The helpers are split into library/elements/provide-own.js with NO framework import,
because defineMapElement.js imports ProfileLoader.vue and is therefore unloadable by the
gate that proves it right. Third time today that split has been necessary; the gate now
exercises the shipped helpers rather than a copy.

check-provide-shadowing asserts BOTH halves — the child ends up with its own value, AND
the parent's other provides still resolve afterwards — against a Vue-shaped fake app that
warns exactly as runtime-core does. Its control is the naive call, which must still warn.
Negative-tested three ways, including moving the restore out of the finally.

check-element-bootstrap now accepts either spelling and was re-checked for the thing it
actually guards: removing the provide entirely still turns it red.
2026-09-28 17:53:38 +00:00