Epic 14 Task 14.1 defines the baseline artifact contract for /start-work <plan> execution.
- keep plan execution deterministic from a human-reviewed artifact
- fail fast on malformed or unsafe plans with actionable errors
- preserve step progress and deviations in a machine-readable state model
The command accepts a markdown file with two required sections in this order:
- metadata frontmatter (YAML)
- execution checklist body (markdown task list)
Reference skeleton:
---
id: plan-2026-02-13-e14t1
title: Example migration plan
owner: diego
created_at: 2026-02-13T10:00:00Z
version: 1
---
# Plan
- [ ] 1. Prepare baseline checks
- [ ] 2. Apply implementation changes
- [ ] 3. Run verification and summarize deltasRequired keys:
id: stable slug-like identifier ([a-z0-9][a-z0-9-_]{2,63})title: non-empty human labelowner: actor/team responsible for executioncreated_at: RFC3339 timestampversion: positive integer
Optional keys:
depends_on: array of external references (issue ids, PRs, doc ids)risk_level: one oflow,medium,hightimeout_minutes: integer guardrail for total execution budget
Unknown metadata keys are preserved but ignored by v1 validation.
- each executable step must be a top-level markdown checkbox (
- [ ]) - step text must start with a numeric ordinal (
1.,2.,3.) to keep ordering explicit - ordinals must be strictly increasing without duplicates
- nested checklist items are treated as notes and are not executable steps
- empty checkbox lines are invalid
Validation must fail before execution when any of these are true:
- missing frontmatter or malformed YAML
- missing required metadata key or invalid key value type/format
- no executable checklist steps
- duplicate or out-of-order ordinals
- all steps already marked complete (
- [x]) at start
Validation output must include:
- deterministic machine-readable error codes
- file path + line numbers for each violation
- remediation hints for each failed rule
Each executable step is tracked with one of:
pendingin_progresscompletedfailedskipped
Allowed transitions:
pending -> in_progressin_progress -> completedin_progress -> failedin_progress -> skippedfailed -> in_progress(retry path)
Disallowed transitions must fail with explicit transition error diagnostics.
Completion semantics:
- exactly one step can be
in_progressat a time - plan is complete only when all executable steps are
completedorskipped - any
failedstep keeps the overall plan status in failed/recovery-required state
Execution runtime must record deviations from the original artifact, including:
- inserted ad-hoc step not present in the source plan
- skipped required step with rationale
- reordered execution relative to declared ordinal sequence
Deviation records should include step id, timestamp, reason, and actor.
- Task 14.2 should implement parser/validator + state transition engine for this contract
- Task 14.3 should expose contract/state health through doctor and digest outputs
- Task 14.4 should add parser/transition/recovery tests and user-facing docs with sample plans