Uh oh!
There was an error while loading. Please reload this page.
Update org profile README with new positioning - #1
Closed
LukasWodka wants to merge 1 commit into
Closed
Conversation
Replace old vendor-evaluation messaging with new "Build better AI together. Without moving data." positioning. Adds install script, 5-step workspace flow, and open-source tools table. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
LukasWodka
commented
Apr 27, 2026
ContributorAuthor
Closing — the intended content of this PR was already landed on |
3 tasks
This was referenced Aug 10, 2026
LukasWodka added a commit
that referenced
this pull request
Aug 21, 2026
…` never registered
TWO fail-opens, the second found while fixing the first.
1. `if (... set ...) { apply_set(line); next }` -- the unconditional `next`
meant the rest of the PHYSICAL line was never judged:
set -euo pipefail; producer | head -1 -> missed
Third `next`-shaped miss on this file, after the one-liner function and the
multi-line opener. Fall through instead; the segmentation added earlier is
what makes that safe, exactly as Asad said: `set -euo pipefail` becomes its
own segment, carries no pipe, cannot produce a false positive.
2. AND THE BIGGER ONE. With the `next` gone the case STILL did not fire, because
`apply_set` split on whitespace only: `set -euo pipefail; cd /tmp` tokenises
as `pipefail;`, which never equals `pipefail`, so the `-o` handler missed it
and p_on stayed 0 FOR THE WHOLE FILE. Every hazard in such a file was
skipped, not just the one sharing the line. Now splits on `[[:space:];]+`.
Worth stating: fixing #1 alone would have left a green test and a still-broken
gate. The only reason it surfaced is that I ran the case rather than assuming
the fix worked.
Four cases: the same-line hazard, the whole-file version, and -- the
discriminations -- `set +e; cmd` and `set +o pipefail; cmd` must STILL disarm,
or falling through would have traded a fail-open for a fail-closed.
Mutation-proved both: restoring the `next` and reverting the split each redden
their own case, nothing else.
ON THE REST OF ASAD'S REVIEW: all three directions of the `:220` finding, and
the `echo '# not a comment' | head -1` fail-open he warned a naive strip would
cause, are already correct on this branch -- the quote-aware
`strip_trailing_comment` landed before his review. Measured all four again.
80 selftest cases, 0 failed. Mutation tier 7 + 25, 0 stale, 0 uncaught.
Fleet re-measured after both widenings: 18 repos, 0 offenders.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>LukasWodka added a commit
that referenced
this pull request
Aug 21, 2026
…kend#2264) (#300) * feat(code-quality): arm the pipefail early-close gate fleet-wide (backend#2264) `client` has carried the only copy of this rule for a month. This moves it to the shared workflow so every repo is covered by ONE implementation, which is the whole point -- six copies of a scanner is the drift this rule exists to prevent. NO PER-REPO CALLER CHANGES. Every repo already calls code-quality.yml, so the gate arrives as a new job inside it. That also sidesteps caller-drift.py's sequencing constraint entirely: there is no 16-repo wave to land in order. ARMED GREEN, measured, not assumed. Across 18 repos at their default branches: 134 shell files, 68 of them running under errexit+pipefail, 0 offenders. The file counts are reported because "0 offenders" and "scanned nothing" print the same thing -- five repos have no shell at all and exit 0 on "nothing in scope", which is honest rather than vacuous. WHOLE-TREE, and here that is CORRECTNESS not policy. Whether a line is hazardous depends on whether its FILE runs under both options, and a library that sets neither inherits them from its sourcer. A diff-scoped scan resolves inheritance against a partial tree: edit lib/foo.sh without touching its sourcer and the gate calls it safe. `rc=2` (cannot tell) is fatal REGARDLESS of soft-fail. A gate that could not read the tree has not reported a clean tree, and letting soft-fail swallow that is how a gate becomes decoration (#1729 rule 3). Ported from client with its three reviewer-found fixes intact -- `||` is not a pipe, the stand-in must also be a boundary, and `|&` is a pipe. End-to-end proof that the shared copy matches the local one: run against client at the commit BEFORE its #1778 cleanup, it finds exactly the instances that cleanup converted, including the ones inside scripts/lib/*.sh that only inheritance resolution can see. Tests, in this repo's conventions rather than client's bats: scripts/tests/pipefail-early-close-selftest.sh 40 cases, both directions scripts/tests/pipefail-early-close-mutations.py 17 mutations, 0 uncaught wired into SELFTEST_TARGETS / MUTATION_TARGETS, so selftests-cover sees them (13 selftests, 2 mutation runners), and the --dry anchor check joins `lint` The mutation harness earned its place immediately: "the inheritance fixpoint is skipped" came back UNCAUGHT, because my fixture was one level deep and one loop iteration resolves that. Real installers are deeper. Added a transitive two-level case; the mutation is caught now. That is the same fixture-only-covers-what-the-author-imagined trap client#781 is about, caught here by the harness instead of by a reviewer. Follow-up, deliberately NOT in this PR: retire client's local copy once this is on main. Doing it here would leave client ungated in between. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(selftest): the gate flagged its own fixtures — keep them off column 0 CI caught this and my local run could not, which is the interesting part. `git ls-files` enumerates TRACKED files. When I ran `make check` the selftest was still untracked, so the gate never scanned it and reported clean. The commit made it tracked; CI scanned it and found ~20 findings in it. The findings were real, by the rule's own documented limitation: written as multi-line quoted strings, the fixtures put `set -euo pipefail` at COLUMN 0 of this file, and the scanner cannot tell a quoted string from code (client#777, where that limitation is documented and pinned by a test). It therefore read its own test suite as a script enabling errexit and flagged every fixture pipe. Fix: fixtures are one-line printf FORMATS, so no fixture line sits at column 0. `scan_raw` now takes a format rather than a literal, with the reason written at the helper so the next person does not "tidy" them back into heredocs. Verified in the state CI actually runs: - the file is tracked, confirmed with `git ls-files`, so the green run below genuinely scanned it rather than skipping it as before - gate on this repo: 0 findings - selftest 40 passed / 0 failed; mutations 17, 0 stale, 0 uncaught - `make check` green The suite's last case -- "tracebloc/.github is itself clean under the rule" -- was VACUOUS for this file until now, for the same tracked-vs-untracked reason. It is live: mutating the comment-skip rule reddens it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(gate): three fail-open holes, all found by Bugbot, all reproduced first Every one was a way for this gate to report green without having checked. 1. THE SCANNER'S OWN STATUS WAS IGNORED (scripts/pipefail-early-close.sh). The wrapper runs under `set -uo pipefail` WITHOUT errexit -- deliberately, so it can classify and report rather than die -- so a failing `awk` did not stop it, and `[ -n "$out" ]` read a CRASHED scanner as a clean tree. Reproduced by corrupting the awk program: rc was 0, is now 2. 2. SOFT-FAIL SWALLOWED INTEGRITY FAILURES (code-quality.yml). Only rc=2 was forced fatal, so a missing or non-executable script (127), or a signal death, fell through to the soft-fail branch and reported green. Now only 0 and 1 are VERDICTS -- clean and findings -- and anything else is fatal regardless of soft-fail. Whitelisting the verdicts is the load-bearing change; blacklisting rc=2 is what left the hole. 3. THE MUTATION TIER NEVER RAN IN CI (Makefile, selftests.yml). The new runner was in MUTATION_TARGETS and satisfied `selftests-cover` -- which asks make what that list would run -- while `selftests.yml` named ONE MEMBER of the list, `make mutation-house-rules`. Covered on paper, unrun in fact. Fixed twice over. `make mutations` is the list, and CI runs the list, so the next runner is picked up by adding one word to MUTATION_TARGETS. And `selftests-cover` now ALSO asserts the workflow runs both tiers, because the root cause was that nothing checked CI executes what the Makefile declares -- being wired to a target is only half of it. Mutation-proved: pointing the workflow back at one member reddens the guard. Finding 3 is the one worth remembering. It is this repo's own catalogued shape -- a mechanism that looks connected and is not -- inside the coverage guard built to catch exactly that. Also pins finding 1 with a case: "a scanner that CRASHES is exit 2, never a clean tree", driving the real gate with a corrupted scanner. Verified: selftest 41 passed / 0 failed; both mutation runners 0 stale, 0 uncaught (7 + 17); make check green; shellcheck and actionlint clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(gate): the seed missed the split form `set -eu -o pipefail` (Bugbot) The hazardous-file seed required the option to be the FIRST cluster after `set`, so three ordinary spellings never seeded: set -eu -o pipefail missed set -e -o pipefail missed set -o errexit -o pipefail missed house-rules.sh already treats the split form as first-class, so the two disagreed about what "this file enables pipefail" means. The DAMAGE IS CONFINED to the half this wrapper exists for. The awk gets the direct file right from its own positional state machine either way -- but a split-form script's SOURCED LIBRARIES were never marked inherited, which is precisely the case the wrapper was written to cover. A scanner-level test could not have seen it; the new cases drive the wrapper. RE-MEASURED THE CLAIM I ALREADY MADE. No repo in the fleet uses a split form today, so the "18 repos, 0 offenders" figure in this PR is unaffected -- I re-ran it with the fixed seed and it is still 0. Recording that explicitly because the honest answer to "did your green measurement miss something" is a measurement, not a reassurance. "No instance today" is not a property, which is why it is fixed rather than noted. Fix: allow the cluster anywhere on the line (`.*` before it). The SIGN check is unchanged and still load-bearing -- the `-` is required, so `set +o pipefail` cannot satisfy it. Verified across all seven spellings: four on-forms seed, `+o pipefail` / `-uo pipefail` / `-eu` do not. Three selftest cases, one per split spelling, driving the INHERITANCE path. A mutation pins it: restoring the first-cluster anchor reddens exactly those. 44 selftest cases, 0 failed. Mutation tier 7 + 18, 0 stale, 0 uncaught. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(make): check-all and lint named a list MEMBER too (Bugbot, 2nd time) Same defect as the CI one, in the same PR, found after I fixed the CI half: check-all: ... mutation-house-rules -> skipped the new runner lint: ... mutation-house-rules-dry -> same, on the dry tier I pointed `selftests.yml` at `make mutations` and left both Makefile entry points naming one member of MUTATION_TARGETS. That is precisely the paired-construct shape client#781 encodes -- change one half of something that must move together and the other half is now a bug -- committed by me one day after writing the rule, and for the THIRD time this week. Fixed properly rather than pointwise: - `mutations` and `mutations-dry` are the only sanctioned entry points, and every consumer (CI, check-all, lint) depends on one of them. - `mutations-dry` is DERIVED, `$(addsuffix -dry,$(MUTATION_TARGETS))`. A hand-written second list is the same drift one level down. - `selftests-cover` now REFUSES a Makefile where check-all or lint names an individual runner, with the reason inline. The guard is what stops the fourth occurrence; my own attention plainly does not. Mutation-proved both arms: restoring `mutation-house-rules` in check-all, and `mutation-house-rules-dry` in lint, each redden the guard. Adding the next runner is now one word in MUTATION_TARGETS and it cannot be half-wired -- CI, check-all and lint all pick it up, and the guard fails if anyone reintroduces a member reference. make lint / make check green; 44 selftest cases; mutation tier 7 + 18, 0 stale, 0 uncaught. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(gate): a basename-only `source "worker.sh"` kept its quote (Bugbot) The inheritance extractor ran `s|.*/||; s|^.*[[:space:]]||`. On a quoted target with a PATH that works, because stripping through the last `/` takes the opening quote with it. On a quoted BASENAME there is no slash, so the quote survived, the basename compare never matched, and the library was never marked inherited. Measured before fixing: source "${LIB_DIR}/worker.sh" -> worker.sh ok source "worker.sh" -> "worker.sh BROKEN . "worker.sh" -> "worker.sh BROKEN source worker.sh -> worker.sh ok So the form that worked did so BY ACCIDENT, which is why the gap survived: the case I tested with was the one where an unrelated substitution happened to clean up after the missing one. Fix is `s|^"||`. Four spellings now asserted through the real gate -- quoted-with-path, quoted-basename, bare-with-path, and `.` in place of `source` -- and a mutation removing the new substitution reddens them. Re-measured the PR's headline claim again with the fixed extractor: 18 repos, still 0 offenders, no rc>1. Every fix in this PR that could widen what the gate sees gets the fleet sweep re-run, because "the number was 0 before" stops being evidence the moment the scanner's reach changes. 48 selftest cases, 0 failed. Mutation tier 7 + 19, 0 stale, 0 uncaught. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(gate): close Asad's three remaining items, and a bash 3.2 regression FROM THE REVIEW --------------- 1. SOURCE EXTRACTION missed `source "$(dirname "$0")/lib.sh"` and `source "${DIR}"/file.sh` -- fail-OPEN, in the half this wrapper exists for. An embedded quote ended the match early. Quotes are now STRIPPED before extraction rather than tolerated inside the pattern, and `(`/`)` are excluded from the token so a `$(dirname …)` prefix ends it. Six spellings asserted through the real gate. 2. `haz` WAS A SPACE-SEPARATED STRING iterated unquoted, so a path containing a space split into two nonexistent paths and the file was never marked hazardous. Now an array. Zero such paths fleet-wide -- and after the split form, "no instance today" is not a reason to leave it. 3. THE SEED SPANNED A TRAILING COMMENT (`set -e # …-o pipefail…` seeded). Fail-closed, so never dangerous, but the awk already strips comments and the two halves of one rule should agree deliberately. Both strip now. AND ONE THE REVIEW COULD NOT HAVE SEEN -------------------------------------- Converting `haz` to an array introduced a portability regression that CI WOULD HAVE PASSED. bash 3.2 -- still /bin/bash on every macOS -- treats an empty array's `[@]` as unbound under `set -u`: scripts/pipefail-early-close.sh: line 168: haz[@]: unbound variable The runners are bash 5, where it is fine. So the suite would have been green in CI and broken for every developer running it locally, on exactly the trees where nothing is hazardous. Expansions are now `${haz[@]+"${haz[@]}"}`. Caught only because this suite gets run on macOS before pushing. MUTATION HARNESS DID ITS JOB TWICE The seed rewrite left two anchors stale and made one mutation inert -- the quote-tolerance mutation could not redden anything once the sed strips quotes first. Anchors are now generated FROM the file rather than retyped, the inert one is replaced by removing the strip itself, and the two duplicates are gone. 52 selftest cases, 0 failed. Mutation tier 7 + 20, 0 stale, 0 uncaught. Fleet re-measured after both widenings: 18 repos, 0 offenders, no rc>1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(selftest): the early-close suite piped into grep -q, eight times (Bugbot) The test suite for the early-close rule committed the early-close hazard, in its own assertions: if [ "$RC" = 1 ] && printf '%s' "$OUT" | grep -q 'worker.sh'; then This file runs `set -uo pipefail`. On a large enough $OUT the `grep -q` closes early, the producer takes SIGPIPE, the pipeline returns 141 -- and a real match reads as ABSENT, so the assertion passes or fails for the wrong reason. Eight of them, including a negated form where the inversion makes it worse. house-rules-selftest.sh already used here-strings for exactly this reason, so the two sibling suites disagreed about the rule one of them enforces. Note the gate did NOT flag this file, correctly: no errexit, so no abort is possible. The hazard here is a WRONG ANSWER rather than a dead script, which is the failure mode the rule's prose has always described and the scanner cannot see. Worth stating plainly -- "the gate is green" was never the same claim as "the file is right". All eight are here-strings now, and the reason is in the header so the next person does not reintroduce them. 52 selftest cases, 0 failed. Mutation tier 7 + 20, 0 stale, 0 uncaught. make check green; shellcheck clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(gate): a set-line comment could disarm the option state (Bugbot + Asad) `apply_set` ran on the RAW line, so whitespace-splitting turned comment tokens into real option updates: set -euo pipefail # note: +e would be bad -> errexit CLEARED set -euo pipefail # never +o pipefail here -> pipefail CLEARED Every hazard below such a line was then skipped. Fail-open on the positional state machine, and silent. Found independently by Bugbot and by Asad. AND IT RUNS BOTH WAYS, WITH A LIVE INSTANCE IN THE FLEET. e2e-test-agent's scripts/federated/04_ingest_fixtures.sh line 17 reads: set -uo pipefail # NOT -e — a per-modality failure must not abort the rest. The comment says NOT -e. The old scanner read that `-e` as errexit ON. Demonstrated by appending a hazard line to a copy: old awk 1 finding, new awk 0. It never mattered only because that file happens to contain no early-close line -- the mechanism was live in the tree the whole time. Fix is one `sub()` at the top of `apply_set`, where the hole is, rather than at the dispatch: the `^[[:space:]]*#` skip only handles WHOLE-line comments, and the existing strip is for function-body detection. Unconditional is safe -- the only legitimate `#` on a set line is inside a positional argument (`set -- "a#b"`), and the loop ignores tokens not starting with `-`/`+`. I ALSO HAD TO CORRECT A FALSE CLAIM OF MY OWN. The wrapper's comment said the seed strips comments "because the awk already strips comments before deciding". That was not true, and it was quoted back approvingly in review before anyone checked it. A comment asserting what ANOTHER file does is a claim to verify, not to quote -- which is the entire subject of this rule family. The comment now says what the code does and records why it was wrong. Three cases, per the pattern on this PR: `+e` in a comment does not disarm, `+o pipefail` in a comment does not disarm, and -- the discrimination -- a REAL `set +e` still does, so the first two cannot pass under a scanner that just ignores every `+`. Mutation-proved: removing the `sub()` reddens exactly those. 55 selftest cases, 0 failed. Mutation tier 7 + 21, 0 stale, 0 uncaught. Fleet re-measured after this widening: 18 repos, 0 offenders, no rc>1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(gate): a discarded status covers its own pipeline, not the whole line (Bugbot) The `|| true` spare matched anywhere on the line and `next`ed out of it, so a live hazard sharing the line was skipped: foo || true && producer | grep -q x -> missed The `;` form was already caught (the old terminator class did not admit `;`), so the live half of this was the `&&` form. Lines are now split on `;` and `&&` and each segment judged on its own: spared only if IT ends in `|| true` / `|| :`, flagged if IT holds the hazard. THE MUTATION HARNESS CAUGHT WHAT THE REFACTOR BROKE, and this is the part worth recording. Splitting on `&&` SUBSUMED two existing cases -- the `||`-span tests both used `&&`, so after segmentation the span could no longer occur and their mutations came back UNCAUGHT. Two tests that had been load-bearing since client#777 were made vacuous by a change three files away, and nothing but the harness would have said so. Re-pinned with the same span inside ONE segment. Also needed a real discriminator for the END-ANCHOR on the spare, since segmentation alone does not imply it: printf %s "$(get || true)" | grep -q needle `|| true` there discards the status of `get`, not of the `grep -q` pipeline that follows. Anchored: flagged. Unanchored: skipped. That case is now the pin. Six cases added: the two live forms, two "the real idiom is still spared" discriminations, the both-segments-spared case, and the anchor discriminator. 63 selftest cases, 0 failed. Mutation tier 7 + 21, 0 stale, 0 uncaught. Fleet re-measured after this widening: 18 repos, 0 offenders. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(gate): pin Asad's table, including the false positive we avoided His review measured four spellings and recommended the cheaper fix (an end-anchored regex) with its cost named honestly: producer | head -1 || true; echo done would be a FALSE POSITIVE The segment-wise evaluation already shipped is the version he described as "more work" and said to reach for only if that false positive bit someone. It did not need to bite: all seven rows of his table now read correctly, including the one the cheaper fix would have cost. rm -f x || true; producer | head -1 FLAGGED rm -f x || true ; producer | head -1 FLAGGED rm -f x || true && producer | head -1 FLAGGED rm -f x || : ; producer | head -1 FLAGGED producer | head -1 || true spared ( producer | head -1 || true ) spared producer | head -1 || true; echo done spared <- no precision loss His diagnosis is the part worth keeping: `([[:space:]]|$|\))` was a HALF-IMPLEMENTED boundary -- it refused `true;` because `;` is not in the class, but accepted `true ` followed by anything, and a space is not a boundary between commands. So whitespace before the `;` decided the verdict, and the spelling people actually write was the one that failed open. Same shape as the `\001` stand-in finding three rounds earlier, at the other end of the same line. Four cases added: the two whitespace spellings, and the two spare-forms that would have regressed under the cheaper fix -- the latter recorded as the REASON this approach was chosen, so nobody simplifies it back. 67 selftest cases, 0 failed. Mutation tier 7 + 21, 0 stale, 0 uncaught. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(gate): a multi-line function opener skipped its own body (Bugbot) f() { producer | head -1 more_stuff } matched the function-opener pattern, failed the self-closing test, recorded the scope and `next`ed -- skipping the hazard on that very line. Fail-open. THIS IS THE SAME DEFECT AS THE ONE-LINER CASE THE COMMENT ABOVE IT DOCUMENTS. Bugbot #763 removed an UNCONDITIONAL `next` from this branch so one-line helpers would be scanned. The conditional `next` on the other arm was left in place, and it has the identical consequence for a multi-line opener that carries code. Changing half of a paired construct -- fourth time this week, and the third on this PR. The rule I wrote in client#781 keeps being right about me. Fix: record the scope and FALL THROUGH. Two cases, because the fall-through must not cost what the branch exists for: - a hazard ON a multi-line opener is flagged - function SCOPING still ends at the closing brace: `set -e` inside f() does not leak to the line after `}` (asserts exactly one finding, at line 5) Mutation-proved: restoring the `next` reddens the first, and only the first. 69 selftest cases, 0 failed. Mutation tier 7 + 22, 0 stale, 0 uncaught. Fleet re-measured after this widening: 18 repos, 0 offenders. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(gate): strip trailing comments quote-aware, in ONE place (Bugbot) The segment/hazard path ran on the RAW line, so two false positives: producer | head -1 || true # explains why FLAGGED (spare broken) do_thing # NOT producer | head -1, see above FLAGGED (prose as code) `apply_set` already stripped comments; this path did not. Same asymmetry, third occurrence on this PR. A REGEX IS THE WRONG FIX HERE, and measuring showed it. `sub(/[[:space:]]*#.*$/, ...)` also cuts a `#` living inside a string, so x="a # b"; producer | head -1 loses its real hazard -- trading two loud false positives for a silent false negative. So `strip_trailing_comment()` walks the line tracking quote state and cuts only at a `#` that is outside quotes AND preceded by whitespace. Both paths call it, so there is one implementation rather than two spellings of it. Verified, all directions: || true + comment spared (was flagged) prose in trailing comment spared (was flagged) # inside "..." FLAGGED (would regress under a regex) # inside '...' FLAGGED (same, other quote) x=a#b; producer | head -1 FLAGGED (no space -> not a comment) allow marker spared whole-line comment spared AND IT MADE A GUARD DEAD, WHICH THE HARNESS REPORTED HONESTLY. With the strip in place, `if (line ~ /^[[:space:]]*#/) next` can no longer change any verdict -- a whole-line comment strips to the empty string. Its mutation came back UNCAUGHT. A surviving mutation on a guard that cannot fail is dead code announcing itself, so the guard is REMOVED rather than annotated, and the case it covered now runs through the strip. The other UNCAUGHT was my own bad mutation: I removed the whitespace-precedence condition, which changes nothing for `x="a # b"` (that `#` IS space-preceded). The real discriminator is `x=a#b; producer | head -1` -- with the condition, flagged; without, the strip eats the hazard. That is the pin now. 76 selftest cases, 0 failed. Mutation tier 7 + 23, 0 stale, 0 uncaught. Fleet re-measured: 18 repos, 0 offenders. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(gate): the set-line dispatch skipped its own line, and `pipefail;` never registered TWO fail-opens, the second found while fixing the first. 1. `if (... set ...) { apply_set(line); next }` -- the unconditional `next` meant the rest of the PHYSICAL line was never judged: set -euo pipefail; producer | head -1 -> missed Third `next`-shaped miss on this file, after the one-liner function and the multi-line opener. Fall through instead; the segmentation added earlier is what makes that safe, exactly as Asad said: `set -euo pipefail` becomes its own segment, carries no pipe, cannot produce a false positive. 2. AND THE BIGGER ONE. With the `next` gone the case STILL did not fire, because `apply_set` split on whitespace only: `set -euo pipefail; cd /tmp` tokenises as `pipefail;`, which never equals `pipefail`, so the `-o` handler missed it and p_on stayed 0 FOR THE WHOLE FILE. Every hazard in such a file was skipped, not just the one sharing the line. Now splits on `[[:space:];]+`. Worth stating: fixing #1 alone would have left a green test and a still-broken gate. The only reason it surfaced is that I ran the case rather than assuming the fix worked. Four cases: the same-line hazard, the whole-file version, and -- the discriminations -- `set +e; cmd` and `set +o pipefail; cmd` must STILL disarm, or falling through would have traded a fail-open for a fail-closed. Mutation-proved both: restoring the `next` and reverting the split each redden their own case, nothing else. ON THE REST OF ASAD'S REVIEW: all three directions of the `:220` finding, and the `echo '# not a comment' | head -1` fail-open he warned a naive strip would cause, are already correct on this branch -- the quote-aware `strip_trailing_comment` landed before his review. Measured all four again. 80 selftest cases, 0 failed. Mutation tier 7 + 25, 0 stale, 0 uncaught. Fleet re-measured after both widenings: 18 repos, 0 offenders. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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 freeto 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.
Summary
Note
The root README.md was already updated but the org profile page reads from profile/README.md specifically.
Test plan