azaion/gps-denied-onboard
1
0
Fork 0
mirror of https://github.com/azaion/gps-denied-onboard.git synced 2026-06-21 08:51:12 +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/skills/implement/SKILL.md
+11 -2
View File
@@ -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