Review a Taiga delivery with evidence

Start with the initiative outcome

The fictional equipment service now lets employees view their own requests. Begin review with the initiative’s outcome and scope. Identify what must be true and what the change must leave intact.

For this delivery, an employee must not read another employee’s request. Managers must retain their defined access. A test that only opens the page does not establish either condition.

Connect the records

The Runs page records attempts, including failures. Each run identifies the plan it executed. A run page is an inspection record; decisions that change the work belong on the initiative.

Read the step evidence for tests and formatting. Taiga makes failed or unexecuted checks visible. Do not convert “not run” into “passed” in your review summary.

Inspect assumptions and boundaries

Look for assumptions about the access model, schema, environment, and external services. Compare them with the published intent and actual code.

For the equipment service, inspect where the request owner is checked. Test an authorized request, a different employee’s request, and a missing request. Check that logs do not reveal confidential request content.

Review the test changes too. A passing result has limited value if the change removed the assertion that would detect the defect. Treat workflow and test-configuration changes as part of the review scope.

Give actionable feedback

Identify the behavior, expected result, and evidence needed. For example: “The endpoint checks login but not request ownership. Add the server-side access check and a test using another employee’s request.”

Taiga can respond to pull-request review feedback and failing checks with changes on the same branch. After updates, inspect the new commit and its checks. Earlier evidence may not cover a changed artifact.

If the run stopped because the plan was incomplete or a check was weakened, read the stated reason. Do not remove draft status merely because the visible check summary is green.

Make the correct acceptance decision

Record which criteria are verified and which remain unresolved. Let the repository’s required reviews and checks enforce the merge boundary. Preserve any separate release decision.

Taiga observes deployments performed by your pipeline. Verify the environment and artifact before telling users that the change is available. A failed deployment can leave the previous successful version serving traffic.

Close the outcome with a service-level check: the employee can use the feature, unauthorized access is denied, and the operational owner can observe failures. Continue with handling an interruption.