cglearn — Practice a better workflow

01 / PREDICT

A test fails but deployment continues. Was the check absent, or did the workflow fail to use its result?

Your prediction

Write a brief prediction before opening the explanation.

02 / EXPLAIN

Read the lesson

A request is not enforcement

Three different things can happen: instructions ask for a check, a tool executes it, and a workflow conditions the next action on its result. Only the third establishes a gate. A convincing completion message cannot substitute for a missing result. Start by naming the action to block, the evidence required and the condition under which work may continue. These conditions must be controlled by the workflow, not inferred from a model sounding confident.

Test the blocked path

A check can run and still be ineffective if its failure is ignored, its status is lost, or another route bypasses it. In a safe test environment, supply a known failure and verify that the dependent action does not occur. Also test the allowed path with valid evidence. A gate that always blocks is not correct either. No shell commands run in this lesson: the following cases describe simulated workflow records, not a tested CI configuration or a Codex hook contract.

Bind evidence to the work being accepted

A passing result from yesterday may be genuine yet unrelated to the current revision. Record the artifact or revision checked, relevant conditions and final outcome. If code changes after verification, decide which checks must be refreshed. A passing build still does not establish every behavior or authorization boundary. Treat missing, stale or interrupted evidence explicitly; request the smallest sufficient next check instead of overriding the gate to make the workflow green.

Common mistake

Accepting the existence of a test step as proof that failure prevents deployment.

03 / DEMONSTRATE

Make the request actionable

A weak starting brief: Always run tests before deploy. If they fail, say everything is probably fine and continue.

Inspect the current release workflow. Identify the action that requires verification, how failure propagates, and whether evidence belongs to the intended revision. Propose a bounded gate that blocks on failed or missing required evidence. In an isolated test, demonstrate both a known failure that prevents the dependent action and valid evidence that allows it. Do not deploy or change permissions during this review.

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

04 / PRACTICE

The ignored failure

Simulated pipeline: test step runs on revision R2 and reports failure. The deploy step still executes because it is configured to continue regardless of test status. The agent says tests were run.

Simulated scenario · No repository access or command execution

What is the correct diagnosis?The gate worked because the test step existed.The tests executed, but failure did not block deployment; correct the dependency and prove the blocked path.Accept the deployment because the agent acknowledged failure.Delete the failing test to restore a green pipeline.

Loading your saved lesson progress…