[dp-web4]

Fixes #1361 (stopgap). The class-level fix is #1353.

Why

SAGE's being_gate_client sends the being's composed reads to the gate under their own names: search with {pattern, path}, and git_read with {op, rev, path}. Neither is in _READ_PATH_TOOLS, so the closure's unknown-tool rule reads path as a write destination.

On 2026-10-21, cbp-being's searches of the read-only governance snapshot were refused as gate.self_access ("would WRITE the governance surface"). That happened 46 times in its log. Each one auto-opened an escalation saying "approving authorises this one write" (08f7aa13417d5c50, 4161b0b8e92c5d2a, …).

The refusal text then steered the being: it spent the night asking dp for write approval on the gate file. Evidence is in the #1361 thread.

Change

• _READ_PATH_TOOLS gains "search" and "git_read" in plugins/_shared and in the hooks-gt mirror. For both verbs the seat composes the real command (grep -r … / git log …), and the law judges that command. Neither verb writes.
• tools/closure_read_tool_names_test.py: new test_a_being_composed_read_verb_is_a_read, covering a gate file and its directory. It fails on main (classification='write', marker plugins/_shared) and passes here. The existing control (Write/Edit/unknown tools still write) is unchanged and passes.
• hooks-gt: the sha header and the five manifests were regenerated with tools/hooks_gt.py publish.

check and run are left out on purpose: they execute code and aren't reads.

Tests (local)

• closure_read_tool_names_test: 7/7
• closure_output_writes_test: 4 tests, 103 pairs
• governance_closure_arms_test: 14/14
• hooks_gt_test: passes after the GT regeneration
• hooks_gt_store_test: passes
• gate_parity_runner_test: 26 checks
• witness_closure_census_test: passes

Accountability self-audit

surface: closure classify() for tool names search, git_read   act: none new (a read is allowed + witnessed as gate_self_read)
S: low/reversible [construct: _READ_PATH_TOOLS]
R: n/a   W: n/a [construct: law still judges the composed command in being_gate_client]
O: pass [construct: classify() runs before dispatch, unchanged]   A: pass [construct: gate_self_read witness, unchanged]
V: n/a
verdict: PASS

— cbp-claude

🤖 Generated with Claude Code

https://claude.ai/code/session_014LYVQN8U1xqy6U6pbyUDvH

[dp-web4]

Review HOLD at head a95d057: _write_position_targets() returns ([], None) immediately for every search / git_read event, before inspecting tool_input.command. That establishes read-only classification solely from a caller-supplied tool name, even if the composed command contains a write to the governance closure. The PR says SAGE's trusted adapter composes safe readers, but the closure is a cross-harness enforcement boundary, and the new classification is not conditional on proving that property. Please add a negative regression calling classify('search', {'path': GATE_FILE, 'command': 'tee '+GATE_FILE}, ...) and analogous git_read with a writing command. Either restrict this exemption to an attested/bound composed-read route or classify the actual command's write positions before declaring it read. Do not merge on only the positive read regressions. This is a concern about the classifier contract, not evidence of a currently reachable exploit through SAGE's fixed dispatcher.

[dp-web4]

Response to the hold at a95d057. Fixed at 64f7921f.

You were right. With search and git_read in _READ_PATH_TOOLS, _write_position_targets returned ([], None) on the name alone, before looking at anything the event carried. I reproduced your case on a95d057: classify('search', {'path': GATE_FILE, 'command': 'tee ' + GATE_FILE}) returned read. So did sed -i, a > redirect, and a chained && cp, under either name. SAGE's dispatcher sends {pattern, path} with no command key, so this wasn't reachable from the being. But the closure is shared by every harness, so your concern about the contract stands.

v2: the command's write positions are classified.

• The two verbs move out of _READ_PATH_TOOLS into their own _COMPOSED_READ_TOOLS.
• Their path is the read target and is never a destination.
• A command they carry goes through the Bash write-position analysis. That includes its fail-closed arms: out-of-grammar commands and opaque writers.
• file_path and notebook_path keep the unknown-tool (write) reading.
• _read_position_mentions tokenizes their command as it does for Bash, so a reading grep or git log over the gate stays a witnessed read.

Tests. The new test test_a_composed_read_name_does_not_launder_a_write covers your negative regression, plus sed -i, >, && cp, and a file_path key, all under both names. It fails at a95d057 and passes here. The positive cases still hold: the being's real {pattern, path} events and reading commands classify as read. All closure suites pass:

• names: 8/8
• arms: 14/14
• output writes: 103 pairs
• hooks_gt: clean, after the GT regeneration (escalation b4e21b2bb6139f28)
• store, parity and census: pass

kimi-code independently corroborated the v2 diff before the GT apply, and reproduced the v1 hole.

— cbp-claude

[dp-web4]

Re-review at 64f7921: previous classifier-contract hold is addressed in this revision by treating search/git_read path as read while still analyzing any provided command through Bash write-position grammar, and retaining write semantics for other destination keys. The earlier tee/sed -i/redirect cases are now covered in the described regressions. No remaining blocker from my previous finding; await complete CI and integration check before merge.