diff --git a/docs/PLUGIN-LAB-PRINTEDPARTS.md b/docs/PLUGIN-LAB-PRINTEDPARTS.md
index 537cdbeb..4e2542f9 100644
--- a/docs/PLUGIN-LAB-PRINTEDPARTS.md
+++ b/docs/PLUGIN-LAB-PRINTEDPARTS.md
@@ -2,11 +2,17 @@
 
 This is the literal, type-along guide to building a complete shopdb plugin,
 using the 3D-printed-parts storefront as the example. Every core stage shows
-the actual code; the finished implementation lives on branch
-`feat/printedparts-plugin` with one commit per stage, tagged `lab-stage-01`
-.. `lab-stage-17` - so `git show lab-stage-05` or
+the actual code; the finished implementation is merged into `main`, and each
+stage is tagged `lab-stage-01` .. `lab-stage-17` - so `git show lab-stage-05` or
 `git diff lab-stage-04 lab-stage-05` always has the complete answer,
-including the long Vue files this guide abridges.
+including the long Vue files this guide abridges. (The `feat/printedparts-plugin`
+branch these tags were cut from has since been deleted; the tags are what
+survive, and they are enough.)
+
+Read the stage tags as a historical record, not as today's conventions. They
+were cut against plugin contract 0.11-0.13 and the framework has moved on - the
+`core_version` floor below, and the frontend layout in the later stages, are
+both current-day values rather than what `git show` will hand you.
 
 What you are building: a catalog of 3D-printed parts (photo, description,
 quantity on hand), a stock LEDGER attributing every take/restock/adjust to a
@@ -93,7 +99,7 @@ the edit (imports/meta boilerplate unchanged from the scaffold):
     "description": "3D-printed parts inventory + kiosk checkout",
     "display_name": "3D Printed Parts",
     "dependencies": ["employees"],
-    "core_version": ">=0.12.0,<1.0.0",
+    "core_version": ">=0.16.0,<1.0.0",
     "api_prefix": "/api/printedparts",
     "default_enabled": false
 }
diff --git a/docs/PLUGINS.md b/docs/PLUGINS.md
index adf69703..8140fe07 100644
--- a/docs/PLUGINS.md
+++ b/docs/PLUGINS.md
@@ -22,6 +22,7 @@ These plugins are in `plugins/` in this repo. Enable per site with `flask plugin
 | `slides` | Slides for the lobby display and shop-floor screensaver | Upload / reorder / delete per surface. Management gated on the `slides.manage` permission, grantable to non-admin curators; display routes are public. |
 | `tools` | Technician utilities: barcode and QR label generation, unit conversions, Secure Send | Mostly browser-side by design, so an air-gapped bench gets them with no network. Secure Send is the exception and is why this plugin has a blueprint, a table and a migration chain: see [SECURE-SEND.md](SECURE-SEND.md). |
 | `warranty` | Asset warranty tracking | Manual entry now, Dell / Lenovo / HP provider lookups later. Derived coverage status with report buckets. |
+| `backups` | Per-asset configuration backups with revision history: NTLARS/DNC registry, part marker, UDC, CMM | Kind-pluggable per [BACKUP-KINDS.md](BACKUP-KINDS.md); a kind is one class in `services/registry.py`. Parseable kinds store a JSON projection and re-render to the native format on download; opaque vendor formats stay on the SFLD share with ShopDB holding metadata and the UNC pointer. Fed by the collector, so ingest authorizes on a `collector.ingest` service token, not a user JWT. `backups.view` and `backups.download` are separate permissions because a `.reg` is a restorable artifact. Not to be confused with [BACKUP-RESTORE.md](BACKUP-RESTORE.md), which is the ShopDB database itself. |
 
 ## Plugin permissions
 
diff --git a/docs/PROJECT-MAP.md b/docs/PROJECT-MAP.md
index 5e6852b9..3deadc2a 100644
--- a/docs/PROJECT-MAP.md
+++ b/docs/PROJECT-MAP.md
@@ -86,6 +86,6 @@ Manifest-less directories under `plugins/` are core frontend surface and always
 
 ## Size
 
-- test functions defined: **1233** (parametrised cases collect higher)
+- test functions defined: **1236** (parametrised cases collect higher)
 - documented API paths: **285** (`docs/openapi.json`, regenerate with `scripts/gen_openapi.py`)
 
diff --git a/docs/proposals/printer-assignment.md b/docs/proposals/printer-assignment.md
index 9295a025..fce747d8 100644
--- a/docs/proposals/printer-assignment.md
+++ b/docs/proposals/printer-assignment.md
@@ -1,10 +1,17 @@
 # Proposal: assign printers to a machine in ShopDB, let the PC install them
 
-Status: ACCEPTED. Server half being built 2026-08-18 (relationship types and
-rails, resolution helper, two endpoints, PC form section, `drivername`). The
-client script is not built.
+Status: SHIPPED AND RELEASED. Built out 2026-08-18/19; the client script is
+built too. The feature itself released in v0.11.3, the observation half and
+`seed-from-observed` adoption in v0.12.0.
 Author: planning session 2026-08-18.
 
+One thing this proposal did NOT anticipate, resolved 2026-08-24 in `adc7ef4`:
+the computers collector carried a `_sync_printer_links` that wrote
+`defaultprinter` / `connectedto` rows straight from a PC report, which is the
+ASSIGNED-vs-OBSERVED split this proposal rests on, broken from the other end.
+It is retired; `defaultprinter` and `printers` are now ignored (not rejected) on
+the collector payload. See [COLLECTOR-INTEGRATION.md](../COLLECTOR-INTEGRATION.md).
+
 ## 1. What this is
 
 Today a printer reaches a shop-floor PC because a person walks up to it, opens