Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
日本語の概要は準備中です。原文の説明を表示しています。
Use when a screen must work without network or a mutation must survive a lost connection - local storage choice, the outbox pattern with idempotency keys, background replay, and how to test it with a fake clock and fake network.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Treat "offline" as a normal state, not an error condition: a screen that only works with a live connection is a defect on mobile. The hard part isn't detecting offline — it's making a queued mutation replay exactly once and keeping the UI honest about what's actually saved.
Follow the repo's existing choice (drift/sqflite for Flutter, Room for Android, SwiftData/Core Data for iOS) — don't introduce a second local-storage mechanism alongside one that's already there.
connectivity_plus and equivalents) report the state of the network interface, not whether the server is actually reachable — treat the server's response as the source of truth for whether a request succeeded, not the interface state alone.WorkManager (native) or the workmanager plugin (Flutter) for replay that must survive the app being backgrounded or killed.BGTaskScheduler for background replay — register and schedule it, and test on-device since the simulator's background scheduling is unreliable.Show sync status explicitly per item — pending / syncing / failed — never render an unsynced change as if it were already saved. A spinner that never resolves is worse than an honest "failed, tap to retry."
Pick one conflict rule per data type (last-write-wins, or an explicit user choice when both sides changed) and write it down in the task — don't leave it implicit in the code for the next person to infer.
Cached data with a staleness indicator beats a spinner that never resolves — show what you have, mark it as possibly stale, and update when the network returns.
adb shell cmd connectivity airplane-mode enable / disable to exercise a real reconnect, not just a mocked one.pending from failed.まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
日本語の概要は準備中です。原文の説明を表示しています。
Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping
日本語の概要は準備中です。原文の説明を表示しています。
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
日本語の概要は準備中です。原文の説明を表示しています。
Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task
日本語の概要は準備中です。原文の説明を表示しています。
How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.
日本語の概要は準備中です。原文の説明を表示しています。
Use when deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation
日本語の概要は準備中です。原文の説明を表示しています。