P158 · Evaluation & feedback

Plan-Mandated Defect Is Still a Finding

Report an implemented requirement that is itself defective without hiding the conflict.

Editorially reviewed

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A plan requires only asserting that paymentMock was called, while the behavior goal is keeping an order pending after rejection. Implementation follows the plan, yet an incorrect state may still pass.

Mechanism

Assess specification compliance and whether verification detects required behavior separately. Cite plan, test and a concrete missed failure, labeling the conflict plan-mandated. Propose an observable-state assertion and identify the required scope change. The responsible owner records a ruling before authorized repair. Do not equate compliance with quality or silently rewrite the plan.

Bad example

The plan asked for this, and the mock was called, so test quality passes. Ignore the wrong order state.

Good example

Report two axes: the mock-call requirement is satisfied, but incorrectly marking rejected payment as paid can still pass. Cite plan and test, label plan-mandated and propose a state assertion subject to a recorded ruling.

Why the change matters

Plan authors can omit necessary behavior. Separate reporting acknowledges accurate implementation while exposing real risk, preventing a plan from certifying its own quality.

Observable expectation

A teaching mutation marks a rejected order paid: the original call assertion passes and a query-state assertion should fail. Record whether the ruling revises requirements. Without running the mutation, report a check design rather than measured evidence.

Limits

The owner resolves conflicts; review does not expand approved scope. Mock assertions can be useful, so show a concrete missed requirement. Severity follows impact rather than the source label.

Sources and evidence

Read the editorial criteria

Related methods