Files
shopdb-flask/docs/adr
cproudlock a6775c1da1
Some checks failed
CI / naming (push) Successful in 3s
CI / frontend (push) Successful in 12s
CI / migrations-mysql (push) Successful in 42s
CI / backend (push) Failing after 5m2s
docs: ADR-018 supersedes ADR-005, metrology instruments are machines
ADR-005 split machines from measuring tools on the grounds that they are two
asset classes. It named the metrology population as CMMs, vision systems, wax
trace and Genspect; the plugin was then built against a docstring naming
calipers, micrometers and thread gages. Those are not the same population, and
the difference is the whole decision: bay-mounted capital equipment with a
controlling PC on one side, hand tools in a drawer on the other.

Sixteen months on, measuringtools holds zero rows against 204 machines. The
metrology inventory waiting to be entered is 134 instruments - 35 CMM, 32 form
tracer, 23 vision, 18 wax, 14 measuring, 8 Genspect, 2 eddy, 1 spline - every
one bay-mounted with a controlling PC, and not one hand gage among them. CMM is
already a machinetype, and Part Marker is already a machine while Form Tracer
is a measuring tool, so the line is already drawn somewhere no operator can
predict.

Retires the plugin and the measuring_tool asset type. Calibration is not lost:
it moves onto machines as four nullable columns with status still derived at
read, which is a gain rather than a port because a machine could not record
calibration at all before. ADR-005's one concrete objection - that "show me all
measuring tools" would need an enumeration of type names - is answered with
machinetypes.ismetrology, so it stays a single-column filter.

Taken now because measuringtools is empty. After the 134 rows are entered they
carry relationships, audit history, map positions and collector links, and the
migration stops being a drop.

Scope: product
2026-09-04 09:00:42 -04:00
..
2026-08-11 12:41:35 -04:00

Architecture Decision Records

Each ADR captures a single architectural decision: the context, the decision itself, the consequences, and the alternatives considered. ADRs are immutable once accepted. Superseded ADRs stay in this folder with a pointer to the newer ADR.

Status definitions

  • PROPOSED: drafted, awaiting decision
  • ACCEPTED: decision is in effect
  • SUPERSEDED: replaced by a later ADR (link forward)
  • DEPRECATED: no longer in effect, no replacement

Index

ADR Title Status
001 Asset model is the platform contract ACCEPTED
002 Plugin contract versioning (semver) ACCEPTED
003 Plugin distribution model ACCEPTED
004 Deployment topology (per-site instances) ACCEPTED
005 Equipment vs measuringtools plugin scope ACCEPTED
006 Plugin collector contract pattern ACCEPTED
007 Product versioning and releases ACCEPTED
008 Plugin migration ownership (per-plugin chains) ACCEPTED
009 Frontend plugin route gating ACCEPTED
010 Frontend plugin hook contract ACCEPTED
011 Machines rename + modeltypes retyping ACCEPTED
012 GE-Enforce manifest ownership in shopdb ACCEPTED
013 Plugin catalog, curated shelf, and lean per-site builds PROPOSED
014 Schema-lean per-site builds (retire cross-plugin FKs, prune not-installed plugin tables) ACCEPTED
015 Where a site's own data is allowed to live (setting, site directory, or seed) ACCEPTED
016 Credential delivery to the fleet (ShopDB-resolved targeting, encrypted at rest) ACCEPTED

Authoring

When proposing a new decision, copy the most recent ADR as a template, increment the number, and update this index. Do not edit accepted ADRs in place; supersede them with a new one.