ci/woodpecker/pr/ci Pipeline was successful
Test-only. No change to the guard; every case below already behaves correctly at46f52eed. They are committed because reasoning that a shape was already covered is exactly what produced rounds four and five, and an unmeasured belief about a security control is worth nothing. Three fail atdf83a9eeand pass here, so they discriminate: \curl --config /tmp/w.cfg escaping the leading character cur"l" --config /tmp/w.cfg the quote at a different offset g"h" api -X POST "repos/a/b/$EP" … both halves dressed at once `\curl` is the ordinary way to bypass a shell alias. It is a thing people type, which makes it the least hypothetical entry in the file, and it was not covered by any of the eight fixtures added in the previous commit. The last one is the case I would have bet on breaking: the name gate reads the normalized copy while the unreadable-endpoint tail reads RAW text, so dressing BOTH halves at once is the input where those two readings are most likely to disagree. They do not — the tail matches through the quote — but the previous commit's message asserted that from reading the regex rather than running it, and one round earlier the same kind of assertion was wrong. Four negatives pass at BOTH heads and are here as regression guards: a quoted read, an ordinary download, `gh --version` with no api subcommand, and the word curl inside a string with no flag. Over-blocking is a real failure and not a safe direction — a guard that refuses legitimate work gets routed around instead of repaired, which costs more than the bypass it was protecting against. Suite 173/173.