gate-101 and a correct app-level invariant are in direct conflict, and the app cannot satisfy both.
The conflict
gate-101 requires every schema in a touched register descriptor to carry at least three demo objects. generate_mock_register.py:1284:
FAIL dossiq: register 'dossiq' schema 'dossiqIntegration' has 0 demo object(s), needs 3 (ADR-111 rule 1).
Regenerate with `python3 vendor/conduction/hydra-gates/scripts/lib/generate_mock_register.py .`
dossiq requires that schema to carry exactly zero. lib/Settings/register.d/96-integrations.json seeds the twelve dossiqIntegration rows with stable slugs (integration-brp). ImportHandler upserts on (register, schema, slug), so machine-slugged demo rows never collapse into them: an instance with demo data installed gets two BRP rows and two ZGW rows.
That is not hypothetical. It has already broken integrations-page.spec.ts twice, and both failures read as product defects rather than duplicate data:
offers no settings link where there is no section to open — Playwright strict-mode violation, two rows matching /BRP/iclaims nothing it has not checked — read status: error for StUF from a demo row asserting "Circuit open on Gemeente Zuid", a connection failure nobody had measured, which is the exact claim that test exists to forbid
dossiq guards it with MockRegisterHasNoSeededCatalogueTest. I hit this today: I added the three rows to satisfy gate-101, and that test failed. Both checks are right.
Why the gate's own advice makes it worse
The failure message says to regenerate. Running generate_mock_register.py on dossiq produces a green gate and destroys 36 hand-written demo objects, replacing curated data with placeholders:
checklist-zonnehof-fundering -> case-location-case-location-1-1
bewijs-amsterdamseweg-schets -> casesupplierinvoice-casesupplierinvoice-1-1
Measured: 2933 insertions, 18011 deletions to add three rows. The gate goes green either way, which is what makes it dangerous advice.
Proposed rule
A schema is exempt from ADR-111 rule 1 when the app already ships objects for it in its own seed data. The schema has data on install; it simply does not come from the mock descriptor, which is the actual intent of the rule.
That is general rather than dossiq-specific, and it can only ever make the gate less strict, so it cannot newly break another app. Mechanically the checker would scan lib/Settings/register.d/*.json (and the equivalents) for objects of that (register, schema) pair before counting the mock descriptor's.
An explicit opt-out would also work (x-hydra-gates: {demoData: seeded} on the schema), but it puts the burden on every app to remember, and this one was discovered by breaking a test rather than by reading a rule.
Current impact
gate-101 fails on any dossiq PR that touches lib/Settings/dossiq_register.json, because the gate is diff-scoped and touching the descriptor is what makes it run. It has been failing since ConductionNL/dossiq#2323 and is not caused by that change. Dossiq is not adding the duplicate rows, so it stays red until this is resolved.
gate-101 and a correct app-level invariant are in direct conflict, and the app cannot satisfy both.
The conflict
gate-101 requires every schema in a touched register descriptor to carry at least three demo objects.
generate_mock_register.py:1284:dossiq requires that schema to carry exactly zero.
lib/Settings/register.d/96-integrations.jsonseeds the twelvedossiqIntegrationrows with stable slugs (integration-brp).ImportHandlerupserts on(register, schema, slug), so machine-slugged demo rows never collapse into them: an instance with demo data installed gets two BRP rows and two ZGW rows.That is not hypothetical. It has already broken
integrations-page.spec.tstwice, and both failures read as product defects rather than duplicate data:offers no settings link where there is no section to open— Playwright strict-mode violation, two rows matching/BRP/iclaims nothing it has not checked— readstatus: errorfor StUF from a demo row asserting "Circuit open on Gemeente Zuid", a connection failure nobody had measured, which is the exact claim that test exists to forbiddossiq guards it with
MockRegisterHasNoSeededCatalogueTest. I hit this today: I added the three rows to satisfy gate-101, and that test failed. Both checks are right.Why the gate's own advice makes it worse
The failure message says to regenerate. Running
generate_mock_register.pyon dossiq produces a green gate and destroys 36 hand-written demo objects, replacing curated data with placeholders:Measured: 2933 insertions, 18011 deletions to add three rows. The gate goes green either way, which is what makes it dangerous advice.
Proposed rule
A schema is exempt from ADR-111 rule 1 when the app already ships objects for it in its own seed data. The schema has data on install; it simply does not come from the mock descriptor, which is the actual intent of the rule.
That is general rather than dossiq-specific, and it can only ever make the gate less strict, so it cannot newly break another app. Mechanically the checker would scan
lib/Settings/register.d/*.json(and the equivalents) for objects of that(register, schema)pair before counting the mock descriptor's.An explicit opt-out would also work (
x-hydra-gates: {demoData: seeded}on the schema), but it puts the burden on every app to remember, and this one was discovered by breaking a test rather than by reading a rule.Current impact
gate-101 fails on any dossiq PR that touches
lib/Settings/dossiq_register.json, because the gate is diff-scoped and touching the descriptor is what makes it run. It has been failing since ConductionNL/dossiq#2323 and is not caused by that change. Dossiq is not adding the duplicate rows, so it stays red until this is resolved.