action handler: reactive dispatch + native executor + hard-gate uplink + B2-lift (capabilities)

[AdaWorldAPI]

What

Continues the arago ActionHandler runtime toward a live drop-in. OGAR now runs a real command end-to-end, behind a hard authorization gate, from a real REST registration.

1. Reactive dispatch + the B1 executor seam (ogar-from-schema/action_ws.rs)

• CapabilityExecutor trait — the seam where a command runner plugs in (the only piece that does real I/O). The RBAC/guard gate (commit_via) is owned downstream, so the producer crate stays lance-graph-free.
• handle_submit(msg, def, signature, executor) — validate id → ack-or-nack → bind params → execute → sendActionResult. Rejects invalid id / unknown capability before ack; reports post-ack bind/exec failure as {"error":…} in the result.
• 5 tests with a mock executor.

2. New crate ogar-action-handler — the runtime (B1 native target)

• NativeCommandExecutor runs an ExecuteCommand's command via a local POSIX shell, returning output/stderr/exitcode. full_dispatch_runs_a_real_command: echo running end-to-end → {"output":"running",…}.

3. The hard-gate uplink (documented here; code in rs-graph-llm)

The executor is wired behind the hard gate in rs-graph-llm's new graph-flow-action-ogar seam (GatedOgarHandler / run_gated): dispatch_via's cold floor (commit_via: RBAC ∧ state-guard ∧ MUL) lands before the OGAR executor's handle. Structural proof — take_result() is None whenever the gate refused, so an unauthorized (Denied) or MUL-blocked (Escalated) action never reaches the executor. OGAR owns the executor; rs-graph-llm owns the gate; the seam joins them without OGAR taking a lance-graph dep. Recorded as the B1-uplink scorecard row + D-ACTIONHANDLER-UPLINK + E-ACTIONHANDLER-UPLINK.

4. B2-lift — REST registration instance lift, capabilities (ogar-from-schema/registration.rs + ogar-action-handler)

The OGIT ontology declares only that a capability has param slots; the concrete (name, mandatory, default) tuples live in a deployed handler's config. B2-lift reads them from the live REST view, so the two halves compose.

• Producer stays parser-free. registration.rs defines the typed REST DTOs (RegisteredCapability / ModelFilter, Deserialize behind the serde feature) + the pure lift (lift_registration → ConcreteCapability with concrete ActionParam[]; model_filter_to_guard: ModelFilter{Var,Mode,Value} → StateGuard, field-for-field). No serde_json, no I/O.
• Runtime owns the read. ogar-action-handler::parse_capabilities does the serde_json read of a GET /capabilities body. rest_registration_lifts_binds_and_runs proves it end-to-end: real JSON → lift → bind_parameters → NativeCommandExecutor runs the command. Same producer-defines-types / runtime-does-I/O split the whole crate family keeps.

Parity state

Contract, lifecycle, protocol binding, reactive dispatch, a working native executor, the hard authorization gate, and the capabilities REST instance lift are all OGAR-native and tested. What remains for a live drop-in of the Python daemon: B2-transport (the WebSocket loop — all message shapes/auth pinned), the B2-lift applicabilities envelope (GET /applicabilities JSON read; the ModelFilter→StateGuard lift is done), and the non-native executor targets (SSH/REST). Each is transport/parser/runner glue over existing types — no missing IR.

Tests

54 green across the two crates (48 ogar-from-schema + 6 ogar-action-handler + doctest), clippy-clean on new code. Docs: ARAGO-ACTIONHANDLER-PARITY scorecard + D-ACTIONHANDLER-{PARITY,UPLINK,B2LIFT} ledger rows + epiphanies.

Sources: github.com/arago/ActionHandlers, arago/python-hiro-stonebranch-actionhandler, and the HIRO 7 Action API spec.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.