🚀 Dev Kit Update: v0.1.13 & v0.1.14 - Executa Plugin Scaffolding & RPC Bridge

Changelog
, ,
1

:rocket: v0.1.13 — Standalone Executa Plugin Scaffolding

  • Added standalone Executa plugin project scaffolding
  • Included local runner for direct plugin execution

:rocket: v0.1.14 — Agent / Storage Reverse RPC Bridge

  • Added agent/storage reverse RPC bridge: Executa plugins can now callback host’s agent and storage capabilities
  • Added executa register subcommand to register plugins to local development environment

anna-app CLI v0.1.14
anna-app CLI v0.1.142458×1326 308 KB

3

Thanks for the update. I tested this locally and wanted to leave one piece of developer feedback about the current debugging workflow.

Environment:

  • anna-app CLI: 0.1.14
  • local runtime used by anna-app dev: anna-app-runtime-local@0.2.0a2
  • test shape: Anna App iframe calls anna.tools.invoke(...), the Executa tool then calls host LLM/Agent through reverse RPC such as sampling/createMessage or agent/session.*.

What works today:

  • anna-app executa dev --app-slug ... --invoke ... works well for testing a single Executa tool invocation in isolation.
  • This is useful for validating one LLM/Agent call from the tool side.

Where I am still blocked:

For a full Anna App, the important local path is:

App iframe


  -> anna.tools.invoke(...)


  -> local Executa tool


  -> sampling/createMessage or agent/session.* reverse RPC


  -> result back to the iframe

With anna-app dev on 0.1.14, this path does not appear to be supported yet. In my local test, the tool receives an invoke with an empty context:

invoke start tool='complete' invoke_id='' context_keys=[]


sampling/createMessage send ... metadata={"executa_invoke_id":"","tool":"complete"}


sampling/createMessage timeout after=30.0s

After checking the local runtime behavior, it looks like anna-app dev invokes the Executa with only:

{"tool":"...","arguments":{...}}

and does not inject params.context with invoke_id / sampling_token. Also, the local Executa stdout reader appears to only match normal JSON-RPC responses by id, so plugin-initiated reverse RPC frames such as sampling/createMessage are not handled and answered in the anna-app dev path.

Feature request / suggestion:

It would be very helpful if anna-app devsupported the same end-to-end local path, not only standalone anna-app executa dev calls. Concretely, I think the local runtime would need to:

  1. inject params.context when invoking local Executa tools, including at least invoke_id and the sampling/agent authorization context required by the host; and
  2. handle plugin-initiated reverse RPC messages from Executa stdout, including sampling/createMessage and agent/session.*, then write the JSON-RPC response back to the plugin stdin.

That would make it possible to test a real app flow where the frontend, anna.tools.invoke, the backend Executa, and host-mediated LLM/Agent calls all work together locally. Right now I can test the tool LLM/Agent behavior only as a single isolated invocation, which is not enough to validate the full app UX and polling/state flow.