Expectations Checklist
Operator wishlist artefact in plain markdown — wish_id slug, status history, current status, override semantics. Written at the requirements step, verified at the quality-review and hardening steps.
Overview
The expectations checklist is an operator-readable list of «things to verify after the work is done», captured at the requirements step for larger tasks and at the planning step for smaller ones. Each item is written in the operator's own words — no technical jargon, no acronyms — so a non-technical reader can understand it. Later, the quality-review step assigns each item a final status, the hardening step verifies the same list a second time, and the archive step renders the outcome in plain language alongside the operator brief.
Schema
- Frontmatter — task identifier, artefact type, capture command, parent links (init-task file, requirements document).
- Each item carries a stable slug (kebab-case, cyrillic allowed), an operator-words description, a success criterion in the operator's own words, an optional link to a formal acceptance criterion from the requirements document.
- Status history — running log of status transitions written by each pipeline step. Format:
<ISO timestamp> / <local time> · <command> · <prior> → <new> · reason: <one-sentence plain text>. - Current status — one of: pending, met, partial, missed, n-a.
- Override line (optional) — operator-driven soft veto with ≥10 characters of justification; lets a partial / missed item not block routing when the operator accepts the gap.
Verification Gate
The quality-review step introduces a dedicated layer that walks every item, computes its status, appends one history line, and updates the current status. A bundled validator then decides whether the verdict is pass (everything met or overridden), conditional pass (partials with overrides), or blocked (any missed item without an override). On a blocked verdict the failure-routing call-to-action paraphrases the focus items and offers a paste-ready command to return the task to implementation with a narrow scope.
Why This Schema
The flat-markdown layout makes the wishlist readable as a plain document — operators can scan it in any editor, edit it in any editor, and review it without any specialised tool. The running status history preserves the audit trail across multiple pipeline runs, so when the same task goes through quality-review twice (an intermediate run, then a final run), both runs leave their own one-line trace.
Source
Contract shipped with Datarim v2.8.0.