Overnight Prs

---
description: Autonomous overnight loop — verify issues against the codebase, close stale ones, open review-ready PRs (bug fixes + trio-decided features/improvements, decisions documented), until done or limited
argument-hint: optional — issue numbers to prioritize, or a focus area
---

You are working autonomously overnight on the 2anki/server repo. Your job: verify each open issue
is still relevant against the current codebase, CLOSE the ones that no longer apply, and turn the
relevant ones into review-ready pull requests (one PR per issue) — not just bug fixes, but
features, improvements, and copy/UX changes too. Keep going until you exhaust the queue or hit
your usage limit. The night is wasted if you only close stale issues and ship nothing; aim to
leave a stack of PRs Alexander can review and merge.

Alexander is asleep and will NOT respond — never wait, never ask a question. **The old rule was
"if a decision is needed, SKIP." That is what made past runs unproductive. The new rule: when an
issue needs a product, UX, or copy decision, CONVENE THE TRIO (pm + designer + engineer in one
parallel Agent call), let them make the call, implement it, and write every decision and
assumption into a `## Decisions made overnight` section of the PR so Alexander can review and
override in the morning.** You only SKIP when a change is genuinely unsafe to make unattended
(see the hard rails below) or when you truly cannot tell what the issue is asking even after the
trio looks at it. Defer the *judgment to a documented trio call*, don't defer the *work*.

Optional focus / seed from the invocation: $ARGUMENTS
(If issue numbers or a focus area are given, prioritize those first, then continue with the rest
of the backlog under the same rules. If empty, work the whole open backlog.)

## Absolute safety rules (violating any of these is failure)
- NEVER merge a PR. NEVER run `gh pr merge`. Alexander does all merging.
- NEVER push to `main`. NEVER `git push` without `-u origin <branch>`. Always work on a branch.
- NEVER deploy, NEVER SSH to the prod box, NEVER touch production data.
- One PR per issue, branched off fresh `origin/main`. NEVER stack PRs.
- NEVER put a reporter's name, email, Notion workspace, or deck title in a commit, PR, branch
  name, OR an issue comment. Use the numeric user ID or a symptom description (see
  `.claude/rules/support-confidentiality.md`). Issue comments are public.
- You MAY close an issue and comment on it ONLY under the "Verify relevance" rules below, with
  concrete evidence. You may NOT relabel, reassign, or edit issue titles/bodies.
- Read `CLAUDE.md` and the relevant layer/feature `CLAUDE.md` + `.claude/rules/*` before editing.
  They override your defaults.

## Step 0a — enumerate the FULL open backlog (run ONCE, before any issue work)
`gh issue list` defaults to 30 results and silently truncates; an ad-hoc `--limit 100` still
drops most of a 200+ issue backlog and makes the "no eligible issues remain" stop condition lie.
NEVER rely on the default. Build the complete work queue up front so you know the denominator (M)
from the start:

```bash
gh issue list --repo 2anki/server --state open --limit 1000 \
  --json number,title,createdAt,labels \
  --jq 'sort_by(.createdAt)' > /tmp/overnight-backlog.json
M=$(jq 'length' /tmp/overnight-backlog.json)   # the denominator for the coverage line

• --limit 1000 overrides the 30 default and covers the current backlog with headroom. If the count ever approaches 1000, raise it or switch to --paginate. NEVER leave it at the default.
• gh returns newest-first; --jq 'sort_by(.createdAt)' re-sorts OLDEST-FIRST. Work the queue in that order — the longest-standing issues are the likeliest to be already-fixed-and-closeable, which is the safest, highest-value work to do unattended. Explicit $ARGUMENTS issue numbers jump the queue first; then resume oldest-first.
• The JSON file — not a live gh issue list page — is the source of truth for "what remains." Do NOT stop early because a screenful looks done.
• High-water mark / resumability across nights. As you finish each issue (PR'd, CLOSED, or REACHED-but-left-open), append its number to /tmp/overnight-processed.txt, one per line. A later night re-runs Step 0a, then works only backlog − processed (set subtraction). Do NOT re-examine issues a prior run already PR'd or CLOSED. You MAY re-examine an earlier SKIP if the code has since changed. This file holds numbers only — never reporter data.
• The goal is real, shipped work: close what's dead and open PRs across all three tiers (bug fixes, trio-decided features/improvements, draft migrations). A night that only closes stale issues and ships no PRs has not earned its run — work the queue, don't just survey it.

Step 0 for EVERY issue — verify it's still relevant against the codebase

Before doing ANY work — bug fix OR feature — confirm the issue still describes a real gap in the current code. Read the actual code paths it names; do not trust the issue text alone.

• For a bug: reproduce it against current main. Does the broken behavior still happen?
• For a feature/improvement: check whether the requested capability already exists or was shipped since the issue was filed. Find the code that would implement it; if it's already there and working, the issue is done.
• For either: confirm the surface, format, or integration it talks about still exists.
• An issue is NO LONGER RELEVANT if you have CONCRETE evidence that:
  • (a) the bug is already fixed — you wrote a test for the reported behavior and it PASSES, or the behavior demonstrably works now; or
  • (b) the requested feature/capability is already shipped — point at the code that provides it; or
  • (c) it targets a feature/surface/integration that no longer exists (removed or replaced by a shipped redesign); or
  • (d) it is a clear duplicate of another open issue (name the other issue #); or
  • (e) it is jun