Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.signalrooms.xyz/llms.txt

Use this file to discover all available pages before exploring further.

​
Approvals

Status: Current reference for the approval-gate model. App-level approval evidence is In progress. Approvals are the seat in the loop that distinguishes “an agent inspected something” from “an agent did something.” Read methods are always free; action methods sit behind two gates, an explicit operator-intent step and a global automation-enabled toggle.

​
The two-gate model

       Action attempted (thread start, evidence export, app lifecycle, ...)
                                  │
                ┌─────────────────┴─────────────────┐
                ▼                                   ▼
       Automation toggle?               Operator intent (caller-side)?
   Warmr's automation-enabled            Explicit human approval or
   switch is ON in the app                durable agent instruction
                │                                   │
                └─────────────────┬─────────────────┘
                                  ▼
                              Action runs
If either gate fails, the action does not run.

​
Gate 1: automation enabled

Warmr has a global Automation Enabled toggle in the app. When it’s off, the control plane refuses every action method and returns a domain error: 
automation disabled
This is enforced server-side. Agents cannot work around it; flipping the toggle is the operator’s job. Operator-side, automation is typically:
  • On during posting runs and active workflows.
  • Off during setup, debugging, configuration edits, or any time the operator wants the host to be observable but inert.
Read methods (status, devices.list, templates.list, thread.list, logs.subscribe) work in both states. You can fully inspect the host with automation off, you just can’t change anything.

​
What’s gated by this toggle

Currently gated:
  • thread.start, start a posting run / activity workflow / onboarding run.
  • thread.stop, gracefully stop a running thread.
  • evidence.export, write a evidence bundle to disk.
  • app.start / app.stop / app.restart. Warmr lifecycle.
  • warmrctl install / upgrade / uninstall, installer surfaces.
Read methods are not gated and can be issued any time the app is running.

​
Gate 2: operator intent

The second gate is caller-side: the agent or operator running the command needs explicit intent to issue an action. For human operators, intent is the click in Warmr.app or the typed command in a terminal. For AI agents, intent is more structured:
  1. The operator named the action: “start configuration X” or “stop the run on lane 2.” Generic instructions like “run my morning routine” need a durable record of what that routine is.
  2. The agent ran pre-flight inspection: status, devices list, thread list to confirm the action wouldn’t collide with existing work.
  3. The agent confirmed the configuration matches the operator’s description: same template, same accounts, same lanes.
  4. The agent captured pre-action state as pre-action evidence.
All four steps are detailed in Agent docs → Common workflows.

​
What “approval” means for each action

ActionWhat needs operator intentReversible?
thread.startOperator named the configuration IDYes (thread.stop)
thread.stopOperator approves stopping mid-runYes (restart) but in-flight publication state may not survive
evidence.exportOperator approves writing the evidence bundleEach export creates a separate bundle; you can re-export
app.restartOperator approves interrupting every lane on the hostHard to reverse, in-flight runs lose state
app.stopOperator approves shutting Warmr downHard to reverse if other agents/operators are mid-action
warmrctl install (install helpers)Operator approves modifying the hostSome helpers are install-only, no automated uninstall
app.restart and the install helpers are the most destructive of this set. Treat them as “operator must be present and aware,” not “operator nodded at it last Tuesday.”

​
Agents and action commands

The rule from Agent docs:
Read-only methods are always safe. Action methods require operator-approved intent and require automation to be enabled. If an action method returns automation disabled, don’t try to enable it, surface the error to the operator and stop.
Agents that try to work around an automation disabled error are violating the policy. The expected response is: 
Action <method> failed: automation disabled.
Automation toggle is off in Warmr.app. Please flip it on and re-run.
…and then wait for the operator. The agent does not call app.start to try a workaround. It doesn’t poll. It reports and stops.

​
Approval evidence (In progress)

Each action’s response frame is the immediate evidence of intent. Including:
  • The JSON-RPC request id the agent sent.
  • The action method.
  • Timestamp.
  • Schema version.
In progress: link these into the evidence bundle so a single export captures the full action history of a run, what was approved, by whom, when, with what parameters.

​
Operator-side approval checklist

Before issuing an action that touches a lane:
  • Automation enabled in Warmr.app.
  • Lane connected (isConnected: true), runner installed, profile trusted.
  • No conflicting thread already running on the lane.
  • Template and account list match expectation.
  • Cooldowns and pacing reviewed for this configuration.
  • Logs visible (either Warmr’s Logs view or warmrctl logs --follow in a terminal).
A no-surprises action looks like: pre-flight passes, action succeeds, post-action state matches expectation, logs and evidence captured. If any of those is missing, the action wasn’t really “approved”, it was guessed.