Tasks

Write the outcome before the activity

A task should describe a result someone can review. “Refactor checkout” names activity. “Replace the payment adapter while preserving the order contract and documented failure behavior” gives the work a purpose and a boundary.

A small task brief

{
  "objective": "Replace the payment adapter",
  "preserve": ["order contract", "decline handling"],
  "review": ["consumer mapping", "relevant test results"],
  "openQuestions": ["How are network failures represented?"]
}

This is a conceptual brief, not a public API request. The point is to make the result and uncertainty understandable before implementation starts.

1. State the intended behavior and what must remain unchanged.

2. Identify the source boundary and relevant constraints.

3. Define the observations needed to assess completion.

4. Record unanswered questions instead of silently assuming an answer.

Completion should survive a handoff

A reviewer who did not perform the work should be able to understand the outcome, locate the evidence and see the remaining limitations. Stopping execution, exhausting a budget or producing a large number of edits is not an acceptance criterion.