Skip to content
arula

Stage 525 minutesPairs301 · Tooled judgment

Plan the spec

Run workbench plan to turn defects/*.md into tasks.json: an executable implementation and validation plan with explicit checks, gates, budget and omissions.

You will produce

tasks.json

We will demonstrate

From defect specs to an executable workbench plan

Done when

Every spec item has an implementation path, validation path, gate and explicit omission state.

Sibling repository../payments-validation-fixture836a75dThe preparation guide explains how to verify a newer revision before using it.

Orient

Why this stage exists

Plan is the SPEED/workbench planning step. It turns approved defect specs into consequences without silently choosing for the learner.

The plan keeps unresolved refund idempotency visible instead of turning a policy gap into coverage.

Start from

What you start from

Work from these inputs only. Anything not on this list is either a later stage’s concern or a decision you do not own.

Defect specs
The audited defects/*.md files from Stage 4.
Review and eval YAML
The evidence and gaps that justify each task.
Constraints
Cost, prerequisites, parallel safety and the 90-second budget.
Demonstrate

Turn defect specs into tasks.json

One worked pass, so the shape of the work is visible before you do it on your own.

  1. Run workbench plan.
  2. Turn each defect file into implementation and validation tasks.
  3. Set order, gates, parallel groups and budget.
  4. Record refund idempotency as unresolved and unplanned if its owner has not decided it.

What this turns onA plan is an explicit argument about how the requirement will become evidence, not a list of every available check.

Practice

Do the work

  1. Inspect tasks.json and trace each task back to defects/1.md or defects/2.md.
  2. Plan removal of providerRequest from logs and the timeout/retry test.
  3. Keep the idempotency policy in explicit omissions.
  4. Review gates, cost and notExamined before continuing.
Output

You produce

Artifact

tasks.json

  • Task id
  • Source defect file
  • Implementation step
  • Validation step
  • Order and gates
  • Budget and omissions
Pressure-test

Challenge your own result

Why not let plan add every available check?

Show how this resolves

Because the plan must answer the risks in this spec within its budget. Extra checks can waste time and still fail to cover refund idempotency.

Gate

Ready to continue when

Readiness gate
  • Every spec item has an implementation and validation path.
  • The plan names its cost, gates and omissions.

What transfersA plan is an explicit argument about how a requirement will become evidence.