# SPEC: Inflight Upgrade Path

## Goal
Create a migration and upgrade path so that projects already using Automaton can adopt the new enforcement mechanisms (`.state` file, phase-scoped prompts, `status.py`) without breaking existing tasks or requiring manual intervention.

## Background
Existing projects have tasks in progress with artifact files but no `.state` files. They use the current prompts without FORBIDDEN sections. The upgrade needs to be backward-compatible — existing tasks must continue to work, and the transition should be automatic.

## Requirements

### 1. `.state` file bootstrap for existing tasks
When `status.py` encounters a task folder without a `.state` file:
1. Use the artifact heuristic (from `workflow.md`) to determine the current phase
2. Write `.state` with the inferred phase name
3. Output a note: "Bootstrapped .state for task '{task-name}': phase inferred as '{phase}' from existing artifacts"

This is already specified in the status-script spec. This task ensures:
- The artifact heuristic is correctly implemented in `status.py`
- Edge cases are handled (empty artifact files, partially completed phases)
- The bootstrap is logged so users can verify the inferred phase

### 2. Upgrade script
Create `scripts/upgrade.sh` (and reference it in `scripts/update.sh`) that:
1. Scans `{project}/.automaton/tasks/` for all task folders
2. For each task folder:
   - Check if `.state` exists
   - If not, call `status.py --task {task-name}` to bootstrap `.state`
   - Report the inferred phase for user verification
3. Scans sub-task folders (`subtasks/*/`) and does the same
4. Runs `status.py --audit` across all tasks to detect:
   - Out-of-order artifacts (Category 1)
   - State-artifact inconsistencies (Category 2)
   - Unauthorized modifications if git is available (Category 3)
5. Produces a summary:
   ```
   Upgrade Summary:
   - 5 tasks scanned
   - 3 tasks already had .state (no change)
   - 2 tasks bootstrapped with inferred .state:
     - add-user-auth: research (SPEC.md exists)
     - fix-login-bug: implement (IMPLEMENTATION.md exists)

   Audit Results:
   - 1 violation found:
     - fix-login-bug: IMPLEMENTATION.md exists but .state says research (corrected to implement)
   - 4 tasks clean
   ```

### 3. Update `install.sh` to create `.state` for new tasks
When the Orchestrator creates a new task folder, it must:
- Create the task folder
- Write `.state` with content `new\n`
- This is already covered by the state-file-enforcement spec; this task ensures the orchestrator prompt is updated to include this step

### 4. Update `migrate-project.sh`
The existing migration script needs to:
1. Handle `.state` files that may exist in old task folders (ignore them — they'll be bootstrapped by `status.py`)
2. Not delete `.state` files during migration
3. Add `.state` to the list of non-artifact files (alongside `VRAM_CONFIG.md` and `PARENT_SPEC.md`)

### 5. Backward-compatible phase prompts
The updated prompts (with FORBIDDEN sections and `.state` checks) must work even when `.state` doesn't exist:
- If `.state` doesn't exist, the precondition check should say: "No .state file found. Proceeding based on artifact heuristic. Recommend running 'python ~/.automaton/scripts/status.py --task {task}' to bootstrap .state."
- The prompt should not refuse to work if `.state` is missing — it should warn but continue
- This ensures a graceful transition period

### 6. Documentation updates
Update `README.md` to document:
- The `.state` file and its role
- The `status.py` command and its flags
- The upgrade path for existing projects
- That `status.py --list` replaces manual artifact checking

Update `CHANGELOG.md` under `[unreleased]`:
- Add `.state` file enforcement
- Add `status.py` script
- Phase-scoped prompts with ALLOWED/FORBIDDEN sections
- Backward-compatible with existing tasks (automatic `.state` bootstrap)

### 7. Version marker
Add a version marker to `~/.automaton/config.md`:
```
## Framework Version
- **Version**: 2.0
- **State enforcement**: enabled (`.state` file + `status.py`)
```

This allows `status.py` to detect the framework version and adjust behavior if needed. Existing projects without this marker are assumed to be on version 1.x and get the bootstrap treatment.

## Acceptance Criteria
- [ ] `status.py` bootstraps `.state` for tasks without it (artifact heuristic fallback)
- [ ] `scripts/upgrade.sh` scans all tasks and bootstraps missing `.state` files
- [ ] `scripts/upgrade.sh` runs `status.py --audit` and reports violations
- [ ] `scripts/upgrade.sh` produces a human-readable summary including audit results
- [ ] `scripts/install.sh` or orchestrator prompt updated to create `.state` for new tasks
- [ ] `scripts/migrate-project.sh` handles `.state` files correctly
- [ ] Phase prompts work with or without `.state` (graceful degradation)
- [ ] `README.md` updated with new features and upgrade instructions
- [ ] `CHANGELOG.md` updated under `[unreleased]`
- [ ] Version marker added to `config.md`
- [ ] Tests for `status.py` bootstrap logic in `tests/test_status.py`
- [ ] Tests for `status.py --validate-folder` and `--audit` in `tests/test_status.py`
- [ ] Tests for `upgrade.sh` in `tests/test_upgrade.py`

## Non-Goals
- This spec does not cover the `.state` file format itself (covered by state-file-enforcement)
- This spec does not cover `status.py` implementation (covered by status-script)
- This spec does not cover prompt restructuring (covered by phase-scoped-prompts)
- This spec does not cover autopilot integration (covered by autopilot-gate-integration)