19 lines
1.3 KiB
Markdown
19 lines
1.3 KiB
Markdown
# Diagnosis — 2026-09-21
|
|
|
|
1. The refusal is the scope working as designed: a module's broker account covers what it emits
|
|
and consumes and nothing else. A tool call needs a reply queue the caller creates and a publish
|
|
to the serving module's request queue, and no declared scope grants either.
|
|
2. Of the three callers the report names, two already have an account with the right shape. The
|
|
controller holds an admin connection to the broker, and an agent acting for an operator runs
|
|
through the controller. Another module is the only caller that would need something minted.
|
|
3. The honest first step is therefore the third option in the report: the controller is the way
|
|
in. A `mesh-controller ask <module> <tool>` needs no new account, routes every question
|
|
through one process — which is where an audit of who asked what belongs anyway — and settles
|
|
what a module declares about being asked by declaring nothing: serving a tool is being
|
|
askable through the controller. A module-to-module call, if one is ever wanted, is a grant
|
|
like any other, and a later decision.
|
|
|
|
**Located in:** the controller (a command speaking the tool request/reply over its own connection)
|
|
and the tool runtime's request contract. Not fixed here: it is a new command against a protocol
|
|
the runtime owns, and needs a lab run against a tools-only bed to be proven.
|