From f29897cb3a147bda3799656f45013922532bcee3 Mon Sep 17 00:00:00 2001 From: Oleksandr Bezdieniezhnykh Date: Wed, 13 May 2026 23:06:48 +0300 Subject: [PATCH] [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 --- .cursor/rules/tracker.mdc | 9 ++++++--- .cursor/skills/implement/SKILL.md | 13 +++++++++++-- _docs/_autodev_state.md | 2 +- 3 files changed, 18 insertions(+), 6 deletions(-) diff --git a/.cursor/rules/tracker.mdc b/.cursor/rules/tracker.mdc index 8d6bffd..78a5c07 100644 --- a/.cursor/rules/tracker.mdc +++ b/.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) diff --git a/.cursor/skills/implement/SKILL.md b/.cursor/skills/implement/SKILL.md index 6e36027..9cb0bc5 100644 --- a/.cursor/skills/implement/SKILL.md +++ b/.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 diff --git a/_docs/_autodev_state.md b/_docs/_autodev_state.md index ac13892..f8ad9e7 100644 --- a/_docs/_autodev_state.md +++ b/_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