A running drain's own order is fixed: category, then severity, then its tie-breaks (orderEligible in internal/core/capture/eligible.go), and its flags can only hold an issue back (--skip), so it cannot be told which eligible issue to take first. The route a person has today is to build one issue themselves with `abcd build <iss-N>` (internal/surface/cli/build.go:102), under the same drain rule. Inside a running drain, an issue a person or a release cut wants sooner waits behind every eligible issue ahead of it.

A running drain's own order is fixed: category, then severity, then its tie-breaks (orderEligible in internal/core/capture/eligible.go), and its flags can only hold an issue back (--skip), so it cannot be told which eligible issue to take first. The route a person has today is to build one issue themselves with abcd build <iss-N> (internal/surface/cli/build.go:102), under the same drain rule. Inside a running drain, an issue a person or a release cut wants sooner waits behind every eligible issue ahead of it.

This concerns only the issues in that order: a major is not in a baseline drain's order at all, and the ledger holds no mark of urgency a drain could read. iss-2610161655393137 carries a ruling that one repository's drain runs most urgent first; that orders by severity and names no issue, so this record neither duplicates it nor is a narrower case of it.