client: a failed workflow run's Open in the Inbox lands on Settings → General, not Workflows #2515

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 18640dfec1ed471c81d1d7ab34b72512
Branch: dev/1-inbox-workflow-page
Base: e5fc62d
At: 2026-11-05T07:19:42Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

What a user sees

In the Inbox, a failed workflow run has no chat to land in, so its row offers Open instead. That Open lands on Settings → General, not on the Workflows page, so the reader has to find the page themselves and then find the graph among the others.

Nothing errors: the settings dialog simply falls back to its first page when it is asked for a page key it does not know.

Reproduction (live main e5fc62de)

A clean e5fc62de tree with only the branch's test file:

not ok 7 - #1706: a workflow row has no chat, opens the Workflow graphs page, and answers nothing
  expected: [ 'Workflows' ]
  actual:   [ 'General' ]
# tests 8 / # pass 7 / # fail 1

The test renders SettingsDialog and reads the current page from the nav's aria-current="page" instead of asserting the argument of the call. It also keeps a "not General" negative assertion.

Counter-proof on the fixed tree: reverting only the one word in inbox.js turns the same test red again (8/7/1), and restoring it leaves git status clean.

Root cause

• core/src/client/inbox.js openCard: a workflow card calls actions.openSettings('workflow') (singular).
• core/src/client/settings.js builds its pages from SETTINGS_PAGES, where the Workflows entry's key is workflows (plural); the dialog then resolves pages.some(([key]) => key === page) ? page : 'general', so an unknown key falls back to general without an error.

The test that covered this path asserted the call argument (['close','settings workflow']), which pinned the wrong string in place: no test rendered the dialog, so CI stayed green while the page was wrong. docs/subsystems/core-client.md repeats the singular call, so the docs agree with the bug.

Expected behaviour

Opening a failed workflow run from the Inbox lands on Settings → Workflows, and nothing else about that row changes.

Scope

• core/src/client/inbox.js: the one page key, with a comment saying that Settings resolves an unknown key to General without an error.
• core/test/inbox-workflow-failure.test.js: assert the rendered page (nav aria-current="page" is Workflows), plus the "not General" negative assertion.
• docs/subsystems/core-client.md: the sentence about where Open goes.
• changelog.d/: one fragment.
• Regenerated core/client.js and patches/ds-bot/ (bundle + the mirrored source and test copies), as the repo's build requires.

Dedup

Checked live main and closed issues before opening: inbox+workflow+settings+page (8), openSettings+workflow (9), Workflows+page+General+fallback (0), failed+workflow+run+Inbox+Open (5).

• A failed workflow run never reaches the Inbox: it is visible only inside its own graph (and publicRun has no finishedAt or current step) #1706 / fix(inbox): a failed workflow run reaches the Inbox #1717 created the Inbox row and its Open entry for a failed workflow run — that is the feature this bug breaks, not a report of the wrong page.
• client: put the read-only Reload where the sentence is #2510 (open PR) is the read-only Reload row in the Inbox, a different control.
• No open or closed issue covers this wrong landing page.

Not in scope

Deep-linking to the failed graph itself (carry the graph id into SettingsDialog → WorkflowsPage) is a separate enhancement and is not part of this issue.