Skip to content

docs(mobile): record why jotai stays on 2.x - #8204

Open
iscekic wants to merge 3 commits into
mainfrom
drain/jotai-major-pin-reason
Open

iscekic wants to merge 3 commits into
mainfrom
drain/jotai-major-pin-reason

Conversation

@iscekic

@iscekic iscekic commented Oct 20, 2026 •

Copy link
Copy Markdown
Collaborator

Change

Adds a dependency note in apps/mobile/AGENTS.md that records the decision on
the jotai major. No dependency, lockfile or source change.

  • jotai stays on 2.x, and the four pins move together: apps/mobile,
    apps/web, apps/extension and packages/cloud-agent-sdk.
  • The note says why, and what unblocks the 3.x major.

Why

The dependency finding asks for either the age-eligible 3.0.1 upgrade or a
recorded reason for staying on 2.20.3. The upgrade is blocked by coupled atom
types across workspace packages, not by the release gate: 3.0.1 was published
2026-09-29 and clears minimumReleaseAge (6842 minutes).

What was measured

@kilocode/cloud-agent-sdk creates the session atoms and apps/mobile reads
them through its own jotai hooks, so both sides need the same major.

  1. apps/mobile on jotai@3.0.1, SDK still on 2.18.1:
    pnpm --filter kilo-app typecheck reports 153 errors across
    session-detail-content.tsx, session-provider.tsx, suggest-tool-card.tsx
    and their helpers. A 2.x Atom is not assignable to the 3.x type: 2.x
    read options still require setSelf, 3.x options carry only signal.
  2. Moving packages/cloud-agent-sdk to 3.0.1 as well clears them:
    • pnpm --filter kilo-app typecheck: clean;
    • pnpm --filter kilo-app test: 1194 files, 17,898 passed, 2 skipped;
    • pnpm --filter @kilocode/cloud-agent-sdk typecheck: clean;
    • pnpm --filter @kilocode/cloud-agent-sdk test: 34 suites, 1714 tests,
      after letting jest transform the ESM-only package.
  3. That state fails pnpm --filter web typecheck (3 errors in
    ConversationMessages.test.ts, atoms built for SessionManager['atoms']),
    and apps/web cannot take 3.x: jotai-minidb@0.0.8, the latest release,
    imports atomFamily from jotai/vanilla/utils and calls setSelf.
    • jotai@3.0.1 vanilla/utils exports neither atomFamily nor loadable;
    • jotai@3.0.1 internals never pass setSelf;
    • jotai-minidb backs web session persistence and worktree review drafts.
  4. Restoring apps/mobile 2.20.3 with the SDK on 2.18.1 gives a clean
    pnpm --filter kilo-app typecheck, which is the state of this branch.

The upgrade therefore needs a jotai-minidb release that supports jotai 3,
or a replacement for the web IndexedDB persistence layer, before any of the
four pins moves.

Verification

No product behaviour changes, so there is no visual surface to exercise. The
runs above are the evidence: every listed configuration was executed on this
work VM, and the final tree keeps the dependency versions unchanged.

Proxy answers

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

  1. Question: Scope: jotai is pinned in four places (apps/mobile 2.20.3; apps/web, apps/extension, packages/cloud-agent-sdk 2.18.1). The SDK creates the session atoms that mobile reads through its own hooks. How far should this upgrade go?
    Answer: apps/mobile only
    Confidence: 0.70 · Precedent: Speed and least work: "do the least amount of work possible, with no drop in quality" (7f3470e0ba6f); Git and PRs: put each separate concern in its own PR (debabfb38c82)
  2. Question: Mount timing: jotai 3 drops the extra post-mount render of useAtomValue; a write landing between first render and subscription is missed until the next change. How should the transcript reads handle that?
    Answer: Keep useAtomValue
    Confidence: 0.55 · Precedent: Speed and least work: "skip work that doesn't need to be done" (00eb2a1d3e4b)
  3. Question: E2E depth: What should the Android proof exercise for the jotai-driven UI?
    Answer: Live streaming fixture
    Confidence: 0.85 · Precedent: Proof and verification: "fixtures are fine for hard to capture states" (269375d6e466); logs and screenshots are mandatory proof (55c9c80332a7)
  4. Question: Fallback: If the mounted tests or the emulator show that a v3 store reading the SDK's v2 atoms misbehaves, what should the PR do?
    Answer: Align the SDK to jotai 3 in the same PR
    Confidence: 0.70 · Precedent: Autonomy: never accept blocked or failed as an end state, "a work item must converge" (2f71af3a787e)
  5. Question: Outcome: Facts: (1) apps/mobile on jotai 3 with the SDK on jotai 2 fails typecheck with 153 errors — v2 atoms are not assignable to v3 atom types because v2's read options require setSelf and v3's do not. (2) Moving packages/cloud-agent-sdk to 3.0.1 fixes that: mobile typechecks and its full suite (1194 files / 17,898 tests) passes, SDK tests pass after a jest ESM transform allowance. (3) But then web typecheck fails in one test that builds atoms for SessionManager['atoms'], and web cannot move to jotai 3 because jotai-minidb@0.0.8 (the latest release) imports atomFamily from jotai/vanilla/utils and calls setSelf, both removed in v3, so web's build would break. What should this work item deliver?
    Answer: Document the pin reason and defer the major
    Confidence: 0.55 · Precedent: Product scope: janitor work is limited to the mobile app and services strictly tied to it (session 55c9c80332a7, "explorer loop is strictly for the mobile app"). Forcing the upgrade would mean swapping out web's IndexedDB persistence library, which is outside that scope. A no_change ending needs proof that the finding is wrong, and this finding is valid but blocked. Documenting the block lets the item converge with a PR (session 2f71af3a787e, "a work item must converge").

@iscekic iscekic added drain Work item from the findings drain janitor:dependencies Findings drain: dependency update work item labels Oct 20, 2026
Comment thread apps/mobile/AGENTS.md Outdated
@kilo-code-bot

kilo-code-bot Bot commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The note now states a reachable trigger — a jotai-minidb release supporting jotai 3 — and its factual claims (four pins on 2.x, jotai-minidb@0.0.8 in apps/web, minimumReleaseAge: 6842) match the tree.

Files Reviewed (1 file)
  • apps/mobile/AGENTS.md
Previous Review Summary (commit bb1a0b7)

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

Previous review (commit bb1a0b7)

Status: 1 Issue Found | Recommendation: Address before merge

Executive Summary

Documentation-only change recording why jotai stays on 2.x; one wording issue makes the revisit trigger unlikely to ever fire, since jotai-minidb is at 0.0.8.

Overview

Severity Count
CRITICAL 0
WARNING 0
SUGGESTION 1
Issue Details (click to expand)

SUGGESTION

File Line Issue
apps/mobile/AGENTS.md 48 "3.x release" of jotai-minidb (currently 0.0.8) is an unlikely trigger; phrase as support for jotai 3
Files Reviewed (1 file)
  • apps/mobile/AGENTS.md - 1 issue

Verified against the tree: jotai is pinned at 2.20.3 in apps/mobile and 2.18.1 in apps/web, apps/extension and packages/cloud-agent-sdk, jotai-minidb@0.0.8 is an apps/web dependency, and pnpm-workspace.yaml sets minimumReleaseAge: 6842. The note's factual claims match the repository.

Fix these issues in Kilo Cloud


Reviewed by deepseek-v4.1-flash-1017 · Input: 31.7K · Output: 2.3K · Cached: 233.9K

Review guidance: REVIEW.md from base branch main

@iscekic iscekic added merge:human Substantive functional risk requires human review. merge:bot Bot-owned review; readiness checks still apply before merging. and removed merge:human Substantive functional risk requires human review. labels Oct 20, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

drain Work item from the findings drain janitor:dependencies Findings drain: dependency update work item merge:bot Bot-owned review; readiness checks still apply before merging.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants