Skip to content
arula

Stage 325 minutesPairs301 · Tooled judgment

Eval the evidence gaps

Run workbench eval on the review output, find gaps in the tests and evidence, and separate code defects, test gaps and specification gaps.

You will produce

Eval YAML

We will demonstrate

From evidence to the smallest correct next action

Done when

Every gap cites evidence and is routed as code, test or specification work.

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

Orient

Why this stage exists

Evaluation reads what ran and what did not before accepting a finding.

The same refund-retry evidence can reveal a code defect, a weak test and a missing policy. Those are different gaps with different next steps.

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.

Review YAML
The bounded review findings from Stage 2.
Current tests
The happy-path refund test and related payment tests.
Requirements
The written payment behavior and its omissions.
Demonstrate

Separate code, test and specification gaps

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

  1. Run workbench eval against the review YAML and available evidence.
  2. Read notExamined and failed checks before the findings.
  3. Classify the weak timeout test as a test gap and provider-request logging as a code defect.
  4. Record missing refund idempotency as a specification gap owned by payments product.

What this turns on“The test did not catch it,” “the code is wrong” and “the requirement never decided it” are different claims.

Practice

Do the work

  1. Evaluate the refund-retry review output.
  2. Record a test gap if a broken timeout retry still passes the happy-path test.
  3. Record a code defect if the provider request reaches a log sink.
  4. Do not invent an idempotency requirement to close the policy gap.
Output

You produce

Artifact

Eval YAML

  • Observed evidence
  • Gap type
  • Risk affected
  • Evidence needed next
  • Owner
Pressure-test

Challenge your own result

The mutation survives. Should the learner immediately add an idempotency test?

Show how this resolves

Only if idempotency is already required. Record the weak retry test as a test gap and route the missing refund-idempotency policy to its owner.

Gate

Ready to continue when

Readiness gate
  • Every gap cites the review or validation evidence that supports it.
  • Code, test and specification gaps are not conflated.

What transfersEvaluation turns evidence into the smallest correct next action.