Pre-existing hydra gate failures on development (6 gates)

[rubenvdlinde]

Surfaced while building clock-weather-widgets (PR #4). None are caused by that change — all findings sit in files it did not touch. Filing so they are not lost.

Gate	Finding
gate-6 orphan-auth	lib/Service/PublicShareContext.php:90 isBearer defined-but-never-called
gate-7 no-admin-idor	lib/Controller/AcknowledgementController.php:94 acknowledge, :152 pending — #[NoAdminRequired] with no auth guard in body
gate-9 semantic-auth	lib/Controller/PublicShareController.php:252 show, :326 unlock — #[PublicPage] annotation with an auth check in the body
gate-30 effective-manifest-crossref	menu entry dashboards route /dashboards resolves to no pages[].id/pages[].route
gate-46 spec-anchor-existence	427 unresolved @spec targets (legacy debt)
gate-52 orphaned-write-capability	TileService::createTile, DashboardService::writeDashboardContent — write-capable, zero production callers

gate-7 and gate-9 are genuine authorization findings and should be triaged first: an #[NoAdminRequired] endpoint with no per-object guard is the classic IDOR shape (ADR-005 Rule 3), and gate-52's orphaned write methods are the 'spec-says-done but nothing calls it' defect class.

[rubenvdlinde]

Correction — the gate-7 entries are false positives. I characterised these as genuine IDOR findings in the issue body without reading the method bodies first. Having now checked both against origin/development:

• AcknowledgementController::acknowledge() — has an explicit guard: a body userId naming another user is rejected with 403, and the write uses $this->userId from the session regardless of the body. Deliberate, and the docblock cites REQ-ACK-003 / ADR-005.
• AcknowledgementController::pending() — takes no object identifier at all; it reads the session user and returns only that user's pending items. There is no caller-controllable reference, so IDOR is not structurally possible.

Both are safe because they derive identity from the session rather than from a request parameter. That is the correct pattern — and exactly what gate-7 cannot see, since it matches on the presence of an explicit guard call in the body.

So the real finding here is about the gate, not the controller: gate-7 should treat "method uses a session-derived user id and accepts no object identifier" as satisfying the check, otherwise it will keep flagging correctly-written endpoints and training people to ignore it.

The other entries in the table (gate-6 orphan-auth, gate-9 semantic-auth, gate-30, gate-46, gate-52) are unreviewed by me and still stand as reported.