mirror of
https://github.com/azaion/loader.git
synced 2026-04-22 21:56:33 +00:00
54 lines
3.1 KiB
Plaintext
54 lines
3.1 KiB
Plaintext
---
|
|
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**, 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`.
|
|
- The user may choose to:
|
|
- **Retry authentication** — preferred; 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.
|
|
- 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.
|