[iscekic]

What

PR-review reconnect messages now name the provider of the surface they appear on.

• lib/pr-review/mutation-error-display.ts gains reconnectExpiredMessage(platform) and an optional
  platform option. The reconnect kind selects prReview.connectionExpired on GitHub and the
  reconnect notice's own prReview.reconnectNotice.gitlabTitle / bitbucketTitle on GitLab and
  Bitbucket, so the status line and the notice beside it agree.
• useComposerInlineError reads the provider scope the pr-review routes publish, which covers the
  inline comment composer and its edit sheet without threading a new prop through their routes.
• The merge sheet, the review-submit sheet, the reply input and the conversation composer pass the
  platform they already hold (prRef.platform / provider.platform).

No new catalog keys: the provider titles already exist in all 87 locales, and connectionExpired
remains the GitHub copy, so check:i18n and check:plurals are unchanged.

Tests

• mutation-error-display.test.ts: the reconnect kind for no platform, github, gitlab and
  bitbucket.
• pr-merge-sheet.test.tsx: a GitLab and a Bitbucket reconnect error write the provider's status
  text, and the GitHub arm keeps the GitHub copy.
• composer-inline-error.test.tsx: the composer hook under a GitLab provider scope selects the
  GitLab copy.
• The edit-sheet suite stubs the scope reader (it calls the sheet as a plain function); the provider
  path is covered by the composer hook suite.

Run on this VM: full pnpm --filter kilo-app test, tsgo --noEmit, mobile lint, and
check:i18n / check:plurals.

End-to-end evidence

Local dev stack on this VM — real Next.js, Postgres and tRPC routers — with GitLab faked at its
network boundary by one local stub (merge-request reads, project settings, approvals, and the
credential broker). Android emulator, dev client, signed in with an owned fixture account in a
fixture organization that owns the fixture GitLab integration, on a fixture merge request. No
product code was changed to produce the failure.

Trigger exercised on the device: the fixture account's organization membership is removed while the
provider-review screen is open. The app's next provider write reaches the real router, and
ensureOrganizationAccess rejects it with UNAUTHORIZED before any GitLab request is sent — the
stub log for the whole run contains reads and broker calls only, no GitLab write. That is the
classification classifyPrReviewMutationError maps to reconnect, the branch this change repaints.

Observed at head 0bcd2f80:

• Merge sheet: providerReview.mergePullRequest answered 401. The status line and the notice title
  both read "GitLab connection expired", above the GitLab connection notice body and its Check
  connection control.
• Discussion reply input: providerReview.replyToComment answered 401. The inline error reads
  "GitLab connection expired" above the same notice.
• Conversation comment composer: providerReview.addComment answered 401. The inline error reads
  "GitLab connection expired".

Screenshots of all three states are attached in a follow-up comment on this pull request.

Already run on this VM: vitest for the four touched suites (66 tests), pnpm --filter kilo-app check:i18n (87 catalogs) and check:plurals.

Limitations

• The Bitbucket arm shares reconnectExpiredMessage and is covered by the unit test, not by an
  emulator run.
• The review-submit sheet uses the same display helper with the provider term; unit-tested.
• The run proves the client copy on the app's own rejection path. It does not prove GitLab accepts a
  real request, which this copy selection does not depend on.

Proxy answers

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

1. Question: Copy source: Where should the GitLab/Bitbucket reconnect message come from?
   Answer: Reuse reconnectNotice.gitlabTitle / bitbucketTitle
   Confidence: 0.75 · Precedent: Speed and least work: "do the least amount of work possible, with no drop in quality" (session 7f3470e0ba6f). Every catalog already holds correct translations, and the status line and the notice stay consistent.
2. Question: Status line: On the merge and review-submit sheets, the reconnect status line appears directly above the reconnect notice that already names the provider. Keep it?
   Answer: Keep, fix its wording
   Confidence: 0.55 · Precedent: Keep similar elements consistent across surfaces (session a247f3c19b1e, thought row to match tool call row). Dropping the line only on the provider arms would make the arms diverge and lose the live-region announcement. The redundant copy applies to all three arms and is outside this item's scope.
3. Question: GitHub arm: Keep the GitHub arm on prReview.connectionExpired?
   Answer: Keep connectionExpired (brief)
   Confidence: 0.70 · Precedent: Speed and least work: "skip work that doesn't need to be done" (session 00eb2a1d3e4b). The brief says GitHub keeps prReview.connectionExpired.
4. Question: E2E depth: How deep should the Android proof go for a GitLab reconnect error?
   Answer: Fake GitLab + broker, before/after
   Confidence: 0.75 · Precedent: Proof and verification: "only bug reports technically need to care about repro" (session 7f3470e0ba6f). This item is a wrong-provider bug, so it needs proof of the base reproduction and of the fix.
5. Question: Red CI: The only red check is mobile-test (5/8), which fails on a to-do list mounted test whose fix (test(mobile): stub BackHandler for the to-do list settings sheet #8475, BackHandler stub) landed on main after this branch was created. The PR merge ref is still built against an older main, so reruns keep failing. How should I clear it?
   Answer: Merge main into the branch
   Confidence: 0.90 · Precedent: Git and pull requests: merge main only when a conflict or a fix on main needs it — session a247f3c19b1e, "try merging main in, that may fix the issue"; also "blocked is not an acceptable end state" (55c9c80332a7).

[iscekic]

bot: Android proof of the provider-aware reconnect copy, captured on a GitLab merge request opened from a fixture integration on the local dev stack (fixture account, fixture repository, fixture merge request).

Flow: opened the merge request's merge sheet, then submitted the merge while the provider call answered with an authorization failure.

• Before (previous bundle): the reconnect status line above the notice read "GitHub connection expired." while the notice itself named GitLab.
• After (this branch): the reconnect status line reads "GitLab connection expired" and matches the notice; the re-check control is unchanged.

Both captures are the same merge sheet frame; only the provider name in the status line differs.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The provider-aware reconnect copy is selected consistently on every PR-review surface, reuses existing translated keys present in all 87 catalogs, and preserves the GitHub bytes for the GitHub and platform-less arms.

Assumptions: [INFERENCE] The mobile suites were not executed (read-only review); test behavior is assessed by reading the suites and their mocks. The provider scope is mounted above the comment-composer, conversation-comment, review-submit, merge and file-navigator formSheet routes by app/(app)/pr-review/[platform]/[...identity]/_layout.tsx:98, so useProviderPrScopeOrNull() resolves on those surfaces.

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	0

Files Reviewed (10 files)

• apps/mobile/src/lib/pr-review/mutation-error-display.ts
• apps/mobile/src/lib/pr-review/mutation-error-display.test.ts
• apps/mobile/src/components/pr-review/composer-inline-error.tsx
• apps/mobile/src/components/pr-review/composer-inline-error.test.tsx
• apps/mobile/src/components/pr-review/discussion/pr-comment-edit-sheet.test.tsx
• apps/mobile/src/components/pr-review/discussion/pr-conversation-comment-composer.tsx
• apps/mobile/src/components/pr-review/discussion/reply-input.tsx
• apps/mobile/src/components/pr-review/merge/pr-merge-sheet.tsx
• apps/mobile/src/components/pr-review/merge/pr-merge-sheet.test.tsx
• apps/mobile/src/components/pr-review/pr-review-submit.tsx

---

_{Reviewed by deepseek-flash-latest · Input: 99.5K · Output: 21.8K · Cached: 2.2M}

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

[iscekic]

bot: Android proof of the provider-aware reconnect copy, captured against the real local routers on this branch's head.

Setup: local dev stack (Next.js, Postgres, tRPC) with GitLab served by one local stub at the network boundary (reads, project settings, approvals, credential broker), Android emulator signed in with an owned fixture account in a fixture organization that owns the fixture GitLab integration, on a fixture merge request.

Trigger exercised: the fixture account's organization membership is removed while the provider-review screen is open, so the app's next provider write reaches the real router, where the organization access guard rejects it before any GitLab request is sent. The stub log shows reads and broker calls only — no GitLab write. That rejection is what the app classifies as a reconnect and repaints here.

Observed (each capture is the sheet after the rejected mutation):

1. Merge sheet: providerReview.mergePullRequest answered 401. The status line and the notice title both read "GitLab connection expired", with the GitLab connection notice body and its Check connection control.
2. Discussion reply input: providerReview.replyToComment answered 401. The inline error reads "GitLab connection expired" above the same notice.
3. Conversation comment composer: providerReview.addComment answered 401. The inline error reads "GitLab connection expired".

Limitations: the Bitbucket arm shares the same selection helper and the review-submit sheet uses the same display helper with the provider term; both are covered by the unit tests, not by this emulator run. The run does not prove GitLab accepts a real request — it proves the client copy on the app's own rejection path, which is what this change selects.