Proposal:
Declaring work and then acting on it in the same assistant turn is refused, and the refusal is wrong -- the work WAS declared. Reproduced twice in a row: I wrote '[!start] slots carry NodeIds on the wire' in my message and called Edit in the same turn. The WriteGate refused it with 'You are about to change with no work declared'. I wrote the identical declaration again and called Edit again -- refused again, same message. I then ran 'commandments journal open' out of curiosity and it printed the declaration as registered, work left open (1), '[!start] slots carry NodeIds on the wire'. The very next Edit, with no new declaration, went through. SO THE DECLARATION IS RECORDED BUT THE HOOK CANNOT SEE IT YET -- it is presumably read from the transcript, and the assistant message carrying the tag is not committed until after the tool call in that same turn has been evaluated. THE COST: the first tool call after declaring any work is always refused, and the only way through is to burn a throwaway call (I used a journal read) to flush the message, then retry. That is a confusing failure for exactly the discipline the gate is teaching -- an agent that declares work correctly is told it did not, so the natural conclusion is that the tag does not work and the honest response is to stop using it. IT ALSO ONLY BITES A CERTAIN SHAPE OF AGENT: I had been working through Bash heredocs all session and never hit it, because a Bash call earlier in the turn had already flushed the message. It appeared the moment the user asked me to use Edit so they could see the changes, which put the declaration and the first write in one turn for the first time. SUGGESTED FIX: read the pending declaration from the in-flight message as well as the committed transcript, or let the gate accept a declaration made anywhere in the current turn.
Filed via commandments feature-request from a consumer project.
Proposal:
Declaring work and then acting on it in the same assistant turn is refused, and the refusal is wrong -- the work WAS declared. Reproduced twice in a row: I wrote '[!start] slots carry NodeIds on the wire' in my message and called Edit in the same turn. The WriteGate refused it with 'You are about to change with no work declared'. I wrote the identical declaration again and called Edit again -- refused again, same message. I then ran 'commandments journal open' out of curiosity and it printed the declaration as registered, work left open (1), '[!start] slots carry NodeIds on the wire'. The very next Edit, with no new declaration, went through. SO THE DECLARATION IS RECORDED BUT THE HOOK CANNOT SEE IT YET -- it is presumably read from the transcript, and the assistant message carrying the tag is not committed until after the tool call in that same turn has been evaluated. THE COST: the first tool call after declaring any work is always refused, and the only way through is to burn a throwaway call (I used a journal read) to flush the message, then retry. That is a confusing failure for exactly the discipline the gate is teaching -- an agent that declares work correctly is told it did not, so the natural conclusion is that the tag does not work and the honest response is to stop using it. IT ALSO ONLY BITES A CERTAIN SHAPE OF AGENT: I had been working through Bash heredocs all session and never hit it, because a Bash call earlier in the turn had already flushed the message. It appeared the moment the user asked me to use Edit so they could see the changes, which put the declaration and the first write in one turn for the first time. SUGGESTED FIX: read the pending declaration from the in-flight message as well as the committed transcript, or let the gate accept a declaration made anywhere in the current turn.
Filed via
commandments feature-requestfrom a consumer project.