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

claimed-declaration

A deny rule by default: it refuses a leased edit landing in a declaration another live job claims (run.go#executeStages), and names what to run instead.

What it catches

A leased edit landing in a declaration another live job claims (run.go#executeStages).

Why

A write path may claim one declaration of a file, so two jobs can start on one file and integrate in order. The claim holds only if an edit into the other job's declaration is caught before it lands, because afterwards both diffs touch it and neither applies over the other. The edit is applied to the file in memory, or a whole-file write's content is compared with the file it replaces, and the changed lines are placed by the same diff-driver matching the job footprint uses, so the declaration this names is the one magus job wait would report. It fires only for a job-bound writer whose own claims in the file do not name the declaration, and only when another live job claims a declaration of that file; a write that lands in the writer's claims, in no one's, or above the first declaration passes. An edit that does not apply to the file on disk, and a file whose lines cannot be placed, stay graded by path alone.

Default and override

By default this rule takes the decision deny. A workspace sets it by name, in its root magusfile, to deny, advise or off:

magus\guard.builtins({"claimed-declaration": "advise"})

A loosening takes effect once it is committed; a tightening applies at once.

Seeing it

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

deny [claimed-declaration]: ...

A workspace that sets this rule to advise sees advise [claimed-declaration]: ... instead.

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

See also

guardrulesclaimed-declarationdeny
Last updated (29d8b3de)
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.

Magusfile

The magusfile.buzz that declares a project's targets (as export funs) and binds its spells. Magusfile in full.

Ward

A coded diagnostic that inspects a resolved op and nudges or blocks an anti-pattern before it runs. Ward in full.

Buzz

The language magusfiles are written in (the .buzz engine). Buzz 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.

Job

The unit of delegated work, and one row of the job store: what an orchestrating agent handed out, with its goal, the checkpoint it was cut against, the paths it may write or must not touch, and the one check it runs. A job's holder is either a session, for work an orchestrator handed out, or the daemon, for its own maintenance. The store records; the agent guard is what reads those facts back when grading a write. Job 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.

Lease

The grant a holder takes on a job: the write and read paths that job declared, enforced in the checkout that took it with magus job exec. A job is the piece of work; a lease is permission over it. Lease in full.

Conventions

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