fix(hydra-gates): two legitimate patterns the gates were blind to (planix)

[rubenvdlinde]

The gap

gate-30/gate-53's deepLink correspondence check resolved urlTemplates against pages[].route and nothing else. That is the complete route inventory for a manifest-driven app — and empty for an app that renders a hand-written SPA.

planix was the first app to trip it: five perfectly valid deepLinks, five FAILs, and the only way to pass would have been to declare pages[] the manifest runtime then tries to render — i.e. break the app to please the gate. Its manifest says so in as many words: "planix renders no manifest-driven UI, so there is deliberately no menu/pages".

Same family as the pageTemplates gap (#542) and the AppHost-detector gap: the first user of a legitimate pattern finds the checker's blind spot.

The fix

discoverRouterRoutes() reads the app's src/router/ table, consulted only when pages[] is empty — manifest-driven apps take the identical path they did before. Parsing is deliberately shallow (a path: string literal in a file that looks like a router); anything cleverer would be a JS evaluator. A dynamically-built route is simply not discovered, which lands on the WARN path rather than a false FAIL.

With no inventory of any kind (no pages, no parseable router) the finding degrades to WARN: absence of evidence is not evidence of a broken link.

Evidence — the check can still fail

Both new fixtures carry the same router table, so the pass/fail difference is the deepLink target alone; the assertions cannot be satisfied by the check silently doing nothing.

control	result
router-routes/ — deepLinks match router routes	passes, 0 deeplink-route findings
router-routes-broken/ — one deepLink (/invoices/{uuid}) the router does not declare	fails, exactly 1 error at /deepLinks/1, message names src/router
no pages[] and no parseable router	WARN, exit 0
regression: manifest-driven app (hrmq, 109 pages)	unchanged — same findings as before
planix (the reporter)	5 FAILs → 0

node scripts/lib/test_check_manifest_crossref.js — all assertions PASSED, including the four added here.

🤖 Generated with Claude Code

[rubenvdlinde]

Second commit: gate-14 AppHost detector

Same failure class, same reporter. The AppHost detector required AppHost\Bootstrap and Bootstrap::register( in one file — one of two legitimate spellings of ADR-040 adoption.

planix wires the same generics itself, and it must: Bootstrap::register() also runs registerServices(), which aliases the leaf's Service\SettingsService to the engine's AppHostSettingsService. An app that ships its own SettingsService then hands its own SettingsController the engine class.

I reproduced this rather than reasoned about it. Attempting the "canonical" one-call refactor on planix produced, on every settings request:

TypeError: OCA\Planix\Controller\SettingsController::__construct():
Argument #2 ($settingsService) must be of type OCA\Planix\Service\SettingsService,
OCA\OpenRegister\AppHost\Service\AppHostSettingsService given

The refactor was reverted; the app is healthy again. Registering the controllers and not the services is the only shape that works there — it is adoption, spelled the long way.

Evidence

New fixture apphost-hand-rolled/ asserts both directions from one fixture, so the exemption cannot widen into "this app registers services, therefore absences are fine":

assertion	result
four AppHost slugs (dashboard/health/metrics/preferences) recognised as served	not reported
gadget#run — not an AppHost slug, controller genuinely absent	still FAILS
full gate-5/gate-14 control-pair suite	47/47 pass (was 41/41 before these fixtures)
planix, real repo	gate-14 FAIL(6) → PASS; gate-53 FAIL(5) → PASS

Only gate-65 (coding-standard) still fails on planix, and that is cleared by ConductionNL/planninq#333.