Skip to content

ci(caps): re-derive the ubuntu anchor and size both caps to it (BACKLOG #1096) - #347

Merged
wshallwshall merged 1 commit into
mainfrom
claude/1096-ubuntu-cap-rederive
Aug 12, 2026
Merged

ci(caps): re-derive the ubuntu anchor and size both caps to it (BACKLOG #1096)#347
wshallwshall merged 1 commit into
mainfrom
claude/1096-ubuntu-cap-rederive

Conversation

@wshallwshall

Copy link
Copy Markdown
Collaborator

ubuntu step_timeout 25 -> 31, job_timeout 37 -> 43. One executable line changed; the rest of the diff is this file's own comment block, kept true to the values beside it.

Both caps move, or neither

Raising only the step cap gives 5:22 + 30:59 + 4:59 = 41:20 against a 37:00 job cap -- negative. The JOB would fire before the STEP, and a job-level kill reports no step conclusion at all, destroying the instrument this item was measured with. The nesting invariant is why the job term is here.

Applied the file's own rules, rather than picking numbers

step = ceil_minute(1.35 x post-#1027 anchor)      22:50 -> 31:00
job  = step + ceil_minute(1.5 x worst overhead)   overhead UNCHANGED at 7:44,
       so the 12:00 room is unchanged and only the step term moves: 31 + 12 = 43

Every published figure was recomputed from its inputs before committing -- including a rounding fix: 31:00 / 20:28 is 1.515x, and I had first written 1.514 by truncating.

check result
instrument preservation 5:22 + 30:59 + 2:22 = 38:43 vs 43:00 -> +4:17, identical to today's band
second gated step 5:22 + 30:59 + 4:59 = 41:20 vs 43:00 -> +1:40, identical to today's
spread rule headroom 10:32 vs spread 5:41 -> HOLDS
margin vs floor 1.515x against a 1.30x floor

What triggered this, because the ordering is the point

main already exceeded the old 16:08 anchor at 17:07 before PR #343 existed. The record rotted on its own. #343 (+274 tests, +3:12) only carried the margin across the 1.30x floor. The floor did exactly what its docstring says: "1.30 sits under every leg's sized margin ... so it fires when a run" approaches its cap. It is a re-derivation signal, and this is the re-derivation.

20:28 is #343's own run, deliberately. Its 274 tests land on main when it merges, so that is the next baseline rather than an outlier being smuggled in. Sizing on the pre-merge population would re-break the cap on contact -- the "three PRs each adding a minute" death this note already records.

#1096 stays OPEN

The caps are re-derived; the drift underneath them is not fixed, and raising a cap is not fixing it. That is the same distinction #1096's own banner draws, and this PR does not close it.

Pool stated with the number: 58 runs since 2026-08-10, 63 rows, 35 passing. Max passing 20:28, next highest 17:18, min 14:47, max non-success 17:01. Smaller than the 441-row original and labelled as such.

…OG #1096)

ubuntu step_timeout 25 -> 31, job_timeout 37 -> 43. One executable line; the rest
of the diff is this file's own comment block, kept true to the values beside it.

BOTH CAPS MOVE OR NEITHER. Raising only step_timeout gives 5:22 + 30:59 + 4:59 =
41:20 against a 37:00 job cap -- NEGATIVE, so the JOB fires before the STEP and a
job-level kill reports no step conclusion at all. That destroys the instrument this
very item was measured with. The nesting invariant is why the job term is here, not
tidiness.

Applied this file's own rules rather than picking numbers:
  step = ceil_minute(1.35 x post-#1027 anchor)   22:50 -> 31:00
  job  = step + ceil_minute(1.5 x worst overhead)  overhead UNCHANGED at 7:44,
         so the 12:00 room is unchanged and only the step term moves: 31+12 = 43

Every published figure recomputed from its inputs before committing, including a
rounding fix: 31:00/20:28 is 1.515x, and I had first written 1.514 by truncating.

WHAT TRIGGERED THE RE-DERIVATION, because the ordering is the point: main ALREADY
exceeded the old 16:08 anchor at 17:07 BEFORE PR #343 existed. The record rotted on
its own. #343 (+274 tests, +3:12) only carried the margin across the 1.30x floor.
The floor did exactly what its docstring says it does.

20:28 is #343's own run, deliberately. Its 274 tests land on main when it merges,
so that is the next baseline rather than an outlier -- sizing on the pre-merge
population would re-break the cap on contact.

#1096 STAYS OPEN. The caps are re-derived; the drift underneath them is not fixed,
and raising a cap is not fixing it. Pool stated with the number: 58 runs since
2026-08-10, 63 rows, 35 passing, max 20:28, next 17:18, min 14:47.
@wshallwshall
wshallwshall enabled auto-merge (squash) August 12, 2026 13:24
@wshallwshall
wshallwshall merged commit e5bd07d into main Aug 12, 2026
38 checks passed
@wshallwshall
wshallwshall deleted the claude/1096-ubuntu-cap-rederive branch August 12, 2026 14:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant