A vertical slice from Lesson 44.1 still contains several jobs: adjust a query, render a field, handle an empty state, write a check. Hand a whole slice to an AI with "just build it" and the agent fills every gap with a broad redesign — new files, changed schema, invented fields. This lesson gives each task a shape that prevents that drift.

The canonical template

Use the same twelve fields for every task. Copy this block to start each card:

# Task: <short outcome>

## User / system outcome
## Why now / roadmap phase
## Read first
## Allowed scope: files, services, environment
## Must preserve / must not change
## Inputs and interface contract
## Acceptance checks
## Evidence to run
## Risk level and approval gate
## Stop / escalate when
## Handoff format

That is eleven headings plus the title — twelve fields total. The rigidity is the point. When every card has the same shape, a missing answer is visible instead of silently guessed.

What each field does, with the source-date example

Take a realistic task: "Show the source publication date on the approved source card." Here is how each field earns its place:

• User / system outcome. "A visitor reading a company page sees each approved source's publication date beneath its title." One observable behavior, not a refactor.
• Why now / roadmap phase. "Slice 2 of the dashboard sequence; unblocks the draft slice, which must cite dates." Connects the card to the roadmap so nobody re-debates priority.
• Read first. "PRD.md (source display section), API.md (source record fields), the existing source-mapping module, and the current card component plus its test." Named files, not "the codebase." A fresh session knows exactly where to look.
• Allowed scope. "Two files: the source-card component and its stylesheet; read-only access to the source API response. No migration, no new service, local preview only." The agent learns where it may write and where it may only read.
• Must preserve / must not change. "Do not change authentication, the source schema, or deployment settings. Do not alter approval filtering — unapproved records stay hidden." This protects everything the task touches but does not own.
• Inputs and interface contract. "The source record exposes publishedAt as an ISO date string or null when the provider omits it. The card renders a formatted date when present and 'Date unavailable' when null." The contract names the field, its type, and both cases.
• Acceptance checks. "Known date renders as 'Mar 4, 2026'; missing date renders 'Date unavailable'; unapproved sources still hidden." Checks are observable and countable.
• Evidence to run. "Component test for both date states plus a local preview screenshot of a company page with one dated and one undated source." Says what to run and what artifact to keep.
• Risk level and approval gate. "Low risk; human reviews the preview before commit, per Class 43's risk tiers." Sets the review bar before work starts.
• Stop / escalate when. "Stop if the provider field is unavailable under a different name or missing from the API response. Do not invent a migration or rename fields — report the actual response shape and wait." This is the anti-guessing clause.
• Handoff format. "Changed files, test command plus result, preview note, open questions, and the exact next step." Feeds Lesson 44.4's delivery loop directly.

Note the source-date field running through the card: it appears in read-first (where the field is defined), in the contract (its name and null case), and in stop-on-missing-field (what to do when reality disagrees). That triple coverage is deliberate. Data fields are where AI invents most confidently, so the card protects them three times: read the definition, state the contract, halt on mismatch.

Sizing: when to split

Two rules of thumb:

1. Split two concepts. If a task introduces two new ideas that each need their own design or test plan — say, date display *and* a new sorting control — it is two tasks. Each concept deserves its own outcome, checks, and evidence. 2. Demand a before/after. If you cannot describe the task as a clear before/after in user behavior ("before: no date shown; after: date or 'Date unavailable' shown"), it is probably not ready. Send it back to slicing before handing it to an agent.

A card should describe roughly one focused session of work: readable in a few minutes, executable without re-scoping mid-stream.

Weak versus strong

Acceptance checks turn subjective language into proof. "Better," "cleaner," "polished" cannot be tested. A rendered string, a hidden record, and a passing test can. Every adjective in the outcome needs a matching check, or it gets cut.

Practical exercise: rescue "better dashboard"

Take the vague request "make my dashboard better" and rewrite it as two task cards.

1. Each card uses the full twelve-field template above. 2. Each card has one visible result, one explicit boundary (a must-preserve or allowed-scope line), and at least two acceptance checks. 3. Keep both cards low-risk and preview-checkable.

Finish line: two task cards a new AI session could execute after reading the named files, without relying on your memory.

Verify: hand one card to a friend (or a fresh chat with no project history) plus only the files it names. Can they restate the outcome, the boundary, and how they would prove it? If they must ask you what you meant, the card is not ready.

Common failure mode: acceptance checks that restate effort ("code is updated") instead of behavior ("unapproved sources stay hidden"). Every check must describe something a reviewer can see or run.

Check your understanding

1. Name four of the twelve task-card fields and what each prevents the AI from guessing. 2. Why does the source-date example appear in read-first, contract, and stop/escalate? 3. State the two sizing rules and apply one to a task that combines "date display plus new sorting." 4. Convert "polish the dashboard" into one sentence with a visible result and two acceptance checks. 5. What makes a task "not ready," and where should it go instead?