docs: wiki staleness sweep (Fable-orchestrated Opus audit)

Audited all 40 docs/ against the live codebase; fixed factual staleness in 23,
14 were clean. Highlights (all verified against code):
- equipment -> machines (ADR-011 rename) in INSTALL/DEPLOY-WINDOWS-IIS,
  PLUGIN-GUIDE, GE-ENFORCE, ROADMAP.
- Versions refreshed: contract 0.10.0 -> 0.13.0, product 0.5.0 -> 0.7.0, plus
  plugin example core_version pins.
- Bundled set corrected to the current 13 (PLUGINS.md 7 -> 13 rows; DEPLOY
  eleven -> thirteen).
- Per-plugin Alembic chain workflow (ADR-008) replacing stale core-chain steps
  in PLUGIN-QUICKSTART / BACKUP-RESTORE; deploy adds plugin upgrade-all.
- Frontend plugin staging (ADR-010) replacing 'no frontend plugin system yet'
  in PLUGIN-GUIDE; view/route paths repointed to plugins/<name>/frontend/.
- Corrected file paths (MapView.vue, manifest_schema.json), CLI (shelf-list),
  API gating (GET /api/plugins is optional-jwt), WJF 15 -> 16 stages, and
  retired Collector/PC-Types settings pages (ADR-012).
- ge-enforce proposal marked ACCEPTED/built.

docs/adr/ADR-001-asset-as-platform-contract.md

@@ -183,7 +183,7 @@ Skipped from migration:
 ## References
 
 - `shopdb/core/models/asset.py`
-- `shopdb/core/models/machine.py` (legacy, deprecated)
+- (core `Machine` model retired per this decision; machine data now owned by the machines plugin at `plugins/machines/models/machine.py`)
 - `shopdb/plugins/base.py`
 - ADR-002 (versioning of the surface)
 - ADR-003 (plugin distribution)

docs/adr/ADR-004-deployment-topology.md

@@ -63,16 +63,21 @@ The framework provides:
 
 ## Migration strategy (resolved)
 
-Deploys run a single core Alembic chain: `flask db upgrade`. Bundled plugins do
-NOT carry their own migration chains - their tables are folded into the core
-chain (migration `7c04_fold_plugin_schema`). This was a deliberate resolution of
-the Phase 7B footgun where bundled-plugin baselines and the core baseline both
-created the same tables, so `flask plugin upgrade-all` would conflict. A fresh
-`flask db upgrade` reproduces the live schema exactly (verified on a scratch DB).
+Deploys run two commands: `flask db upgrade` then `flask plugin upgrade-all`
+(lean/ADR-014 sites add an optional `flask plugin prune-schema` at initial
+provisioning). The core Alembic chain applied by `flask db upgrade` creates the
+full core AND bundled-plugin schema through the chain head (this includes
+migration `7c04_fold_plugin_schema`). But every bundled plugin still carries its
+own Alembic chain per ADR-008: `flask plugin upgrade-all` stamps each plugin's
+own chain (the `alembic_version_<plugin>` tables) and applies any plugin-specific
+migrations added after the ownership cutover. The earlier Phase 7B state that
+folded everything into core with no per-plugin chains was superseded by ADR-008's
+per-plugin ownership. A fresh `flask db upgrade` reproduces the live core schema
+exactly (verified on a scratch DB).
 
-External (out-of-tree) plugins per ADR-003 may still ship their own migrations;
-the framework supports per-plugin chains for them. Only the in-tree bundled
-plugins are consolidated into core.
+External (out-of-tree) plugins per ADR-003 ship their own migrations too; the
+framework runs the same per-plugin chain mechanism (ADR-008) for both bundled and
+external plugins.
 
 ## Open questions
 

docs/adr/ADR-005-equipment-vs-measuringtools.md

@@ -145,5 +145,5 @@ Reclassification is one-shot, run once, archived. Like the original migration sc
 
 - ADR-001 (Asset is platform contract)
 - ADR-002 (versioning of the surface)
-- `plugins/equipment/` (current placeholder)
+- `plugins/machines/` (equipment plugin, renamed per ADR-011)
 - `plugins/computers/` (existing example of plugin pattern)

docs/adr/ADR-009-frontend-plugin-gating.md

@@ -41,7 +41,9 @@ list. This is the whole of what ships now.
    anonymous callers is safe because `GET /api/dashboard/navigation`
    already leaks the same enabled/disabled signal, and unauthenticated
    kiosk routes (`/tv`) need the answer too. It carries no metadata, so it
-   reveals strictly less than the admin-gated `GET /api/plugins`.
+   reveals strictly less than the equally-anonymous but metadata-carrying
+   `GET /api/plugins` (also `jwt_required(optional=True)`; only the
+   `PUT /api/plugins/<name>` toggle is admin-gated).
 
 2. **Route tagging.** Every plugin-owned route carries `meta.plugin =
    '<pluginname>'`. This covers the per-plugin route modules

docs/adr/ADR-010-frontend-plugin-hooks.md

@@ -43,7 +43,7 @@ one would mean forking a core view:
    printer detail page, a calibration-status card on a measuring tool. Today
    `WarrantyPanel.vue` is composed in by hand-editing each detail view.
 4. **Map marker / overlay contributions.** A calibration-due badge on the
-   shop-floor map (`frontend/src/views/map/MapView.vue`). The map draws type
+   shop-floor map (`frontend/src/views/MapView.vue`). The map draws type
    colors but has no plugin decoration path.
 5. **Search-result rendering / routing for plugin asset types.** Global search
    returns assets, but core hardcodes how each type renders and where its detail

docs/adr/ADR-013-plugin-catalog-and-lean-builds.md

@@ -134,7 +134,7 @@ before signing (section 4).
   increasing `serial` plus a `revoked` list of name-version pairs. Each site
   records the last-seen serial in instance state and refuses an index with a
   lower serial (anti-rollback of the catalog itself). The index also carries
-  per-entry version/tier/core_version so `flask plugin shelf list` can display
+  per-entry version/tier/core_version so `flask plugin shelf-list` can display
   compatibility without unpacking, but the index is a BROWSE layer only:
   adopt reads dependencies, tier, and core_version from the signed manifest
   inside the verified artifact, never from the index.
@@ -344,7 +344,7 @@ against the real code, not the idealized layout:
   window.
 - Version skew across ADR-004 sites: one shelf serves sites at different
   contract versions. Adopt checks core_version from the signed manifest against
-  the site's own __contract_version__ (authoritative); shelf list shows an
+  the site's own __contract_version__ (authoritative); shelf-list shows an
   advisory compatibility column from the index. Incompatible artifacts are
   listable but not adoptable.
 - Partial/placeholder sync files: fail closed on hash verification; the error
@@ -361,7 +361,7 @@ against the real code, not the idealized layout:
 
 - Phase 0, groundwork (small, days): upgrade_all_plugins uses
   registry.get_all(); reverse-dep checks read installed manifests from disk;
-  cycle detection in _sort_by_dependencies; docs/plugin-manifest.schema.json +
+  cycle detection in _sort_by_dependencies; shopdb/plugins/manifest_schema.json +
   `flask plugin validate` (directory mode); `flask plugin apply-profile` with
   install+enable closure ordering; fix Dockerfile stale comment. All additive,
   zero risk to running sites.
@@ -370,7 +370,7 @@ against the real code, not the idealized layout:
   ed25519 signing tooling and curator docs. No runtime behavior change yet.
 - Phase 2, shelf and enforcement (medium-large, one to two weeks):
   PLUGIN_SHELF_DIR, signed shelf-index with serial + revoked list,
-  `flask plugin shelf list` / `adopt` / `audit` with atomic verified unpack;
+  `flask plugin shelf-list` / `adopt` / `audit` with atomic verified unpack;
   verify-at-load in load_plugin and verify-at-migrate in
   run_plugin_migrations, fail-closed in prod; PLUGIN_DEV_TRUST_DIRS for
   dev/test and the external-repo harness; tier:core lifecycle guard;