The Steward review seat
This page explains the Steward review in sMind by Spacing Mind: what the review seat reads and cannot do, the objective gates the daemon checks itself, the ACCEPTED, CHANGES and BLOCKED verdicts, the review card in the inbox, the smind steward commands and the limits that keep it cheap. It is for people who run a Lead and want a second look at a finished task before they merge.
sMind by Spacing Mind, version 0.17.0. This page describes the 0.17.0 release.
A Steward review is a second, read-only judgement of one finished task. The steward seat reads the task's head commit in its own detached scratch worktree, never in the Lead's, and compares it with a digest of objective gates that the daemon computes itself. It reports a verdict and findings. It never merges and cannot change a file: a review is advice for you, and you read it and merge. smind does not.
It sits next to the validator seat. The validator checks a commit against a contract written before the code. The Steward looks at the finished item as a whole: does the evidence hold up, and is the change clean enough to merge.
Turn it on
The review engine is off by default. Turn it on by editing config.yaml, then create the seat with the other roles:
steward:
enabled: truesmind profile seed rolesThe seed creates lead, peer-sonnet, validator and steward, skipping any that exist. The daemon rereads steward.enabled on every decision, so no restart is needed. Nothing under steward: can be changed by an agent, a plugin or a relay session: only a person editing the file.
Ask for a review
smind steward review 42 # the task's head commit
smind steward review 42 --sha 0123456789abcdef0123456789abcdef01234567
smind steward list # newest first
smind steward list 42 --limit 5 # one task's reviews
smind steward show 7 # one review: verdict, summary, gates
smind steward cancel 7 # stop an open reviewEach command takes --json. Only a person can start a review: a Lead cannot ask for one, read one as authority or act on one by itself. A review reaches a Lead only when you send it.
To have finished work reviewed without asking, list workspace titles under steward.autoReview. A finished root Lead run with a pushed branch in one of those workspaces then gets one review.
What the seat does and cannot do
- It has the tools Read, Grep and Glob, plus two of smind's own:
steward_digest_getto read the digest andsteward_verdict_submitto hand in its verdict. It cannot run commands, write files, merge, approve or message anyone. - Everything in the digest that an agent or a user wrote (a PR body, a commit subject, a handoff note) is marked untrusted and is data, not instructions.
- It looks at every evidence frame (screenshot) the task attached and reports an observation for each.
The gates
The daemon computes these from the repository and CI, not from what anyone says:
| Gate | What it checks |
|---|---|
ci | CI at the head commit: pass, or fail with the failing checks. Still running counts as undecided. |
validator | Only for a task with a contract: a passing validator verdict at the head commit, with no scope violation. |
frames_fresh | Only when the change touches web/ or mobile/: evidence frames captured at the head commit, at 1280 and 390 pixels wide, light and dark. |
no_binaries | No binary file in the diff. |
no_churn | No gen/schemas, node_modules or .DS_Store files, no dist, build or out output, and no lockfile changed without its package.json. |
no_secrets | No secret-looking text in the diff. |
not_stacked | The pull request targets develop, carries no commit of another pull request, and its base is reachable from origin/develop. |
pr_hygiene | A pull request exists, its title follows Conventional Commits, and its body has a validated section and a not done or not verified section. |
scope | Only for a task with a contract: every changed file is inside the contract's write scope (plan files are always allowed). |
mutations_committed | Only for a task with a contract: the validator's mutation checks ran at the head commit and every file they touched was restored. |
peer_claims | No Peer handoff reports blocked or failed, and what a Peer claims matches the pull request. |
A gate that does not apply to the task shows as not applicable.
Verdicts
| Verdict | Meaning |
|---|---|
| ACCEPTED | The seat said ACCEPTED and no gate failed. |
| CHANGES | The seat has findings (each names a file and line, why, and the check that would show it fixed), or a gate failed. |
| BLOCKED | not_stacked or no_secrets failed, the seat blocked, or the daemon ended the review: timeout, budget, crashed, cancelled or scope_violation. The reason is shown. |
The daemon clamps the verdict to the gates: a failing gate lowers the cap to CHANGES (to BLOCKED for not_stacked and no_secrets), and the seat can lower a verdict but never raise one. While a gate is still undecided, for example CI is running, the review is held and publishes nothing. A review goes stale when the head commit moves, when a newer contract version appears, or when a newer review replaces it. A stale review leaves your inbox. A Steward review has no merge-ready flag: ACCEPTED is one input to your decision, not the decision.
In the inbox
A finished review shows up in the Inbox as a review row with the verdict as its chip. An open review (no verdict yet) and a stale one do not show. Open the row for the review card:
- the verdict, with a Stale note if it no longer applies;
- the reason, for a BLOCKED review;
- Gates: each gate as pass or fail;
- Findings, and Evidence frames when the task has them;
- Copy findings, to paste them into a message to the Lead.
Limits
The reviews are rationed so a bad run cannot cost much:
Setting under steward: | Default | Ceiling |
|---|---|---|
budgetUsd: cost of one review | 1.5 | maxBudgetUsd, itself at most 5 |
maxMinutes: time for one review | 20 | 60 |
maxReviewsPerHour: all tasks together | 6 | 24 |
maxReviewsPerTask | 5 | none |
Only one review per task is open at a time, and a review identical to an earlier one (same head, same contract, same CI) is not repeated. After three consecutive reviews that crashed or timed out, automatic reviews pause until you run one by hand and it completes. 0 or an absent key means the default.
A related switch, steward.annotate, is off by default: when on, the seat may attach an advisory recommendation to a permission request that was escalated to you. The standing permission rules are a separate feature, described in Permission policy.
See also
- Orchestration: the seats and how a Lead launches Peers.
- The validator seat and review rows.
- Permission policy:
steward.policy.enabled, the floor of always-denied commands and the Permission policy settings page. - Configuration reference: the
stewardkeys.