[matt2e]

Summary

Split out of the flakey-monday flake-fix series. Three Desktop E2E tests in persistent-agent-audience.spec.ts and community-rail.spec.ts acted on signals that could arrive before the app state they implied (a logged command before the submit lock rendered, a URL check that only held before a view transition landed). They now wait on the readiness signals the product actually exposes. No product code changes.

Commits (cherry-picked from flakey-monday, original messages kept):

• test(desktop): wait for composer focus and send cycles in audience specs
• test(desktop): assert the kept remembered route after the community switch
• test(desktop): assert Home after repairing the remembered channel

Root cause and fix per test

a manual mention persists when automatic mentions are enabled (desktop/tests/e2e/persistent-agent-audience.spec.ts): locator.fill("follow up") failed because message-input was not editable.

• Root cause (from the code and CI symptom; not reproduced locally): the test sends with a 1.5 s mock send delay, during which the composer is submit-locked and contenteditable="false". The lock is React state and renders a frame after Enter. The test's last two checks before the fill could both pass before that frame: the outgoing-mention poll (the e2e bridge logs a command when invoked, before the delay) and the contenteditable="true" wait. Playwright's fill rejects a contenteditable="false" element outright instead of waiting.
• Fix: after Enter, wait for the full send cycle: data-submit-locked "true", contenteditable "false", data-submit-locked "false", contenteditable "true". Only then assert on the editor. Existing assertions are unchanged.

the mention setting is reachable and operable by keyboard (same spec): the thread composer's mention autocomplete never became visible.

• Root cause (likely; not reproduced locally): opening a thread by URL mounts both the channel composer and the thread composer. useComposerAutofocus focuses whichever mounts first and TipTap defers focus() by a frame. A click and fill that land before that deferred focus lose it, and the focus-gated mention menu unmounts.
• Fix: a readyThreadComposerInput() helper waits for the thread editor to be editable and for exactly one message-input to hold focus, so the app's own autofocus has landed. Both tests use it.

community rail > does not repair a remembered channel until live validation succeeds (desktop/tests/e2e/community-rail.spec.ts): expect(page).not.toHaveURL(/#\/channels\/general$/) failed right after the click on community B.

• Root cause (confirmed; 21/40 failures at 14 workers on the old spec): switchCommunity runs inside a view transition whose callback writes B's remembered channel into the hash and then activates B, a few frames after the click returns. By design the URL is then #/channels/general, which AppShell keeps until a live channel read succeeds and only then repairs to Home. The inverted check from 631b05c passed only when its first poll beat the view transition.
• Fix: wait for B's rail button to have aria-current="true" (switch finished), then assert the URL is #/channels/general, the kept route. After live validation repairs storage to Home, assert the Home route /#\/$/ (the follow-up commit; not.toHaveURL(general) would have passed for any route, and AppShell's repair calls goHome({ replace: true })).

Related issue

N/A (flake fixes; none found).

Testing

Human testing is still required. This PR does not carry buzz-review-completed; the author has not yet run these specs themselves on this branch.

Verification

Verified locally on the flakey-monday branch before the split (Playwright smoke project, e2e build):

• Audience spec: neither flake reproduced before the fix, even with CPU throttled 4x and 8x. After the fix, both tests 40 repeats each at 10 workers: 80/80; whole spec: 35/35.
• Community-rail test: 40 repeats at 14 workers: 40/40; whole spec: 27/27 at 4 workers. The Home assertion was falsified: with the repair temporarily sending the app to #/channels/random, the new assertion failed and the previous not.toHaveURL check passed.
• The four desktop flake tests from the series together, 10 repeats each at 8 workers: 40/40.
• Two untouched tests in these specs are pre-existing flakes a baseline build fails as often, and are out of scope: community-rail "enters a remembered channel before live validation completes" and persistent-agent-audience "the mention button preserves manual rementions after undo until explicitly readdressed".

Nothing was re-run on this split branch: the workstation was overloaded, so no tests, builds or linters were executed after cherry-picking. CI on this PR is the verification for the split branch.

🤖 Generated with Claude Code

[github-actions]

🔐 Codex Security Review

Note: This is an automated, security-focused review generated by Codex.
Use it as a supplement to human review; false positives are possible.

Scope

• Exact PR diff: 65e864301d2e51a93003816b45e77cae96be901f...0737d665bc16b4fb420a6bd4833ec70e449c3118
• Model: gpt-6.1-sol

💡 Click "edited" above to see earlier reviews for this PR.

---

Review Summary

Overall Risk: NONE

No concrete findings in the authorized PR range. Changes are limited to desktop end-to-end test synchronization and assertions consistent with existing navigation and composer behavior.

Findings

No concrete security, correctness, or reliability findings were identified.

Notes

• Review used read-only source and history inspection. Tests were not executed, as instructed.

---

_{Generated by Codex Security Review |
Requested by: @matt2e |
Workflow run}

[kazemek21]

Kyle reviewed this PR and the Nexus review-tracker notes and approved with no comments.

Posted by Codex (gpt-6.1-sol) on behalf of kylez