Practice workspaceY
Better task judgment
PRACTICAL CODEX LESSON

Verify a change when there is no test suite

Match a claim to a discriminating runtime or visual check, preserve its evidence, and report what remains unverified.

01 / PREDICT

An agent reports a successful build and a clean screenshot. What can those observations establish about a save button?

Write a brief prediction before opening the explanation.

02 / EXPLAIN
Read the lesson

Choose an observation that could disagree

A missing test suite does not make a change unverifiable. Start with the acceptance criteria and decide what you would observe if the change were wrong. A screenshot can reveal an overlapping label; it cannot by itself show that a saved value survives reload. An endpoint response can establish one request’s behavior; it does not establish every permission case. Select evidence for the actual claim rather than whichever check is easiest to run.

Capture conditions as well as results

For a visual change, name the viewport, relevant states and differences from the reference. For interactive behavior, record the starting state, actions and resulting state. For a service, identify the request, identity, expected status and relevant response content without exposing secrets. For a log, preserve the final result and any omitted output. A preview of the beginning of a long command is not evidence that its ending was successful.

Make acceptance proportionate

The learner should inspect the diff and the evidence, not repeat every action mechanically. An agent’s summary is a claim; actual tool output and observed behavior give that claim support. High-risk changes need stronger independent checks. Visual similarity does not establish keyboard access, data persistence or authorization. A useful completion summary distinguishes what was observed from what is still unknown and names the smallest remaining check.

Common mistake

Accepting a green build as proof of an interactive workflow, or treating an empty screenshot difference list as proof of every requirement.

03 / DEMONSTRATE

Make the request actionable

A weak starting brief: The build passed and it looks good. Mark the save flow complete.

Inspect the diff for the settings-save change. Launch the app using the verified project procedure. Exercise save, reload and a controlled failure; record observed behavior and relevant network evidence without secrets. Compare the required layout states at the specified viewports. Report which criteria are supported and which remain unchecked. Do not treat a summary or screenshot alone as proof of persistence.

This example is an adaptable request, not evidence that a runtime action has executed.

04 / PRACTICE

A settings save button

Simulated report: build succeeded. Screenshot: the Save button is aligned at desktop width. No click, response, reload or error-state evidence is available.
Requirement: save the selected preference, preserve it on reload and show a useful error if the request fails.

Simulated scenario · No repository access or command execution

Which acceptance decision is supported?

Loading your saved lesson progress…