Refactor autopilot workflows and documentation: Update .gitignore to include binary and media file types, enhance agent command references in documentation, and modify annotation class for improved accessibility. Adjust inference processing to handle batch sizes and streamline test specifications for clarity and consistency across the system.

.cursor/skills/autopilot/state.md

@@ -10,28 +10,29 @@ The autopilot persists its state to `_docs/_autopilot_state.md`. This file is th
 # Autopilot State
 
 ## Current Step
-step: [0-6 or "2a" / "2b" / "2c" / "2d" / "2e" / "2ea" / "2f" / "2g" / "2h" / "2hb" / "2hc" / "2i" or "5b" / "5c" or "done"]
-name: [Problem / Research / Plan / UI Design / Blackbox Test Spec / Decompose Tests / Implement Tests / Refactor / UI Design / New Task / Implement / Run Tests / Security Audit / Performance Test / Deploy / Decompose / Done]
+flow: [greenfield | existing-code]
+step: [1-10 for greenfield, 1-12 for existing-code, or "done"]
+name: [step name from the active flow's Step Reference Table]
 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)
-
 When updating `Current Step`, always write it as:
-  step: N          ← autopilot step (0–6 or 2b/2c/2d/2e/2ea/2f/2g/2h/2hb/2hc/2i or 5b/5c)
-  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
+  flow: existing-code   ← active flow
+  step: N               ← autopilot step (sequential integer)
+  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
+  flow: greenfield
+  step: 3
   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
+  flow: existing-code
+  step: 2
+  name: Test Spec
   status: failed
   sub_step: 1b — Test Case Generation
   retry_count: 3
@@ -40,8 +41,8 @@ Example (failed after 3 retries):
 
 | Step | Name | Completed | Key Outcome |
 |------|------|-----------|-------------|
-| 0 | Problem | [date] | [one-line summary] |
-| 1 | Research | [date] | [N drafts, final approach summary] |
+| 1 | [name] | [date] | [one-line summary] |
+| 2 | [name] | [date] | [one-line summary] |
 | ... | ... | ... | ... |
 
 ## Key Decisions
@@ -69,10 +70,10 @@ 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)
+1. **Create** the state file on the very first autopilot invocation (after state detection determines Step 1)
 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
+4. **Cross-check**: after reading the state file, verify against actual `_docs/` folder contents. If they disagree (e.g., state file says Step 3 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
@@ -83,7 +84,7 @@ Read `_docs/_autopilot_state.md` first. If it exists and is consistent with the
 
 ### Folder Scan Rules (fallback)
 
-Scan `_docs/` to determine the current workflow position. The detection rules are defined in each flow file (`flows/greenfield.md` and `flows/existing-code.md`). Check the existing-code flow first (Pre-Step detection), then greenfield flow rules. First match wins.
+Scan `_docs/` to determine the current workflow position. The detection rules are defined in each flow file (`flows/greenfield.md` and `flows/existing-code.md`). Check the existing-code flow first (Step 1 detection), then greenfield flow rules. First match wins.
 
 ## Re-Entry Protocol
 
@@ -97,12 +98,12 @@ When the user invokes `/autopilot` and work already exists:
 
 ## Session Boundaries
 
-After any decompose/planning step completes (Step 2c, Step 2f, or Step 3), **do not auto-chain to implement**. Instead:
+After any decompose/planning step completes, **do not auto-chain to implement**. Instead:
 
 1. Update state file: mark the step as completed, set current step to the next implement step with status `not_started`
-   - After Step 2c (Decompose Tests) → set current step to 2d (Implement Tests)
-   - After Step 2f (New Task) → set current step to 2g (Implement)
-   - After Step 3 (Decompose) → set current step to 4 (Implement)
+   - Existing-code flow: After Step 3 (Decompose Tests) → set current step to 4 (Implement Tests)
+   - Existing-code flow: After Step 7 (New Task) → set current step to 8 (Implement)
+   - Greenfield flow: After Step 5 (Decompose) → set current step to 6 (Implement)
 2. Write `Last Session` section: `reason: session boundary`, `notes: Decompose complete, implementation ready`
 3. Present a summary: number of tasks, estimated batches, total complexity points
 4. Use Choose format: