Standard: Standards Compliance Audit

How the mesh checks that its own standards are actually being followed — the enforcement layer. Each standard says (in its own ## Verify section) how to tell whether a repo follows it; this audit is the single on-request pass that runs every one of those checks at once and reports the result.

Canonical, project-agnostic standard (the version other repos copy). It does not introduce a new flow — it reuses the read-only, on-request reads defined in cross-project-sync.md, and a run can end in a process report like any other procedure.

Establishment vs. enforcement

Two different questions, both required for a standard to be real:

• Established — the rule is written once, canonically, in hub/standards/, and is reflected wherever it's used (the templates, the skeleton, the runbooks, the CLAUDE.mds). A standard that contradicts the artifacts that operationalize it isn't established — it's drift, and drift is exactly why a project "forgets" a rule (it follows the stale artifact, not the spec).
• Enforced — there's a concrete check that catches a violation, run deliberately, reported honestly. A rule with no check is a suggestion.

This audit is the enforcement instrument. Keeping the standards internally consistent (establishment) is a precondition for it — you can't check against a spec that disagrees with itself.

Relationship to the other audits

• Onboarding completeness audit (the 8-row table) is the join-time gate: is this repo in the mesh yet?
• docs-site compliance checklist is the deep check for the one docs-site standard.
• This audit is the recurring, whole-set check: re-runnable anytime against the hub or any node, covering every standard via its ## Verify section. Onboarding is "did it join"; this is "is it still following everything."

The audit matrix

Run every row; report each done / partial / missing with the specific gap named. The detailed pass/fail lives in each standard's ## Verify section — this table is the index that drives the pass.

How to run it (on request only)

Gated like every cross-repo read here: an explicit request paired with the intent — "audit the fairyfox standards", "are the standards being followed", "run a compliance pass". A bare "check things" doesn't qualify (see the gate in adopting-updates.md).

1. Pick the target. The hub itself, or a node read out of the read-only assets/references/<project>/ clone (an ordinary single-branch clone; if a refresh ever fails, just delete and re-clone the disposable mirror). No new sync — reuse the round-up clones.
2. Run each matrix row against the target, using that standard's ## Verify check.
3. Report done/partial/missing per row, naming the exact gap for anything not done. A clean-looking repo with one missing row is not compliant — say which.
4. Report findings, then stop. An audit changes nothing on disk.
5. Fix only on go-ahead, and only the right side. Hub drift → fix the hub standard (the normal git-flow way, changelog + VERSION in the commit). A node's gap is the node's to close through ordinary adoption — the hub never edits a node to "make it pass" (the anti-recursion rule in cross-project-sync.md). A compliance run can end in a process report.

Verify (is this audit itself sound?)

• Every standard in hub/standards/ appears as a matrix row (no standard is unchecked).
• Every atomic standard has a ## Verify section the matrix can point at.
• A run reported per-row status honestly, named gaps, and changed nothing without a go-ahead.