quality

Assess the quality of the current working directory's repo against Rhiza standards. This is the global variant of the per-repo rhiza_quality command synced from jebel-quant/rhiza; it adapts to whichever repo it runs in by reading that repo's CLAUDE.md, .rhiza/template.lock, and git remote at runtime.

0. Establish the mode — how much of this repo is Rhiza's

These three checks come first — before any make, any tool, any analysis, because they decide which half of this command applies:

test -f .rhiza/template.yml            # rhiza-managed at all?
test -f .rhiza/template.lock           # ...and actually synced?
test -f .rhiza/template-bundles.yml    # ...or is this repo the template itself?

| template.yml + template.lock | Full mode — the template's gates plus the design assessment. | | template.yml only | Degraded mode — managed but never synced, the state /init deliberately leaves behind. Mention /rhiza:update performs the first sync, then continue. | | template-bundles.yml, no template.yml | Template mode — this repo is the template. See below; never suggest /rhiza:init or /rhiza:update here. | | None of them | Degraded mode — not rhiza-managed. Mention /rhiza:init once, as information, then continue. |

The pointer wins where both appear. template-bundles.yml is decisive only when there is no template.yml: a repo with a pointer is a consumer, whatever else its .rhiza/ holds.

The second probe is the lock, not a synced file. It used to be .rhiza/rhiza.mk, which was a proxy: the sync delivered it, so its presence stood in for "a sync has happened". Template v1.4 retired the make layer and stopped shipping it, and the proxy inverted — every correctly and fully synced v1.4 repo answered "never synced" and was quietly assessed in degraded mode, which is the narrower assessment and understates the repo. .rhiza/template.lock is not a proxy: every sync writes it, at every template version, and its files: block is the authoritative record of what was materialised. /rhiza:init deliberately leaves it absent, which is exactly the never-synced state the table's middle row describes. Probe for an artefact the sync itself writes, never for one a particular template version happened to ship.

Degraded mode is a narrower assessment, not a refusal. Skip the template-delivered gates, run whatever the repo's own makefile provides, and score the design work in full. Say which mode you're in before the first gate, so nothing that follows is read as a Rhiza verdict when it isn't.

What degrading must never become is running the template's gates anyway. Every numbered gate below is a gate the sync provides — a make target through v1.3, a rhiza-task task from v1.4 — and in an unsynced repo it exists in neither form, so running it fails with "No rule to make target" and reporting that as FAIL describes a broken repo when the truth is an unsynced one. That was the original reason this was a hard stop, and it still holds — the answer is to not run them and mark them unavailable, which is exactly what the existing out-of-scope rule already does for a reduced profile. An unavailable gate is never a FAIL, in any mode.

So in degraded mode:

• Skip the template-delivered gates, and every .rhiza/-dependent step: make rhiza-test (there is no .rhiza/tests/), template fidelity, and the known-issues.md lookup (it is keyed by the template ref in .rhiza/template.lock, which does not exist).
• Except fmt, typecheck, docs-coverage and deps, which resolve in any repo. Each falls back to the repo's own tool config — see step 1 for the ladder and its one hard limit: no config means out-of-scope, never the template's flags. These four are gated in most mature repos, so skipping them reported gaps that usually are not there.
• Run the bundled example checker, which needs no template at all — gate 8. It is stdlib-only Python this plugin ships, so it does not depend on a sync. Its README half is language-neutral and runs on a Rust or Go repo too; only its docstring half is Python's. It matters most here: the docstring and README checks a managed repo gets from make rhiza-test have no counterpart in an unmanaged one, so without it nothing at all asks whether this repo's documented examples still work.
• Run the targets check_make_targets.py reports as undeclared — the repo's own documented ones. An unmanaged repo with a working make test and make lint is the Go/Rust case generalised: the named list describes a template this repo isn't using, and the discovered targets are the real gates. Score those.
• Do steps 3 and 4 in full. The design analysis reads source, not .rhiza/, so it is unaffected — and in degraded mode it carries most of the assessment.
• Score nothing you did not measure. A skipped gate is out-of-scope, never a 0 and never an assumed pass.