[meta] Tighten Jira tracker error handling: STOP and ASK on any error

User feedback after a transitionJiraIssue call returned a bare
{"success": true} that I trusted blindly: the rule should require
explicit verification and stop-and-ask on any ambiguous response.

Two targeted clarifications:

- .cursor/rules/tracker.mdc - Tracker Availability Gate now lists
  the full set of failure modes (non-2xx, timeout, empty body,
  opaque success) and bans automatic retries. Adds an explicit
  read-back requirement when the response is minimal, and adds
  "abort" to the user-choice menu.

- .cursor/skills/implement/SKILL.md - Step 5 (In Progress) and
  Step 12 (In Testing) now spell out the STOP-and-ASK rule inline
  instead of just pointing at tracker.mdc. Adds the read-back
  verification step for opaque responses.

Co-authored-by: Cursor <cursoragent@cursor.com>

.cursor/rules/tracker.mdc

@@ -14,11 +14,14 @@ alwaysApply: true
 - Issue types: Epic, Story, Task, Bug, Subtask
 
 ## Tracker Availability Gate
-- If Jira MCP returns **Unauthorized**, **errored**, **connection refused**, or any non-success response: **STOP** tracker operations and notify the user via the Choose A/B/C/D format documented in `.cursor/skills/autodev/protocols.md`.
+- If Jira MCP returns **Unauthorized**, **errored**, **connection refused**, **timeout**, a non-2xx status code, an empty body, or any response shape that does not clearly confirm the requested change: **STOP IMMEDIATELY** — no automatic retry, no silent continuation. Surface the full raw error/response to the user verbatim and notify via the Choose A/B/C/D format documented in `.cursor/skills/autodev/protocols.md`.
+- A minimal `{"success": true}` body with no echoed issue state is NOT a confirmed transition. When a transition's success matters (status moves, ticket creation, blocking link), follow it with a read-back call (`getJiraIssue` or equivalent) and confirm the new state matches what you asked for. If the read-back disagrees → STOP and ASK.
+- Do NOT loop "retry up to N times before asking". One call, one verification. On failure, the user decides whether to retry.
 - The user may choose to:
-  - **Retry authentication** — preferred; the tracker remains the source of truth.
+  - **Retry the same operation** — once, after the user authorizes it. If it fails again, surface both responses.
+  - **Retry authentication** — preferred when the failure looks like an auth/credentials problem; the tracker remains the source of truth.
   - **Continue in `tracker: local` mode** — only when the user explicitly accepts this option. In that mode all tasks keep numeric prefixes and a `Tracker: pending` marker is written into each task header. The state file records `tracker: local`. The mode is NOT silent — the user has been asked and has acknowledged the trade-off.
-- Do NOT auto-fall-back to `tracker: local` without a user decision. Do not pretend a write succeeded. If the user is unreachable (e.g., non-interactive run), stop and wait.
+- Do NOT auto-fall-back to `tracker: local` without a user decision. Do not pretend a write succeeded. Do not paper over an opaque response by moving on. If the user is unreachable (e.g., non-interactive run), stop and wait.
 - When the tracker becomes available again, any `Tracker: pending` tasks should be synced — this is done at the start of the next `/autodev` invocation via the Leftovers Mechanism below.
 
 ## Leftovers Mechanism (non-user-input blockers only)

.cursor/skills/implement/SKILL.md

@@ -137,7 +137,14 @@ If `_docs/02_document/module-layout.md` is missing or the component is not found
 
 ### 5. Update Tracker Status → In Progress
 
-For each task in the batch, transition its ticket status to **In Progress** via the configured work item tracker (see `protocols.md` for tracker detection) before starting work. If `tracker: local`, skip this step. If a tracker operation fails unexpectedly, follow `.cursor/rules/tracker.mdc`.
+For each task in the batch, transition its ticket status to **In Progress** via the configured work item tracker (see `protocols.md` for tracker detection) before starting work. If `tracker: local`, skip this step.
+
+**On any tracker error or ambiguous response: STOP and ASK the user.** Per `.cursor/rules/tracker.mdc`:
+
+- Errored / non-2xx / timeout / empty body / opaque `{"success": true}` → STOP. Do not retry automatically. Do not move on.
+- Surface the raw response verbatim to the user via Choose A/B/C/D (retry / re-auth / `tracker: local` / abort).
+- If the response is a bare `{"success": true}` with no echoed issue state, perform a read-back (`getJiraIssue`) to confirm the status actually changed. If the read-back shows the old status or fails → STOP and ASK.
+- Never proceed past the transition assuming success when the evidence is opaque.
 
 ### 6. Implement Tasks Sequentially
 
@@ -224,7 +231,9 @@ Track `auto_fix_attempts` and `escalated_findings` in the batch report for retro
 
 ### 12. Update Tracker Status → In Testing
 
-After the batch is committed (and pushed if the user approved pushing), transition the ticket status of each task in the batch to **In Testing** via the configured work item tracker. If `tracker: local`, skip this step. If a tracker operation fails unexpectedly, follow `.cursor/rules/tracker.mdc`.
+After the batch is committed (and pushed if the user approved pushing), transition the ticket status of each task in the batch to **In Testing** via the configured work item tracker. If `tracker: local`, skip this step.
+
+**Same STOP-and-ASK rule as Step 5**: on any tracker error, non-2xx response, timeout, empty body, or opaque `{"success": true}` without echoed state, STOP — surface the raw response and ask the user. Verify the transition by reading the issue back when the response is minimal. Never silently proceed.
 
 ### 13. Archive Completed Tasks
 

_docs/_autodev_state.md

@@ -8,7 +8,7 @@ status: in_progress
 sub_step:
   phase: 7
   name: batch-loop
-  detail: "batch 47 complete — selecting batch 48"
+  detail: "batch 48 — AZ-508 (ISO timestamp helper consolidation)"
 retry_count: 0
 cycle: 1
 tracker: jira