novox/hq
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Issue 147: the tool surface is not the mesh's, it is the predecessor's

Browse Source 
Diagnosed from the configuration: the tool server is HAL's brain, a local
process on the workstation with the predecessor's broker URL in the assistant's
own config. No manifest, no assignment, no seat, no account. Nothing regressed
— the mesh removed a transport this program still dials, and the program was
never part of the mesh. The mesh has a tool model and nothing publishes an
operator-facing surface onto it.
This commit is contained in:
jschoubben
2026-09-29 21:50:50 +02:00
parent 0dd00e88b6
commit 3c0f7082e6
1 changed files with 19 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
04-ISSUES/147-the-operators-tools-still-dial-the-bus-that-was-removed/00-report.md
+19 -2
View File
@@ -1,7 +1,7 @@
--- ---
status: open status: located
opened: 2026-09-29 opened: 2026-09-29
located-in: [] located-in: [nothing in the mesh — the surface in use is the predecessor's, installed on the workstation]
--- ---
# 147 — the operator's tools still dial the bus that was removed # 147 — the operator's tools still dial the bus that was removed
@@ -49,6 +49,23 @@ reason, which is why lessons from the last two days were written into this repos
a person can ask it anything ([issue 145](../145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md), a person can ask it anything ([issue 145](../145-a-machine-reads-healthy-while-its-modules-cannot-reach-each-other/00-report.md),
the same shape one level out). the same shape one level out).
## Diagnosed at once, because the answer was in the configuration
**The surface is not the mesh's.** The tool server the operator's assistant speaks to is the
predecessor's brain, installed on the workstation and started as a local process, with the
predecessor's broker URL — `amqp://…@<the control node>` — written into the assistant's own
configuration. Nothing about it is a module: it has no manifest, no assignment, no seat, no account
on the mesh's bus, and the mesh has never known it exists.
So nothing regressed. The mesh removed a transport that this program still dials, and the program
was never part of the mesh to be moved. **The mesh has a tool model** — `tools` in a manifest, the
calls a seat accepts, the subjects a module answers on, and a control-plane command that asks one —
and **nothing publishes an operator-facing surface onto it.** What an operator uses is the thing
that came before, kept alive by a URL in a file.
That is the issue, and it is larger than a broken connection: the way a person drives this mesh is
outside the mesh.
## Evidence to carry into diagnosis ## Evidence to carry into diagnosis
- The failure text names `hal/mesh@<node>`, so the bridge is resolving a node and then dialling the - The failure text names `hal/mesh@<node>`, so the bridge is resolving a node and then dialling the