Standing orders

A standing order is a persistent instruction the agent must remember and follow. It turns operational rules that would otherwise live in chat into an auditable project artifact.

Example:

When every card on the roadmap is complete, bump the minor version and update VERSION.

That rule is too important to rely on conversation history.

The artifact

.mdboard/orders/
  SO-0001.md
  SO-0002.md

Each order has:

• a stable id (SO-0001);
• a title and instruction;
• rationale and consequences;
• a scope;
• a status: draft, active or retired;
• the guardian or co-guardian who authorised it;
• a history of amendments and retirement.

retire, remove and drop are one operation. An order is never hard-deleted in the normal lifecycle; retirement keeps it auditable.

Scopes

An order applies only where its scope matches:

A project order cannot be combined with other selectors. Without project, at least one selector is required.

Lifecycle

propose → draft → add → active
                        ├── amend
                        └── retire

Propose

The guardian states the intended rule. The agent restates the meaning, scope and consequences before recording it.

mdboard --actor agent order propose \
  --title "Minor version on roadmap completion" \
  --instruction "When all roadmap cards are complete, bump the minor version and update VERSION." \
  --rationale "Release hygiene." \
  --consequences "A version bump becomes part of completion." \
  --project \
  --authorised-by guardian \
  --authorization "Add this standing order."

The result is a draft.

Add

mdboard --actor agent order add SO-0001 \
  --authorised-by guardian \
  --authorization "Activate this standing order."

Only an active order applies to work.

Amend

mdboard --actor agent order amend SO-0001 \
  --instruction "When all roadmap cards are complete, bump the minor version and update VERSION and CHANGELOG." \
  --reason "Include the changelog." \
  --authorised-by guardian \
  --authorization "Amend this standing order."

The previous instruction, status and reason are kept in history.

Retire

mdboard --actor agent order retire SO-0001 \
  --reason "Superseded by SO-0002." \
  --authorised-by guardian \
  --authorization "Retire this standing order."

Retirement stops application but keeps the artifact.

Authority

Only the guardian or a co-guardian may authorise a change. The agent may propose wording, but cannot adopt, amend or retire an order alone.

Agent awareness

The order is not merely stored; it is injected into the agent’s working context:

• mdboard runbook includes the full text of every active order;
• mdboard context and brief show the active count and applicable orders;
• the HTML board shows active orders and the orders applicable to a card;
• mdboard order list shows all orders and statuses;
• mdboard order show SO-0001 prints the instruction, scope and history.

Conflict policy

Before adding or amending an order, the agent compares it with every active order whose scope overlaps.

• A conflicting order is rejected.
• The explanation must include a concrete scenario where both orders cannot be satisfied.
• The agent may propose a revision, an amendment or a retirement.
• It never silently chooses a winner.
• A standing order cannot weaken a human gate, the state machine or a review rule.

Semantic conflict detection is agent judgement, not a hard-coded rule engine. The recorded order and its history are the audit trail.

Commands

mdboard order list
mdboard order show SO-0001
mdboard order propose ...
mdboard order add SO-0001
mdboard order amend SO-0001 ...
mdboard order retire SO-0001 ...

The usual owner-authorisation rules apply when the agent executes a guardian-only change.

Limits

• A standing order is guidance and recorded intent; it is not a code-enforced policy engine.
• Date scopes are compared as YYYY-MM-DD dates.
• Conflicting active orders are detected by the agent and rejected by the CLI when known.
• The agent must not use an order to bypass a human gate, review independence, branch rules or the state machine.