---
alwaysApply: true
---

# Work Item Tracker

- Use **Jira** as the sole work item tracker (MCP server: `user-Jira-MCP-Server`)
- **NEVER** use Azure DevOps (ADO) MCP for any purpose — no reads, no writes, no queries
- Before interacting with any tracker, read this rule file first
- Jira cloud ID: `denyspopov.atlassian.net`
- Project key: `AZ`
- Project name: AZAION
- All task IDs follow the format `AZ-<number>`
- Issue types: Epic, Story, Task, Bug, Subtask

## Tracker Availability Gate
- 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 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. 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)

When a **non-user** blocker prevents a tracker write (MCP down, network error, transient failure, ticket linkage recoverable later), record the deferred write in `_docs/_process_leftovers/<YYYY-MM-DD>_<topic>.md` and continue non-tracker work. Each entry must include:

- Timestamp (ISO 8601)
- What was blocked (ticket creation, status transition, comment, link)
- Full payload that would have been written (summary, description, story points, epic, target status) — so the write can be replayed later
- Reason for the blockage (MCP unavailable, auth expired, unknown epic ID pending user clarification, etc.)

### Hard gates that CANNOT be deferred to leftovers

Anything requiring user input MUST still block:

- Clarifications about requirements, scope, or priority
- Approval for destructive actions or irreversible changes
- Choice between alternatives (A/B/C decisions)
- Confirmation of assumptions that change task outcome

If a blocker of this kind appears, STOP and ASK — do not write to leftovers.

### Replay obligation

At the start of every `/autodev` invocation, and before any new tracker write in any skill, check `_docs/_process_leftovers/` for pending entries. For each entry:

1. Attempt to replay the deferred write against the tracker
2. If replay succeeds → delete the leftover entry
3. If replay still fails → update the entry's timestamp and reason, continue
4. If the blocker now requires user input (e.g., MCP still down after N retries) → surface to the user

Autodev must not progress past its own step 0 until all leftovers that CAN be replayed have been replayed.