magus v0.4.3 is out. See what's new
¶ View markdown source · ✎ Suggest an edit
2 min read

guard-unfinished

An advisory by default: it explains, and blocks nothing, on guard checks that never finished, so no rule judged their calls.

What it catches

Guard checks that never finished, so no rule judged their calls.

Why

A host stops waiting on a hook that has not answered within its hook timeout, with no trail row and no word to the agent. So a check that has not answered within the guard's own budget, 7s against the host's 10s, stops waiting on its rules and answers unjudged: a call that changes state is denied, to be retried, and one that only reads runs with a note saying no rule judged it. The trail records the check as lapsed. Each check leaves a mark when it starts, before the workspace's rules load, and removes it when it answers while the host still waits. The host stopped waiting when the hook process it started is gone, or past the hook timeout the host's harness declares in mgs_getLimits; a host whose harness declares none is not taken to have given up on a slow check. The next check in the session reports and clears every mark whose process ended without removing it, and every one still running past the declared timeout. It stands alone only when the rules passed the call; on any other verdict the note is appended to that verdict. A workspace cannot set it: magus\guard.builtins refuses the name, since the notice is how the workspace learns a guard check of its own judged nothing.

Default and override

This rule always takes the decision advise. A workspace cannot set it: naming it in magus\guard.builtins fails to load, because the rule is how a workspace learns that a rule of its own judged nothing.

Seeing it

A verdict names its rule in brackets, which is how you got here:

advise [guard-unfinished]: ...

magus describe rule guard-unfinished prints the same entry at a terminal, and magus describe rules lists every rule this workspace enforces.

See also

guardrulesguard-unfinishedadvise
Last updated (73992e6a)
Earlier changes on this page (2)

Full history ↗ · Blame source ↗

Glossary

Workspace

The magus root directory that owns a set of projects and shared config; the unit magus operates over. Workspace in full.

Op

A single tool-native command a target composes (long form: operation); the middle of the work hierarchy (Spell to Op to Target). Op in full.

CI

An ordinary target you compose yourself with ctx.needs; magus does not hardcode its stages. It is the anchor magus affected ci keys off, and ci strips the rw charm. CI in full.

Agent

A model working through an agent host such as Claude Code, Codex, Cursor or OpenCode. magus treats an agent as one more caller of its CLI, MCP tools and console, held to the same checks as a person. Agent in full.

Harness

The deterministic scaffolding around the work on a change, for a person or an agent: compiler errors, formatters, linters, checks, gates, leases and hooks, placed at points a person chose. Around an agent's loop, magus supplies one and keeps it outside. Harness in full.

Session

An agent host's conversation, by the id the host delivers to its hooks. magus never mints one: a record with no session is unattributed, and the OS user it carries says whose account ran it. Session in full.

Run

One target executing under one magus invocation, such as magus run test web or magus affected ci. A run keeps its captured output behind an output reference. Every magus run is a run whether or not any job asked for it; see Job for how the two relate. Run in full.

Advisor

One read-only check from the advice suite: it reads the changeset through magus and writes one titled section of findings. The same advisors run as a pull request comment in CI and inside magus diff --impact locally. Advisor in full.

Conventions

This page uses none of the site's convention markers. The full set is on the conventions page.