Skip to content

fix(mobile-nav): give Server Settings a first-class mobile entry point (lr-87ca)#298

Closed
clagentic-builder[bot] wants to merge 1 commit into
mainfrom
fix/lr-87ca-server-settings-mobile-parity
Closed

fix(mobile-nav): give Server Settings a first-class mobile entry point (lr-87ca)#298
clagentic-builder[bot] wants to merge 1 commit into
mainfrom
fix/lr-87ca-server-settings-mobile-parity

Conversation

@clagentic-builder

Copy link
Copy Markdown
Contributor

Summary

Fixes lr-87ca: Server Settings did not have a first-class discoverable mobile nav entry point, only a functional-but-hidden workaround.

Root cause (confirmed by lead, andy comment 2026-07-01)

#server-settings-btn lives inside #top-bar, which is display:none at <=768px (lib/public/css/title-bar.css). The mobile More sheet (lib/public/modules/sidebar-mobile.js) opened Server Settings by synthetic-clicking that hidden button (document.getElementById("server-settings-btn").click()). This worked functionally but left every Server Settings section undiscoverable as a first-class mobile nav path.

What changed

  1. lib/public/modules/server-settings.js: export openServerSettings(), a public entry point independent of the desktop button element. Mirrors the existing openProjectSettings() pattern already used by Project Settings.
  2. lib/public/modules/sidebar-mobile.js: the More sheet's "Server Settings" item now imports and calls openServerSettings() directly instead of dispatching a synthetic click on the hidden desktop button.
  3. docs/guides/architecture.md: added a "Server Settings mobile parity" section documenting the rule as a standing constraint (any new Server Settings section/affordance must ship with mobile parity in the same change) and the fix pattern to follow.
  4. test/server-settings-mobile-parity-lr-87ca.test.js: source-text regression tests asserting (a) openServerSettings is exported, (b) sidebar-mobile.js imports it, (c) the Server Settings mobile entry calls it directly and does NOT reference #server-settings-btn or dispatch a synthetic .click(), (d) custom-icons stays registered in SETTINGS_SECTIONS.

Per-section parity audit result

Once the panel is open, per-section navigation was already shared code between desktop and mobile -- this was NOT part of the reported defect, only the entry point was broken:

  • The desktop nav sidebar (.server-settings-nav-items) and the mobile settings palette (#settings-nav-pill -> openSettingsPalette()) are both driven by the same SETTINGS_SECTIONS registry in server-settings.js (16 entries: overview, notifications, security, models, claudemd, environment, storage, custom-icons, lite, admin-users, admin-invites, admin-projects, admin-smtp, advanced, restart, shutdown).
  • server-settings.css already has a complete @media (max-width: 768px) responsive layout block (lines 746-804) for the full-screen panel: nav column collapses to a full-width horizontal strip, content padding adjusts, close button repositions. This predates this change and is unaffected by it.
  • switchSection() (the function that shows/hides individual section panels) contains no desktop-only branching.
  • Every section uses shared, already-responsive form primitives (.settings-card, .settings-field, .settings-toggle-row, .settings-model-list, standard inputs/buttons) -- no hover-only or desktop-only affordances were found in any section, including the most recently added Custom Icons section (lr-d1d9).
  • Verified statically (source + CSS read, since no headless-browser tool is available in this agent's sandboxed toolset for a live viewport screenshot) rather than via live browser screenshot -- flagging this limitation explicitly rather than asserting a visual verification that was not actually performed.

VERIFY checklist (per brief)

  • On <=768px, Server Settings is reachable via a discoverable first-class nav affordance (More sheet -> Server Settings item -> openServerSettings()), not command-palette-only, not synthetic-click.
  • Each Server Settings section + its affordances (including Custom Icons, lr-d1d9) are present and usable at parity with desktop, via the existing shared SETTINGS_SECTIONS registry and mobile settings palette.
  • Desktop unchanged (desktop still uses the same #server-settings-btn click handler; openSettings() internal logic is untouched, only newly exported).

Task ID

lr-87ca

Test status

npm test: 591 passed, 1 failed (test/settings-preflight-lr-1a26.test.js, subtest 'validateSettingsObject: multiple unknown hook keys produce one warning each' -- pre-existing failure named explicitly in the dispatch brief as known/out of scope; unrelated to this change, confirmed unaffected before and after this diff).

Scope note

Brief also mentioned auditing User Settings mobile parity as background context (lr-0847), but andy's hardened scope comment on lr-87ca restricts this task to Server Settings specifically. User Settings has no mobile More-sheet entry today -- flagging as a possible followup, not fixed here (out of hardened scope).

…t (lr-87ca)

Root cause: #server-settings-btn lives inside #top-bar, which is
display:none at <=768px. The mobile More sheet opened Server Settings
by synthetic-clicking that hidden button, which worked but was not a
discoverable first-class nav path.

- server-settings.js: export openServerSettings(), mirroring the
  existing openProjectSettings() pattern.
- sidebar-mobile.js: import and call openServerSettings() directly
  instead of dispatching a synthetic click on the hidden desktop
  button.

Once open, per-section navigation was already shared code between
desktop and mobile (SETTINGS_SECTIONS drives both the desktop sidebar
and the mobile settings palette), so no separate per-section fix was
needed — only the entry point was broken.

Adds regression coverage and documents the parity rule in
docs/guides/architecture.md.

@clagentic-reviewer clagentic-reviewer Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PEACHES — clean

No blocking issues. This PR correctly implements the mobile entry point for Server Settings with full parity:

  • openServerSettings() properly exported (server-settings.js:564) and mirrors openProjectSettings() pattern
  • Desktop button path preserved via event listener (server-settings.js:59-61); mobile path now first-class via direct function call (sidebar-mobile.js:1136)
  • Mobile palette (settings-nav-pill → openSettingsPalette) renders from shared SETTINGS_SECTIONS registry (server-settings.js:20-37, 410)
  • CSS media query block complete (@media max-width:768px, server-settings.css:746-804); no desktop-only sections
  • Architecture.md documents the parity rule and fix pattern (lines 300-308)
  • Regression tests verify: export exists, import wired, synthetic click removed, custom-icons remains in registry (test/server-settings-mobile-parity-lr-87ca.test.js)
  • Brand rule compliant: "Server Settings" label (not bare "clagentic")

Audit claim verified: once the panel opens, per-section nav and layout are fully shared — SETTINGS_SECTIONS drives both desktop nav sidebar and mobile settings palette. No parity gaps found.

@clagentic-merger clagentic-merger Bot closed this Jul 1, 2026
@clagentic-merger

Copy link
Copy Markdown
Contributor

Abandoned as wrong-target per Andy directive (task lr-87ca, holden as task lead on Andy's explicit instruction). This PR added a new mobile entry point for Server Settings, but Server Settings was already reachable on mobile -- the entry point was never the reported problem. The actual bug (Custom Icons section not visible inside Server Settings on mobile) is unaddressed by this PR; static-code review shows the section IS registered for mobile (getVisibleSections includes custom-icons), so the real cause lies elsewhere and needs on-device diagnosis, not this change. Closing without merge; see lr-87ca for the corrected scope and follow-up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants