jschoubben
b13ef1be81
192: no provision says where the console is, its port was never assigned, and nothing owns a person's agent configuration since the predecessor left. 193: the query verb wraps the caller's text in a read-only transaction the text can end, and its rows come back keyed by BEGIN.
5.0 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| open | 2026-10-02 |
|
192 — The mesh's tools reach a person only by a registration made by hand
What was observed
A design session on a workstation had none of the mesh's tools. The console was running on that machine and answering on its loopback port. It was reached over the bus as the console's account, and listed every running module's tools and every seat's verbs (ADR 0152). What was missing was the registration that tells the person's coding agent where the console is. That registration had been made by hand, once, while migrating the machine, and scoped to the one project directory it was made in. Every session started anywhere else had no mesh tools. Nothing said so: the agent simply offered no mesh tools, and the session fell back to a pull-request link for a person to open by hand.
The predecessor did this job itself: it wrote its tool server into the agent's user configuration on every machine. Migrating removed that entry, as it should have, and no module took the job over.
Why this is here
Three gaps, each of which would have stopped a module from doing it even if one existed.
1. The console tells nobody where it is. Its definition listens on a port and provides nothing. A module that wanted to point an agent at the console has no requirement it could name, so it would have to write the address into its own definition as a literal. That is exactly what ADR 0112 and ADR 0155 remove.
2. The console's port is one its definition chose. The definition names a port, and the mesh
never assigned one: no port assignment exists for the console on any machine. The plan assigns a
machine port only to a port a container publishes through a mapping, "without one the software binds
what it binds". The console runs on the host network with no mapping, but it reads its listening
address from ${port:…}, so the mesh could move it and does not. That is a module choosing a
machine port, which ADR 0038 exists to
prevent, through a gap in how the rule is applied rather than a decision against it. A module that
reads its port from the mesh should be assigned one like any other.
3. Nothing in the mesh owns a person's agent configuration. No catalogue module writes the agent's settings, its tool-server registrations, or the rules and skills the predecessor delivered. On the four machines these are hand-kept, or left over from the predecessor, or missing.
What a fix looks like (not decided)
- The console provides its endpoint. A provision, working name
mesh-tools, served as the URL on the machine port the mesh gives it. The console listens only on loopback, so the provider must be on the consumer's own machine. Co-location already chooses it (ADR 0084), and a machine with no console refuses the consumer, naming the provision. - A module for the coding agent requires it and writes the registration into the agent's
system-wide managed settings. The agent reads tool servers from a
managedMcpServerskey there. That file is the machine's rather than a user's, so the module owns it whole and no home directory is named. People keep their own registrations beside it. The agent's separate exclusive managed file is the wrong one: it blocks every registration a person makes and hides the hosted connectors. The agent's per-user file is rewritten by the agent continuously and sits in a home directory, which would make its path an operator value. These facts come from the agent's documentation (managed MCP and managed settings pages), not yet verified on a machine. - The same module owns the rest of the agent's configuration the predecessor delivered: managed settings and the rules, skills and instructions every session reads. Each declared setting carries a default (ADR 0164, proposed on its own branch), so one configuration serves every machine and one machine may differ.
Open questions
- Is the agent's configuration one module or several? Tool registration, managed settings, and the instruction files have different readers and change at different rates.
- Whose machine port is the console's? Should a host-network container that reads its port from
${port:…}be assigned one, or should a machine-only listener keep its declared number? The second needs a decision, because ADR 0038 does not allow it today. - Credentials. The console's authority is the machine's login (ADR 0152). A registration that reaches it carries no secret today. If the console ever listens beyond loopback, the registration needs one, from the vault.