fix(gate-100): the rule is the offer at step 2, not the id it is called

[rubenvdlinde]

ADR-111 rule 4 says the configuration wizard opens by saying what the app is, then offers the data that lets a reader see it work. It does not say what that step must be called. Gate-100 matched one literal id, demo-data, so an app that satisfied the rule under a better name was judged as having no offer at all.

Measured on decidiq (2026-08-30)

It stopped planting 334 unchosen objects on install (decidiq#1024) and now ships four example sets an operator picks between (municipality, association, company board, works council) plus the ADR-111 generated dataset, all in one choice step at index 1 named example-set.

Under the id-only rule that read as:

WARN: setup declares no "demo-data" step (ADR-111 rule 4) … Build the demo data, then add the step.

The remedy it printed — declare a step calling install-demo-data — would have replaced a working chooser with the single un-chosen dataset the app had deliberately stopped shipping. A gate that advises undoing the fix is worse than no gate.

What changes

The accepted ids become the ones that mean "the offer": demo-data for an app offering one dataset, example-set for one offering several. A future name for the same step belongs in that set, not in a finding.

Nothing else moves:

• step 1 must still be welcome
• the offer must still be at index 1
• an app with no setup block is still not this gate's business
• a missing offer still WARNs rather than blocks

Verification

All five existing acceptance arms still pass, plus a sixth that fails without this change:

ARM 1  gate-100 FAILs a setup whose first step is not welcome            ok
ARM 2  gate-100 PASSes when welcome is followed by demo-data             ok
ARM 5  does not block an app that merely lacks demo data                 ok
       records the missing step as a WARN in its log                     ok
ARM 6  accepts an example-set offer at step 2                            ok
       records no warning for an example-set offer                       ok
ARM 3  editing a manifest with no setup block reports no finding         ok
ARM 4  a commit touching no manifest reports no finding                  ok

The ordering rule is unweakened: a manifest whose offer sits at index 2 still FAILs, now saying The app HAS the offer, at index 2.

Note on releases, separate from this PR

conduction/hydra-gates v1.10.0 was tagged 2026-08-27 18:18. The vendored manifest schema refresh to 2.26.0 landed at 22:35 the same day, four hours later, and 51 commits have landed on main since the tag, 21 of them touching hydra-gates. So every app's gates currently run against a schema that predates the flow page type, which fails gates 22 and 53 on decidiq and on any app using that page type. This PR does not cut that release; flagging it because the fix is already on main and only a release carries it.

🤖 Generated with Claude Code