tip: click a tool card to expand and see its parameters. Use the toggles on the Tool State tab to enable/disable specific tools and actions.

two gates: approving installs a tool — registered, visible, and switched off. You enable it separately on the Tool State tab. Read the runs line, not the description: that's what actually executes. Rejecting requires a critique, and the proposer reads it and can revise. A project is a piece of work: approving one agrees to its plan, its one directory and its download sites, and to nothing else - each need it lists is its own proposal below it, with its own switches. A revision changes an agreed project; read the diff.

the cabinet of plans: every project agreed through the queue, with where it stands and what has been done inside it. The journal is written by the model as it works - what it did, which files, what it checked, what is next - and is the no-repo git. The model may mark a project in progress or paused and may ask for done; you confirm done here, because done means the plan's "what done looks like" was met. A revision agreed against a done project reopens it.

override layer: tools ship with Nano-floor defaults at the call site; this shows only the operator overrides on top. Secrets are masked.

enable/disable: toggle tools and their sub-actions on or off. A disabled tool is refused at call time — the LLM gets a clear "disabled by the operator" error immediately. (Toggles here are in-memory and reset on restart; to persist a disable, add the tool to dashboard.tools_disabled in seren-workbench.yaml.)

content-blind: entries capture metadata only — tool name, duration, success/failure. Argument values and result text are intentionally not stored.