flutter-project-harness

name	flutter-project-harness
description	Plan, implement, resume, revise, validate, package, and finalize work in this Flutter repository with durable file-backed state and deterministic gates. Use for new features, bug fixes, refactors, continuation of interrupted work, targeted revisions, verification, release preparation, or any request that changes project artifacts.

Flutter Project Harness

Use _workspace/ as the durable source of truth and .harness/config.json as the machine contract.

Start or resume

1. Read AGENTS.md.
2. Run python3 .codex/skills/flutter-project-harness/scripts/harness.py status.
3. If no work exists, initialize it with init --work-id <slug> --title <title>.
4. If work exists, inspect its current stage and required files. Do not create a second work item over it.
5. Read production-contract.md before changing stage state or workspace layout.

Execute

1. Keep user intent in 00_input/request.md.
2. Put scope and observable acceptance criteria in 01_specification/requirements.md.
3. Put architecture, affected files, tests, risks, and rollback notes in 02_plan/implementation-plan.md.
4. Change source only after the planned stage.
5. Summarize observable changes in 03_output/change-summary.md.
6. Register material files with register; never edit manifest.json directly.
7. Move stages with advance; never edit state.json directly.

Read flutter-architecture.md when adding a feature, dependency, repository, provider, route, or persistence mechanism.

Validate

1. Run validate --profile quick for normal source changes.
2. Run validate --profile release for dependency, platform, routing, initialization, or release preparation changes.
3. Preserve failure output in 04_validation/validation.json.
4. Fix the earliest failing stage. Do not weaken gates.
5. Record semantic, UX, accessibility, localization, and risk review in 04_validation/quality-review.md.

Read validation-rules.md when choosing a profile or writing quality review.

Revise, package, and finalize

1. For a partial revision, run revise <earliest-stage> --reason <reason>.
2. Re-run that stage and every invalidated downstream gate.
3. Package only after machine and quality validation.
4. Treat packaging as a local candidate, not deployment.
5. Never set human approval. Finalize only when the user has supplied a valid approval record.
6. After finalization, run archive before initializing the next work item.

Run harness.py --help for the complete command interface.