OUTCOMES
What this Prompt helps you deliver
- The shared contract is clear
- Target-client behavior and acceptance criteria agree
BEFORE YOU START
Before you start
- The user flow to align is explicit
- At least two target clients can run
What AI should inspect first
apps/tabtin-electronapps/tabtin-iosapps/tabtin-androidpackagesREADY TO RUN
Complete Prompt
Copy the complete Prompt with its execution and acceptance boundaries.
Align a TabTin capability across multiple clients from the real user flow and a shared contract. Do not mechanically port one platform’s UI components to another.
Read AGENTS.md, platform rules, and the relevant code in apps/tabtin-electron, apps/tabtin-ios, apps/tabtin-android, and packages. Confirm the user goal, target clients, and current differences. Trace user action → client state → API/realtime event → persistence → rerender on each client. Identify shared behavior and legitimate platform differences. The backend API must remain compatible with released clients.
Define platform-neutral state, inputs, outputs, errors, and permissions. Place shared business rules in a reusable domain or protocol layer, then implement within each platform’s navigation, lifecycle, accessibility, and offline conventions. New backend fields must be optional with safe defaults, and old clients must still request and parse responses. Do not change Daemon or a deprecated path merely for visual symmetry.
Add automated tests for the shared contract. Run Electron typechecks/tests, xcodebuild after every iOS change, and Gradle compilation after every Android change. Use the same scenario data on every target and compare success, empty, failure, denied, and re-entry states.
Report a difference table with old behavior, target behavior, implementation per client, evidence, accepted platform differences, API-compatibility conclusion, and uncovered devices. Do not commit or release clients without permission.