mirror of
https://github.com/azaion/ai-training.git
synced 2026-04-22 07:06:36 +00:00
06b47c17c3
- Updated the coding rule descriptions to emphasize readability, meaningful comments, and test verification. - Revised guidelines to clarify the importance of avoiding boilerplate while maintaining readability. - Enhanced the testing rules to set a minimum coverage threshold of 75% for business logic and specified criteria for test scenarios. - Introduced a mechanism for handling skipped tests, categorizing them as legitimate or illegitimate, and outlined resolution steps. These changes aim to improve code quality, maintainability, and testing effectiveness.
51 lines
2.6 KiB
Plaintext
51 lines
2.6 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.
|
|
- The user must fix the Jira MCP connection before any further ticket creation/transition/query is attempted.
|
|
- Do NOT silently create local-only tasks, skip Jira steps, or pretend the write succeeded. The tracker is the source of truth — if a status transition is lost, the team loses visibility.
|
|
|
|
## 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 `/autopilot` 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
|
|
|
|
Autopilot must not progress past its own step 0 until all leftovers that CAN be replayed have been replayed.
|