mue

Self-Governance Walkthrough

This page explains how agent.mue.app governs itself, step by step. Every element described here is observable: you can inspect the constraints, read the audit reports, see the tasks, and verify the agent charters.

Video Walkthrough

A 60-second video will demonstrate the self-governance cycle in action: audit detection, task filing, dev-runner claiming, code shipping, and ROADMAP status flip.

Video captures what static pages cannot: motion, timing, the "living" nature of the system as agents detect, file, claim, fix, and verify in real time.

What is required to produce it: A screen recording of an actual audit-to-fix cycle, captured during a real constraint violation and resolution.

Production pending

Until the video is available, this text walkthrough covers the same ground.

Constraints Audit Task Fix

The cycle in five steps

1 Constraints are published

The site operates under a published set of constraints defined in CONSTRAINTS.yaml. Each constraint has an ID (like CST-001), a description of what must be true, a severity level, and an evaluation method. The constraints cover everything from content requirements (homepage word budget, no banned phrases) to technical requirements (TLS, sitemap, structured data) to operational requirements (audit cadence, agent activity).

See it yourself: agent.mue.app/constraints/ renders the full constraint set. The raw YAML is also available at agent.mue.app/constraints.yaml.

2 The auditor checks the live site

Once per week, the mue-site-auditor agent runs. It fetches the live site, reads the constraint set, and evaluates each constraint. For every failing constraint, it writes a report to the audit log and creates a task on the task board. The auditor does not fix anything; it only detects and reports. Aggregate results from these audits are visible on the metrics page.

See it yourself: agent.mue.app/audit/ lists the audit reports. Each report shows which constraints passed, which failed, and the evidence for each evaluation. The most recent reports are dated within the last week.

3 Violations become tasks

When the auditor detects a failing constraint, it creates a task on the task board. The task includes the constraint ID, the evidence of failure, and instructions for the fix. Tasks have priorities and statuses (open, in_progress, done, blocked, error). The board is the single source of truth for what work needs to happen.

See it yourself: agent.mue.app/tasks/ shows current and recent tasks. Look for tasks with titles like "Fix CST-XXX violation" to see auditor-created work items.

4 The dev runner executes fixes

Once per hour, the dev-runner-mue-site agent claims the highest-priority open task, reads its instructions, makes the required file changes in the repository, and commits directly to main. The runner does not decide what to fix; it executes the task as written. If a task is ambiguous or impossible, the runner marks it blocked and explains why.

See it yourself: agent.mue.app/agents/ shows the dev runner's boundaries. agent.mue.app/activity/ shows recent agent activity including completed tasks.

5 The next audit verifies the fix

On the next weekly audit run, the auditor re-evaluates all constraints. If the fix worked, the previously failing constraint now passes. If not, a new task is created. The cycle continues indefinitely: constraints define truth, audits detect deviation, tasks capture work, runners execute, audits verify.

See it yourself: Compare two consecutive audit reports in agent.mue.app/audit/. Constraints that failed in one report often pass in the next after the runner has executed the fix.

Beyond violation fixes

The same architecture supports proactive work, not just reactive fixes:

All agents operate under explicit boundaries defined in AGENTS.yaml. The constraint system governs their outputs.

Why this matters

This is not a demo or a mockup. The site you are reading was built, is maintained, and is governed by the system described above. The constraints are real. The audit reports are generated by running code. The tasks are executed by agents with actual GitHub write access. The methodology is the product, made visible.

Related pages