You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Decision: Whether the #2112 Heredoc Fix Ships With Three Open Review Findings #2126
The fix for #2112 on branch feature/auto-2112 (handoff #2123) denies every shape #2112 names. After two rounds of edits, its third local strict review pass still raises three findings the change introduced. How should the lane proceed?
The open findings
Hook time on an adversarial shift line._heredoc_shift_ends does O(openers^2 x lines) work per line holding (( or $[, where develop did O(openers x lines). A constructed 55 KB command with 1000 << X on one (( line and 3000 filler lines takes about 78 s against about 3 s on develop. Past the hook's timeout a PreToolUse failure is non-blocking, so the command would run. No agent writes this shape by accident.
Readings double per two-heredoc line. A line opening two data heredocs is read as opening its first alone and as opening both in order, and the two readings never meet again, so n such lines build 2^n readings. Five such lines whose document text names both sleep and while pass the reading limit and are denied, where develop allows them. No loop runs in that shape.
Prose. The module docstring, the _heredoc_readings docstring, and host-setup/agent-safety/README.md say the in-order reading is built "where every body closes". The code requires closure only through the last data body, so it builds more readings than the text says, which is the safe direction.
Two older defects the review also found are filed separately as #2124 and #2125, and block nothing here.
Options
Recommended: open the pull request as the branch stands and file the three findings as follow-ups. The branch denies every A Line Opening Two Heredocs Strips Only the First Body #2112 shape and adds readings to what develop builds rather than replacing them, so apart from these three it allows nothing develop denies. Finding 1 needs a crafted command, finding 2 needs five two-heredoc lines naming both words, and finding 3 errs in the safe direction. The parked work then drives to develop unchanged, with the follow-ups filed first.
Authorize a third round of edits before the pull request. It would cap the openers a shift line reads before treating the command as past the limit (finding 1), build the first-alone and in-order readings once each across the whole command rather than per line, so only shift lines multiply readings (finding 2), and reword the closure claim (finding 3). This redesigns how readings combine, which is why it was not done inside the two-round budget, and it owes another review pass that can raise findings of its own.
Question
The fix for #2112 on branch
feature/auto-2112(handoff #2123) denies every shape #2112 names. After two rounds of edits, its third local strict review pass still raises three findings the change introduced. How should the lane proceed?The open findings
_heredoc_shift_endsdoes O(openers^2 x lines) work per line holding((or$[, where develop did O(openers x lines). A constructed 55 KB command with 1000<< Xon one((line and 3000 filler lines takes about 78 s against about 3 s on develop. Past the hook's timeout a PreToolUse failure is non-blocking, so the command would run. No agent writes this shape by accident.sleepandwhilepass the reading limit and are denied, where develop allows them. No loop runs in that shape._heredoc_readingsdocstring, andhost-setup/agent-safety/README.mdsay the in-order reading is built "where every body closes". The code requires closure only through the last data body, so it builds more readings than the text says, which is the safe direction.Two older defects the review also found are filed separately as #2124 and #2125, and block nothing here.
Options
Blocks
auto-2112), branchfeature/auto-2112at 3c5fc4c, no pull request open yet.