mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-21 17:31:14 +00:00
Oleksandr Bezdieniezhnykh
cb444c4f8a
Captures the pattern observed this cycle: when /autodev rewinds from Step 11 (Run Tests) back to Step 7 (Implement) due to a gate fail, the rewind itself eats real context (task spec drafting + state update + dependencies survey). Continuing into the destination step's batch loop in the same conversation risks context truncation mid-batch. Treat the rewind as a session boundary; let a fresh /autodev invocation start the implement loop cleanly. Co-authored-by: Cursor <cursoragent@cursor.com>
18 lines
2.4 KiB
Markdown
18 lines
2.4 KiB
Markdown
# LESSONS
|
|
|
|
Append-only ledger of lessons learned during the project. New entries go at the **top**. Each entry is one short bullet + a one-sentence "what changed".
|
|
|
|
---
|
|
|
|
## 2026-05-18 — When autodev rewinds N → 7 (or any earlier step) mid-session, treat the handoff as a session boundary
|
|
|
|
**Trigger**: In Step 11 (Run Tests) cycle 1, the Jetson e2e gate routed the flow back to Step 7 (Implement) for AZ-618 (cross-cutting 5pt task with 12 infrastructure deps). The user repeatedly chose to continue in the same conversation. I rewound state cleanly (task spec + autodev state) but, on attempting to enter the implement skill's batch loop in the SAME conversation, found that even just investigating the 12 builder signatures consumed enough context to reach the Caution zone — writing the implementation would have hit truncation mid-batch.
|
|
|
|
**What changed**: When the autodev rewinds the flow to an EARLIER step in the same conversation (Step 11 → Step 7, Step 11 → Step 9, etc.), treat the rewind itself as a session boundary, regardless of whether the flow file's Auto-Chain Rules table marks it as one. Save the bootstrap artifacts (task spec, state, dependencies-table refresh), commit them, then ask for a fresh conversation. The rewind already cost real tool calls; the destination step's batch loop deserves clean context. Document the rewind reason in `sub_step.detail` so re-entry is one-line clear.
|
|
|
|
## 2026-05-17 — Always call `getTransitionsForJiraIssue` before `transitionJiraIssue`
|
|
|
|
**Trigger**: In batch 87 (autodev step 10), I transitioned AZ-436..AZ-439 with `transition.id="31"` assuming = "In Progress" from stale memory. Read-back showed all four moved to **Done** instead (id `31` in this workflow = Done; In Progress = `21`, In Testing = `32`, To Do = `11`). The mistake was caught by the tracker rule's mandatory read-back gate, fixed by re-transitioning to `21`, and confirmed via second read-back.
|
|
|
|
**What changed**: Treat the transition ID as workflow-specific, not memorizable across sessions. Always query `getTransitionsForJiraIssue` first on the actual target issue (or one in the same project/workflow) and select the transition by `name` ("In Progress" / "In Testing" / "Done" / "To Do") — never by hard-coded numeric id. This is true even when you "remember" the IDs from a prior batch this same day, because the agent has no guarantee the workflow definition is stable.
|