{
  "$comment": "Flaky-test quarantine ledger (deletion ratchet \u2014 see AGENTS.md 'Flaky tests: quarantine on sight' and docs/testing.md 'Quarantine ledger and the deletion ratchet'). A test observed failing without a corresponding real bug is quarantined ON SIGHT: add an entry here AND a matching one-line `exclude` entry in that package's vitest config, in the same commit. Every entry needs a non-empty `reason` (link the failing run) and a `quarantinedAt` date \u2014 the entry expires 14 days later, at which point the test file is DELETED unless someone rescues it with evidence it catches real regressions plus a root-cause fix (never appeasement). scripts/check-quarantine-ledger.mjs mechanically verifies this ledger and concrete `exclude:` array entries stay in lockstep.",
  "entries": [
    {
      "file": "packages/engine/src/__tests__/self-healing-pending-wedge-notification.test.ts",
      "reason": "SECOND sighting of a suite-only flake: 'reconcile pending wedge notifications > selects elapsed markers and audits the completion outcome verbatim' fails ONLY in a full engine-suite run (expected 1 selected marker, saw 2) and passes deterministically in isolation and in small multi-file runs. First sighting was recorded in docs/solutions/test-failures/suite-only-flakes-observed-register.md at ea48af7ab5; observed again on the full run at a97aa84a20. Reads as cross-test state bleed into the reconciler's marker selection, not a timing wait \u2014 no timeout, retry, or assertion was changed. Per AGENTS.md the second sighting is an on-sight quarantine with no further discretion.",
      "quarantinedAt": "2026-08-23"
    },
    {
      "file": "packages/core/src/__tests__/postgres/mission-store.pg.test.ts",
      "reason": "Load-sensitive wall-clock race: 'serializes concurrent claims on the same task (Greptile P1 race)' holds a transaction open, sleeps 250ms, then asserts the competing claim has not settled. Under parallel machine load the second claimant settles (its `settled` flag flips on EITHER success or failure), so the assertion fails with no serialization bug. Observed twice on 2026-08-23 while three dashboard suites ran concurrently (a subagent's 180-file core run, then a full-core run plus an isolated run); passes 65/65 three consecutive times once the machine is calmer. An A/B against the projectTableNames registry change looked causal on one run and did NOT reproduce - the coincidence is the flake itself. Rescue needs a deterministic block-detection signal (e.g. pg_locks / a lock-wait probe) instead of a sleep, not a longer sleep.",
      "quarantinedAt": "2026-08-23"
    }
  ]
}