examples.jsonl

{"description":"## Add Apple Pay support to checkout\n\nAdd Apple Pay as a payment option in the checkout flow. Show a native Apple Pay button below the existing 'Pay with card' button. On tap, present the Apple Pay sheet. On success, mark the order as paid and navigate to the confirmation screen.","expected":"sufficient","assistant":"- Task type: feature\n- What changes: Apple Pay button added below 'Pay with card' on checkout; tap opens native Apple Pay sheet; success → order paid + navigate to confirmation\n- Expected behavior: open checkout → see Apple Pay button → tap → Apple Pay sheet → confirm → order shown as paid on confirmation screen\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Update icon\n\nUpdate the settings icon.","expected":"insufficient","assistant":"- Task type: feature\n- What changes: settings icon update — gap: which icon, where, in which states\n- Expected behavior: gap: no acceptance criteria provided\n- Questions for developer:\n  1. What is the new icon (asset/file)?\n  2. On which screens does this icon appear?\n  3. Does it apply to all themes (light/dark) or only one?\nVerdict: Insufficient"}
{"description":"## Fix double network request on cart open\n\nWhen the user opens the cart screen from the home tab, two identical GET /api/v1/cart requests are fired. Expected: exactly one request per open.","expected":"sufficient","assistant":"- Task type: bugfix\n- What changes: cart screen makes exactly one GET /api/v1/cart on open instead of two\n- Expected behavior: open cart from home tab → exactly one GET /api/v1/cart fires\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Remove deprecated AuthV1 module\n\nAfter migration to AuthV2 is complete, delete classes: AuthV1, AuthV1TokenStore and AuthV1Migrator. Update all references.","expected":"sufficient","assistant":"- Task type: tech-refactor\n- What changes: deletes AuthV1, AuthV1TokenStore, AuthV1Migrator and their references\n- Expected behavior: code compiles; sign-in/out flow on top of AuthV2 still works\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## See thread\n\nhttps://example.com/thread/12345","expected":"insufficient","assistant":"- Task type: feature\n- What changes: gap: only a link, no description of what is being changed\n- Expected behavior: gap: cannot derive any test from the ticket text alone\n- Questions for developer:\n  1. What exactly is being changed by this thread?\n  2. Which screens or modules does the change affect?\n  3. What is the expected outcome from a user perspective?\nVerdict: Insufficient"}
{"description":"## Add header X-Request-Id to POST /orders\n\nAdd `X-Request-Id: <uuid>` header to POST /orders. Backend uses this header for idempotency: a repeated request with the same id returns the same response without creating a duplicate order.","expected":"sufficient","assistant":"- Task type: api-contract\n- What changes: POST /orders now sends X-Request-Id header with a fresh UUID per request\n- Expected behavior: request has X-Request-Id; replaying the same request with the same id returns the same response, no duplicate order is created\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Support new card layout\n\nWe support a new card layout in the feed. [Design](https://example.com/design/abc)","expected":"insufficient","assistant":"- Task type: feature\n- What changes: new card layout in the feed — gap: no integration scenario\n- Expected behavior: gap: cannot tell when card appears or how user interacts\n- Questions for developer:\n  1. On which screens does the new card layout appear?\n  2. Under what conditions is it shown (always / experiment / specific data)?\n  3. What happens when the user taps it?\nVerdict: Insufficient"}
{"description":"## Change banner padding\n\nChange the padding of the home banner. [Design](https://example.com/design/xyz)","expected":"insufficient","assistant":"- Task type: feature\n- What changes: home banner padding change — gap: no exact pixel/dp values\n- Expected behavior: gap: QA cannot validate without opening the design\n- Questions for developer:\n  1. What are the exact new padding values (top/bottom/leading/trailing)?\n  2. Does it apply on all device sizes or only some?\n  3. Does it apply to all banner states or only specific ones?\nVerdict: Insufficient"}
{"description":"## Flag `lazy_home_init`\n\nFlag `lazy_home_init`, field `enabled: bool`. If true → home screen initializes lazily on first open. If false → eager init at app launch. Default: false.","expected":"sufficient","assistant":"- Task type: config-flag\n- What changes: home screen init mode is controlled by `lazy_home_init.enabled` flag\n- Expected behavior: enabled=true → lazy init on first open; enabled=false (default) → eager init at launch\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Flag `card_style`\n\nFlag `card_style`, field `style`. See design.","expected":"insufficient","assistant":"- Task type: config-flag\n- What changes: card visual is controlled by `card_style.style` flag — gap: no example values, no effect mapping\n- Expected behavior: gap: QA cannot tell what to set in `style`\n- Questions for developer:\n  1. What concrete values can `style` take?\n  2. What does each value change?\n  3. What is the default value?\nVerdict: Insufficient"}
{"description":"## Add deeplink `notification_settings`\n\nAdd a deeplink `app://notification_settings`. It must open the notification settings screen with the navigation stack preserved from any source screen.","expected":"insufficient","assistant":"- Task type: feature\n- What changes: new deeplink `app://notification_settings` opens notification settings — gap: no source/trigger described\n- Expected behavior: gap: how does the user actually invoke the deeplink in real flows\n- Questions for developer:\n  1. From where does the user receive this deeplink (push / web link / in-app banner)?\n  2. What stack should be preserved on each entry point?\n  3. What is shown on the notification settings screen?\nVerdict: Insufficient"}
{"description":"## Show inapp 1 time\n\nShow the discount inapp 1 time per session. We must show it 1 time per install, unique by id.","expected":"insufficient","assistant":"- Task type: feature\n- What changes: discount inapp display rule — description contains a contradiction\n- Expected behavior: contradiction: '1 time per session' vs '1 time per install'\n- Questions for developer:\n  1. Which rule is correct — per session or per install?\n  2. If per install — uniqueness key is what exactly?\n  3. What happens on app reinstall?\nVerdict: Insufficient"}
{"description":"## Add haptic feedback on pager swipe\n\nOn pager swipe, trigger UISelectionFeedbackGenerator.selectionChanged() to give the user a tactile response.","expected":"sufficient","assistant":"- Task type: feature\n- What changes: pager swipe triggers UISelectionFeedbackGenerator.selectionChanged() haptic\n- Expected behavior: swiping between pages produces a tactile feedback\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Refresh items state on return from cart\n\nFlow: Search screen → Cart → back to Search. Currently, the items state (likes, badges) is stale because /items/refresh is never called. Fix: call /items/refresh when Search reappears after returning from Cart.","expected":"sufficient","assistant":"- Task type: bugfix\n- What changes: returning to Search from Cart now triggers /items/refresh\n- Expected behavior: was — items state stale; now — Search → Cart → back → /items/refresh fires and state updates\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Move caching from DataRepository to DataStore\n\nMove the cache from DataRepository.cache to DataStore. Delete DataRepository afterwards.","expected":"sufficient","assistant":"- Task type: tech-refactor\n- What changes: cache moves from DataRepository.cache to DataStore; DataRepository deleted\n- Expected behavior: code compiles; existing cache behavior preserved\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Increase header padding for the holiday season\n\nIncrease the padding in the header for the holiday season. [Design](https://example.com/design/holiday)","expected":"insufficient","assistant":"- Task type: feature\n- What changes: holiday-season header padding increase — gap: no values, no scope\n- Expected behavior: gap: QA cannot verify without parsing the design\n- Questions for developer:\n  1. What exact padding values (top/bottom)?\n  2. On which screens — only home, or everywhere with a header?\n  3. Is this active only during a date range, or permanently?\nVerdict: Insufficient"}
{"description":"## Add /accept endpoint contract\n\nAdd POST /accept with body `{\"item_id\": string, \"location\": {\"lat\": number, \"lng\": number}}` and header `X-Client-Version`. Response: 200 with body `{\"status\": \"ok\"}` or 400 with `{\"error\": string}`.","expected":"sufficient","assistant":"- Task type: api-contract\n- What changes: new POST /accept with item_id, location and X-Client-Version header; documented 200/400 responses\n- Expected behavior: request matches the documented body/header; 200 returns status:ok, 400 returns error string\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Support new promo type\n\nWe support a new promo type called Ticket. [Design](https://example.com/design/promo)","expected":"insufficient","assistant":"- Task type: feature\n- What changes: new promo type 'Ticket' supported — gap: no integration scenario\n- Expected behavior: gap: where it is shown and when it appears\n- Questions for developer:\n  1. On which screens does the Ticket promo appear?\n  2. Under what conditions / triggers is it shown?\n  3. What happens on tap?\nVerdict: Insufficient"}
{"description":"## Pre-select payment method via deeplink\n\nDeeplink `app://payments?type=<method>&id=<id>` opens the payment sheet with the given method pre-selected. Supported values for `type`: card, apple_pay, google_pay.","expected":"sufficient","assistant":"- Task type: api-contract\n- What changes: deeplink `app://payments?type=&id=` opens the payment sheet with the given method pre-selected; supported types listed\n- Expected behavior: opening the deeplink with type=card / apple_pay / google_pay → sheet appears with that method pre-selected\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Add caching layer to /catalog\n\nAdd a 60-second TTL in-memory cache to the GET /catalog request. Cache key = (locale, segment). On cache miss → make the request and store. On cache hit → return cached value.","expected":"sufficient","assistant":"- Task type: feature\n- What changes: GET /catalog now backed by a 60s in-memory cache keyed by (locale, segment)\n- Expected behavior: first call → network request, response cached; subsequent calls within 60s with same (locale, segment) → no network, cached value returned; after 60s → request again\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Animation\n\nAdd a transition animation between Home and Wallet.","expected":"insufficient","assistant":"- Task type: feature\n- What changes: transition animation between Home and Wallet — gap: no trigger or animation spec\n- Expected behavior: gap: how the user triggers the transition and what the animation looks like\n- Questions for developer:\n  1. What user action triggers the transition (swipe / button / deeplink)?\n  2. What does the animation look like (spec / design)?\n  3. Does it apply in both directions or only one?\nVerdict: Insufficient"}
{"description":"## Delete unused LegacyCache\n\nLegacyCache is no longer referenced after migrating to HttpClient. Delete the class and related tests.","expected":"sufficient","assistant":"- Task type: tech-refactor\n- What changes: LegacyCache and its tests are deleted\n- Expected behavior: code compiles; all API calls continue to go through HttpClient as before\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Logout per config\n\nThe logout flow follows a config. Config link: https://example.com/configs/logout","expected":"insufficient","assistant":"- Task type: config-flag\n- What changes: logout flow controlled by external config — gap: config content not described in ticket\n- Expected behavior: gap: cannot tell what values exist or what they do\n- Questions for developer:\n  1. What fields does the config have?\n  2. What concrete values are possible for each field?\n  3. What is the effect of each value on the logout flow?\nVerdict: Insufficient"}
{"description":"## Add loading state to favorites screen\n\nOn the Favorites screen, when /favorites/list is in flight, show a centered spinner. On success, render the list. On error, show an error state with a Retry button.","expected":"sufficient","assistant":"- Task type: feature\n- What changes: Favorites screen now has loading / loaded / error states tied to /favorites/list\n- Expected behavior: open Favorites → spinner; on 200 → list renders; on error → error state with Retry button (tap retries the request)\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Sync corner radius\n\nThe corner radius of the background and the card should be the same to remove visual artifacts.","expected":"insufficient","assistant":"- Task type: bugfix\n- What changes: align corner radius of background and card — gap: no exact value\n- Expected behavior: gap: which value is the source of truth (background or card)\n- Questions for developer:\n  1. What is the target corner radius value?\n  2. On which screen / component does this apply?\n  3. Is there a screenshot of the artifact for reference?\nVerdict: Insufficient"}
{"description":"## Pass status to OrderRequestState\n\nCurrently the JSON request for orders sends `status: null`.","expected":"insufficient","assistant":"- Task type: api-contract\n- What changes: order request should send a real status instead of null — gap: which field, which values\n- Expected behavior: gap: where to read the status from and what valid values are\n- Questions for developer:\n  1. Where should the status value come from?\n  2. What are the valid status values?\n  3. Which endpoint receives this change?\nVerdict: Insufficient"}
{"description":"## Force location check on home open\n\nThe home screen sometimes opens without location, leading to loading sections or stale cache. On home open, force a location refresh and only render content once a location is available (or show a permission prompt if denied).","expected":"sufficient","assistant":"- Task type: feature\n- What changes: home open now forces a location refresh; content renders only after location is available; permission denied → show prompt\n- Expected behavior: open home → location refreshed → content renders; if permission denied → permission prompt is shown\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Unify font in inapps\n\nUse the new font in inapp cards, stories, fullscreens and deeplink shortcuts. If the title fits in 3 lines in fullscreen / story → font size 50; if it fits in 2 lines → font size 60; otherwise → font size 40.","expected":"sufficient","assistant":"- Task type: feature\n- What changes: inapp cards/stories/fullscreens/deeplink shortcuts use new font with size depending on title line count\n- Expected behavior: open inapp with title in 3 lines → font 50; in 2 lines → font 60; more than 3 → font 40\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Animate service offers on home\n\nAdd an animation to the service offers section on home. The animation plays once per session. Mock for the section: see attachment.","expected":"sufficient","assistant":"- Task type: feature\n- What changes: service offers section on home plays an animation once per session\n- Expected behavior: open home (first time in session) → animation plays once; subsequent opens within the same session → no animation\n- Questions for developer: —\nVerdict: Sufficient"}
{"description":"## Capture badge for shortcuts\n\nCapture the badge (new, counter) on shortcut into the onboarding.","expected":"insufficient","assistant":"- Task type: feature\n- What changes: badge state captured into onboarding — gap: where exactly badge is captured and how it is reused\n- Expected behavior: gap: trigger and onboarding step that consumes this state\n- Questions for developer:\n  1. At which moment is the badge captured?\n  2. Which onboarding step uses this state?\n  3. What does the user see if there is no badge to capture?\nVerdict: Insufficient"}