pstack: bug-fix playbook gets a flake-triage rule

[chesley-veko]

What

Adds one paragraph to pstack/skills/poteto-mode/playbooks/bug-fix.md: how to treat a test that failed once.

A test that failed once is a bug until proven otherwise. Capture the full failure output before rerunning. A rerun without a saved assertion destroys the evidence. Fails-in-suite but passes-alone is the signature of order-dependent shared state, not noise. Name the shared resource before you stop. A flake verdict needs a captured assertion plus either a reproduction or a tracker entry. One green rerun earns neither, and a privacy or security assertion never earns it at all.

Why: the case that produced it

Running the bug-fix playbook over a 67-failure pytest suite, one privacy-boundary test (test_export_has_owner_only_initial_generation_audit_without_private_payloads, asserting an account export contains only the owner's calibration audit rows and no private payloads) failed once in a 239-test subset, then passed alone and passed on the identical subset rerun. The agent labelled it a flake and moved on without saving the assertion. The playbook had nothing to say about that decision, so nothing stopped it.

The user rejected the verdict. Rerunning with full capture and forcing the suspected race showed it was a real bug:

>   assert claimed is not None and claimed.lease_owner_token
E   assert (None is not None)

Mechanism: earlier tests in the same module instantiated a module-scoped app client whose lifespan runs a calibration scheduler polling claim_next every second. The failing test enqueues a job by hand and then claims it itself. When a scheduler tick lands in the gap between the enqueue and the test's own claim_next, the scheduler owns the job and the test sees None. Running the test alone never fails because nothing requests the app-client fixture, so the scheduler never exists. That is exactly the fails-in-suite / passes-alone signature.

Evidence: with the scheduler interval tightened to 0.5s the module failed 1 in 12 runs. After idling the scheduler for the duration of the test, 0 in 20. The cross-process variant (any live backend sharing the dev database) went to the project's tracker as a per-worker database isolation item.

Every sentence in the new paragraph maps to a step that was skipped: capture before rerun, name the shared resource, reproduction or tracker entry before closing, and no flake label on a privacy assertion.

Style

Follows #331: no semicolons, em dashes, or connector colons in the prose.

---

Note

Low Risk
Documentation-only change to an internal playbook; no runtime or product code paths.

Overview
Extends the bug-fix playbook with a short flake / intermittent-failure triage block so agents do not dismiss a one-off test failure without evidence.

The new prose sets defaults and guardrails: treat a single failure as a real bug until disproven, save full failure output before any rerun, read fails-in-suite / passes-alone as order-dependent shared state (name the resource), and only allow a flake call with a captured assertion plus reproduction or a tracker entry—never on privacy or security assertions from one green rerun.

^{Reviewed by Cursor Bugbot for commit 790d899. Bugbot is set up for automated code reviews on this repo. Configure here.}

[GitTim2Day]

A lot of these can be mitigated by saving the flawed-unverified in a log or archive then rerun the code using BASIC and Python or other logic. Like:
GO_SUB
Do_until nearly flawless
Run (code/program/process)
error test-mitigate, retest, mitigate as the nest inside the do_until loop then
RETURN
And let the AI fix it

Works as NLP.

[GitTim2Day]

mitigate until nearly flawless