Codify workflow parity requirements

AGENTS.md

@@ -95,6 +95,17 @@ These features are product requirements, not “nice to have” ideas.
 - Phone should optimize for low tap count, not purity of mobile patterns.
 - The stacked phone layout is the current preferred phone direction.
 - Do not reintroduce the abandoned phone flow mode unless explicitly requested.
+- Keep the product feeling like the same application on desktop, Android phone,
+  and Android tablet.
+- Platform adaptation is allowed for layout and spacing, not for changing the
+  user's mental model of the workflow.
+- Use the same action names, the same primary next steps, and the same workflow
+  order across platforms unless there is a hard platform constraint.
+- Treat workflow prominence and reachability as product behavior, not visual
+  polish. A feature is not parity-complete if it technically exists but is
+  harder to discover or reach on one platform.
+- Prefer shared workflow decisions with platform-specific presentation, rather
+  than platform-specific workflow branches.
 - Make all test strings `Heist Movie` themed. Use characters, crews, casinos,
   vaults, and locations from heist movies so test fixtures stay obviously fake
   and consistent with the product theme.
@@ -117,6 +128,14 @@ These features are product requirements, not “nice to have” ideas.
   implement the minimum code to satisfy them,
   verify with `go test ./...` and relevant lint checks,
   and commit each completed behavior.
+- For cross-platform UI work, behavior tests must cover workflow parity, not
+  just feature or label parity.
+- For lifecycle, open, unlock, sync, and other primary flows, tests should
+  assert the same conceptual next step across desktop, phone, and tablet
+  layouts.
+- When Android or phone UX is part of the slice, verify real reachability on an
+  emulator or device for the exact flow being changed. Do not count “the same
+  buttons exist somewhere on screen” as sufficient validation.
 - Only stop before the requirements are satisfied if the work is genuinely blocked by a missing decision, missing external dependency, or a hard technical constraint that cannot be resolved within the repo.
 - If blocked, state the blocker concretely and stop only at that point.
 

TODO.md

@@ -11,6 +11,36 @@ The product is not complete until the global exit criteria at the end of this fi
 These items came from a hands-on emulator and desktop walkthrough.
 They should be treated as usability work, not just polish.
 
+### Cross-Platform Workflow Parity
+
+These items are required to keep desktop, Android phone, and Android tablet
+feeling like the same application rather than three related UIs.
+
+- Workflow parity:
+  define canonical workflows for open, unlock, set up remote sync, use remote
+  sync, browse entries, and edit entries.
+- Workflow parity:
+  ensure desktop, phone, and tablet use the same action names and the same
+  primary next steps for those workflows.
+- Workflow parity:
+  remove or reduce platform-specific workflow exceptions where the same user
+  intent currently takes a different route on different form factors.
+- Testing:
+  add cross-mode behavior tests that assert workflow order and action
+  prominence, not just label presence.
+- Testing:
+  add explicit lifecycle/open-screen tests for reachability of the primary
+  action on desktop, phone, and tablet layouts.
+- Testing:
+  add explicit remote-sync workflow tests that prove setup, settings, use, and
+  removal are reachable from the same primary affordance family across modes.
+- Android verification:
+  validate changed lifecycle/open/sync workflows on the emulator or a device,
+  including with the on-screen keyboard visible.
+- Android verification:
+  treat “present but below the fold or behind an unexpected branch” as a parity
+  failure, not as acceptable platform variation.
+
 ### Primary Workflow Changes
 
 These should remain in the main user flow rather than being hidden behind a settings gear.