Aglet

How to verify built-in project check recovery

Verification should prove that a new owner can run the built-in check, understand its status, and reach the labeled sample Signal and linked Work Item when saved. Exercise failure paths so a blank or pending state never looks like success. Keep any uncontrolled processing timing visibly partial.

Check whether the outcome improved

  1. Verify the happy path

    Create a synthetic project and non-production test key, run the built-in check, and assert the request status and next action. Confirm the sample Signal and linked Work Item use explicit built-in labels, correct project scope, and safe links after refresh.

  2. Verify failure states

    Use missing, invalid, wrong-project, repeated, and interrupted attempts where supported. Assert each state explains retry or inspection without exposing secrets or suggesting customer data. Verify a failed check does not fabricate a saved Signal or Work Item.

  3. Verify roles and timing

    Run the overview and result links as owner and restricted roles available in fixtures. Assert actions remain authorized and labels remain truthful. Repeat after a controlled delay and mark any processing stage the harness cannot observe as partial with the missing proof recorded.

What to carry forward

Accept when the local check has one clear outcome, its sample evidence is labeled and scoped, and failure states offer safe recovery. Mark background timing or external intake questions partial; successful local sample evidence cannot prove another producer path.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow