A forge is stopped for CPU only far past its limit for minutes, never at its limit and never in its first ten minutes #11590

A cell is now stopped for CPU only when it held more than twice its cores for five minutes straight, and never while it is younger than ten minutes. I ran test/cpu-breach.test.ts and test/contain.test.ts: 26 pass, 30 skipped (the unix-socket and cell suites skip in this sandbox, and the forge's check runs them). bun scripts/gate.ts and tsc --noEmit are clean.

The two earlier tries had left a forge.json change that I think kept the check red: it set FORGE_CHECK_SHARDS=10 on the fast check. scripts/fast.ts exits 2 ("forge.json changed; the diff is not bounded") on that change, so the fast check ran the full tier. This push reverts forge.json to the base. I did not see the forge's log from those tries, so that is my reading rather than a confirmed cause.

I did not run the broader fast-tier list. contain.ts is imported widely, so scripts/fast.ts names 2,137 of 2,856 test files, with an estimated 180 minutes. I left that to the forge's check.

What changed

• Rule: the pure function cpuVerdict is in the new src/apps/cpu_breach.ts. It compares cores rounded to one decimal, so the line it prints never contradicts the decision: 1.04 of 1 is kept, and 2.04 of 1 prints as 2.0 and is kept.
• Watch: the watch in src/apps/contain.ts records each cell's birth time and when it went over, and asks cpuVerdict each tick. The stop message now reads "over twice its limit of N".
• Tests: test/cpu-breach.test.ts covers the five cases from the issue: at limit kept, 1.9× for 10 min kept, 2.1× for 4 min kept, 2.1× for 5 min stopped, 3× at minute 9 kept. It also covers a dip back under the line resetting the clock. test/contain.test.ts has a one-line update for the new message.

What I left alone: memory, disk and process limits, and the rest of the watch.

To try it: run bun test test/cpu-breach.test.ts test/contain.test.ts.

Closes #11558

A cell is now stopped for CPU only when it held more than twice its cores for five minutes straight, and never while it is younger than ten minutes. I ran test/cpu-breach.test.ts and test/contain.test.ts: 26 pass, 30 skipped (the unix-socket and cell suites skip in this sandbox, and the forge's check runs them). bun scripts/gate.ts and tsc --noEmit are clean.

The two earlier tries had left a forge.json change that I think kept the check red: it set FORGE_CHECK_SHARDS=10 on the fast check. scripts/fast.ts exits 2 ("forge.json changed; the diff is not bounded") on that change, so the fast check ran the full tier. This push reverts forge.json to the base. I did not see the forge's log from those tries, so that is my reading rather than a confirmed cause.

I did not run the broader fast-tier list. contain.ts is imported widely, so scripts/fast.ts names 2,137 of 2,856 test files, with an estimated 180 minutes. I left that to the forge's check.

What changed

• Rule: the pure function cpuVerdict is in the new src/apps/cpu_breach.ts. It compares cores rounded to one decimal, so the line it prints never contradicts the decision: 1.04 of 1 is kept, and 2.04 of 1 prints as 2.0 and is kept.
• Watch: the watch in src/apps/contain.ts records each cell's birth time and when it went over, and asks cpuVerdict each tick. The stop message now reads "over twice its limit of N".
• Tests: test/cpu-breach.test.ts covers the five cases from the issue: at limit kept, 1.9× for 10 min kept, 2.1× for 4 min kept, 2.1× for 5 min stopped, 3× at minute 9 kept. It also covers a dip back under the line resetting the clock. test/contain.test.ts has a one-line update for the new message.

What I left alone: memory, disk and process limits, and the rest of the watch.

To try it: run bun test test/cpu-breach.test.ts test/contain.test.ts.