fix(web): bound workspace member pagination

[SebTardif]

What Problem This Solves

The chat workspace member directory follows has_more with no cursor-cycle cap. Settings overview already rejects a repeated member-directory cursor. Chat did not, so a stuck page can hang the web client.

Why This Change Was Made

Align chat pagination with the existing settings overview guard.

User Impact

A repeated member cursor stops the directory load instead of looping fetch forever.

Evidence

terminal output from the shared helper used by ChatApp:

$ cd apps/web && node --test src/lib/member-cursor.test.ts
# tests 4
# pass 4
# fail 0

Real behavior proof

Behavior addressed: Chat member pagination rejects an incomplete page and a repeated cursor.
Real environment tested: macOS, Node, clone at /tmp/pr-clickclack on the patched branch.
Exact steps or command run after this patch: cd apps/web && node --test src/lib/member-cursor.test.ts
Evidence after fix: terminal output copied below.

$ cd apps/web && node --test src/lib/member-cursor.test.ts
# tests 4
# pass 4
# fail 0

Observed result after fix: A repeated cursor throws Member directory repeated a pagination cursor.
What was not tested: Live ClickClack workspace UI against a wedged API.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed August 29, 2026, 9:46 AM ET / 13:46 UTC.

ClawSweeper review

What this changes

The branch adds repeated-cursor and incomplete-page validation to the web chat member-directory loader, tests the helper, and regenerates the embedded web assets.

Merge readiness

⛔ Blocked until real behavior proof from a real setup is added - 5 items remain

Keep open: the normal chat loader is guarded, but the same member-pagination loop remains unbounded in both supported embedded chat views; the submitted helper-only test output also does not prove production behavior.

Priority: P2
Reviewed head: 0890c17670bc09bc8481ac291c6225af6d384c48

Review scores

Measure	Result	What it means
Overall readiness	🦪 silver shellfish (2/6)	The shared guard is a focused repair, but coverage is incomplete and the supplied evidence is helper-test-only.
Proof confidence	🦪 silver shellfish (2/6)	Needs real behavior proof before merge: The changed production owner is the ChatApp member loader, but the supplied terminal output runs only the isolated cursor helper; it does not exercise a production member loader with a repeated API page or demonstrate that requests stop. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs real behavior proof before merge: The changed production owner is the ChatApp member loader, but the supplied terminal output runs only the isolated cursor helper; it does not exercise a production member loader with a repeated API page or demonstrate that requests stop. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	6 items	Normal chat path is guarded: The introduced ChatApp call passes every member page through the new cursor validator before continuing the loop. Embedded channel path remains unbounded: The embedded channel view still follows has_more directly and will request the same cursor indefinitely when the API repeats it. Embedded thread path remains unbounded: The embedded thread view has the same direct has_more cursor loop and calls the same workspace-members API helper.
Findings	1 actionable finding	[P2] Guard both embedded member loaders
Security	None	None.

How this fits together

The web client loads workspace members page by page to populate chat mentions and member-aware controls. Each API page returns a cursor that either drives another request or ends the load.

flowchart LR
  A[Workspace selected] --> B[Member directory loader]
  B --> C[Member page API]
  C --> D[Cursor validation]
  D -->|Fresh cursor| C
  D -->|End or invalid cursor| E[Stop loading]
  E --> F[Chat mention state]

Loading

Before merge

• Add real behavior proof - Needs real behavior proof before merge: The changed production owner is the ChatApp member loader, but the supplied terminal output runs only the isolated cursor helper; it does not exercise a production member loader with a repeated API page or demonstrate that requests stop. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Guard both embedded member loaders (P2) - The new guard is used only by ChatApp, while the supported embedded channel and thread views retain the same direct has_more cursor loops against the workspace-members endpoint. A repeated cursor can therefore still issue requests indefinitely in embedded chat; import the shared validator and track cursors in both loaders.
• Resolve merge risk (P1) - Merging as-is leaves repeated member cursors capable of causing indefinite requests in embedded channel and thread clients.
• Resolve merge risk (P1) - The supplied terminal output covers only an isolated helper, not a production member loader receiving a repeated API page.
• Complete next step (P2) - The two remaining unguarded loops have a narrow mechanical repair, although real behavior proof remains a contributor-side merge gate.

Findings

• [P2] Guard both embedded member loaders — apps/web/src/ChatApp.svelte:1121

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Source, test, and generated delta	production +22/-1, tests +42/-0, generated +15/-15	The eight generated asset updates are derived from a small source change and need to remain synchronized after the embedded-path repair.
Remaining unguarded loaders	2 embedded loaders	Both call the same workspace member endpoint but retain the repeated-cursor failure mode.

Merge-risk options

Maintainer options:

1. Complete embedded pagination coverage (recommended)
   Apply the shared cursor guard to both embedded loaders and prove a repeated member-page response stops all affected clients before merge.
2. Pause the incomplete fix
   Do not merge while supported embedded chat routes retain the same unbounded request loop.

Technical review

Best possible solution:

Use the shared cursor validator in every automatic workspace-member pagination loop, regenerate the embedded assets, and attach a redacted browser or production-loader trace showing the repeated request sequence stops.

Do we have a high-confidence way to reproduce the issue?

Yes: return has_more=true with the same next_cursor twice from the workspace-members endpoint; both embedded loops at the cited lines will continue requesting that cursor on the reviewed head.

Is this the best way to solve the issue?

No: the shared validator is a maintainable solution, but applying it only to ChatApp leaves two equivalent supported loaders unprotected.

Full review comments:

• [P2] Guard both embedded member loaders — apps/web/src/ChatApp.svelte:1121
  The new guard is used only by ChatApp, while the supported embedded channel and thread views retain the same direct has_more cursor loops against the workspace-members endpoint. A repeated cursor can therefore still issue requests indefinitely in embedded chat; import the shared validator and track cursors in both loaders.
  Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.99

AGENTS.md: found, but no applicable review policy affected this item.

Codex review notes: model internal, reasoning high; reviewed against 486fd23545af.

Labels

Label justifications:

• P2: This is a bounded web-client availability defect affecting supported embedded chat routes.
• merge-risk: 🚨 availability: Merging would leave embedded clients vulnerable to an unbounded request loop on a repeated pagination cursor.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The changed production owner is the ChatApp member loader, but the supplied terminal output runs only the isolated cursor helper; it does not exercise a production member loader with a repeated API page or demonstrate that requests stop. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

Acceptance criteria:

• [P1] pnpm --filter @clickclack/web test.
• [P1] pnpm build.
• [P1] pnpm test:e2e -- tests/e2e/routing.spec.ts.

What I checked:

• Normal chat path is guarded: The introduced ChatApp call passes every member page through the new cursor validator before continuing the loop. (apps/web/src/ChatApp.svelte:1121, 0890c17670bc)
• Embedded channel path remains unbounded: The embedded channel view still follows has_more directly and will request the same cursor indefinitely when the API repeats it. (apps/web/src/components/embed/EmbedChannelView.svelte:93, 0890c17670bc)
• Embedded thread path remains unbounded: The embedded thread view has the same direct has_more cursor loop and calls the same workspace-members API helper. (apps/web/src/components/embed/EmbedThreadView.svelte:97, 0890c17670bc)
• Prior blocker remains at the reviewed head: The affected normal and embedded loader paths are unchanged since the previous completed review at this exact head, so the prior embedded-loader finding remains applicable. (apps/web/src/ChatApp.svelte:1121, 0890c17670bc)
• Generated assets are a required product artifact: The root build embeds the web build into the API asset tree, and CI verifies that the generated assets are current and repeatable. (package.json:6, 0890c17670bc)
• Embedded-chat ownership history: Feature history identifies Peter Steinberger as the author of the embedded channel and standalone embedded thread surfaces that retain the unbounded loaders. (apps/web/src/components/embed/EmbedChannelView.svelte:84, 48d14b87d6b0)

Likely related people:

• Peter Steinberger: Introduced the embedded channel and standalone embedded thread surfaces that contain the remaining pagination loops. (role: embedded-chat feature owner; confidence: high; commits: 48d14b87d6b0, 7314f189bc97; files: apps/web/src/components/embed/EmbedChannelView.svelte, apps/web/src/components/embed/EmbedThreadView.svelte)
• Jacqueline Henriksen: Recent merged web work also touched both embedded chat views, making this a likely adjacent routing contact. (role: recent web-area contributor; confidence: medium; commits: b409a28f8ab4, ca3c86ff6a8b; files: apps/web/src/components/embed/EmbedChannelView.svelte, apps/web/src/components/embed/EmbedThreadView.svelte)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Apply the shared guard to the embedded channel and thread loaders, then regenerate the web assets.
• Post redacted browser or production-loader evidence using a repeated member-page response and showing no third request is sent; update the PR body to trigger re-review.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (5 earlier review cycles)

• reviewed 2026-08-18T21:52:08.400Z sha 71b3d10 :: needs real behavior proof before merge. :: [P2] Guard both embedded member loaders
• reviewed 2026-08-18T22:01:50.428Z sha 19b6e01 :: needs real behavior proof before merge. :: [P2] Guard both embedded member loaders
• reviewed 2026-08-28T02:49:27.169Z sha 19b6e01 :: needs changes before merge. :: [P2] Guard both embedded member loaders
• reviewed 2026-08-28T20:09:29.501Z sha b29f428 :: needs real behavior proof before merge. :: [P2] Guard both embedded member loaders
• reviewed 2026-08-28T20:18:15.799Z sha 0890c17 :: needs real behavior proof before merge. :: [P2] Guard both embedded member loaders