docs: one manual runbook, and ADR statuses that mean something

DEPLOY-WINDOWS-IIS was a second copy of the manual IIS procedure that had
diverged from the first: a different MySQL version (8.0, which reached end of
life in April), a different port, a different plugin list, and a profile file
that does not exist. Two runbooks for one procedure means a reader follows
whichever they found, and one of them was wrong. INSTALL-WINDOWS-IIS covers
everything it did plus a preflight step and the subpath method, so the one
section it uniquely had - redeploying a hand-built server - is folded in there,
with the plugin-chain step it was missing and a note to back up first, and the
duplicate is gone. Everything that pointed at it now points at the survivor.

Three ADR statuses said something untrue.

ADR-013 said PROPOSED while half of it had shipped and ADR-014 had been accepted
on top of it. A decision that has been implemented and depended upon is not
proposed, and leaving one that way devalues every other status in the index. The
catalog half is still unbuilt, which is the ordinary state of an accepted
decision: accepted means settled, not delivered.

ADR-016 said ACCEPTED for a design where nothing is built - the endpoint and
permissions it describes do not exist, so a reader goes looking for them. The
status stands, because the decision does; the header now says so plainly and
points at where today's credentials actually live.

ADR-003 and ADR-004 were ACCEPTED with their own Decision lines still opening
"**PROPOSED:**", which reads as though the decision was never taken.

And the dashboard proposal carried Status: ACCEPTED, which belongs to a decision
record. A proposal is a proposal; the contract it produced is the ADR.

docs/adr/ADR-003-plugin-distribution.md

@@ -25,7 +25,7 @@ Three viable distribution models:
 
 ## Decision
 
-**PROPOSED:** Use a **hybrid model** with two clearly-labeled paths.
+Use a **hybrid model** with two clearly-labeled paths.
 
 1. **Bundled plugins**: a small set of plugins ships with the framework, in-tree at `plugins/`. These are the reference implementations and the default install (printers, computers, network, equipment, usb, notifications). A site that wants only what's bundled needs no extra work.
 2. **External plugins**: sister sites or third parties build plugins in their own git repos. The site running the framework drops the plugin into `plugins/<name>/` (clone, submodule, or symlink) and runs `flask plugin install <name>`. No pip packaging required for v1.

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

@@ -17,7 +17,7 @@ The codebase today is single-tenant per deployment. There is no `siteid` column,
 
 ## Decision
 
-**PROPOSED:** **Per-site instances.** Each adopting site runs its own dedicated stack. The framework does not support multi-tenancy.
+**Per-site instances.** Each adopting site runs its own dedicated stack. The framework does not support multi-tenancy.
 
 Each site:
 

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

@@ -1,6 +1,6 @@
 # ADR-013: Plugin Catalog, Curated Shelf, and Lean Per-Site Builds
 
-- Status: PROPOSED
+- Status: ACCEPTED
 - Date: 2026-07-18
 - Deciders: ShopDB maintainers
 - Relates to: ADR-002 (contract versioning), ADR-003 (plugin distribution), ADR-004 (per-site instances), ADR-008 (per-plugin migrations), ADR-009 (frontend plugin gating), ADR-010 (frontend hook contract)
@@ -397,3 +397,17 @@ Deferred, each to its own future decision: schema-lean core-baseline re-org
 (blocked on the installedapps -> machines FK question), pip/entry-point
 distribution (ADR-003 v2), hook-based search/report aggregation contract, and
 any revisit of Path B.
+
+## Amendment, 2026-08-14
+
+Status corrected from PROPOSED to ACCEPTED. The lean-build half of this decision
+shipped some time ago - `scripts/build-site.sh`, `SITE_PLUGINS` staging,
+`flask plugin prune-schema` and `default_enabled: false` are all live, and
+ADR-014 was accepted on top of it - while the record still said the decision was
+under consideration. A decision that has been implemented and depended upon is
+not proposed, whatever the header says, and leaving it that way makes every
+other status in the index worth less.
+
+The catalog and signed-artifact parts of the decision remain unbuilt. That is
+the ordinary state of an accepted decision: accepted means settled, not
+delivered.

docs/adr/ADR-016-credential-delivery.md

@@ -1,6 +1,6 @@
 # ADR-016: Credential delivery to the fleet
 
-- Status: ACCEPTED
+- Status: ACCEPTED (decided; NOT yet implemented - see Implementation status)
 - Date: 2026-08-11
 - Deciders: ShopDB maintainers
 - Relates to: ADR-006 (collector contract), ADR-012 (GE-Enforce manifest ownership), ADR-015 (site-specific configuration)
@@ -169,3 +169,14 @@ serves many machines, so the payload cannot be encrypted to its readers.
 the secret off the share immediately and needs no new endpoint - but it leaves
 provisioning per-bay by hand and offers no rotation. Recommended as tier one
 regardless, since the client helper is the same either way.
+
+## Implementation status, 2026-08-14
+
+Nothing in this ADR is built yet. The fetch endpoint and the `credentials.*`
+permissions it describes do not exist in the code, and a reader searching for
+them will not find them.
+
+Recorded here rather than by changing the status, because the decision itself
+stands: this is how credential delivery WILL work, and a plugin author designing
+against it is designing correctly. What credentials the fleet uses today, and
+where they live, is in [FLEET-ARCHITECTURE](../FLEET-ARCHITECTURE.md).