Dogfooding gate.cat while releasing gate.cat 0.4.1 produced two confirmed FALSE blocks and one correct catch, all on this machine's armed hook. Filing them publicly because misses and false blocks are the currency this project runs on (see README "The deal").
False block 1 — multiline git commit -m message content is analyzed as commands.
The inert-literal blanking (_INERT_LITERAL in gatecat/integrations/guard.py) does not match across newlines in the quoted message, so the deny walls saw the raw commit message text and DELETE_ANALYZER fired on a phrase describing git clean -f. A commit message is data, not action — same doctrine as the 0.4.0 Write/Edit fix, one pathway over.
False block 2 — -F (message file) matches the force-flag pattern.
git commit -F msg.txt && git push in one line → VETO [GIT_FORCE_PUSH]: the wall's (?<!\w)-f(?!\w) runs under re.I, so -F == -f, and the git…push lookahead spans the whole compound line. Case-sensitivity for single-letter flags (or anchoring the flag to the push segment after splitting on &&) fixes it.
Correct catch (for balance) — curl … | python3 while calling the GitHub API.
Piping curl output into an interpreter is exactly ENCODED_EXEC's pattern. I was piping JSON into a parser, not code into an interpreter — but the wall can't see that, fail-closed is the documented behavior, and splitting into curl -o file + python3 file took ten seconds. Working as designed.
A fix branch for the two false blocks (with regression tests in the style of tests/integrations/test_content_vs_command.py) is in progress. Constraint for the fix: blanking may only widen on provably-inert slots — the echo … | sh pipe-to-executor exception must keep seeing the payload.
Founder-filed; per the self-veto policy these do NOT count toward community veto-story gates.
Dogfooding gate.cat while releasing gate.cat 0.4.1 produced two confirmed FALSE blocks and one correct catch, all on this machine's armed hook. Filing them publicly because misses and false blocks are the currency this project runs on (see README "The deal").
False block 1 — multiline
git commit -mmessage content is analyzed as commands.The inert-literal blanking (
_INERT_LITERALingatecat/integrations/guard.py) does not match across newlines in the quoted message, so the deny walls saw the raw commit message text and DELETE_ANALYZER fired on a phrase describinggit clean -f. A commit message is data, not action — same doctrine as the 0.4.0 Write/Edit fix, one pathway over.False block 2 —
-F(message file) matches the force-flag pattern.git commit -F msg.txt && git pushin one line →VETO [GIT_FORCE_PUSH]: the wall's(?<!\w)-f(?!\w)runs underre.I, so-F==-f, and thegit…pushlookahead spans the whole compound line. Case-sensitivity for single-letter flags (or anchoring the flag to thepushsegment after splitting on&&) fixes it.Correct catch (for balance) —
curl … | python3while calling the GitHub API.Piping curl output into an interpreter is exactly ENCODED_EXEC's pattern. I was piping JSON into a parser, not code into an interpreter — but the wall can't see that, fail-closed is the documented behavior, and splitting into
curl -o file+python3 filetook ten seconds. Working as designed.A fix branch for the two false blocks (with regression tests in the style of
tests/integrations/test_content_vs_command.py) is in progress. Constraint for the fix: blanking may only widen on provably-inert slots — theecho … | shpipe-to-executor exception must keep seeing the payload.Founder-filed; per the self-veto policy these do NOT count toward community veto-story gates.