ship-a-change

Submit with `scripts/ci_utils.py <PR#> --wait --merge`, which polls CI to green, submits to the Trunk queue, and waits for it to land. The queue requires the `qa-approved` label and squash-merges each PR; conflicting or red PRs must be rebased and resubmitted.

Launch the reference watcher in `reference/ci_watcher.py` via `ava.watcher.launch` after configuring REPO_ROOT, PR_NUMBER, and CI_UTILS. It wraps the repo's `check_ci()` and sends exactly one wake-up message when CI settles, including failed and conflict verdicts.

`--no-verify` disables every hook at once, silently skipping lints that have no other local gate. Instead skip only the hooks the machine cannot run by name, e.g. `SKIP=frontend-tsc,frontend-eslint git commit`, and note the skipped hooks in the commit message.

No. Direct pushes to main are forbidden and history must stay linear: always rebase your feature branch onto origin/main, never merge main into it. The only exception is when the user explicitly says to push directly.

Symlinking a shared `.venv` into a worktree makes a later `uv sync` write through the symlink and re-point the shared venv's editable path at the worktree, breaking other checkouts. Each worktree needs its own real venv created with `guard_editable_venv.py` and `uv sync`.

The merge queue cannot rebase a conflicting PR, so resolve it locally: run `git fetch origin main && git rebase origin/main`, resolve conflicts, force-push with `--force-with-lease`, and resubmit. A failed queue attempt on the same head SHA also requires a rebase before resubmitting.