Module bench 

The tool bench: which door one call goes through, in which order, and what comes back when a door says no.

Gate routing is turn-layer work (Handoff verdict 10), so the executor above stays thin: it hands the bench a call and receives an exhaustive BenchOutcome rather than deciding anything itself.

Three orderings are load-bearing.

• Dedup runs before any side effect, so a replayed call cannot bill or write twice.
• exec is forecast for discards before the Write door, because “this command deletes things” is a stronger claim than “this command writes somewhere” and deserves the stricter door.
• A Deny comes back as a tool_result carrying the refusal rather than ending the turn: the model that asked for something it may not have should learn that, and continue.

The tool itself arrives as a Box<dyn Tool> and the sandbox behind it is a port, so what this module owns is the ordering rather than the effect.

Structs

CheckpointNet

The checkpoint net a run works under: the repository, what a checkpoint covers, and who is signing it.

DeclaredWrites

Each registered tool’s answer to what it may write, by declared effect.

Ticket

A call clear let through: the tool tool_for names, and what account records the answer under.

ToolBench

The tool bench: the turn layer’s routing of a call through the gate its own declared Effect names, in the three orderings the module documentation states.

Enums

BenchOutcome

What the bench decided, alongside what the tool produced.

Clearance

What clear decided about one call.