Development record
abcd's own tests warn before running on an overloaded machine
Press Release
Before abcd runs its own tests on your machine, it looks at what is already running. If a program that is not part of abcd's work has been running flat out for over half an hour, or the machine is loaded far beyond its cores, abcd says so loudly before it starts: your own stray programs by name, with how to stop them; other people's only as a count and how much of the machine they use. Then it carries on, because the choice to stop is yours. In an autonomous run the warning also lands in the run's log, so nobody finds out two days later from a crash.
"Two days of leftover busy loops took my machine down and nothing said a word," said Maya, an autonomous-development practitioner. "Now the first test run after I leave something burning tells me what it is and how to stop it."
Why This Matters
On 2026-09-21 the development machine panicked: eight leftover CPU burners from
a load experiment had run for more than two days, abcd's own test binaries were
found running beneath them, and nothing had said a word
(iss-2609210828122412, promoted into this intent; promoted_from (historical) was
written by hand because the issue route of capture promote --intent stamped only
promoted_to (historical)). On 2026-09-22/23 the autonomous run then worked for a whole
session under a load of about 440 from another account's orphaned loops that it
could not stop, and the product thinker chose to carry on.
The product thinker ruled on 2026-09-23 that a load experiment is trusted only
under four conditions. The first three (one owned process group killed
together; "clean" proven by what is running, never by a list; consent and a cap
below the core count on a live development machine) ship as the bundled LOAD
rule domain. The fourth, abcd's own test lanes checking the machine before they
start, is this intent. At the planning interview the product thinker changed
that fourth condition from "refuse when the load is too high" to "warn, never
refuse": the load average alone cannot tell the incident from the run's normal
state (one preflight peaks near 7, eight concurrent preflights near 42, the
incident's burners near 8 to 12 on 16 cores), and a refusal would have stopped
every lane of a run the product thinker chose to continue.
Decomposition (itd-84 hand-run, 2026-09-23, confirmed by the product thinker at the planning interview)
Verdict: FILE-AS-IS. One capability; the rest is already shipped, carried by this intent's criteria, or plumbing.
| Part | Type | Home |
|---|---|---|
| A warning before abcd's own tests start, naming the caller's stray programs and counting other accounts', written to the run log in an autonomous run | capability | this intent |
| One owned process group killed together; clean proven by what is running; consent and a cap for load experiments; never kill by pattern | rules | already shipped as the bundled LOAD rule domain (the last added in the loadtrust fix round) |
| abcd never starts its tests under foreign load | trust rule | not recorded: the product thinker ruled warn-only, so no refusal invariant exists to record |
| What a warning may say about other accounts' programs | stance | carried by acceptance criteria 2 and 4 and the scope conditions; no new principle |
The settings file under ~/.abcd/, the process reading on each platform, and the preflight and eval-harness wiring |
plumbing | the spec intent plan mints |
Relations, in prose because the schema carries no typed field for them (iss-2609091256264547): this intent refines the fourth condition of the 2026-09-23 ruling on iss-2609210828122412, and changes that condition from a refusal to a warning.
What's In Scope
- A check that runs once at the start of
make preflight(so the pre-push hook inherits it) and once at the start of the eval harness, never once per test package. - Two warning triggers: a process outside abcd's own lanes at near full CPU for longer than the stray limit (default 30 minutes), and a load average above the extreme limit (default four times the online core count).
- The caller's own strays named in full (executable name, pid, age, CPU share) with how to stop them; other accounts' strays reported only as a count and a total CPU share. The output passes the private-names scrub.
- A
loadwarning event in the run log when the check runs inside an autonomous run. - Per-machine limits in a settings file under
~/.abcd/, defaulting from the online core count in the same unit as theLOADrule's cap. - macOS and Linux, with no new dependency.
What's Out of Scope
- Refusing to start. The check never refuses and never waits.
- Killing or pausing anything. The warning names the remedy for the caller's own strays; the caller acts.
- CI runners. A fresh runner carries no strays; the check does not run there and says so.
- Windows.
- Load experiments themselves, which the
LOADrule domain governs.
Acceptance Criteria
- Given one of the caller's own programs outside abcd's work has run at near full CPU for longer than the stray limit, when
make preflightor the eval harness starts, then it prints a warning naming the program's executable name, pid, age and CPU share with how to stop it, and carries on. - Given stray programs that belong to other accounts, when the check runs, then the warning reports only how many there are and their total CPU share, with no program name, command line or account name, and carries on.
- Given only abcd's own short-lived test processes are running, however many at once (for example eight concurrent preflights at a load near 42 on 16 cores), when the check runs, then no warning is printed, and a test proves it.
- Given a load average above the extreme limit (four times the online core count by default), when the check runs, then the warning gives the load and the core count, and carries on.
- Given an autonomous run, when the check prints a warning, then the same warning is written to that run's log as an event.
- Given a settings file under
~/.abcd/that sets either limit, when the check runs, then it uses those limits; without the file it derives the defaults from the online core count; a malformed file is reported loudly and the defaults are used. - Given the check's placement, when the local check run or the eval harness starts, then the check runs once at its start and never once per test package; and given a CI runner, then the check does not run and the log says it was skipped and why.
- Given macOS or Linux, when the check runs, then it reads load and processes with no new dependency; and given a platform where it cannot read them, then it says it could not check and carries on.
Decisions
Ruled by the product thinker on 2026-09-23 at the planning interview, after two independent adversarial reviews of the draft (design/feasibility and record discipline):
- Signal. Both triggers: foreign sustained CPU (the incident's shape) and an extreme load ceiling. The load average is not the trigger for the incident.
- Warn, never refuse. For the caller's own strays and for other accounts' alike. This changes the 2026-09-23 ruling's fourth condition from "refuse when it is too high".
- Where. Once at the start of the local check run and of the eval harness; in an autonomous run, also the run log; not on CI.
- Privacy. Other accounts' programs appear only as a count and a total CPU share.
- Limits. Defaults of 30 minutes near full CPU for a stray and four times
the online core count for extreme load, adjustable per machine in a settings
file under
~/.abcd/.
Open Questions
None open; decisions 1 to 5 settle the four the draft carried (the ceiling, which lanes, what a refusal names, an override) and the signal the reviews raised.
Mechanism
We expect the foreign-sustained-CPU signal to flag both recorded incidents (the 2026-09-21 leftover burners and the 2026-09-22/23 other-account loops) and none of the run's 58 recorded normal-work load samples, because normal work is entirely short-lived test processes; shown wrong if it flags normal parallel work or misses a real stray.
Scope Conditions
- macOS and Linux developer machines; Windows is not covered.
- abcd's tests running on a person's own development machine, not on CI.
- abcd's own test processes finish within minutes; a test running flat out for longer than the stray limit would read as a stray.
- The machine may be shared by several accounts, which is why other accounts' programs are only counted.
Audit Notes
Fidelity review — receipt rcp-46f69cff6b50 (verifier intent-auditor claude-fable-5-1).
Provenance: intent-auditor@claude-fable-5-1 · rubric_hash sha256:effa65b3e9e88ff29433b443ec2be159522a8b0b71cf1434526514aa61edb13e · prompt_hash sha256:98e58bb42916e7f0648e4befdeefa2dea3cf5f9503c15495bec70b925497f3a1 Input attestations: diff:tree at 4c09b5c749de3dc3d1a1e0ab85d9dcd58ffcb4d5 (main lineage, itd-2609231434459890 shipped)@-;
Acceptance rollup: MET 8 · MET_WITH_CONCERNS 0 · NOT_MET 0 · INCONCLUSIVE 0
Per-criterion verdicts:
- ac-1 — MET: Classify names the caller's own processes past the stray limit at near-full share, excluding the invocation's ancestry; the render prints each with name, pid, group, age and CPU share and the pgrep/kill remedy, and ends with abcd carries on; TestImplementLoadNamesOwnStraysWithTheRemedy covers it and the Makefile target ignores the exit evidence: internal/core/machineload/classify.go:146 — "if ancestry[p.PID] || p.Age <= limit {" evidence: internal/surface/cli/implement_load.go:140 — "pid %d group %d running %s CPU %d%% of a core" evidence: internal/surface/cli/implement_load.go:168 — "still shows it, then: kill %d%s" evidence: internal/surface/cli/implement_load.go:201 — "abcd carries on; stopping them is your call." evidence: internal/surface/cli/implement_load_test.go:69 — "func TestImplementLoadNamesOwnStraysWithTheRemedy(t *testing.T) {" evidence: Makefile:343 — "-go run ./cmd/abcd implement load --site preflight"
- ac-2 — MET: a stray with another uid only increments a count and a cores total, the OtherStrays type carries no identity field, and the render prints the count and share alone; TestImplementLoadKeepsOtherAccountsAnonymous and TestOtherStraysTypeCarriesNoIdentity cover it evidence: internal/core/machineload/classify.go:157 — "v.Others.Count++" evidence: internal/surface/cli/implement_load.go:173 — "Other accounts: %d programs at nearly all the CPU they can get, for over %s, using about %.1f cores." evidence: internal/core/machineload/classify_test.go:355 — "func TestOtherStraysTypeCarriesNoIdentity(t *testing.T) {" evidence: internal/surface/cli/implement_load_test.go:112 — "func TestImplementLoadKeepsOtherAccountsAnonymous(t *testing.T) {"
- ac-3 — MET: TestEightConcurrentPreflightsAreQuiet models eight make/go/core.test/compile trees under the caller's uid and asserts no trigger, TestEightConcurrentShortLivedProcessesDoNotWarn does it with live busy children, and TestImplementLoadIsQuietUnderOwnParallelWork covers the front door; the machineload package is green at BASE evidence: internal/core/machineload/classify_test.go:298 — "func TestEightConcurrentPreflightsAreQuiet(t *testing.T) {" evidence: internal/core/machineload/live_test.go:47 — "func TestEightConcurrentShortLivedProcessesDoNotWarn(t *testing.T) {" evidence: internal/surface/cli/implement_load_test.go:196 — "func TestImplementLoadIsQuietUnderOwnParallelWork(t *testing.T) {"
- ac-4 — MET: the extreme trigger fires strictly above lim.ExtremeLoad, which defaults to four times the online cores, and the render states the load averages, the limit and the core count; TestExtremeTriggerIsStrictlyAbove and TestImplementLoadReportsLoadAndCores cover it evidence: internal/core/machineload/classify.go:171 — "if snap.HasLoad && snap.Load1 > lim.ExtremeLoad {" evidence: internal/core/machineload/limits.go:30 — "DefaultExtremeFactor = 4" evidence: internal/surface/cli/implement_load.go:189 — "Load %.1f over 1 min (%.1f over 5, %.1f over 15) is above the extreme limit of %s (%s)." evidence: internal/surface/cli/implement_load_test.go:213 — "func TestImplementLoadReportsLoadAndCores(t *testing.T) {"
- ac-5 — MET: logLoadWarning appends an EventLoad event to the live run's log with the result's fields, LoadResultFromEvent reads it back, and a failed write is reported with the warning standing; TestLoadWarningIsLoggedInALiveRun, TestNoEventOutsideARun and TestLoggedEventRendersToThePrintedWarning cover it evidence: internal/core/implement/log.go:62 — "EventLoad = "load"" evidence: internal/core/implement/load.go:402 — "_, err := run.append(session, EventLoad, fields)" evidence: internal/core/implement/load_test.go:114 — "func TestLoadWarningIsLoggedInALiveRun(t *testing.T) {" evidence: internal/surface/cli/implement_load_test.go:288 — "func TestLoggedEventRendersToThePrintedWarning(t *testing.T) {"
- ac-6 — MET: readLimits reads ~/.abcd/load-limits with stray-minutes and extreme-load keys over DefaultLimits(cores), a fault discards the whole file and the render prints LOAD CHECK SETTINGS UNUSABLE with the defaults; TestLimitsFromTheSettingsFile, TestMalformedLimitsFileFallsBackWhole and TestImplementLoadMalformedLimitsIsLoud cover it evidence: internal/core/implement/load.go:306 — "path := filepath.Join(home, ".abcd", machineload.LimitsFileName)" evidence: internal/core/machineload/limits.go:53 — "func DefaultLimits(cores int) Limits {" evidence: internal/surface/cli/implement_load.go:87 — "LOAD CHECK SETTINGS UNUSABLE: %s%s%s; using the defaults for both limits" evidence: internal/core/implement/load_test.go:277 — "func TestMalformedLimitsFileFallsBackWhole(t *testing.T) {"
- ac-7 — MET: load-check is the first prerequisite of make preflight and runs one
implement loadinvocation, the eval harness runs its own once from TestMain with ABCD_LOAD_CHECKED keeping one preflight to one terminal report, and a CI runner is skipped with a reason the render prints; TestCheckLoadSkipsOnCIWithReason and TestImplementLoadSkipsOnCI cover it evidence: Makefile:307 — "preflight: load-check lint-reviews lint-issues" evidence: evals/harness_test.go:85 — "if os.Getenv("ABCD_LOAD_CHECKED") != "preflight" {" evidence: internal/core/implement/load.go:196 — "skipped on a CI runner (" + reason + "): a fresh runner carries no programs left from earlier work" evidence: internal/surface/cli/implement_load.go:93 — "load check (%s): %s" evidence: internal/core/implement/load_test.go:77 — "func TestCheckLoadSkipsOnCIWithReason(t *testing.T) {" - ac-8 — MET: read_darwin.go shells /bin/ps and sysctl, read_linux.go reads /proc, read_other.go returns ErrUnsupported which CheckLoad turns into LOAD CHECK UNAVAILABLE naming the platform and carrying on; TestMachineLoadImportsOnlyTheStandardLibrary proves no dependency and TestImplementLoadCannotCheck covers the unavailable path evidence: internal/core/machineload/read_other.go:10 — "func Read() (Snapshot, error) { return Snapshot{}, ErrUnsupported }" evidence: internal/core/implement/load.go:211 — "abcd reads load and processes on macOS and Linux only, and this is" evidence: internal/surface/cli/implement_load.go:98 — "LOAD CHECK UNAVAILABLE (%s): %s; carrying on without checking the machine's load" evidence: internal/core/machineload/read_test.go:50 — "func TestMachineLoadImportsOnlyTheStandardLibrary(t *testing.T) {" evidence: internal/surface/cli/implement_load_test.go:250 — "func TestImplementLoadCannotCheck(t *testing.T) {"
Gap audit:
- honoured:
- warn, never refuse: the check exits 0 on every status and the Makefile ignores even a build failure evidence: Makefile:343 — "-go run ./cmd/abcd implement load --site preflight"
- own strays' names pass the private banned-names scrub evidence: internal/core/implement/load.go:340 — "func scrubOwnNames(repoRoot string, own []LoadOwnStray) bool {"
- the remedy never group-kills a mixed or the caller's own group and never names a pattern kill evidence: internal/surface/cli/implement_load.go:170 — "Never by pattern (pkill -f, killall)"
- the verb is reachable from the plugin surface evidence: commands/implement.md:147 — "implement load --site preflight|eval-harness [--json]"
- diverged: (none)
- missing: (none)
Scope-condition dispositions:
- cond-2609231542464428 — survived: the readers are darwin and linux build files and every other platform takes read_other.go's ErrUnsupported, reported as unavailable evidence: internal/core/machineload/read_other.go:10 — "return Snapshot{}, ErrUnsupported"
- cond-2609231542466193 — survived: a CI runner is detected from GITHUB_ACTIONS or CI and the check is skipped there with a reason, as the condition assumed evidence: internal/core/implement/load.go:273 — "if getenv("GITHUB_ACTIONS") == "true" {"
- cond-2609231542465241 — survived: the classifier keys a stray on age past the limit and near-full share alone, excluding only the invocation's ancestry, so a test running flat out past the limit would read as a stray exactly as assumed; the eight-preflight fixtures stay under the limit evidence: internal/core/machineload/classify.go:146 — "if ancestry[p.PID] || p.Age <= limit {"
- cond-2609231542469551 — survived: strays under another uid are counted and summed with no identity carried, as the condition's reason requires evidence: internal/core/machineload/classify_test.go:355 — "func TestOtherStraysTypeCarriesNoIdentity(t *testing.T) {"
Grounds
- pursued: we expect that no leftover program will again run for days unnoticed on a machine abcd tests on; shown wrong if a stray runs for a day or more while abcd's tests keep running without a warning.
Frontmatter
| id | itd-2609231434459890 |
|---|---|
| type | intent |
| lifecycle | shipped |
| kind | standalone |
| severity | minor |
.abcd/development/intents/shipped/itd-2609231434459890-abcd-s-own-test-lanes-check-the-machine.md
open on GitHub ↗ · commit history ↗
Referenced by10
- iss-2609210828122412abcd must never do this to a machine when running tests for a repo it manages. On 2026-09-21 at 08:16Z the development Mac kernel-panicked (userspace watchdog: no successful check-ins from WindowServer in 120 seconds, two induced crashes, then the panic), killing the pilot run's orchestrator session mid-gate and losing its scratchpad. The stackshot taken 25 seconds before the first WindowServer kill shows CPU starvation, not memory: eight orphaned /usr/bin/yes processes pegging eight cores for 2.3 days, two spinning zsh loops, and abcd's own reading.test and cli.test running under them from another session's go test; the OS's low-priority daemons (dasd at priority 4) got under a millisecond of CPU, 500-plus threads queued behind them through turnstiles, and WindowServer blocked in a synchronous XPC to cfprefsd that was itself blocked behind dasd. The burners came from a test-under-load experiment in a managed repository on 2026-09-19: an agent launched eight of them with nohup yes and appended each pid to a file whose directory did not exist yet, so the launches succeeded and the bookkeeping failed; the later kill loop read the pid file, pgrep -x yes still printed 8, a second kill pass over the same file followed, and the agent declared the machine clean. The pattern is one abcd can be asked to run and must refuse to run this way. Wanted, as the rule the record carries: (1) a test or experiment that spawns background load owns its children in a way that survives a failed bookkeeping step, a process group or setsid with the group killed, or a parent that dies with the session, never nohup with pids in a file as the only handle; (2) clean is proven by a process query, pgrep -x on the session's own burner name returning nothing, never by the pid file having been read; (3) a load experiment on a live development machine needs explicit consent and a hard ceiling below the core count, leaving cores for the OS's own daemons, and abcd's own test run is never started while such load is present, so the gate reads the load average before it begins and refuses above a declared ceiling, naming what is burning. Severity major: it took the product thinker's machine down and lost a session. Diagnostic report names (under the system's diagnostic-reports directory): panic-full-2026-09-21-091803.0002.panic, WindowServer-2026-09-21-091552.ips, WindowServer-2026-09-21-091632.ips, and two WindowServer userspace_watchdog_timeout spin stackshots.related
- iss-2610262032099691Invariant 21 names abcd's home `~/.abcd.noindex`; itd-2609231434459890 keeps the load-check limits in a settings file under `~/.abcd/`.related
- iss-2610262037542283The load-check intent defines a stray as a process outside abcd's lanes at near full CPU; the implement chapter defines it by a share of the process's fair share, a 0.4-core loop included, with nothing exempt by name.related
- iss-2610262037548530The load-check intent says the check never refuses and never waits; the implement chapter's load check, with its wait flag, holds make preflight's test stages until the load falls.related
- iss-2610262037558450The load-check intent keeps the per-machine limits under ~/.abcd/; the implement chapter keeps them at ~/.abcd.noindex/load-limits.related
- iss-2610262045302788itd-2609231434459890 keeps the load-check limits in a settings file under ~/.abcd/; itd-2610030720038073 renames that homerelated
- iss-2610262045435815itd-2609231434459890 says the pre-push hook runs make preflight; itd-2609091034175565 has the pre-push hook gate on a preflight receiptrelated
- itd-2610262127138979A preflight waits for its turn as one whole runbuilt on by
- spc-2609231542463113The load check: preflight and the eval harness warn about strays and extreme load, and never refuseimplemented by
- spc-2609232027132755stray-rule-silent-bandimplemented by
mentions7
- dcn-26092300000000212026-09-23 — The load check before abcd's own test lanes warns and never refuses (product thinker, planning interview for itd-2609231434459890; spc-2609231542463113, Decision 2). This changes the fourth condition of the run A interview ruling on iss-2609210828122412, which had the check refusing. The check names foreign sustained CPU (a near-full core for longer than 30 minutes) and an extreme load (four times the online cores), both limits overridable in the caller's `~/.abcd/load-limits`; it names the caller's own strays with a remedy and counts other accounts' processes without naming them; it writes a run-log event; it runs once at the start of `make preflight` and of the eval harness; CI skips it with a stated reason; it always exits 0, and its findings are minor.
- dcn-26092500000000122026-09-25 — The load check's stray rule is "busy for its share" (ruling H1, the product thinker via the interview session, 07:57Z, on iss-2609231947544298). A long-running process outside abcd's lanes is a stray when it uses nearly all the CPU it could get on the machine as loaded: its lifetime CPU share is measured against its fair share, the online cores divided by the runnable demand, not against a fixed 0.9 of one core, so forty busy loops each at a fortieth of the machine all count. The share test applies to the caller's own processes and to other accounts' alike, and other accounts' strays stay counted only. It is not a second sample and not a summed-cores trigger. The build reads the runnable demand as the snapshot's one-minute load average and caps the fair share at one core, so on a machine loaded no higher than its cores the rule is the near-full core it was (`machineload.FairShare`, spc-2609232027132755). This closes the band between 1.125 and 4 times the cores in which the check said nothing (pinned by `TestStrayRuleSilentBand`, succeeded by `TestStrayRuleCoversTheOversubscribedBand`), and lets the load check's remainder spec close and itd-2609231434459890 ship. The check still warns and never refuses (the 2026-09-23 entry above on that intent).
- iss-2609091256264547The decomposition discipline requires a cross-record link to be typed with one of four relations, supersedes or reverses or duplicates or refines, and never a vague related. Only the first of those four exists. supersedes is schema-known through recordHandleFields and is carried by fifty-eight decision records and three others, while reverses, duplicates and refines appear in no schema and in no committed record anywhere in the tree: the field list a record may carry is related_adrs, related_intents, builds_on and blocked_by, and a record carrying a key outside the known set is dropped by the reader rather than reported, so writing one of the three missing words would make the record invisible to every surface that reads it. The consequence is that an author following the rule literally either writes a link the tooling silently discards or writes the relation in prose and calls it typed, and the corpus shows the second: records assert a typed link in a heading and carry no frontmatter edge, which reads as done to a human and is invisible to every graph walker. That is the shape enforcement-claims-are-facts refuses, a convention naming a mechanism that does not exist, and it is load-bearing here because the decomposition protocol is the documented gate until its automated rung ships. Fix candidates, none chosen: implement the three missing relations as known fields so the rule can be followed; or narrow the rule to the vocabulary the schema implements and say what an author does with a relation the four words cannot express; or record that prose is the sanctioned form for the three and stop calling them typed. Detector: a record asserting a typed relation in its body carries a frontmatter edge naming the same target, and a relation the schema cannot express is refused at write time rather than dropped in silence.
- iss-2609231947544298The load check's stray rule is silent across a load band that itd-2609231434459890's Mechanism, Decision 1 and Grounds claim it covers. A process is a stray only when it is older than the stray limit and its lifetime share of a core is at least 0.9 (NearFullShare, internal/core/machineload/classify.go); the extreme trigger fires only when the one-minute load is strictly above four times the online cores. Busy loops that have run for days each hold their fair share, cores divided by their count, so on 16 cores at the default limits: 17 loops (0.94 of a core each) warn through the stray trigger; 18, 20, 40 or 64 loops, a load between 1.125 and 4 times the cores, each hold under 0.9 of a core and raise no trigger, so the check is silent (no warning, no run-log event); from 65 loops the warning is the extreme trigger's alone, as at the 2026-09-22/23 incident's load of about 440, where the stray count read 0. The share filter applies before the uid split, so the band silences the caller's own loops as well as another account's. The fixture that shows it is TestStrayRuleSilentBand in internal/core/machineload/classify_test.go (TestMechanismFlagsIncidentTwo pins the 440 case). Major: the check's main purpose, flagging a forgotten busy loop, fails silently in the band, and the intent's Grounds say it is shown wrong by exactly that. The remainder spec spc-2609232027132755 holds the intent planned on this band. Fixing it needs a ruling on the stray definition (a share relative to what the machine could give the process, or a second sample), which the lane cannot take.
- iss-2609240646533487RS005 judges every `Delivers: itd-N` trailer in the range, so once a commit carrying the trailer is on a branch, a later `git revert` of that commit cannot withdraw the declaration: the revert takes the intent back out of `shipped/`, the trailer stays in the range, and `lint-issues` refuses the branch. In autonomous run A the load-check lane (itd-2609231434459890) shipped its intent, review found that shipping it over-claimed, and the fix round reverted the ship commit and closed the spec with a remainder instead, which RS005 refused. The branch had not been pushed, so the orchestrator rebuilt it from the commits before the ship plus cherry-picks, with no ship-and-revert pair in the history; a pushed branch under an open pull request has no such exit short of a new branch and a new pull request. Wanted: RS005 treats a delivery whose commit is reverted within the same range as withdrawn (git names the reverted commit in the revert's message), or its refusal names the rebuild as the remedy.
- iss-2610262036569134The configuration chapter counts two limits in load-limits, while the implement chapter names three keys in that file
- itd-84An Intent Is Decomposed Before It Is Filed, And A Reversal Is Only Ever Flagged