Expectations Checklist

Selected task documents

Since 4.3.3, validators read the task description's prd and plan pointers, including explicit versioned PRDs and plans. A broken selection is an error; a clean legacy copy cannot replace the selected document. Missing pointers preserve the existing legacy and complexity-dependent behavior. The expectations parent_prd must refer to the selected PRD. Task identities and allowed paths are checked, but unrelated document metadata and concurrent-writer atomicity are not certified.

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, schema version (new files are written at schema_version: 4; v1–v3 are still read), capture command, parent links (init-task file, requirements document).
• Each item carries a stable slug (ASCII kebab-case for new items; legacy Cyrillic IDs remain readable), 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, deleted.
• Customer binding (schema v4) — every item declares customer_derived: true | false; a true item also carries the requirement ID, surface class, visibility and a coverage-receipt pointer.
• Override line (optional) — a soft veto that lets a partial / missed item not block routing. Since 2.31.0 the override carries an authorship check: an operator-authored override is accepted unconditionally, while an agent-authored one must cite an allowed class (time-dependent / external-blocker / operator-authorized / plan-scope-boundary) plus an artefact id that exists in the backlog or task index — an agent can no longer self-certify a gap with prose alone.

Language compatibility

New templates keep stable machine keys such as success_criterion, linked_ac, status_history and current_status. The shared parser also accepts existing English labels such as Operator expectations and Related AC from PRD, and historical Russian labels. Every linked V-AC is checked; localization does not waive evidence, status or override requirements.

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.