Verify Index (generated — do not hand-edit)

Every standard's ## Verify table in one place, for a single-read full compliance audit. Generated by build-verify-index.mjs from the canonical standards — regenerate when a standard changes (node hub/standards/build-verify-index.mjs). The standards themselves remain the source of truth; this is a derived convenience.

Adopting Updates — bringing hub changes into a project

_{adopting-updates.md}

• git status is clean; assets/references/ stayed untracked/ignored. Any mirror refresh (fast-forward, or re-clone) targeted only the git-ignored hub mirror, never a tracked branch — and no reset --hard was used.
• The adopted change is present in the project's own tree (not just the reference clone).
• Each touched standard's ## Verify ran and its result is recorded in notes/reference/adoption-manifest.md; no row reads implemented without a recorded pass, and no Standards adopted ✅ summary lacks a backing row (checklists-are-contracts).
• "What changed" was scoped from the hub changelog across the version span (last adopted hub_version → current hub VERSION).
• Changelog + session log + (if bumped) VERSION ride in the same commit.
• A process report for this run is in notes/fairyfox-reports/ and committed — written even on a check-only run, except a check-only run on a node that hasn't adopted process-reports yet, which reports inline and writes no file (process-reports standard).
• If release.yml owns tagging, the release did not hand-push a tag; otherwise the hand tag matches VERSION.
• The run ended with a close-out stating dev/main status and that any hub-mirror refresh (fast-forward / re-clone) hit the git-ignored mirror only.
• On a check-only run, the node's own working tree was glanced at and anything alarming (mid-merge, conflicts, detached HEAD, large unpushed divergence) was surfaced in the report without being acted on.
• If a run skipped the pause, an active hub/authorizations.yml entry actually coversed the change (not assumed), and the other safety steps still ran — divergence re-prompt, process report, reviewable commit, and full verification (build/tests + standards ## Verify + project-constraint checks) before and after. If verification couldn't complete, the run fell back to check-report-wait rather than auto-applying.
• If the project builds/serves, it builds green.

Standard: Agent Tooling & Execution

_{agent-tooling.md}

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Standard: AI Context (CLAUDE.md)

_{ai-context.md}

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Standard: README Badges

_badges.md

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Standard: Checklists Are Contracts

_{checklists-are-contracts.md}

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Standard: CI Service Secrets

_{ci-secrets.md}

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Standard: Coins (reading-engagement points)

_coins.md

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Standard: Dependencies — upgrade aggressively

_{dependencies.md}

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Standard: Deployment

_{deployment.md}

• Each project's live URL matches its kind: static → fairyfox.io/<key>/ (Pages, shared domain); built app → Netlify host. No built app is parked on Pages, and no static site is on a needless separate host, unless a recorded exception says so.
• fairyfox-games resolves at fairyfox.io/games/ on Pages (no subdomain, no Netlify), and any other exception has a written reason in the project's notes.
• Pages projects carry no CNAME and inherit the domain (per docs-site/10); the base path equals the repo slug so chrome/links resolve.
• The registry URL (docs: / public URL) points at the real deploy location, and hub/registry.yml and _data/projects.yml agree.

Standard: Docker — local-first build, test, setup & install

_docker.md

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Standard: Docs Lifecycle — current-state vs. dated history

_{docs-lifecycle.md}

The per-standard slice the compliance audit aggregates — done/partial/missing:

Standard: Engineering Quality

_{engineering-quality.md}

The per-standard slice the compliance audit aggregates — done/partial/missing:

Standard: Farm Operating Model

_{farm-operating-model.md}

The per-standard slice the compliance audit aggregates — done/partial/missing:

Standard: Git Workflow

_{git-workflow.md}

The check that catches a violation — run on request, report done/partial/missing (the per-standard slice the compliance audit aggregates):

Standard: Legal Docs

_{legal-docs.md}

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Standard: Maintenance Sweep

_{maintenance-sweep.md}

The per-standard slice the compliance audit aggregates — done/partial/missing:

Standard: Owner Mandates Become Ledgers

_{mandate-ledger.md}

The per-standard slice the compliance audit aggregates — report done/partial/missing:

New Project Setup — bootstrapping a project into the mesh

_{new-project-setup.md}

• git status is clean; assets/references/ is untracked/ignored.
• CLAUDE.md opens to a real notes/status.md, and actually contains the "Cross-project standards & checking the fairyfox system for updates" standing instruction (confirm the text is present, not just that the file exists).
• VERSION reads a sane starting number.
• The project resolves in both registries (hub/registry.yml and _data/projects.yml) with matching key and branch, and the _data/projects.yml row has its project details filled by default (blurb/tags/lifecycle/version/activity/links/ accent/icon) — blanks only on a recorded user exception; social/preview image exempt.
• The README opens with the full 20-badge set in the canonical order (badges), each slot the right per-project source; omissions only on a recorded user exception.
• The docs site loads at fairyfox.io/<key>/, wears the shared fairyfox chrome (header, nav + submenu, footer) so it reads as a page of the site, with the brand/Home link as the way home and no separate back-button — look at the served page; default-theme JSDoc/Doxygen output, any stack's default theme with only cosmetic changes (a couple colours + a footer mention), or a merely-resolving docs: URL is a miss. The coin + reader buttons are present, the subnav is not bare, and the tool's own default chrome (footer/header/sidebar/CSS) is removed, not left alongside. If the docs are generator-produced, theme the generator itself (docs-site/06). Bar: docs-site/08-compliance-checklist.md.
• The deploy target matches the project's kind (static → Pages on the shared domain; built app → Netlify) per the deployment standard.
• If the project builds/serves, it builds green.
• notes/fairyfox-reports/ exists and holds this run's setup report, committed — process-reports standard.

Don't report the project as fully set up unless every item above actually holds — name any that don't rather than rounding up.

Standard: The Living-Notes System

_{notes-system.md}

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Onboarding an Existing Project — folding an established repo into the mesh

_{onboarding-existing-project.md}

Run every row and report each with its real status — done, partial, or missing. This same audit is what you run to check a project that's claimed to be onboarded; finding missing rows means it isn't. This is the join-time gate; the recurring whole-set check (every standard, re-runnable anytime) is the standards compliance audit.

If a setup/onboarding report from the same day already exists, read it first (notes/fairyfox-reports/YYYY-MM-DD-*.md). A verification run right after setup shouldn't re-litigate caveats the setup report already recorded (e.g. a collection/monorepo shape, or a static project whose site doubles as its docs) — confirm against it rather than re-deriving.

Reporting rule: only call a project "fully onboarded" when rows 1–9 are all done. If any row is partial or missing, say exactly which — e.g. "registered and noted, but the docs site is unthemed JSDoc and the CLAUDE.md mesh block is missing." A clean hub-side registration is not a green light.

Verifying under a held-release flow. If you're committing on dev and holding the release to main until an explicit go-ahead, the live fairyfox.io/<key>/ page can't change until that release. That's fine: verify the built output locally (open it in a browser) on each iteration, then do one live re-verification of the served page after the release merge + Pages deploy. Local-during, live-once-after — Row 6 still gets its real look at a rendered page.

Standard: Plan Before Execute

_planning.md

• Substantive work (a multi-file change, a release-worthy feature, a standards pass) has a written plan that predates the execution — typically a file in notes/plans/, or an in-thread plan agreed before edits began.
• The plan breaks the work into phases across research / planning / implementation, with as many as the work needs — not one undifferentiated push. Research phases went to the primary source (local + online) rather than being skipped or rushed.
• The Default Workflow in the project's CLAUDE.md states plan-before-execute and phase-by-default.
• Trivial one-step changes are not gratuitously bureaucratized — the rule is applied with judgment, not as paperwork for its own sake.

Standard: Process Reports — the system's feedback loop

_{process-reports.md}

• The node has a notes/fairyfox-reports/ folder and the run's report is in it, committed to the node's own tree (not left in assets/references/).
• The report names the procedure, the outcome, and the hub version/commit it ran against, and its friction/suggestions sections are real (not "all good").
• The front matter's hub_version is a real version number (usable as the next adoption's "last adopted" anchor), not a placeholder like "see VERSION at run time".
• A check that became an adopt in one session is a single combined report, not two.
• A node → hub proposal uses procedure: propose-standard with complete front matter (incl. hub_version/hub_commit) and restates the "a node never edits the hub" guardrail — no bare/frontmatter-less proposals.
• On the hub side, a review pass appended to reports_through (the digested-report filename list, not a date) only the reports it actually digested, and any standard changes it made are hub-side commits.
• The review pass spot-checked each report's adoption/completion claims against the node's manifest + tree (step 3a) and recorded any unbacked claim as a finding — a report is not digested by reading it alone.

Standard: Repo Hygiene

_{repo-hygiene.md}

The per-standard slice the compliance audit aggregates — done/partial/missing:

Standard: Research Capture — understanding lands in the notes

_{research-capture.md}

The per-standard slice the compliance audit aggregates — done/partial/missing:

Standard: Self-Hosted Assets

_{self-hosted-assets.md}

The per-standard slice the compliance audit aggregates — done/partial/missing:

Standard: Supply-Chain Hardening

_{supply-chain-hardening.md}

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Standard: Testing & Verification

_testing.md

The per-standard slice the compliance audit aggregates — done/partial/missing:

Standard: Versioning

_{versioning.md}

The per-standard slice the compliance audit aggregates — report done/partial/missing:

Standard: Working Rhythm — how an agent collaborates

_{working-rhythm.md}

The per-standard slice the compliance audit aggregates — done/partial/missing:

No ## Verify section (runbooks / meta — expected)

• cross-project-sync.md