ci: skip stacked PRs unless they carry ci/force-ci

[raphaelvigee]

Three repo-config changes.

1. Drop the Orca default worktree tabs

orca.yaml's defaultTabs (a claude tab wrapped in devenv shell, opened in every new worktree) is gone. scripts.setup is untouched, so a new worktree still gets gen — which it cannot build without, since gen/proto is a declared workspace member whose Cargo.toml isn't committed — and a codegraph index.

What goes with it is the wrapping. Anything opening a shell or agent in a worktree now has to enter the devenv shell itself, and the failure mode when it doesn't is the quiet one: missing cargo/buf/gen/lint fails immediately and visibly, but an ambient rustc with no RUSTC_WRAPPER builds perfectly well and silently bypasses kache. The header comment keeps the command and the reason.

2. Stacked PRs no longer run CI

A PR stacked on another PR's branch is not the change about to land. It can't merge until everything under it does, and master is squash-only so the layer above always gets rebased once its base lands — that force-push is the run anyone acts on. Building every layer on every push multiplied a deep stack's cost by its depth for verdicts about a tree nobody would merge.

A new gate job decides once:

situation	builds?
push to master	yes
PR whose base is the default branch	yes
PR whose base is another branch	no
…unless it carries ci/force-ci	yes

gen, govet and abi hang off it; everything else is transitively behind those. A skipped PR reports skipped checks and costs one ~15s runner.

The stack still merges, with no ruleset change

Required status checks live in the master ruleset, whose condition is ~DEFAULT_BRANCH — it applies to exactly the PRs whose base is master, which is exactly the set the gate builds. GitHub asks nothing of a PR that doesn't target a protected branch.

That argument has one seam, and edited in the trigger list is what closes it. A job skipped by an if: concludes skipped, which branch protection reads as a pass. GitHub retargets a child PR at master by itself when the base merges, and that retarget fires no synchronize — so without edited the child would sit at master carrying skipped-reads-as-green checks over content nothing ever built. The retarget is an edited event with changes.base, so it now starts a run whose base is master. gh stack sync (required anyway) is the second path; neither is trusted alone.

Cost of the extra trigger types, taken deliberately

labeled and edited fire on things that aren't code changes, and the gate can't suppress those without concluding "skip" on a master-targeting PR — which would replace its green required checks with skipped ones. So a label or a body edit on a master-targeting PR re-runs CI, and with cancel-in-progress doing either mid-run restarts it. gh stack submit pushes and rewrites bodies seconds apart, so those collapse into one run via the concurrency group.

Diagnosability

The summary job reports the verdict on the run page. The gate itself writes its reason to stdout and a ::notice annotation, and deliberately not to the step summary — $GITHUB_STEP_SUMMARY renders on the run page and nowhere else, not in gh run view --log and not in gh pr checks --json, so an agent seeing eleven skipping rows and exit 0 couldn't reach it. The annotation is in the check-run API and survives into gh. The text also names the ci/perf-test trap (labelling a stacked PR for perf gets nothing — perfbench needs the gated build). summary branches on needs.gate.result before touching its outputs, so a cancelled gate isn't reported as "this PR is stacked".

Tests

tests/ci_gate.rs freezes the structure, not today's job list: every job reachable from gate; a job that needs gate must also read its verdict (otherwise it looks gated and isn't); labeled/edited stay in the trigger types; the gate emits an annotation; summary consults gate.result; and no branches: filter returns to pull_request: — that skips at the workflow level, which publishes no checks at all, an empty list that reads like a pass (#240). Each guard was mutation-tested.

Also fixes a comment this change falsified: the perfbench block said adding a label doesn't retrigger the job.

3. perf-test → ci/perf-test

Both CI labels now share one namespace — a lone pr/ prefix on the other was a typo waiting to happen. Renamed in place on the repo, so ci/perf-test keeps its id and stays applied to #435 and #437. The functional reference is perfbench's if:; the rest are comments here and in perf.yml.

Not touched: the perf-test skill in .claude/skills/ and its references in .claude/agents/ and .cargo/config.toml — that's samply profiling, unrelated beyond sharing a name.

One transition window: a pull_request run resolves its workflow from head-merged-into-base, so an open PR carrying the label gets the renamed if: as soon as this lands on master, no rebase needed. Before it lands, those two PRs hold a label their own base's workflow doesn't match, so perfbench won't fire for them in that window.

Still open

Full skip vs. reduced matrix. product-vision offered running lint + test on linux/amd64 for stacked PRs — ~⅓ the spend, and it keeps real green checks plus pre-merge platform signal instead of a wall of skips. Full skip means a break that only shows on darwin/arm64 surfaces only once the layers below land. Recorded in CLAUDE.md next to the escape hatch rather than decided quietly.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NQ8kRpuBjgxsSf15RjLDZz