[iscekic]

Change

When the server removes the user's membership in the active organization, the app previously stayed on the dead organization: Home showed an access-denied live section with only a back action, and the Profile credits row lost its organization name and balance ("Failed to load balance. Tap to retry.") with a disabled organization row.

Two additions make the app recover:

1. Provider reconciliation (apps/mobile/src/lib/organization-context.tsx): the provider now compares each settled organizations.list snapshot against the one the current selection was published with. A new snapshot that no longer names the stored organization switches to the first remaining membership — or Personal, writing the explicit-Personal marker — through the existing setOrganizationId path (persistence, activity-token cleanup, glanceable blanking all reused), and announces the new context with a localized toast (organization.boundary.membershipLostNotice): "You no longer have access to this organization. Switched to Org Beta."

2. List refresh on permission loss (apps/mobile/src/lib/query-client.ts): the cached list can still name the org after the server already dropped the membership, so the provider would have nothing to act on until the next foreground freshness pass. A permission-denied error (FORBIDDEN / procedure-level UNAUTHORIZED) on an org-scoped query now invalidates the shared organizations.list once, so the fresh snapshot reaches the provider immediately. A list still holding the org (role-scoped denial, org intact) changes nothing: the fresh snapshot matches the selection's own, and the existing access-denied surface stays.

New key organization.boundary.membershipLostNotice in en.json, translated into all 86 non-English catalogs (placeholder parity kept).

End-to-end verification (Android emulator, local stack, owned fake account)

Signed in as a fake account member of two seeded organizations (Org Alpha active, Org Beta secondary); credits row showed "Org Alpha" with a loaded balance.

After deleting the member's Org Alpha membership row on the local server and returning to Home:

• The app switched to Org Beta and showed the localized toast: "You no longer have access to this organization. Switched to Org Beta." Home rendered the live section normally — no access-denied dead end.
• Profile then showed "Org Beta" as the credits context with a loaded balance, and "View organization / Org Beta" — no generic name, no failed balance, no disabled row.

Checks: pnpm --filter kilo-app typecheck clean; lint 0 errors; check:unused clean; check:plurals clean; vitest suites for organization-context (8, including four new recovery cases), query-client (27, including two new list-refresh cases), and the home mounted suite (57) all pass — 92/92.

Screenshots: baseline "Org Alpha" credits row, the recovery toast on Home, and the recovered "Org Beta" credits row are attached in a follow-up comment.

Sync with main

The branch merged main (through cef32d4d04) so it keeps the newer organization surfaces:

• Every locale catalog keeps both this change's organization.boundary.membershipLostNotice and main's new organization strings, with sv resolved by taking main's retranslated boundary block and inserting the notice in its order.
• Main's PR-review context line (added after this branch was cut) is aligned: a stored organization that left the list now shows the recovered membership instead of the unavailable scope, because the provider switches before that line renders. Its suite mocks the toast adapter the provider imports, like the other provider-mounted suites.
• A restoration test now resolves the memberships list with the stored organization, so it no longer raced the lost-membership switch.

Re-run on the merged tree: apps/mobile vitest 1241 files / 18439 tests pass, pnpm --filter kilo-app typecheck clean, pnpm check:i18n reports 87 catalogs matching en.json, format:check clean.

Proxy answers

The owner's proxy gave these answers in the owner's place.

1. Question: When the active organization disappears, which context should the app switch to?
   Answer: First remaining membership (Recommended)
   Confidence: 0.80 · Precedent: Do the least work possible (session 7f3470e0ba6f: "do the least amount of work possible, with no drop in quality"). This reuses the existing default-resolution rule and matches the brief.
2. Question: How should the app tell the user the context was switched?
   Answer: Toast notice (Recommended)
   Confidence: 0.85 · Precedent: Localize every string in the mobile app (session dcb3f9170164: "the mobile app always must respect i18n"). The brief requires a localized notice.
3. Question: When the fallback lands on Personal, should it write the explicit-Personal marker?
   Answer: Write the marker (Recommended)
   Confidence: 0.70 · Precedent: Do the least work possible (session 00eb2a1d3e4b: "skip work that doesn't need to be done"). Reuse the existing switch path and do not add a duplicate recovery branch.
4. Question: Which FORBIDDEN errors should force a refresh of the organizations list (the trigger that catches a server-side membership removal while the cached list still contains the org)?
   Answer: Any org-scoped FORBIDDEN (Recommended)
   Confidence: 0.80 · Precedent: Fix the class of issue on every affected surface (session 75f8833fe8c1: "fix this for all ... on all surfaces"). React just in time, not on the next poll (session 55c9c80332a7: "react just in time, no polling").
5. Question: When the app restores a stored organization and the FIRST fetched organizations list does not contain it (cold start, read cache expired), should the app auto-switch to the remaining context with the toast, or keep the existing "Organization unavailable" surface with a manual picker?
   Answer: Auto-switch on first list (Recommended)
   Confidence: 0.75 · Precedent: Autonomy: 'Fix the root cause and the class of the issue, not the single symptom' (session 00eb2a1d3e4b, 'fix the class'); Speed: 'Replace old paths instead of keeping them alongside' (session ad6a3f589364, 'alongside? why not instead?')

[iscekic]

bot: End-to-end recovery on the Android emulator (local stack, owned fake account, member of two seeded organizations).

Signed in with the first organization active; the Profile credits row showed that organization's name with a loaded balance.

After the server removed that membership and the app refreshed:

1. Home switched to the remaining organization and showed the recovery toast — the live section rendered normally, no access-denied dead end.
2. Profile then showed the remaining organization as the credits context with a loaded balance and a working organization row — no generic name, no failed balance, no disabled row.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The incremental commit is a single test-fixture correction that makes the stored-selection test's list include the saved organization, matching the new first-snapshot recovery behavior; the previously reported findings are resolved in current code and no new subscriptions, timers, or listeners are introduced.

Assumptions: [INFERENCE] Vitest suites were not executed in this read-only review; verification is from the current source and the PR's reported checks.

Files Reviewed (4 files)

• apps/mobile/src/lib/organization-context.mounted.test.tsx - 0 issues (incremental change)
• apps/mobile/src/lib/organization-context.tsx - 0 issues (targeted re-verification; first-snapshot detection and error-guarded baseline confirmed at current HEAD)
• apps/mobile/src/lib/query-client.ts - 0 issues (targeted re-verification; cancelRefetch: false confirmed)
• apps/mobile/src/lib/query-client.test.ts - 0 issues (targeted re-verification; isInvalidated assertion confirmed)

Previous Review Summaries (6 snapshots, latest commit d0a74a3)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit d0a74a3)

Status: No Issues Found | Recommendation: Merge

Executive Summary

The incremental commit is test-only: it mocks the toast adapter the provider imports and aligns the PR-review context-line case with the provider's lost-membership recovery, and the earlier findings remain fixed in current code; no new subscriptions, listeners, or timers are added, so there is no additional memory-leak surface.

Assumptions: [INFERENCE] The vitest suites were not executed in this read-only review; the PR reports organization-context, query-client, and mounted suites passing on this head.

Files Reviewed (4 files)

• apps/mobile/src/components/pr-review/pr-review-context-line.mounted.test.tsx - 0 issues (incremental change)
• apps/mobile/src/lib/organization-context.tsx - 0 issues (targeted re-verification; first-snapshot detection and error-guarded baseline remain fixed)
• apps/mobile/src/lib/query-client.ts - 0 issues (targeted re-verification; cancelRefetch: false remains present)
• apps/mobile/src/lib/query-client.test.ts - 0 issues (targeted re-verification; isInvalidated assertion remains present)

Previous review (commit 7443c66)

Status: No Issues Found | Recommendation: Merge

Executive Summary

The incremental change only seeds the shared memberships list in the organization credits expiry test so the provider keeps the staged selection, matching the provider's current recovery semantics; the four earlier findings are resolved in current code and no new defect or memory leak was introduced.

Assumptions: none.

Files Reviewed (4 files)

• apps/mobile/src/components/profile-credits-card.mounted.test.tsx - 0 issues (incremental change)
• apps/mobile/src/lib/organization-context.tsx - 0 issues (targeted re-verification; first-snapshot detection and pre-guard baseline findings are fixed)
• apps/mobile/src/lib/query-client.ts - 0 issues (targeted re-verification; cancelRefetch: false is present)
• apps/mobile/src/lib/query-client.test.ts - 0 issues (targeted re-verification; isInvalidated assertion is present)

No new subscriptions, listeners, or timers are added by the incremental change, so the PR introduces no additional memory-leak surface.

Previous review (commit 00a9f40)

Status: No Issues Found | Recommendation: Merge

Executive Summary

The incremental commit only clarifies comments in OrganizationProvider and updates four mounted suites to seed the fetched list the provider reconciles against; the earlier findings remain fixed in the current code. No memory leaks were introduced: the recovery path adds no subscriptions or listeners, and the provider's refs are reset on sign-out and unmount.

Files Reviewed (5 files)

• apps/mobile/src/lib/organization-context.tsx - 0 issues
• apps/mobile/src/lib/organization-context.mounted.test.tsx - 0 issues
• apps/mobile/src/lib/deep-link-launch.mounted.test.tsx - 0 issues
• apps/mobile/src/components/context-control.mounted.test.tsx - 0 issues
• apps/mobile/src/components/profile-credits-card.mounted.test.tsx - 0 issues

Previous review (commit 5124f72)

Status: No Issues Found | Recommendation: Merge

Executive Summary

The follow-up commit only adds the organization.boundary.membershipLostNotice string to the 86 non-English catalogs, all with the {{target}} placeholder preserved, and the four prior findings are fixed in the current code.

Files Reviewed (87 files)

• apps/mobile/src/i18n/locales/*.json (86 files) - 0 issues
• apps/mobile/src/lib/organization-context.tsx - targeted re-check of prior findings, all fixed
• apps/mobile/src/lib/query-client.ts - prior cancelRefetch: false finding fixed
• apps/mobile/src/lib/query-client.test.ts - prior assertion finding fixed (isInvalidated now asserted)

Previous review (commit 2f369b3)

Status: No Issues Found | Recommendation: Merge

Executive Summary

The follow-up commits fix all four prior findings: a restored selection is now evaluated against its first settled snapshot, snapshots seen during an error are re-evaluated after it clears, the list invalidation joins an in-flight fetch, and the non-org test now asserts isInvalidated. The new cold-start case is covered by a test.

Files Reviewed (4 files)

• apps/mobile/src/lib/organization-context.tsx - 0 issues
• apps/mobile/src/lib/organization-context.test.ts - 0 issues
• apps/mobile/src/lib/query-client.ts - 0 issues
• apps/mobile/src/lib/query-client.test.ts - 0 issues

Previous review (commit 710bf49)

Status: 4 Issues Found | Recommendation: Address before merge

Executive Summary

The lost-membership recovery is sound for a running app, but a selection restored after the 24h read-cache expiry becomes its own baseline, so the dead organization is never recovered; three smaller issues cover a snapshot consumed during an error, repeated list-fetch restarts, and a vacuous test assertion.

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	3

Issue Details (click to expand)

WARNING

File	Line	Issue
apps/mobile/src/lib/organization-context.tsx	247	A restored selection has no prior snapshot, so when the persisted read cache has expired the first settled list (already missing the org) becomes the baseline and structurally-shared refetches never trigger recovery.

SUGGESTION

File	Line	Issue
apps/mobile/src/lib/organization-context.tsx	255	A snapshot observed while state.error is set is recorded as the baseline before the guard skips detection, losing the recovery permanently.
apps/mobile/src/lib/query-client.ts	244	invalidateQueries defaults to cancelRefetch: true, so concurrent org-scoped denials cancel and restart the shared list fetch repeatedly.
apps/mobile/src/lib/query-client.test.ts	286	The non-org FORBIDDEN test asserts dataUpdatedAt (unchanged by invalidation) and cannot detect a wrongly scheduled refresh.

Files Reviewed (5 files)

• apps/mobile/src/i18n/locales/en.json - 0 issues
• apps/mobile/src/lib/organization-context.tsx - 2 issues
• apps/mobile/src/lib/organization-context.test.ts - 0 issues
• apps/mobile/src/lib/query-client.ts - 1 issue
• apps/mobile/src/lib/query-client.test.ts - 1 issue

No memory leaks found: the provider's new refs hold the shared query array for the provider lifetime only, are reset on sign-out and restore, and the invalidation adds no subscription or listener.

Fix these issues in Kilo Cloud

---

_{Reviewed by deepseek-flash-latest · Input: 41.6K · Output: 3.3K · Cached: 301.7K}

_{Review guidance: REVIEW.md from base branch main}

[iscekic]

bot: Addressed all four threads in 2f369b3:

1. Cold-start recovery (organization-context.tsx): a selection restored from storage now has no list baseline, so its very first settled snapshot is evaluated — a snapshot already missing the stored organization arms the recovery instead of becoming the baseline. A manual pick records the snapshot it was made against as its baseline, so picker-offered orgs stay trusted. Regression test added ("recovers a stored selection whose very first snapshot already misses it").
2. Error-state baseline (organization-context.tsx): the snapshot is now recorded only after every guard passes, so a snapshot observed during a save/restore error is re-evaluated once the error clears.
3. Concurrent denials (query-client.ts): the invalidation passes cancelRefetch: false, so several org-scoped denials around the same time cannot cancel each other's shared list fetch.
4. Test assertion (query-client.test.ts): the non-org case now asserts isInvalidated is false instead of dataUpdatedAt.

[iscekic]

bot: Cold-start recovery on the Android emulator (local stack, owned fake account, member of two seeded organizations).

Signed in with the first organization active; the Profile credits row showed that organization's name with a loaded balance.

Then the app was closed, the server removed that membership, and the app was relaunched:

1. Home switched to the remaining organization and showed the recovery notice; the live section rendered normally, with no access-denied dead end.
2. Profile showed the remaining organization as the credits context, with a loaded balance and a working organization row.

The earlier comment covers the live removal while the app is open; this run covers the restored-selection case on the current head.

[iscekic]

bot: Follow-up evidence on the account selector after a membership disappears (Android emulator, local stack, owned fake account, two seeded organizations).

The selector's rows come from the shared membership list, so this run exercised that surface directly.

1. Baseline: membership in exactly one organization, first remaining organization, personal account for a second capture.
2. Before removal: the selector listed Personal, Drain Alpha (checked) and Drain Beta.
3. Server-side removal of the active membership, then back to Home: the live section rendered normally, and Profile's credits row read "Drain Beta" with a loaded balance — no generic account name, no failed balance.
4. Selector right after that recovery: Personal and Drain Beta, with Drain Beta checked.
5. Server-side removal of the last membership: Profile's credits row read "Personal" with the personal balance loaded.
6. Selector with no memberships left: Personal only.

Commands and observation source: adb exec-out uiautomator dump on each screen, cross-checked with the captures below; membership rows deleted directly in the local development database.

Attachments show only the fake seeded organizations and fake balances on http://localhost:3000 over adb reverse.