loop-system-architectlisted

# Loop System Architect Turn a repeated task into an observable control system that can execute, prove its result, recover after interruption, and improve without rewriting its own purpose. ## Choose the mode - **Audit**: inspect an existing workflow and report missing or open-loop parts. Do not edit unless asked. - **Design**: produce the contract, state schema, role graph, evals, and runtime design. - **Operationalize**: implement the controller, adapters, persistence, evidence, and one-command run path. - **Evolve**: analyze completed runs, validate a proposed loop/knowledge/skill improvement, and promote or reject it. When the user asks to “build” or “get it working,” include Operationalize. A Markdown plan alone is not an operational loop. ## Start from live reality 1. Read repository instructions and the artifacts the user placed in scope. 2. Inspect the actual tools, entry points, state files, tests, schedulers, agent CLIs, and dirty worktree. 3. Separate current authoritative input from reference material. Do not use model memory to fill gaps. 4. Classify the loop: - **Terminal**: one goal with a demonstrable finish line. - **Recurring**: every run terminates, while the monitor/service continues until retired. 5. State what exists, what is missing, and what is only claimed before changing anything. For a full audit, read [audit-rubric.md](references/audit-rubric.md). ## Require a closed control loop Identify and connect all of these: 1. objective and o