Files

20 lines
1.4 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. Fixed as
[ADR 0095](../../02-DECISIONS/0095-the-control-plane-is-the-way-to-ask-a-module.md): `ask`,
proven by the confluence bed asking a served tool and getting its answer.