docs: track the recurring e2e CI flake pattern as a prioritized backlog item (#26)

Owner-directed: record a recurring problem the moment it's found, not
just individually re-diagnose and shrug it off each time. Three
distinct specs have each failed once on a shard then gone green on
rerun across three different PRs tonight (resizable-table.spec.ts,
canvas-live-sync.spec.ts, and the already-fixed MCP shutdown-timeout
flake, PR #21) -- worth investigating as a batch rather than
re-establishing the same 'confirmed transient, moving on' verdict
every time it recurs.


Claude-Session: https://claude.ai/code/session_01FYwojT8GdUbYSoggbvEFft

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Author: alicoding

docs/goals/BACKLOG.md

@@ -164,6 +164,7 @@ live-review material, interleaved during owner reviews, not a lane.**
 13. [x] [0020 — Workflow breakpoints](archive/0020-workflow-breakpoints.md) — delivered 2026-08-11 (ADR-0031 full scope incl. step mode + MCP debug tools; delegated build; found+fixed the ExecuteOptions.WorkflowID never-set bug that silently disabled all workflow/instance-scoped guardrail rules at runtime)
 
 **Standing**
+- [ ] E2e CI flake investigation (owner-directed 2026-08-12: "add to the backlog when problem found so that we prioritize to unblock us") — three distinct e2e specs have each independently failed once on a shard, then gone green on an immediate rerun, across three different PRs in one session: `resizable-table.spec.ts` (drag-handle bounding-box), `canvas-live-sync.spec.ts` (MCP `update_workflow` live-redraw assertion), and (Go side, same class) `TestMillMCPService_RealClientRoundTrip` (already fixed — its 2s `Shutdown` timeout was genuinely too tight for a loaded shared runner, bumped to 10s, PR #21). Each so far individually diagnosed as unrelated to the PR that triggered it and confirmed transient by a clean rerun — but three in one session is a real pattern worth investigating as a batch rather than re-diagnosing from scratch every time: is the shared macOS/ubuntu CI runner under-resourced for the current suite size, are these three specs sharing some real timing sensitivity (a fixed wait/assertion window too tight for runner variance), or is this the general shape more of the suite's specs have and will keep surfacing one at a time. DoR: pull the actual CI run history for these (and any other) specs' pass/fail/rerun rate over the last N runs before assuming root cause; DoD: either a fix (raise a shared timeout/wait pattern, add strategic retries per goal 0024's existing e2e-retry precedent) or, if genuinely just runner variance, a documented decision to accept it with reasoning, not silence.
 - [ ] [0001 — Authoring-surface overhaul](0001-authoring-surface-overhaul.md) (spacing audit + §3.8 prototype elements — live-review material)
 - [ ] [0021 — MCP dogfood gap closure](0021-mcp-dogfood-gap-closure.md) (owner-mandated 2026-08-11: orchestrator live-probes the MCP surface against the bank use cases, logs ranked gaps, fixes graduate out; **Phase 1 fully complete 2026-08-12** — all 4 gaps fixed/verified + 1 confirmed-by-design; Phase 2/3 still open, need live interactive probing not code changes)
 - [ ] Workflow pins/favorites (tech debt, split from goal 0015's remainder 2026-08-12) — no pin/favorite concept exists anywhere in Mill today (grepped before scoping it out); needs its own small schema decision (which store owns a pin list, per-workflow or a plain ID set) before any build — deliberately not invented ad hoc under 0015's frecency-only ship. Quick Panel's workflow list sorts by frequency alone until this lands.