ADR 0216: the agent's configuration is registered through its module, at three scopes, and served as one plugin

Graduates research 029 and amends design 36 (section 8): skills, subagents,
commands, hooks and output styles in one nox-mesh plugin; servers, settings
and instructions in the managed files; mesh, node and home scopes.

03-DESIGN/01-to-be/36-the-operators-agent-on-a-machine.md

@@ -2,8 +2,9 @@
 layer: to-be
 status: in-progress
 code: [mesh-catalog modules/claude-code]
-updated: 2026-10-04
+updated: 2026-10-05
 decisions:
+  - 02-DECISIONS/0216-the-agents-configuration-is-registered-through-its-module-at-three-scopes-and-served-as-one-plugin.md
   - 02-DECISIONS/0213-the-operator-sets-the-agents-managed-settings-through-the-agent-module.md
   - 02-DECISIONS/0209-a-login-on-a-node-moves-that-node-to-its-account-and-an-api-key-is-added-from-any-node-sealed.md
   - 02-DECISIONS/0206-a-node-reports-the-anthropic-grant-it-holds-and-the-licence-manager-adopts-a-licence-by-refreshing-it.md
@@ -41,7 +42,8 @@ The agent reads a machine-wide, administrator-owned configuration directory unde
 by the vendor: a managed settings file that outranks every user and project setting; a key in it that
 adds HTTP tool servers *beside* a person's own without blocking them; and a managed instruction file every
 session reads before the user's and the project's. The agent has **no** machine-wide directory for
-rules, skills, slash commands or hooks; those exist only under a home or a project.
+rules, skills, slash commands or hooks; those exist only under a home or a project — or in a **plugin**
+the managed settings enable, which is how the mesh puts them on every machine (§8).
 
 So the mesh's part of the agent's configuration lives there, **owned whole by the module**, and the home
 is left alone. What the predecessor shipped as two rule files and two skills folds into the managed
@@ -205,6 +207,60 @@ answer is a package repository for this ecosystem as a seat
 and trusted by every node's package manager; not built, and not this module's to build. The vendor's own
 installer is rejected: it puts a self-updating binary under the person's home, invisible to the mesh.
 
+## 8. The agent's configuration, registered at three scopes
+
+Everything about the agent that can be configured is registered through this module's tools, once, from
+any machine, and kept in the module's state on the bus
+([ADR 0216](../../02-DECISIONS/0216-the-agents-configuration-is-registered-through-its-module-at-three-scopes-and-served-as-one-plugin.md)). Every instance watches that state and writes what applies to its
+machine. A machine that joins later takes it at its first start.
+
+**What goes where.** The vendor honours each kind of item in one place only, so the module writes four:
+
+- skills, subagents, slash commands, hooks and output styles go into **one plugin named `nox-mesh`**. It
+  sits in a marketplace directory inside the managed directory, written whole by the module and read in
+  place by the agent. Its items are offered as `nox-mesh:<name>`, so nothing the mesh adds shadows a
+  person's own item;
+- tool servers go into the managed tool-server file, as in §4. The exclusive file would block a
+  plugin's servers;
+- settings and permission rules go into the managed settings file, as in §2;
+- instructions go into the managed instruction file, as sections (§3).
+
+The managed settings name the marketplace and enable the plugin. Those two keys are the mesh's, laid
+last with the attribution key, and no setting replaces them.
+
+**Three scopes.** Every registration names one:
+
+- **mesh:** every machine running the agent;
+- **node:** one machine or a list of them, rendered into the same plugin and files there only;
+- **home:** the operator account's own agent directory on one machine, where the item sits as if
+  written there by hand.
+
+Settings take the first two scopes only. In the managed settings file they are laid in this order:
+the operator's `managed_settings` setting (§2), then the mesh scope, then the node scope, then the
+mesh's own keys.
+
+**Instructions follow the scopes.** The managed instruction file holds the mesh's piece, then the node's
+piece: its role, and the sections registered for it. Further customisation per machine is a rule file
+placed at the home scope. The agent concatenates these and does not override, so the status tool names
+a section that contradicts another, or that calls a tool the mesh no longer serves.
+
+**The home scope owns only what it placed.** The module records each home path it placed and touches
+only those (ADR 0182). It refuses to register a name the person already uses there.
+
+**The tools.**
+
+- For each kind: list, register and unregister. Each register takes a scope, and a list says where
+  each item came from.
+- For settings and permission rules: read, and set at a scope.
+- A **status tool** lists the home's own items beside the mesh's and names the stale ones.
+- An **import tool** registers an item found in one machine's home at a scope the operator chooses.
+
+An item and its files are one value in the state, refused above 256 KiB.
+
+**Changing the agent's own settings is the operator's act.** The vendor refuses an agent that loosens its
+own settings, and the module does not route around that refusal. A settings tool is called on the
+operator's word.
+
 ## How it is checked
 
 | Check | Defends |
@@ -215,6 +271,9 @@ installer is rejected: it puts a self-updating binary under the person's home, i
 | a switch asked of the seat through the console changes the licence and the token on the node; no tool answer and no log line holds a token | ADR 0183 |
 | the API-key binding writes nothing under the home and the agent authenticates through the helper | ADR 0183 |
 | the module's test: keys set in `managed_settings` (an auto-mode allow list, a permissions list) appear in the rendered managed settings file, a setting naming the attribution, the connectors key or a key-helper is overridden, and a key-helper appears only for an API-key binding | ADR 0213 |
+| the module's render test: a registered skill, subagent, command, hook and output style land in the `nox-mesh` plugin; a tool server, a setting and an instruction section in their managed files; for one machine of two, a mesh item on both, a node item on one, a home item only in that home; a setting naming the marketplace keys is overridden | ADR 0216 |
+| the module's test: a home name the person already uses is refused, unregistering removes only the placed path, and an item above 256 KiB is refused | ADR 0216, ADR 0182 |
+| live: a skill registered at the mesh scope is offered as `nox-mesh:<name>` in a new session on each machine | ADR 0216 |
 | the console's provision resolves by co-location; a machine without the console refuses the module by name | ADR 0027, ADR 0152 |
 | a new session on the assigned workstation lists the console's five tools under `mesh` ([ADR 0195](../../02-DECISIONS/0195-the-meshs-tools-are-found-by-address-not-announced-whole.md)) and answers "which node am I" from the instruction file | the exit of the build |