Skip to content

ADR-079: manifest ships a 'Settings' page that renders Settings > Settings — gate-63 has only ever skipped over it #460

Description

@rubenvdlinde

What gate-63 says

Measured full-tree with hydra-gates@main over src/manifest.json:

FAIL src/manifest.json: page 'Settings' is a type:settings page claiming the platform meaning of
     'Settings'. App configuration lives at /settings/admin/<app>; a domain page that happens to be
     called settings must be renamed (ADR-079 D1).
FAIL src/manifest.json: settings-foldout entry is labelled 'Settings' — the foldout button is
     already called Settings, so this renders Settings > Settings (ADR-079 D4).
WARN src/manifest.json: app ships an in-app type:settings page AND a lib/Settings/*Admin.php
     section — two homes for one concern; delete the in-app page (ADR-079 D1).

The second one is directly user-visible: the navigation foldout renders Settings > Settings.

Why nobody has seen it

gate-63 is diff-scoped to the manifest, and it says so in its own findings log when it does nothing:

No changed manifest / menu-layout — gate skipped (ADR-020 diff scoping).

src/manifest.json has not been touched on development for long enough that every run of gate-63 in this repo has been a skip printed as PASS. The debt has been there the whole time; the gate has never once looked at it.

This is worth stating plainly because it is a general shape, not a quirk of this gate: a green whose log says "skipped" is not a measurement. Confirmed here by running the gate against origin/development in a clean worktree (PASS, log says skipped) and then against a tree with the manifest byte-identical to development but in scope (FAIL, the two findings above).

How it surfaced

PR #458 changes four icon strings in src/manifest.json. That is enough to pull the whole file into scope, so the two pre-existing ADR-079 findings appear on that PR's Hydra Gates run and block it.

Proven pre-existing, not caused by #458: reverting the manifest content to origin/development's bytes while keeping it in scope reproduces both findings identically.

Why this is not fixed in #458

Both fixes are renames on a live navigation surface:

  • D1 wants the type:settings page renamed (or deleted, per the WARN, since lib/Settings/SoftwareCatalogAdmin.php already provides the real admin section at /settings/admin/softwarecatalog).
  • D4 wants the foldout entry relabelled.

A page id / route / menu-label change belongs in its own change with its own e2e evidence, not bolted onto an accessibility PR. Filing so the two can be sequenced.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions