fix(loops): group loops by ownership rather than visibility

[MattPua]

Problem

Team-visible loops owned by the current user appeared under Team loops.

Changes

• Group loops by owner
• Keep owned loops under My loops

How did you test this?

• UI tests
• UI typecheck

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

---

Created with PostHog Code

[trunk-io]

😎 Merged successfully - details.

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 4ef2141.}

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/ui/src/features/loops/components/LoopsListView.tsx:141
**Null identity misgroups owned loops**

When the loops query resolves while the independent current-user query is loading or has failed, this passes a null user ID into the grouping logic, causing the current user's team-visible loops to appear under “Team loops” instead of “My loops.”

_{Reviews (1): Last reviewed commit: "fix(loops): group loops by ownership rat..." | Re-trigger Greptile}

[stamphog]

Note

🤖 stamphog reviewed b63536b65441fab91cadb32bccd2e350d669a3b9 — verdict: REFUSED

An unresolved P1 comment from the automated reviewer is substantive and unaddressed: when the current-user query hasn't resolved yet, currentUserId is null, so the new grouping logic puts the user's own team-visible loops under "Team loops" — reproducing the exact bug this PR claims to fix. The diff and tests don't address that race, and no later commit fixes it.

• Author wrote 86% of the modified lines and has 9 merged PRs in these paths (familiarity STRONG).
• greptile-apps[bot] reviewed the current head.
• Unresolved Greptile inline comment on LoopsListView.tsx:141 flags that a null/loading currentUserId misclassifies the user's own team-visible loops under 'Team loops', undermining the PR's stated fix.
• No test covers the loading/null currentUserId case, so the regression isn't caught by CI.

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✓	no deny categories matched
size	✓	21L, 2F substantive, 40L/4F incl. docs/generated/snapshots — within ceiling
tier	✓	T1-agent / T1b-small (40L, 4F, single-area, fix)
stamphog 2.0.0b3		.stamphog/policy.yml @ a8396c6 · reviewed head b63536b

[github-actions]

Small, well-tested UI fix that groups loops by ownership instead of visibility; it also directly addresses Greptile's flagged null-identity race by gating on the current-user query's loading/error state, with a new test covering that case. No risky territory (auth/billing/API/migration) touched, and the author has STRONG familiarity with these lines.

• Author wrote 89% of the modified lines and has 9 merged PRs in these paths (familiarity STRONG).
• 👍 on the PR from greptile-apps[bot].

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✓	no deny categories matched
size	✓	36L, 2F substantive, 71L/4F incl. docs/generated/snapshots — within ceiling
tier	✓	T1-agent / T1b-small (71L, 4F, single-area, fix)
stamphog 2.0.0b3		.stamphog/policy.yml @ a8396c6 · reviewed head 4ef2141