[AZ-137] [AZ-138] Decompose test tasks and scaffold E2E test infrastructure

Made-with: Cursor

.cursor/skills/autopilot/state.md

@@ -12,8 +12,9 @@ The autopilot persists its state to `_docs/_autopilot_state.md`. This file is th
 ## Current Step
 step: [0-6 or "2b" / "2c" / "2d" / "2e" / "2f" / "2g" / "2h" / "2hb" / "2i" or "5b" or "done"]
 name: [Problem / Research / Plan / Blackbox Test Spec / Decompose Tests / Implement Tests / Refactor / New Task / Implement / Run Tests / Security Audit / Deploy / Decompose / Done]
-status: [not_started / in_progress / completed / skipped]
+status: [not_started / in_progress / completed / skipped / failed]
 sub_step: [optional — sub-skill internal step number + name if interrupted mid-step]
+retry_count: [0-3 — number of consecutive auto-retry attempts for current step, reset to 0 on success]
 
 ## Step ↔ SubStep Reference
 (include the step reference table from the active flow file)
@@ -21,11 +22,19 @@ sub_step: [optional — sub-skill internal step number + name if interrupted mid
 When updating `Current Step`, always write it as:
   step: N          ← autopilot step (0–6 or 2b/2c/2d/2e/2f/2g/2h/2hb/2i or 5b)
   sub_step: M      ← sub-skill's own internal step/phase number + name
+  retry_count: 0   ← reset on new step or success; increment on each failed retry
 Example:
   step: 2
   name: Plan
   status: in_progress
   sub_step: 4 — Architecture Review & Risk Assessment
+  retry_count: 0
+Example (failed after 3 retries):
+  step: 2b
+  name: Blackbox Test Spec
+  status: failed
+  sub_step: 1b — Test Case Generation
+  retry_count: 3
 
 ## Completed Steps
 
@@ -45,6 +54,14 @@ ended_at: Step [N] [Name] — SubStep [M] [sub-step name]
 reason: [completed step / session boundary / user paused / context limit]
 notes: [any context for next session]
 
+## Retry Log
+| Attempt | Step | Name | SubStep | Failure Reason | Timestamp |
+|---------|------|------|---------|----------------|-----------|
+| 1 | [step] | [name] | [sub_step] | [reason] | [date-time] |
+| ... | ... | ... | ... | ... | ... |
+
+(Clear this table when the step succeeds or user resets. Append a row on each failed auto-retry.)
+
 ## Blockers
 - [blocker 1, if any]
 - [none]
@@ -53,10 +70,12 @@ notes: [any context for next session]
 ### State File Rules
 
 1. **Create** the state file on the very first autopilot invocation (after state detection determines Step 0)
-2. **Update** the state file after every step completion, every session boundary, and every BLOCKING gate confirmation
+2. **Update** the state file after every step completion, every session boundary, every BLOCKING gate confirmation, and every failed retry attempt
 3. **Read** the state file as the first action on every invocation — before folder scanning
 4. **Cross-check**: after reading the state file, verify against actual `_docs/` folder contents. If they disagree (e.g., state file says Step 2 but `_docs/02_document/architecture.md` already exists), trust the folder structure and update the state file to match
 5. **Never delete** the state file. It accumulates history across the entire project lifecycle
+6. **Retry tracking**: increment `retry_count` on each failed auto-retry; reset to `0` when the step succeeds or the user manually resets. If `retry_count` reaches 3, set `status: failed` and add an entry to `Blockers`
+7. **Failed state on re-entry**: if the state file shows `status: failed` with `retry_count: 3`, do NOT auto-retry — present the blocker to the user and wait for their decision before proceeding
 
 ## State Detection