HumanVerifyTool

Exposes the {@see HumanVerifier} as the `human_verify` tool (D8 / T089). Called without a `decision`, it opens the verification and surfaces through {@see ToolResult::confirmation()} (PENDING). Called with `decision=grant|reject` and a `principal`, it resolves and returns the verdict. The single registered callback is the MCP `tools/call` surface — the same one engine as every other tool (D7).

public function __construct(Milpa\ToolRuntime\Verification\HumanVerifier $verifier):

Parameters

public function register(Milpa\Interfaces\Tooling\ToolRegistryInterface $registry): void

Register the `human_verify` tool callback on the given registry. Wires {@see handle()} as the single callback behind the MCP `tools/call` surface, marking the tool as mutating. `requiresConfirmation` is deliberately `false` (tool-runtime 0.2): `handle()` already owns its own two-phase `request_id` protocol — open a request, resolve it later — so stacking the registry's generic confirm-token gate on top produced a confusing 3-4 call choreography (registry gate -> redeem -> handle()'s own request phase -> resolve, itself gated again) with no `request_id` visible until the SECOND call. With the gate bypassed, `handle()` runs directly on every call: one call opens a request and returns its `request_id` immediately, a second call with `decision` + that `request_id` resolves it — the two-phase flow the tool was built around, reached directly through the registry, not just by calling {@see handle()} out of band. Note: a channel whose policy sets `require_confirmation_for_mutating` (e.g. the built-in `telegram` policy) still gates ANY `mutating: true` tool regardless of this flag — see {@see \Milpa\ToolRuntime\PolicyGate::requiresConfirmation()}. The bypass is only total on channels without that policy (e.g. `cli`, `mcp`, `web` by default).

Parameters

public function handle(array $args): Milpa\ToolRuntime\ToolResult

Handle a `human_verify` tool call: open a verification request, or resolve a pending one. Omitting `decision` opens the request and returns a confirmation carrying its `request_id`; passing `decision=grant|reject` with a `principal` resolves it via {@see HumanVerifier::grant()} or {@see HumanVerifier::reject()}.

Parameters