azaion/gps-denied-onboard
1
0
Fork 0
mirror of https://github.com/azaion/gps-denied-onboard.git synced 2026-06-22 16:51:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
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>
This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-05-13 23:06:48 +03:00
parent cfe3d357f4
commit f29897cb3a
3 changed files with 18 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.cursor/rules/tracker.mdc
+6 -3
View File
@@ -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)