Update test results directory structure and enhance Docker configurations

- Modified `.gitignore` to reflect the new path for test results.
- Updated `docker-compose.test.yml` to mount the correct test results directory.
- Adjusted `Dockerfile.test` to set the `PYTHONPATH` and ensure test results are saved in the updated location.
- Added `boto3` and `netron` to `requirements-test.txt` to support new functionalities.
- Updated `pytest.ini` to include the new `pythonpath` for test discovery.

These changes streamline the testing process and ensure compatibility with the updated directory structure.

.cursor/skills/autopilot/SKILL.md

@@ -32,10 +32,10 @@ Auto-chaining execution engine that drives the full BUILD → SHIP workflow. Det
 
 - **Auto-chain**: when a skill completes, immediately start the next one — no pause between skills
 - **Only pause at decision points**: BLOCKING gates inside sub-skills are the natural pause points; do not add artificial stops between steps
-- **State from disk**: all progress is persisted to `_docs/_autopilot_state.md` and cross-checked against `_docs/` folder structure
-- **Rich re-entry**: on every invocation, read the state file for full context before continuing
+- **State from disk**: current step is persisted to `_docs/_autopilot_state.md` and cross-checked against `_docs/` folder structure
+- **Re-entry**: on every invocation, read the state file and cross-check against `_docs/` folders before continuing
 - **Delegate, don't duplicate**: read and execute each sub-skill's SKILL.md; never inline their logic here
-- **Sound on pause**: follow `.cursor/rules/human-attention-sound.mdc` — play a notification sound before every pause that requires human input
+- **Sound on pause**: follow `.cursor/rules/human-attention-sound.mdc` — play a notification sound before every pause that requires human input (AskQuestion tool preferred for structured choices; fall back to plain text if unavailable)
 - **Minimize interruptions**: only ask the user when the decision genuinely cannot be resolved automatically
 - **Single project per workspace**: all `_docs/` paths are relative to workspace root; for monorepos, each service needs its own Cursor workspace
 
@@ -44,7 +44,7 @@ Auto-chaining execution engine that drives the full BUILD → SHIP workflow. Det
 Determine which flow to use:
 
 1. If workspace has source code files **and** `_docs/` does not exist → **existing-code flow** (Pre-Step detection)
-2. If `_docs/_autopilot_state.md` exists and records Document in `Completed Steps` → **existing-code flow**
+2. If `_docs/_autopilot_state.md` exists and `step >= 2` (i.e. Document already ran) → **existing-code flow**
 3. If `_docs/_autopilot_state.md` exists and `step: done` AND workspace contains source code → **existing-code flow** (completed project re-entry — loops to New Task)
 4. Otherwise → **greenfield flow**
 
@@ -65,7 +65,7 @@ Every invocation follows this sequence:
    a. Delegate to current skill (see Skill Delegation below)
    b. If skill returns FAILED → apply Skill Failure Retry Protocol (see protocols.md):
       - Auto-retry the same skill (failure may be caused by missing user input or environment issue)
-      - If 3 consecutive auto-retries fail → record in state file Blockers, warn user, stop auto-retry
+      - If 3 consecutive auto-retries fail → set status: failed, warn user, stop auto-retry
    c. When skill completes successfully → reset retry counter, update state file (rules in state.md)
    d. Re-detect next step from the active flow's detection rules
    e. If next skill is ready → auto-chain (go to 7a with next skill)
@@ -82,10 +82,26 @@ For each step, the delegation pattern is:
 3. Read the skill file: `.cursor/skills/[name]/SKILL.md`
 4. Execute the skill's workflow exactly as written, including all BLOCKING gates, self-verification checklists, save actions, and escalation rules. Update `sub_step` in state each time the sub-skill advances.
 5. If the skill **fails**: follow the Skill Failure Retry Protocol in `protocols.md` — increment `retry_count`, auto-retry up to 3 times, then escalate.
-6. When complete (success): reset `retry_count: 0`, mark step `completed`, record date + key outcome, add key decisions to state file, return to auto-chain rules (from active flow file)
+6. When complete (success): reset `retry_count: 0`, update state file to the next step with `status: not_started`, return to auto-chain rules (from active flow file)
 
 Do NOT modify, skip, or abbreviate any part of the sub-skill's workflow. The autopilot is a sequencer, not an optimizer.
 
+## State File Template
+
+The state file (`_docs/_autopilot_state.md`) is a minimal pointer — only the current step. Full format rules are in `state.md`.
+
+```markdown
+# Autopilot State
+
+## Current Step
+flow: [greenfield | existing-code]
+step: [number or "done"]
+name: [step name]
+status: [not_started / in_progress / completed / skipped / failed]
+sub_step: [0 or N — sub-skill phase name]
+retry_count: [0-3]
+```
+
 ## Trigger Conditions
 
 This skill activates when the user wants to: