Where proposed actions wait for Ryan to review. Agents propose. The executor validates. Ryan approves.
The approval queue is the file where proposed agent actions wait for Ryan. It lives at working/approval_queue.md and is the single surface where every pending human-gated decision shows up.
The lifecycle of an action request is: an agent writes a markdown file into action_requests/YYYY-MM-DD/ with frontmatter describing the verb, arguments, scope, expected rollback, and idempotency key. The executor reads the request, evaluates it against the five approval rules, and either auto-executes (if no rule fires) or appends the request to the approval queue (if any rule fires).
The queue format is intentionally minimal. Ryan sees the agent that proposed the action, the verb it wants to run, the target, the reason, and the scope. He edits inline: approve, reject, or modify. The executor picks up the edit on its next cycle and acts on the verdict.
The queue is not a dashboard. There is no UI layer. It is a flat markdown file because markdown files compose with every other part of the system — version control, grep, memory loading, diffing — and a dashboard would add a second place to look, which is the failure mode of most approval systems.
The discipline the queue enforces: no action enters the world without showing up here first. This is how the system stays legible. When something surprising happens, the queue is the first place to look, and everything that crossed the gate is traceable to the moment the verdict landed.