docs(board): a worker restart during a repo index loses the run

[sshlg]

What was measured

Release v279 restarted the worker at 10:59:34 UTC, 37 minutes into a 42-minute repo index:

10:59:36  shutdown on SIGTERM ◆ 0 jobs complete ◆ 2 failed ◆ 0 retries ◆ 1 ongoing to cancel
10:59:36  Process exited with status 143
10:59:45  Starting process with command `arq app.worker.WorkerSettings`

The fresh worker re-queued nothing — no run_repo_index or run_daily_project_knowledge_sync start in the next 30 minutes of worker log. WorkerSettings sets neither retry_jobs nor max_tries, so arq's defaults were in force and still did not retry.

The reaper then did its job correctly: both rows to failed / stale run reaped, which reaches error_log since N3.

Worth saying plainly: the restart was my own merge of #237 deploying. The finding is real regardless — a routine deploy silently costs a 42-minute index — but the trigger was self-inflicted, not a production incident.

Why filed and not fixed

The fix is a decision, not a detail:

• re-enqueue on shutdown — risks a double run against the _indexing_locks and advisory-lock guarantees;
• leave it to the nightly cron — then the loss must become visible in the UI instead of only in error_log.

Blast radius is bounded either way: the checkpoint survived with its completed steps recorded (indexing_checkpoint_step), so the next run resumes cheaply, and the cron re-runs within 24 h. A resilience gap, not lost data.

Also in this change

CB-OPS1 struck — closed on measurement, not assertion: a full rebuild on Standard-2X logged zero R14, zero R15, and no mem= at all, and graph_build completed over the full symbol set, which is the case the row said no run had exercised.

Severity table and the tally sentence are re-derived from the rows by script, not edited by hand: 33 open F-, 76 struck, 6 open CB-, 39 open total.

Verification

pytest tests/unit/docs/ — 50 passed (the ratchets that check this file's own arithmetic).

[sshlg]

Superseded by the PR above: the CB-OPS3 row travels there alongside the CB-OPS1 re-opening and the resume fix, so the board moves in one change rather than two that conflict.