Diagnostic: machine state and the ceiling

Two read-only tools that change nothing and open no session. They are not subject to the ceiling.

Tool	Role
daimon_doctor	Diagnosis of the whole machine, organ by organ
main_ceiling	Active authorization ceiling of Mains (Hands)
ping	Health check (appendix)

daimon_doctor

Returns the state of every organ in a single call. Call it first when something behaves strangely, and before concluding that a tool is broken.

Parameters: none. Level: read.

Example call: daimon_doctor with no arguments.

Returns: a structured object. The top-level keys:

Key	Content
ok	Overall verdict: reliable probes, Screen Recording and Accessibility granted, nothing broken
backend	Kind of the permissions probe (kind), its reliability (trustworthy) and a note
responsible_app	The responsible application, the one the system attaches the permissions to
permissions	Actual verdict for screen_recording and accessibility (granted, affected tools)
exclusions	State of the exclusions file
organs	State of each organ
overlay	State of the Overlay helper (see below)
consequences	What each missing permission concretely does to each tool
ceiling	Active ceiling, in the format of main_ceiling
cannot_detect	What the diagnosis cannot detect
next	Suggested next steps

The overlay key describes the process that draws the Overlay, without ever connecting to it:

Sub-key	Type	Meaning
enabled	boolean	The "Présence à l'écran" (Presence on screen) setting is enabled
socket_present	boolean	The helper's socket file exists (it may be stale)
lock_held	boolean	A helper holds the lock: it is alive
listening	boolean	socket_present and lock_held together: the helper is alive and listening
last_log_line	string or null	Last line of overlay.log, truncated to 200 characters; null if the log is absent or unreadable

Example of a helper that stopped cleanly:

{ "enabled": true, "socket_present": true, "listening": false, "lock_held": false,
  "last_log_line": "2026-10-16T07:50:27Z overlay: exit reason=idle" }

This key affects neither ok, nor next, nor consequences.

Pitfalls

• Verdicts are probed in the current process, through APIs that never ask for permission: running it cannot make a dialog appear.
• Read consequences: without Accessibility, main_type, main_key, main_hover and main_navigate return status: "done" as silent no-ops, and main_click, main_press, main_drag wait 30 seconds for a confirmation dialog.
• Also read cannot_detect: a reported absence of problems is not proof for what is listed there.

main_ceiling

A read-only snapshot of the active authorization ceiling of Mains: the current level, whether L4 is active, the nominal level of each action tool and those currently refused because they are above the ceiling. It is the tool to call before driving, to announce up front what you will not be able to do rather than being refused along the way.

Parameters: none. Level: read.

Example call: main_ceiling with no arguments.

Returns

Key	Type	Content
ceiling	string	Active ceiling: READ, NONDESTRUCTIVE, INPUT, VALIDATION or AUTONOMOUS
l4_active	boolean	True when the ceiling is AUTONOMOUS (L4)
levels	object	Name of each action tool mapped to its nominal level
gated_above	list of strings	Tools refused at the current ceiling, sorted alphabetically

Mapping to the L0 to L4 convention: READ = L0, NONDESTRUCTIVE = L1, INPUT = L2, VALIDATION = L3, AUTONOMOUS = L4. Tool levels are detailed on the Mains page.

Pitfalls

• A ceiling that exceeds a tool's level allows it, but the target can still raise the effective level: the tool's absence from gated_above does not guarantee that every call will go through.
• A malformed configuration or a missing log degrades to safe values, without error: the report is always returned.
• The ceiling is a human setting: no tool lets the AI raise it.

ping

Health check: always returns the literal string pong. No parameters.