0.1.12: retire a consumer the mesh stops asking for, after five stable passes, and wait for a person over the bound

The hourly release let a mistaken bulk unassignment drain one consumer an hour
with nobody deciding. Per novox/hq ADR 0230 a consumer is retired (disabled,
marked, data kept) only after the same unasked set in five consecutive passes;
more than 3, or more than half of those held, waits for approve or reject.
Deletion is a separate act of a person, of a retired consumer only.
This commit is contained in:
jochen
2026-10-06 13:47:51 +02:00
parent a6b7b566b0
commit e0453316b8
6 changed files with 675 additions and 135 deletions
+13
View File
@@ -28,6 +28,19 @@ a database", "create a umami site" — which is the volatile, per-service half a
module. This is the ADR 0039 line drawn through provisioning: stable loop here, per-service create
in the module.
**A consumer the mesh stops asking for is retired, not withdrawn whole** (novox/hq ADR 0230). ACTIVE
becomes RETIRED — access disabled through the adapter's `retire` (or `remove`, for an adapter that
has none), marked with when and why, nothing deleted — only once the same set of consumers has gone
unasked in five consecutive passes that read the file (20 s at the default 5 s interval; a pass that
cannot read the file resets the count). A stable set of more than 3, or more than half of those held
where more than one is held, is not retired without a person: the provider waits for
`provisioner_retire_approve` or `provisioner_retire_reject`, and says `provisioner.retirement`
(`waiting`) through the `announce` option. Asked for again, a retired consumer is created — re-enabled
— at once. DELETED only through `provisioner_delete`, of a retired consumer. Given `module`, the four
tools (`provisioner_retirement`, `provisioner_retire_approve`, `provisioner_retire_reject`,
`provisioner_delete`) are registered for it; `provisionerTools(handle)` builds them otherwise.
Additions and changes are never delayed.
### `tools` — the tool-serving harness
`registerModuleTools`, the `ToolDefinition` type, and the registry/worker that loads a module's
tools and exposes them through the mesh's command surface. *How* a tool is declared and served is