Conversation
The hold goes at the top of "To release 0.3.1" because that is the section a releaser reads, and a hold recorded anywhere else does not stop a tag. Not a defect in 0.3.1. Measured: PR #15's pull_request run passed and its push run failed on the SAME commit, and that commit contains no code -- only a PLAN file and an archived specification page. run 34174978505 event=pull_request success run 34174975336 event=push failure test FAIL (exit 2), max_cases: 8 HTTPBanditTest "a refusal over the adapter's drain cap now announces the close it always did" While that is true, "gate green, every step line reading pass" is a sample rather than a measurement -- and that sentence is the entire evidence that 0.3.1 is fit to ship. Tagging now would publish on a green nobody can distinguish from a lucky one. SCR-289, slice 006. Lift the line when that is on main, then re-run the gate on the release commit and read the step lines. Gate OK. GATE_EXIT=0 Signed-off-by: Ayla Croft <aylacroft@proton.me>
HackTuah
added a commit
that referenced
this pull request
Sep 8, 2026
…ced on demand
SCR-289. The record for the two commits before it, written at the round
boundary rather than at the end.
Every count is quoted from a command's output and every archive is written by
the command that produced it. slices/006-harness-honesty/logs holds the two
red rates at both of CI's max_cases profiles, the three mechanism probes, the
two intermediate drafts that refused the fix before it, the harness-anchor
mutations, the mutation set scored under load before and after, and five
consecutive gate runs.
THE FINDING THAT MATTERS IS NOT THE FIX. Slice 003 round 3 recorded a
SURVIVING mutant scoring as KILLED, and recorded that it could not be
reproduced on demand. It can:
tools/mutate.sh score, 4 passes per mutant, 32 busy loops on 32 cores,
with the harness as it was --
M2never recorded 0 failures, a SURVIVOR read 1 | 1 | 1 | 0
Mc2 recorded 0 failures, a SURVIVOR read 0 | 0 | 0 | 0
Sixteen of forty scored suites read one failure more than the mutant deserves,
and the row corrupted is a recorded survivor. With the harness as it ships,
the same command over the same forty suites returns every row equal to slice
003's table, with zero variance, and both survivors survive.
Slice 003's table is NOT re-scored and its records are NOT rewritten. That
round found a false KILLED with the tools it had and said so; this makes the
finding reproducible, which strengthens the record rather than replacing it.
Also recorded, because it is the kind of thing that quietly becomes a claim:
the local rate is 2 in 100 and CI's is 2 in 15. The disagreement is reported
rather than smoothed. Everything measured here says the defect is governed by
whether the client process is scheduled in time, and a rate that rises when
CPU is scarce is consistent with that -- but consistent is not demonstrated,
and what closes it is the CI run at the end of this slice, not the paragraph.
PR #15's and PR #17's red push runs were not re-run. lib/ is untouched.
Signed-off-by: Ayla Croft <aylacroft@proton.me>
HackTuah
added a commit
that referenced
this pull request
Sep 8, 2026
…ced on demand
SCR-289. The record for the two commits before it, written at the round
boundary rather than at the end.
Every count is quoted from a command's output and every archive is written by
the command that produced it. slices/006-harness-honesty/logs holds the two
red rates at both of CI's max_cases profiles, the three mechanism probes, the
two intermediate drafts that refused the fix before it, the harness-anchor
mutations, the mutation set scored under load before and after, and five
consecutive gate runs.
THE FINDING THAT MATTERS IS NOT THE FIX. Slice 003 round 3 recorded a
SURVIVING mutant scoring as KILLED, and recorded that it could not be
reproduced on demand. It can:
tools/mutate.sh score, 4 passes per mutant, 32 busy loops on 32 cores,
with the harness as it was --
M2never recorded 0 failures, a SURVIVOR read 1 | 1 | 1 | 0
Mc2 recorded 0 failures, a SURVIVOR read 0 | 0 | 0 | 0
Sixteen of forty scored suites read one failure more than the mutant deserves,
and the row corrupted is a recorded survivor. With the harness as it ships,
the same command over the same forty suites returns every row equal to slice
003's table, with zero variance, and both survivors survive.
Slice 003's table is NOT re-scored and its records are NOT rewritten. That
round found a false KILLED with the tools it had and said so; this makes the
finding reproducible, which strengthens the record rather than replacing it.
Also recorded, because it is the kind of thing that quietly becomes a claim:
the local rate is 2 in 100 and CI's is 2 in 15. The disagreement is reported
rather than smoothed. Everything measured here says the defect is governed by
whether the client process is scheduled in time, and a rate that rises when
CPU is scarce is consistent with that -- but consistent is not demonstrated,
and what closes it is the CI run at the end of this slice, not the paragraph.
PR #15's and PR #17's red push runs were not re-run. lib/ is untouched.
Signed-off-by: Ayla Croft <aylacroft@proton.me>
HackTuah
added a commit
that referenced
this pull request
Sep 8, 2026
…ced on demand
SCR-289. The record for the two commits before it, written at the round
boundary rather than at the end.
Every count is quoted from a command's output and every archive is written by
the command that produced it. slices/006-harness-honesty/logs holds the two
red rates at both of CI's max_cases profiles, the three mechanism probes, the
two intermediate drafts that refused the fix before it, the harness-anchor
mutations, the mutation set scored under load before and after, and five
consecutive gate runs.
THE FINDING THAT MATTERS IS NOT THE FIX. Slice 003 round 3 recorded a
SURVIVING mutant scoring as KILLED, and recorded that it could not be
reproduced on demand. It can:
tools/mutate.sh score, 4 passes per mutant, 32 busy loops on 32 cores,
with the harness as it was --
M2never recorded 0 failures, a SURVIVOR read 1 | 1 | 1 | 0
Mc2 recorded 0 failures, a SURVIVOR read 0 | 0 | 0 | 0
Sixteen of forty scored suites read one failure more than the mutant deserves,
and the row corrupted is a recorded survivor. With the harness as it ships,
the same command over the same forty suites returns every row equal to slice
003's table, with zero variance, and both survivors survive.
Slice 003's table is NOT re-scored and its records are NOT rewritten. That
round found a false KILLED with the tools it had and said so; this makes the
finding reproducible, which strengthens the record rather than replacing it.
Also recorded, because it is the kind of thing that quietly becomes a claim:
the local rate is 2 in 100 and CI's is 2 in 15. The disagreement is reported
rather than smoothed. Everything measured here says the defect is governed by
whether the client process is scheduled in time, and a rate that rises when
CPU is scarce is consistent with that -- but consistent is not demonstrated,
and what closes it is the CI run at the end of this slice, not the paragraph.
PR #15's and PR #17's red push runs were not re-run. lib/ is untouched.
Signed-off-by: Ayla Croft <aylacroft@proton.me>
Member
Author
|
Hold lift-condition is met: slice 006 is on main, gate is a measurement again, lib/ and mix.exs shipping surface unchanged. Merging this PR would leave a hold on main whose wait has already ended. Close, do not merge. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One paragraph at the top of
HANDOFF.md's To release 0.3.1 section. That is where a releaser looks, and a hold recorded anywhere else does not stop a tag.Why
Not a defect in
0.3.1. Measured: PR #15'spull_requestrun passed and itspushrun failed on the same commit — a commit containing no code, only a PLAN file and an archived spec page.While that is true, "gate green, every step line reading pass" is a sample rather than a measurement — and that sentence is the entire evidence that
0.3.1is fit to ship. Tagging now would publish on a green nobody can currently distinguish from a lucky one.Lifting it
SCR-289, slice 006 (PR #16 plans it, fix in progress). When that is on
main: remove the line, re-run the gate on the release commit, read the step lines, then tag and publish.