[iscekic]

Change

• Upgrade mobile to Expo SDK 58 (~58.0.10), stable React Native 0.88.0 and React 19.3, following the selected SDK's bundled native ranges and the existing release-age policy.
• Port versioned native patches and migrate affected Router, native refs, filesystem, idle scheduling and SwiftUI APIs. Preserve the existing approved Sentry/FlashList divergences and share-intent peer-warning policy.
• Complete SDK 58 native integration: Android source-built background modules and AGP compatibility, Router's CSS native-component registry, widgets registration and native factory construction, iOS scene-forwarded lifecycle hooks, inference TurboModule bindings, and noncopyable Swift JavaScript ownership.
• Anchor root/shared React types to the existing root/web runtime while mobile keeps its SDK-matched types, making cached installs deterministic.
• Remove obsolete source-text/version-pinned checks rather than re-pin implementation details; retain behavioral contract suites. Update existing native compatibility documentation.
• Keep the code-review service's single infra retry available when a pre-dispatch sandbox or workspace setup failure leaves the failed session's usage unmeasurable. That failure stage runs no model work, so the spend guard no longer blocks the retry there.

Verification

Android — real native client and local backend

• Built and installed an x86_64 SDK 58 development client on the VM emulator. Signed in with an owned fake account against the isolated local backend; optional analytics off. Home rendered successfully.
• Typed a draft, verified Back → Keep editing retains it, then Back → Discard returns Home. No agent started. Compact native launcher header/tab labels rendered and Updates opened; viewport defaults restored.
• Applied the existing running-only glanceable fixture. The native ongoing card displayed 3 Working. Clearing the badge retained both the ongoing card and an unrelated local SDK notification. This emulator launcher reports no numeric badge support; numeric badge display is not claimed.
• Exercised two real cold OS WorkManager refreshes with the app behind the launcher. Both succeeded, and task IDs advanced within the same native React context. The cold development-client proof temporarily embedded the unmodified app bundle in ignored generated debug assets; the temporary asset and scheduler fixture were removed afterward.
• Native inference initialization reached the model loader's absent-file boundary. No model download or inference request was sent.
• Verified moveA11yFocus returns true for a mounted prompt host and observed its real Android TYPE_VIEW_FOCUSED event. Under sustained native scheduler load, the cache-maintenance timer fallback completed in 507 ms while higher-priority work remained queued.

iOS — rebuilt simulator client and ActivityKit

• Native development-client build succeeded: https://github.com/Kilo-Org/cloud/actions/runs/39435140822. Installed the fingerprint-matched client through the leased iOS lane; JavaScript/backend stayed on this VM.
• Signed in to the owned fake account, disabled optional analytics before consent, and observed Home. Aggregate ActivityKit banner displayed 3 Working; tapping it opened Agents. The session fixture rendered its native elapsed date (1 minute) and detail rows.
• Native getInfo/getProps, default end, active-versus-retained-ended discovery, and immediate dismissal passed against real ActivityKit instances. Native inference JSI reached the absent-file model boundary. Dispatcher registration/replacement and JSI initialization passed again after a real runtime reload.
• Limits: a one-second ActivityKit .stale transition was not observed in the simulator probe; no accelerated stale-transition claim. OS-triggered Shortcuts/App Intent delivery requires physical hardware; this simulator proof covers native registration/replacement and runtime teardown, not that delivery path.
• Released the fixture hold, dismissed owned activities, and released the lane. Screenshots below are app-only crops where unrelated system notifications were present.

Automated checks

• Full mobile suite: 1,191 files; 17,879 passed, 2 skipped, including deadline-first/idle-first cache-maintenance race coverage and direct coverage of the accessibility focus dispatch and announcement error path.
• Full web suite: 1,204 suites; 20,415 passed, 3 skipped with two workers and a 30-second VM deadline. Initial default five-second deadlines caused unrelated DB fixture/import timeouts; no timeout changes committed. Jest reported a worker teardown warning.
• Full workspace typecheck and lint passed. Mobile unused/config checks, frozen lockfile install, formatting and Expo doctor (20/20) passed.
• Root script suites passed, including dependency SBOM and mobile release checks. The real production closure resolved Expo 58.0.10 with integrity and no skipped dependencies. The headless tmux fixture required TERM=xterm-256color.
• Code-review status suite: 153 passed after the retry-boundary change, including a new pre-dispatch workspace setup case; removing the new allowance fails that case. Web typecheck and lint clean.
• Reproduced CI's React type-identity failure with a controlled cached root type link in an isolated checkout. A normal frozen install with the explicit root type dependency repaired the link; tRPC and web typechecks passed. Full workspace typecheck also passed after the fix.

Visual proof: #8307 (comment).

Proxy answers

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

1. Question: SDK target: Which Expo SDK 58 release should the upgrade target? Age-gate facts at 2026-10-19T23:45Z: 58.0.9 (published 10-13, eligible), 58.0.10 (published 10-14T22:11, eligible, newest), 58.0.11 (10-15T19:40, not eligible until ~10-20T05:27Z), 58.0.16 latest (10-19, not eligible).
   Answer: expo ~58.0.10 (Recommended)
   Confidence: 0.72 · Precedent: Respect the repository's release-age rule and use the newest eligible release rather than an older one (prior owner precedent: chose "Wait for 24.14.0" over the recommended older release). 58.0.10 is the newest release that clears the gate, as the brief asks.
2. Question: React Native: SDK 58.0.10's bundled map pins react-native 0.88.0-rc.4. Stable 0.88.0 exists (published 2026-10-15T14:08Z) but is inside minimumReleaseAge until ~2026-10-20T08:11Z, and no exemption exists. Which RN should the upgrade use?
   Answer: Wait for 0.88.0 stable
   Confidence: 0.50 · Precedent: Respect the release-age rule and wait for the newest release rather than pin an older version or add an exemption (prior owner precedent: "Wait for 24.14.0"). Do the patch regeneration and e2e prep in parallel while the gate clears.
3. Question: Version set: The 58.0.10 map also moves third-party native modules: gesture-handler ^3 private major 2.32.0 -> ~3.3.0, screens 4.26.2 -> ~4.30.0, safe-area-context 5.7.0 -> ~5.10.1, keyboard-controller 1.22.6 -> 1.22.7, react 19.2.3 -> 19.3.0, svg/webview minor. Follow the map?
   Answer: Follow the map (Recommended)
   Confidence: 0.80 · Precedent: Fix the root cause and the class of the issue: "fix class of issue preventing progress". Staying outside the SDK's tested native set invites repeat doctor and build failures; typecheck and the native build catch API breaks.
4. Question: share-intent peer: expo-share-intent's latest (8.0.1) declares peer expo ^57 and no SDK 58 release exists. pnpm strict peers are off, so it installs with a warning.
   Answer: Keep 8.0.1, accept the peer warning (Recommended)
   Confidence: 0.60 · Precedent: Do the least work possible with no drop in quality: "cut all the unnecessary crap out". A metadata-only patch adds no quality, and waiting would block the upgrade indefinitely.
5. Question: RN wait: RN 0.88.0 stable becomes eligible at ~2026-10-20T08:11Z. How should the session use the wait?
   Answer: Build the port against rc.4 now, swap to 0.88.0 when eligible, then run native E2E (Recommended)
   Confidence: 0.85 · Precedent: Run independent work in parallel and use the wait time: "you can do e2e while waiting for CI, save some time". Also "we want to catch errors in PRs, as early as possible".
6. Question: iOS proof: apps/mobile/package.json changes count as iOS-specific. The iOS-only patch surfaces are Live Activity, widgets, dev-launcher header, @expo/ui date styles. How much iOS driving is required?
   Answer: Boot the app on the simulator + prove the Live Activity surface (Recommended)
   Confidence: 0.65 · Precedent: Verify on both iOS and Android: "Both iOS and Android need to be verified". Proof must exercise the ported patched code, not only show a boot.
7. Question: Excluded files: The SDK 58 upgrade cannot typecheck without touching files under excluded features: they use useRef<TextInput> and call focus/blur/clear on it, and React Native 0.88's generated types split component and instance types. Reverting them leaves 7 type errors across 5 files; the public-text gate refuses any commit that changes those paths. How should I resolve it?
   Answer: Patch RN's generated TextInput type to stay legacy-compatible (Recommended)
   Confidence: 0.70 · Precedent: Product scope: never touch excluded features; those routes are EOL and forbidden. Autonomy: "a work item must converge".
8. Question: Dev client: The workspace already exempts Expo development tools from release age. The SDK map requests expo-dev-client ~58.0.13, so a fresh resolution can select the younger 58.0.14 and its launcher instead of the age-eligible pair. Which constraint should this upgrade use?
   Answer: Use existing development-tool exemptions
   Confidence: 0.55 · Precedent: Respect the repository's release-age rule, and wait for the newest release rather than pin an older version or add an exemption (prior owner precedent: chose "Wait for 24.14.0" over the recommended older release). The existing exemption is part of the repo's current rule, so it adds nothing new. Keeping the bundled range matches the brief, and pinning an older build is what the owner rejected.
9. Question: AGP 9: SDK 58 moves Android to AGP 9, which now rejects AppsFlyer’s existing SDK and purchase-connector AARs because both declare namespace com.appsflyer. Android documents an opt-out for this migration. How should this build handle the vendor packaging?
   Answer: Use documented AGP compatibility flag
   Confidence: 0.72 · Precedent: Speed and least work: "do the least amount of work possible, with no drop in quality" (prior owner precedent); maintaining a forked vendor artifact adds ongoing work with no quality gain over the documented opt-out
10. Question: Commit gate: The public-text gate blocks the regenerated lockfile because mobile’s shared workspace dependency names include excluded-feature tokens. All excluded source files are untouched. The installed gate has no generated-lockfile exception; restoring those resolution lines would make the native dependency graph inconsistent. How should the drain resolve this policy/tooling conflict?
    Answer: Refresh the drain gate policy
    Confidence: 0.85 · Precedent: Never accept blocked; treat it as a workflow bug and fix the class: prior owner precedent, "a work item must converge". Also, never hand-edit generated files: prior owner precedent, "generated files must always be regenerated on conflict".
11. Question: Gate refresh: The normal synced setup bundle still carries the old gate. The workflow repository’s current main already contains the generated-lockfile exception. May I refresh the installed gate module byte-for-byte from that canonical upstream file and run the commit in a fresh gated omp process? The source exclusions and public-text review remain active.
    Answer: Install canonical upstream gate update
    Confidence: 0.80 · Precedent: Never accept blocked as an end state: prior owner precedent, "blocked is not an acceptable end state". Workflow changes reach the fleet automatically: prior owner precedent, git pull every 5 minutes with a restart on change.
12. Question: Gesture API: Gesture Handler 3.3 still implements the existing Gesture.Pan builder, but marks it deprecated. Type-aware lint now fails its callers, including one in an excluded feature that must remain untouched. What policy should this SDK upgrade use?
    Answer: Allow the supported builder API in lint
    Confidence: 0.60 · Precedent: Speed and least work: "do the least amount of work possible, with no drop in quality". Product scope: never touch excluded features. A narrow lint allowance leaves the excluded caller untouched and adds no new dependency patch to maintain.
13. Question: Retrigger review: Head review on 62ae449 failed inside the review service before it ran ('Review failed: Workspace setup failed', attempt 7aaf0049). The App-owned check cannot be rerequested (404) and the status callback skipped the infra auto-retry because usage was unmeasurable. The head only adds two mobile tests; CI is fully green and the accessible tests pass. Which recovery should I use?
    Answer: Don't block, and don't add an empty or filler commit. This is a workflow bug, so fix the class. The status callback must auto-retry infra failures like 'Review failed: Workspace setup failed' even when usage is unmeasurable, because a setup failure ran nothing and cost nothing. Fix that path, then use it to rerun the head review on 62ae449. If the fix can't land from this session, push one empty commit as a one-time fallback so the item converges, and note the infra gap in the PR.
    Confidence: 0.50 · Precedent: Autonomy: 'Never accept blocked or failed as an end state; treat a blocked item as a workflow bug' (55c9c80332a7: "blocked is not an acceptable end state"; 2f71af3a787e: "a work item must converge"), plus 'fix class of issue preventing progress' (7f3470e0ba6f)

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​expo-audio@​57.0.5 ⏵ 58.0.9			+1	+1
	npm/​@​expo/​app-integrity@​57.0.2 ⏵ 58.0.2	+1			+1
	npm/​expo-application@​57.0.3 ⏵ 58.1.1				+1
	npm/​@​expo/​ui@​57.0.21 ⏵ 58.0.17	+1		+1
	npm/​react-native-safe-area-context@​5.7.0 ⏵ 5.10.1	+1		+1
	npm/​expo-router@​57.0.24 ⏵ 58.0.19			+1
	npm/​@​types/​react@​19.3.0
	npm/​expo-system-ui@​57.0.4 ⏵ 58.0.5			+1	+1
	npm/​expo-dev-client@​57.0.19 ⏵ 58.0.14	+1		+1	+1
	npm/​@​expo/​fingerprint@​0.20.13 ⏵ 0.21.5	+1		+1	+1
	npm/​expo-constants@​57.0.20 ⏵ 58.0.12			+1
	npm/​expo-linking@​57.0.11 ⏵ 58.0.13			+1
	npm/​expo-asset@​57.0.18 ⏵ 58.0.15			+1
	npm/​expo-battery@​57.0.3 ⏵ 58.0.3				+1
	npm/​expo-store-review@​57.0.3 ⏵ 58.0.2				+1
	npm/​expo-device@​57.0.2 ⏵ 58.0.5				+1
	npm/​expo-widgets@​57.0.22 ⏵ 58.0.17			+1	+1
	npm/​expo-keep-awake@​57.0.2 ⏵ 58.0.3	+1		+1
	npm/​expo-task-manager@​57.0.21 ⏵ 58.0.11				+1
	npm/​expo-status-bar@​57.0.1 ⏵ 58.0.3			+1	+1
	npm/​expo-clipboard@​57.0.2 ⏵ 58.0.3
	npm/​expo-background-task@​57.0.21 ⏵ 58.0.10				+1
	npm/​expo-apple-authentication@​57.0.2 ⏵ 58.0.2				+1
	npm/​expo-secure-store@​57.0.4 ⏵ 58.0.2			+1	+2
	npm/​expo-linear-gradient@​57.0.2 ⏵ 58.0.3	+1		+1	+1
	npm/​expo-video@​57.0.5 ⏵ 58.0.10			+1	+1
	npm/​expo-blur@​57.0.3 ⏵ 58.0.3	+1		+1	+1
	npm/​react@​19.2.3 ⏵ 19.3.0	+1		+1
	npm/​expo-localization@​57.0.2 ⏵ 58.0.4			+1	+1
	npm/​expo-notifications@​57.0.21 ⏵ 58.1.4			+1
	npm/​expo-haptics@​57.0.3 ⏵ 58.0.6			+1
	npm/​expo-image-manipulator@​57.0.20 ⏵ 58.0.14			+1
See 22 more rows in the dashboard

View full report

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Priority	Alert  (click "▶" to expand/collapse)	Action
	Potential security risk (AI signal): npm expo-sqlite is 70.0% likely risky Notes: No evidence of overt malware (e.g., network exfiltration, backdoor logic, or obfuscated payloads) is visible in this snippet. However, the component exposes a high-risk capability: it executes caller-supplied SQLite SQL text (executeQuery) and performs unsafe identifier interpolation in PRAGMA table_info for schema retrieval (getTableSchema). If an attacker can reach or influence these message handlers or parameters, they can likely achieve unauthorized read/write access and metadata/data exfiltration via returned results and error messages. This should be treated as a security-critical design requiring strict authentication/authorization and strong SQL/identifier allowlisting or sandboxing. Confidence: 0.70 Severity: 0.88 From: pnpm-lock.yaml → npm/expo-sqlite@58.0.13 ℹ Read more on: This package | This alert | What are AI-detected potential security risks? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system identified potential security problems in this package. It is advised to review the package thoroughly and assess the potential risks before installation. You may also consider reporting the issue to the package maintainer or seeking alternative solutions with a stronger security posture. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/expo-sqlite@58.0.13. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.	Warn
	Potential security risk (AI signal): npm expo-widgets is 98.0% likely risky Notes: No clear malware, data theft, or unauthorized network behavior is present. The main security concern is an unconstrained targetName feeding a recursive filesystem deletion, which can delete unintended directories if supplied by untrusted configuration. Direct XML interpolation is also unsafe for untrusted values. Confidence: 0.98 Severity: 0.76 From: pnpm-lock.yaml → npm/expo-widgets@58.0.17 ℹ Read more on: This package | This alert | What are AI-detected potential security risks? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system identified potential security problems in this package. It is advised to review the package thoroughly and assess the potential risks before installation. You may also consider reporting the issue to the package maintainer or seeking alternative solutions with a stronger security posture. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/expo-widgets@58.0.17. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.	Warn
	Potential security risk (AI signal): npm expo is 66.0% likely risky Notes: This module is a dynamic JavaScript loader that injects a script tag whose src is directly controlled by the caller and appends it to document.head, which can result in attacker-controlled code execution in the browser if url/options are not strictly validated and allowlisted. In non-browser/ DEV mode it delegates to a component named for fetch-then-evaluate behavior, increasing potential execution impact beyond mere script loading. No explicit stealer/malware routine is visible in this snippet, but the arbitrary remote-code-load primitive is a substantial security risk requiring strong caller-side controls and appropriate CSP/network restrictions. Confidence: 0.66 Severity: 0.78 From: pnpm-lock.yaml → npm/expo@58.0.10 ℹ Read more on: This package | This alert | What are AI-detected potential security risks? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system identified potential security problems in this package. It is advised to review the package thoroughly and assess the potential risks before installation. You may also consider reporting the issue to the package maintainer or seeking alternative solutions with a stronger security posture. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/expo@58.0.10. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.	Warn
	Potential security risk (AI signal): npm expo is 72.0% likely risky Notes: This snippet is a development WebSocket command handler, but it contains a critical high-impact sink: it injects and executes JavaScript received over the WebSocket by assigning data.params.moduleData.code to script.text on a dynamically created <script type='module'>. If the WebSocket endpoint/messages are not strictly restricted to a trusted dev server (or if dev mode is enabled in an unintended context), an attacker could achieve arbitrary code execution in the browser. Callback invocation via global listener registries further broadens potential effects beyond direct injection. Confidence: 0.72 Severity: 0.78 From: pnpm-lock.yaml → npm/expo@58.0.10 ℹ Read more on: This package | This alert | What are AI-detected potential security risks? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system identified potential security problems in this package. It is advised to review the package thoroughly and assess the potential risks before installation. You may also consider reporting the issue to the package maintainer or seeking alternative solutions with a stronger security posture. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/expo@58.0.10. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.	Warn
	Potential security risk (AI signal): npm expo is 82.0% likely risky Notes: High security risk: this module can execute arbitrary JavaScript fetched over the network via eval(body) on HTTP 200 responses. Unless the url and the fetched response are strictly integrity-checked and fully trusted, this constitutes an effective remote code execution capability consistent with supply-chain/active content execution hazards. Additionally, non-200 error handling may leak remote body contents through thrown error messages. Confidence: 0.82 Severity: 0.92 From: pnpm-lock.yaml → npm/expo@58.0.10 ℹ Read more on: This package | This alert | What are AI-detected potential security risks? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system identified potential security problems in this package. It is advised to review the package thoroughly and assess the potential risks before installation. You may also consider reporting the issue to the package maintainer or seeking alternative solutions with a stronger security posture. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/expo@58.0.10. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.	Warn
	Potential security risk (AI signal): npm metro-runtime is 76.0% likely risky Notes: This module is an HMR client that intentionally performs runtime JavaScript injection by executing server-supplied module code via eval/globalEvalWithSourceUrl. In the absence of integrity/authentication/origin checks in this module, it can act as a remote code execution channel if an attacker can control or spoof the WebSocket endpoint or messages. No additional malicious behaviors (exfiltration/credential theft/system modification) are evident in this fragment beyond the eval-based injection pipeline. Confidence: 0.76 Severity: 0.82 From: pnpm-lock.yaml → npm/drizzle-orm@0.45.2 → npm/react-native-css@3.0.7 → npm/@sentry/react-native@8.29.0 → npm/babel-preset-expo@58.0.14 → npm/expo@58.0.10 → npm/react-native@0.88.0 → npm/metro-runtime@0.87.1 ℹ Read more on: This package | This alert | What are AI-detected potential security risks? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: An AI system identified potential security problems in this package. It is advised to review the package thoroughly and assess the potential risks before installation. You may also consider reporting the issue to the package maintainer or seeking alternative solutions with a stronger security posture. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/metro-runtime@0.87.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.	Warn

View full report

[iscekic]

bot: Verified the rebuilt SDK 58 clients against an isolated local backend with an owned fake account and optional analytics off.

• Android: signed-in Home; native ongoing card retained through badge clearing; compact development-launcher header and tab labels.
• iOS: signed-in Home; actual ActivityKit aggregate banner showing 3 Working; session fixture rendering the native elapsed date and detail row. Tapping the aggregate banner opened Agents; native ended-instance discovery and dismissal also passed.

Activity screenshots are explicitly card-only crops. Unrelated system notifications were excluded; all visible activity data comes from the existing development fixtures. Screenshots do not claim accelerated ActivityKit staleness or physical-device Shortcuts delivery.

[iscekic]

bot: Reviewed the dependency warning contexts. The SQLite handlers are in SQLiteDevToolsClient.ts and initialization/registration return outside DEV. The widgets prebuild entry fixes targetName to ExpoWidgetsTarget before passing it to source generation. The Expo and Metro findings identify their intentional bundle/HMR execution primitives; those remain trusted build/development inputs, not a new application input path. No Socket suppression or global policy change was applied. These warnings remain visible for dependency review.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (3 files)

• apps/mobile/src/lib/a11y/announce.test.ts - no issues; the new success case asserts sendAccessibilityEvent(node, 'focus') and a true return, and the throwing-announcement case restores the swallowed-failure coverage, resolving the prior suggestion
• apps/web/src/app/api/internal/code-review-status/[reviewId]/route.ts - no issues; allowing the single infra retry for pre_dispatch + workspace_setup_failed matches the delivery classifier, which only assigns that stage when the failing message was never accepted, and getSessionUsageFromBilling is bounded by reviewCreatedAt so earlier session usage cannot be masked
• apps/web/src/app/api/internal/code-review-status/[reviewId]/route.test.ts - no issues; the new positive case covers the workspace-setup allowance and the renamed negative case keeps the post-dispatch stage-mismatch guard fail-closed

Previous Review Summaries (2 snapshots, latest commit c249e6e)

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

Previous review (commit c249e6e)

Status: 1 Issue Found | Recommendation: Merge

Executive Summary

The incremental commit bounds deferred cache maintenance with a 500 ms timer fallback and adds regression coverage; the single remaining item is the previously raised accessibility test-coverage suggestion, which has not been implemented.

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	1

Issue Details (click to expand)

SUGGESTION

File	Line	Issue
apps/mobile/src/lib/a11y/announce.test.ts	50	The migrated moveA11yFocus still has no positive test (native sendAccessibilityEvent(node, 'focus') dispatched, returns true); remaining cases only assert false, so a regression that never dispatches focus or always returns false would still pass.

Files Reviewed (3 files)

• apps/mobile/README.md - no issues (documentation only; no images added)
• apps/mobile/src/lib/query/schedule-cache-maintenance.ts - no issues; the 500 ms timer fallback plus { timeout: 500 } idle deadline are both cancelled by the shared completed guard, so maintenance runs once and neither callback outlives the flush
• apps/mobile/src/lib/query/schedule-cache-maintenance.test.ts - no issues; both race orders (deadline first, idle first) assert exactly-once delivery and timer release

Carried forward after targeted re-check: apps/mobile/src/lib/a11y/announce.test.ts (1 issue). Dropped as no longer valid: apps/mobile/package.json release-age warning (react-native-keyboard-controller@1.22.7 was published 2026-10-12, so it clears the 6,842-minute gate and was resolved in the lockfile without an exact exemption) and the ConversationMessages.test.ts writable-atom suggestion (the author's Jotai self-write mechanism evidence; the fixture is never written in the test).

Previous review (commit 008ff78)

Status: 4 Issues Found | Recommendation: Address before merge

Executive Summary

The SDK 58 migration is broadly mechanical and well covered, but the keyboard-controller pin moved to 1.22.7 without moving its exact-version release-age exemption, and the rewrite dropped positive coverage for the migrated accessibility focus path.

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	3

Fix these issues in Kilo Cloud

Issue Details (click to expand)

WARNING

File	Line	Issue
apps/mobile/package.json	129	react-native-keyboard-controller pinned to 1.22.7, but minimumReleaseAgeExclude and the release-age contract test still exempt only 1.22.6. Exact entries do not cover the new version, so a future fresh resolution can be rejected by the age gate and the policy test cannot detect the drift.

SUGGESTION

File	Line	Issue
apps/mobile/src/lib/a11y/announce.test.ts	50	The only positive test for moveA11yFocus (native focus dispatched, returns true) and the throwing-announcement test were deleted; remaining cases only assert false.
apps/web/src/components/cloud-agent-next/ConversationMessages.test.ts	744	Writable atom mocks call set on themselves, so any future write recurses until stack overflow.
apps/mobile/src/lib/query/schedule-cache-maintenance.ts	2	requestIdleCallback(run) has no timeout and can be starved by continuous JS work; useAfterIdle in the same PR bounds its wait for this reason.

Files Reviewed (186 files)

• apps/mobile/package.json, root package.json, pnpm-workspace.yaml, apps/mobile/tsconfig.json, apps/mobile/.oxlintrc.json - 1 issue
• apps/mobile/app.config.ts, apps/mobile/plugins/** - no issues
• apps/mobile/modules/kilo-app-actions/** (Kotlin, Swift, tests) - no issues
• apps/mobile/src/app/**, apps/mobile/src/components/**, apps/mobile/src/lib/** - 3 issues
• apps/mobile/src/glanceable-ios/**, apps/mobile/src/lib/glanceable/** - no issues
• patches/** (react-native, expo-widgets, expo-modules-core, expo-task-manager, expo-background-task, expo-dev-launcher, expo-notifications, expo-router, router-server, @expo/ui, llama.rn, react-native-css, react-native-appsflyer) - no issues
• apps/mobile/src/**/*.test.*, apps/web/src/components/cloud-agent-next/ConversationMessages.test.ts, scripts/mobile-sbom-pnpm.test.mjs, dev/local/*.test.ts - 2 issues
• apps/mobile/README.md, apps/mobile/AGENTS.md - no issues (no images added; no HTML <img> usage)
• pnpm-lock.yaml (generated) - not reviewed line by line

---

_{Reviewed by deepseek-v4.1-flash-1017 · Input: 62.6K · Output: 10.3K · Cached: 1M}

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