mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-21 08:41:12 +00:00
Oleksandr Bezdieniezhnykh
1f634c2604
ci/woodpecker/push/02-build-push Pipeline failed
- Modified the autodev state to reflect the current testing phase and details of the new `jetson-e2e` tests. - Enhanced the "How to Test" documentation to provide clearer instructions on the demo replay validation process, including video and tlog alignment steps. - Updated architectural documentation to include the new demo replay operator flow and its dependencies. - Documented the removal of deprecated auto-sync features and clarified the operator-facing UI for replay validation. - Added new entries in the dependencies table for upcoming tasks related to the demo replay flow. These changes improve clarity and usability for operators and developers working with the demo replay system.
57 lines
4.0 KiB
Plaintext
57 lines
4.0 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**, **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.
|