Phase 0: lock platform contract, naming convention, and style enforcement

Establishes the framework's foundation as a multi-site adoptable platform.

ADRs (migrations/adr/):
- ADR-001 (ACCEPTED): Asset is the platform contract; Machine retires.
  Three relationship types (partof, controls, connectedto) with free-text
  label, position-resolution chain (asset > related > location),
  hierarchical locations, sibling-bay propagation.
- ADR-002 (ACCEPTED): Plugin contract semver via __contract_version__.
- ADR-003 (ACCEPTED): Hybrid plugin distribution (in-tree bundled +
  filesystem-based external).
- ADR-004 (ACCEPTED): Per-site instances, not multi-tenant.
- ADR-005 (ACCEPTED): Equipment plugin (manufacturing) split from
  measuringtools plugin (metrology). Subtype-table pattern for protocol
  data (FOCAS, CLM, MTConnect).
- ADR-006 (ACCEPTED): Plugin collector contract via get_collector_schema
  hook with API-key auth and identity-based upsert.

Naming convention v1 (CONTRIBUTING.md):
- DB tables/columns: lowercase concatenated, no underscores or dashes
- DB-mirrored Python/JS variables match column names exactly; pure code
  follows host-language convention (PEP 8 / camelCase)
- Closed acronym allowlist (universal + shop-floor domain), banned
  shorthand list with suffix exception (printers_bp etc allowed)
- Plain ASCII everywhere: chat, docs, comments, string literals

Style enforcement (scripts/check-naming-and-style.sh):
- Pre-commit-runnable check script: non-ASCII, banned shorthand,
  snake_case DB names, snake_case API params in frontend
- Fixes 14 violations across 11 files (Unicode arrows, snake_case
  params, ctx -> canvasContext, res -> response, req -> request_obj)

Project state (CLAUDE.md, README.md, frontend/CLAUDE.md):
- De-staled CLAUDE.md to reflect actual current state
- README unifies DB story (MySQL canonical, SQLite test-only)
- frontend/CLAUDE.md points at root convention

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

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

@@ -0,0 +1,69 @@
+# ADR-004: Deployment topology (per-site instances)
+
+- **Status:** ACCEPTED
+- **Date:** 2026-05-08
+- **Deciders:** cproudlock
+
+## Context
+
+shopdb-flask manages shop-floor inventory. If multiple GE Aerospace sites adopt it, the deployment can take one of two shapes:
+
+| Model | How it works |
+|---|---|
+| **Per-site instances** | Each site runs its own Flask + MySQL + Vue stack. Each site has its own DB, its own users, its own enabled-plugin list, its own deploy. Sites are isolated. |
+| **Multi-tenant single instance** | One central Flask + MySQL + Vue stack serves all sites. A `siteid` foreign key on every asset partitions data. Auth distinguishes which site a user belongs to. |
+
+The codebase today is single-tenant per deployment. There is no `siteid` column, no tenant filter, no cross-site auth model. Plugins can be enabled / disabled but only globally for the running instance.
+
+## Decision
+
+**PROPOSED:** **Per-site instances.** Each adopting site runs its own dedicated stack. The framework does not support multi-tenancy.
+
+Each site:
+
+- Owns its database (own credentials, own backup policy, own retention)
+- Picks its own enabled plugins
+- Configures its own JWT secret, CORS allowlist, Zabbix integration, Active Directory binding
+- Deploys at its own cadence
+
+The framework provides:
+
+- A `Dockerfile` and `docker-compose.yml` template suitable for a single-site deploy
+- A `.env.example` listing all required environment variables
+- A `docs/DEPLOY.md` walking through a fresh-site install
+
+## Consequences
+
+### Positive
+
+- Simpler code: no tenant filter on every query, no cross-tenant auth, no shared-state partitioning bugs.
+- Sites are independent. A schema change at one site does not affect another. A plugin crash at one site does not blast radius to other sites.
+- Clear ownership: each site's IT team owns their own stack and data. Compliance and audit boundaries match operational boundaries.
+- Aligns with how GE Aerospace sites already operate (independent IT, independent shop floors).
+
+### Negative / cost
+
+- No cross-site reporting out of the box. If GE corporate ever wants a fleet-wide view, it has to be built on top (e.g., a roll-up dashboard that queries each site's API). That layer is out of scope for the framework.
+- Each site administers its own stack. Higher operational overhead than a single central instance, but each site already runs its own infrastructure.
+- Updates require visiting each site's deploy. Fine for the current adoption model; revisit if dozens of sites adopt.
+
+### Neutral
+
+- No `siteid` column needed. The existence of one DB per site is the partition.
+
+## Alternatives considered
+
+1. **Multi-tenant single instance.** Lower operational overhead at scale, easier cross-site reporting, but adds significant code complexity and risk: every query needs a tenant filter, auth gets complex, schema migrations affect every site at once, and a bug at one site can leak data across sites. Rejected for v1; revisit if and only if more than five sites adopt and operational overhead becomes painful.
+2. **Hybrid: per-site DB but central app server.** Adds the operational complexity of multi-tenancy without isolating the failure domain (one app crash = all sites down). Rejected.
+
+## Open questions
+
+- Should the framework provide an optional **read-only fleet roll-up** mode where a "central" instance can pull aggregate metrics from each site's API? Defer. Out of scope for v1.
+- Backup strategy per site: framework recommendation, or each site decides? Framework should publish a recommended backup runbook (mysqldump + offsite copy) but not enforce.
+- Auth federation: each site has its own user table, or sites can share an LDAP / SSO? Recommend documenting the LDAP config knob in `.env.example` so sites can plug in their own auth without code change.
+
+## References
+
+- `shopdb/config.py` (currently single-tenant, no `siteid`)
+- ADR-001 (asset model is per-site, not cross-site)
+- ADR-003 (plugin distribution per site)