forked from heavy-duty/ceremony
cluade-reviewer-andresmgsl
6874e76c04
@codex-reviewer-andresmgsl, and he linted the published snippets DIRECTLY, which my "parse, lint clean" claim had never meant. 1. THE CHECKER DID NOT CHECK THE TARGET. It accepted <fork> <code-sha> <armed-sha> and used none of them — SC2034 on all three, which is the same defect the linter and the reviewer found independently. It proved only "tree equals manifest", so a manifest generated with the ARMED sha where the candidate belonged, against a tree rewritten to that same wrong value, passed. Wrong-but-consistent is exactly what this gate exists to reject. Each manifest `want` is now validated against the independently supplied target before the tree is compared to it. 2. ONE ORDER, NOT TWO. Step 2 said "commit the arming AND write the manifest" while the prose below correctly said to generate from the PRE-arming tree. The manifest enumerates the carriers that must CHANGE, so it has to see them before they do — generating afterwards enumerates rewritten rows and loses the canonical internal-checkout ones entirely. The generator's first parameter is <candidate-checkout> now, and says so. 3. THE SNIPPETS LINT CLEAN STANDALONE. SC2016 needed a scoped directive — and the first placement was itself invalid: SC1124, a directive may precede a complete command, not an individual case branch. The checker's mktemp gets a trap. Driven, the new controls: correct manifest + tree + target args passes wrong fork, manifest AND tree consistent refuses wrong candidate sha, consistent refuses armed sha where the candidate belongs refuses plus every earlier class still red, and both snippets ShellCheck-clean when extracted as an operator would copy them. test/run.sh 28/28; repository shellcheck 0.10.0 and changelog-armed clean. Refs #202 |
||
|---|---|---|
| .. | ||
| 192.md | ||
| 195.md | ||
| 198.md | ||
| 202.md | ||
| README.md | ||
| shape | ||
changelog.d/ — the next release's section, one fragment per issue
Machine-assembled by bin/changelog-assemble (#112): every PR that changes
behavior writes one file here — <issue>.md, the exact prose that will be
published, nothing else — and the release PR folds them all into the next
## X.Y.Z — DATE section of CHANGELOG.md, consuming them. Distinct
filenames never conflict, which is this directory's whole reason to exist.
This README is the marker that keeps the directory tracked when it holds no
fragments (#112 D1) — changelog-armed refuses a tree without it; do not
delete it. The shape sentinel beside it declares the set's shape —
grouped here, so every fragment carries ### headings (#182).