Write down the plugin nobody documented, and stop pointing at a deleted branch

PLUGINS.md listed 14 of the 15 bundled plugins. `backups` had no row: the
per-asset configuration backups the collector takes off shopfloor machines,
kind-pluggable, with view and download as separate permissions because a .reg
is a restorable artifact. Added, with the pointer that separates it from
BACKUP-RESTORE.md, which is the database and a different subject.

PLUGIN-LAB-PRINTEDPARTS said the finished implementation lives on branch
feat/printedparts-plugin. That branch was deleted in the v0.8.0 cleanup; only
the 17 lab-stage tags survived, and they are enough. Says so now, and warns
that the tags are a record of contract 0.11-0.13 rather than today's
conventions. Its manifest example carried core_version >=0.12.0 against a
shipped >=0.16.0.

The printer-assignment proposal still said the client script is not built. It
shipped and released, across v0.11.3 and v0.12.0, and the collector half that
contradicted the assigned-vs-observed split was retired in adc7ef4.

PROJECT-MAP regenerated for the test count.
This commit is contained in:
cproudlock
2026-08-24 14:05:24 -04:00
parent 7b79a444b8
commit 90da0a1c09
4 changed files with 23 additions and 9 deletions

View File

@@ -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
}