[matt2e]

Problem

In Settings → Manage plugins, a plugin's details pane had no way to reach that plugin's own settings. To change who can wake agents from GitHub comments, for example, you had to know the rules live in a GitHub comment authors section and find it in the sidebar yourself.

What the pane shows now

Under the Enable/Disable button, the pane lists the Settings sections that hold the plugin's settings, for example Settings: GitHub comment authors. Each name links to its section. Clicking it or pressing Enter opens the section and moves focus into it.

• Sections come from the sidebar's current sections whose contributed card belongs to the plugin, in sidebar order. A plugin with no section gets no line, and neither does a disabled plugin (it registers no cards). A community section isn't linked in Personal space, where the sidebar doesn't show it.
• Decision providers: TypeSafe's settings live in the built-in Decisions API section rather than one it adds. The pane now links Decisions API for any plugin with a registered decision provider, once however many providers it registers.
• Accessibility: the line is a group named "‹Plugin› settings" (for example "GitHub settings"), so a screen reader doesn't read out bare section names right after "Disable".
• The new links and the existing Decisions API hint share one openSection helper that opens a section and moves focus into it. docs/buzz-help.md mentions the links.

Opening a linked section at its start

In a narrow window, Settings stacks the sidebar above the content in one scroll container. A section opened from a link inside the content kept that container's offset, and the focus step uses preventScroll. So after scrolling down to the link, the section opened partway down with its heading out of view (423 px in, at 480×800 with 200% text).

The focus step now scrolls the opened section to its start, but only after a link inside the content, and only when a scroll container around it has scrolled past that start. A sidebar click, Back or other route change never triggers it. The scroll is instant, so reduced motion is unaffected. The same fix applies at full width to the Decisions API hints that open Manage plugins, where the plugin list could open scrolled with its focused start out of view.

Before and after

media-before-after.mp4

Left: main at 0b2dfbf. Right: this branch at d4c6ad5. Both sides play the same steps in sync, in the browser fixture build at 1280×800:

1. Settings → Manage plugins → View GitHub details.
2. Open GitHub comment authors: from the sidebar on the left, from the new link on the right.
3. Manage plugins → View TypeSafe details → Decisions API.
4. Manage plugins → View Codex details: no link line on either side.

The pink outline marks the control about to be clicked, then the element that has focus once the section opens. The later commits only change narrow-window scrolling, which these steps don't hit.

Dark theme, with keyboard focus on the link:

480 px wide, where the pane covers the plugin list:

Checks

102 Settings Vitest tests and 17 Settings browser tests (Chromium) pass, and pnpm lint is clean. Typecheck and design:check were clean at af551cd; b06c71f only adds a test. Not run: the desktop app and WebKit.

Not in this PR

• Codex: its settings are under Agent setup → Harness defaults → Codex. Codex doesn't register them as a card or a decision provider, so its pane gets no link.
• Back: going Back from a linked section returns to Manage plugins with the pane closed, not where you left off. Restoring that is a separate follow-up that needs a product decision.
• TypeSafe with Builderlab: when Builderlab is the active Decisions API backend, TypeSafe's link opens Decisions API at the backend picker rather than TypeSafe's key form, so you pick TypeSafe there first.

🤖 Generated with Claude Code

[joahg]

🤖 Read the Settings changes and tests; sections are derived from live cards/providers so retired or disabled plugins drop their links, and the scroll-into-view is limited to link-opened sections. Merge state is DIRTY, needs a rebase.

[wesbillman]

🤖 Star Lord automated source review via Wes's account, with independent Rocket, Mantis and Groot passes.

Reviewed full feature at head b1fabf356f72c43d431d9de886cf9bb402914321 against target base 25e3282fe248317a87ae87f1e1cf7c99495341fa (feature merge base b99951af32f143376404fbcf8b50064aedf39d08). Recommend approval at this revision; no blocking source finding. This is a COMMENT recommendation, with integration and validation limits below.

The links reuse the sidebar's live sections and card/provider ownership. Inactive revisions and withdrawn providers disappear through the existing registries; provider plugins get one Decisions API link in sidebar order. The real Settings opener preserves viewer/community scope. The shared focus helper scrolls a linked destination only when its start is above an ancestor scrollport. Codex, Back closing the details pane, and TypeSafe opening the backend picker when Builderlab is selected are accurately disclosed limits.

Optional P3 follow-up, extending an existing pattern: src/app/Settings.tsx:763-783 retains contentFocus if a section request is superseded or becomes unavailable before selection. If the same Settings instance later visits that id via the sidebar, the old intent can move focus and scroll as though the original content link had just opened it. Consider expiring the intent on cancelled/superseding navigation, preserving the normal intermediate render before selected adopts the requested section. A useful regression is request X → supersede with Y → later sidebar X, with no stale link-specific focus/scroll. This is conditional source inference, not a reproduced runtime failure.

Validation: reviewed all three changed files and relevant owners/callers, test sources and documentation. Hosted snapshot: 41 successful checks, two skipped. The new scroll regression mocks geometry; real 480×800/200% text heading visibility remains unverified. Two fixture screenshots inspected; video not replayed. No tests, builds or app runs performed by this review; native/WebKit behavior, assistive technology and human acceptance remain unverified.

The earlier DIRTY report is historical: captured metadata varies from mergeable/blocked to unknown. This review does not establish a current merge conflict or validate a rebased combination; recheck integration against the landing base.