fix(fold): make reported screen dimensions match their coordinate-space contract
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
- Domain
- documentation, mobile, testing
Research direction
Read AGENTS.md, then inspect packages/contracts/src/fold-runtime.ts and packages/platform-apple/src/foldable/pose.ts, along with the owning response fixtures/schema and user docs/help. Run the focused contract tests and pnpm check:affected --run. Done means reported dimensions retain their native-panel values and discriminator, ambiguous panels still omit screen, and documentation no longer describes snapshot coordinates.
Written by the indexing model from the issue text.
Description
Part of #2725.
Decision: report native panel points, not an app viewport
Keep the already-released screen.display, screen.widthPt, and screen.heightPt fields and their numeric meaning. Add the required discriminator screen.coordinateSpace: "native-panel" whenever screen is present. These are the panel's native pixel dimensions divided by its point scale; do not rotate them. Explicitly state that they are not snapshot coordinates and cannot be used to place a tap. A caller needing the app viewport must take a fresh snapshot.
Example for the open Duo:
{"pose":"open","hingeAngleDegrees":180,"screen":{"display":"LCD-1","coordinateSpace":"native-panel","widthPt":669,"heightPt":951}}
Its active app window can be 951x669. That difference is expected and must be documented.
Evidence and rationale
git tag --contains e8da1e10d includes v0.21.8: fold metadata is released. Preserve the existing fields/values, add explicit meaning, and correct the false contract instead of adding aliases or breaking field names. PR #2724 and the native capture investigation in #2727 measure a 951x669 app window on the 669x951 native-point inner panel. currentOrientation describes the display and is not a sufficient app-orientation contract for a locked app. Choosing native geometry removes that inference entirely; no locked-app experiment is needed to justify these fields.
Fold remains independent of app identity and runner startup. Do not query XCTest or rotate native dimensions solely to fill this metadata.
Bounded implementation
- Update
packages/contracts/src/fold-runtime.ts,packages/platform-apple/src/foldable/pose.ts, owning response fixtures/schema where applicable, and user docs/help. - Set the literal discriminator at the report construction site. Remove every claim that these dimensions equal the next snapshot's viewport.
- Do not alter pose control, display selection, snapshot geometry, or gestures.
Acceptance and validation
- Closed native panel: 466x678; open/half-open inner panel: 669x951 for the existing measured fixture, all marked
native-panel. - Changing fixture
currentOrientationalone does not swap native dimensions. - Unresolved/ambiguous panel selection retains the existing omission of
screen; never invent a viewport. - Cover the public fold response through its owning contract tests, run focused tests and
pnpm check:affected --run, and record a local fold response on the PR head.
Ready for implementation on current main. No dependency on #2724 or #2728: their geometry evidence explains the bug, but this fix promises only native panel geometry. Follow AGENTS.md and keep one issue per PR.
- Dominant language
- TypeScript
- Stars
- 4.7k
- Forks
- 304
- Avg merge
- 12h 42m
- Merged PRs (30d)
- 463
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from callstack/agent-device
-
mutation-model: indirect-ownership self-test pins a test that stopped reaching scroll-edge-state Openbug needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
callstack/agent-device#2547 ·
-
refactor
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
callstack/agent-device#2530 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
callstack/agent-device#1869 ·
-
enhancement ready-for-agent
Difficulty 4/5 3-5 days Newbie friendliness 42/100
callstack/agent-device#2731 ·
-
bug ready-for-agent
Difficulty 5/5 Over a week Newbie friendliness 38/100
callstack/agent-device#2728 ·
All issues in callstack/agent-device
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
copse-dev/agent-pane#2953 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·