Aglet

What to learn from a failed first project check

The durable lesson from a failed setup check is a local evidence contract: a test key submits a built-in sample, the app reports its status, and saved results link back to the same project. Preserve failure and retry fixtures so onboarding remains specific without promising external intake behavior.

Keep the lesson for the next incident

  1. Write the check contract

    Document key environment rules, request states, built-in sample labeling, Signal and Work Item links, retry behavior, and project scope. State that the local check does not establish customer or external producer behavior. Keep secret display and storage boundaries explicit.

  2. Keep setup fixtures

    Save synthetic traces for success, missing key, invalid key, wrong project, repeat, delayed result, and interrupted check. Assert status, labels, links, role, and durable records. Attach fixtures to the work record without storing key secrets or event payloads.

  3. Define recurrence signals

    Reopen review when a check has no observable status, sample evidence loses its built-in label, links cross project scope, or an error suggests an unsafe retry. Record processing and producer limits and assign owners for local setup versus broader intake questions.

What to carry forward

Close learning with the local check contract, redacted fixtures, project-scope rules, and recurrence triggers. Keep processing and external-source limits explicit so a future setup change is tested against what the application actually controls for future reviews.

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