ProcessSubmitDecisionTool

`process_submit_decision` — resolves an open gate via {@see HumanGate::resolve()} then drives the process forward again via {@see ProcessRunner} (so a decision that reaches a terminal state fires `process.terminal` — see {@see ProcessRunner}'s own docblock — and a decision that loops back to a gated state re-opens a fresh gate, both in one call). {@see HumanGate::resolve()}'s failure modes are each surfaced as a distinct, clean {@see ToolResult::error()} instead of a generic catch-all — `SelfApprovalException` MUST be caught before the generic `\RuntimeException` arm since it extends it. Parameters are named `instance_id`/`gate_id` (snake_case), not `instanceId`/`gateId`, on purpose: {@see \Milpa\ToolRuntime\ToolScanner::buildSchema()} takes a tool's wire argument names directly from `ReflectionParameter::getName()` with no case conversion, so the PHP parameter name IS the JSON-RPC argument key a caller must send — this family's wire convention is snake_case throughout. This tool touches NO domain entity — reaching a terminal state is surfaced purely via the `process.terminal` event {@see ProcessRunner} dispatches; a consumer subscribes to that event to run whatever domain effect its own process definition's terminal state should trigger.

public function __construct(Milpa\EventStore\EventStoreInterface $store, Milpa\Orchestrator\HumanGate $gate, Milpa\Orchestrator\ProcessRunner $runner, Milpa\Orchestrator\ProcessDefinitionRegistry $registry):

Parameters

public function submit(string $instance_id, string $gate_id, string $decision, string $principal): Milpa\ToolRuntime\ToolResult

Resolves `$gate_id` for `$instance_id` with `$decision` and auto-advances the process again.

Parameters

Returns

with data `{instance_id: string, current_state: string}` on success