TASK-001B: Domain and App State Core
Goal
Define the shared language of the system so later workflow, simulator, and UI tasks all build on the same contracts and canonical state model.
Scope
- implement the minimum core contracts from the requirements
- define canonical state enums or records
- define the central
AppStateshape - define command guard helpers or policies against canonical state
- create any application-layer interfaces needed for a future state store
Non-Scope
- actual workflow handlers
- simulator runtime behavior
- streaming loops
- full UI binding logic
AI Execution Profile
- Model class:
Balanced - Reasoning effort:
Medium - Use this on: your default strong coding model
- Escalate only if the tool keeps inventing alternate state vocabularies
Files Or Areas Expected To Change
DomaincontractsApplicationstate and guard definitions- shared enums or records for workflow, connection, motion, camera, alarms, and run summaries
Acceptance Targets
- all minimum first-slice contracts exist
- canonical state terminology matches the requirements
- command guard logic is defined against canonical state
- no UI-specific mutable state is introduced as the source of truth
Copy/Paste Prompt
text
Implement only TASK-001B: Domain and App State Core in this repository.
Read first:
- docs/requirements.md
Focus on Sections 6.7, 6.8, 7.5, 9.3, 9.5, 12, and 13.2
- docs/adrs/ADR-001-use-central-app-state-store.md
- docs/specs/SLICE-001-first-strong-vertical-slice.md
Focus on Canonical Contracts, Runtime Behavior, and Layer Boundaries
- docs/tasks/slice-001/TASK-001B-domain-and-app-state-core.md
Goal:
- Define the shared contracts and canonical app state model for the first slice.
Scope:
- Implement the minimum contracts:
Recipe
ScanPoint
Frame
InspectionResult
Alarm
RunSummary
- Define canonical state types for connection, workflow, motion, camera, and safety/readiness state.
- Define the central AppState shape.
- Define command guard helpers or policies based on canonical state.
- Add any small application interfaces needed for later state-store implementation.
Do not:
- Implement the state store runtime yet
- Implement simulator loops
- Implement workflow handlers
- Implement full UI logic
Important constraints:
- Use the exact state names from requirements
- Avoid inventing alternate enums or duplicate readiness flags
- Keep the UI from becoming the source of truth
Verification:
- Build if possible
- Summarize the contracts and state types introduced
- Call out any ambiguous requirement you had to interpret
Important:
- Implement only this task
- Do not preemptively implement later tasks