AbstractRuntime 0.7.2__tar.gz → 0.7.3__tar.gz

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/ACKNOWLEDGMENTS.md

@@ -11,7 +11,7 @@ The canonical dependency list lives in `pyproject.toml`.
 - **AbstractMemory** (`>=0.3.0`) — TripleStore models and store contract used by Runtime's `MEMORY_KG_*` effects. Durable/vector backend dependencies such as LanceDB remain selected by hosts.
 
 ## Runtime integrations
-- **abstractcore** (`abstractcore>=2.19.0`) — LLM, tools, media, and capability integration used by the base `abstractruntime` install (AbstractCore's light install); the `apple` and `gpu` extras select `abstractcore[apple]` / `abstractcore[gpu]` at the same floor (declared in `pyproject.toml`, implementation under `src/abstractruntime/integrations/abstractcore/*`, docs: `docs/integrations/abstractcore.md`).
+- **abstractcore** (`abstractcore>=2.19.2`) — LLM, tools, media, and capability integration used by the base `abstractruntime` install (AbstractCore's light install); the `apple` and `gpu` extras select `abstractcore[apple]` / `abstractcore[gpu]` at the same floor (declared in `pyproject.toml`, implementation under `src/abstractruntime/integrations/abstractcore/*`, docs: `docs/integrations/abstractcore.md`).
   - The AbstractCore integration uses **httpx** for remote mode (`src/abstractruntime/integrations/abstractcore/llm_client.py`) and **pydantic** for structured validation (`src/abstractruntime/integrations/abstractcore/effect_handlers.py`). These are provided by AbstractCore’s dependency set.
   - The `tools` extra of AbstractCore backs the base Runtime toolset and the `abstractruntime-mcp-worker` entry point.
 - **RestrictedPython** (`>=7.0`, core install) — sandbox for VisualFlow “Code” nodes and pin expressions (`src/abstractruntime/visualflow_compiler/visual/code_executor.py`).

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/CHANGELOG.md

@@ -7,6 +7,42 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.7.3] - 2026-09-29
+
+### Security
+
+- **An automation's tool grant no longer pre-approves sending messages** (framework backlog 0992
+  WP0). With the default `policy.tool_approval: "auto"`, the grant listed every tool the runtime
+  classifies, `send_email` included, and an explicit name in the grant overrides the
+  `model_controlled_destination` belt: an occurrence that read an inbound email or a web page could
+  mail data to any address that text named. The grant now withholds every tool whose inventory row
+  carries `comms_send` (`send_email`, `send_whatsapp_message`, `send_telegram_message`,
+  `send_telegram_artifact`), even when the target's `allowed_tools` names it, and lists them in
+  `tool_policy.withheld_tools`. Their calls take the normal approval point: a `send_email` whose
+  every recipient is the registered user's address (`_runtime.operator_email`) still runs
+  unattended; any other recipient parks the occurrence on a `tool_approval` wait until a person
+  approves or refuses it (the behaviour of `"ask"`). Recipients named in an automation's definition
+  are not auto-approved yet; that allowlist is part of backlog 0992.
+
+### Fixed
+
+- **A resident image/video model serves generation.** After `load_model_residency(task="image_generation")`
+  (the Gateway's `POST /models/load`, the console Load button, a flow's model residency node), a local
+  image or video request whose every media output names a resident model runs in-process on the loaded
+  pipeline (`execution_mode="resident_in_process"`, `resident_load_ids`) instead of loading the model
+  again in a one-shot subprocess. Measured through AbstractGateway with FLUX.2 [klein] 4B on a 16 GB
+  NVIDIA card: 17-19 s per image on the resident pipeline against 54-59 s with a reload per request, and
+  no second copy of the weights on the GPU. Pooled clients of `create_local_runtime(...)` use their pool's residency core. Models that
+  were not explicitly loaded keep the isolated subprocess (crash isolation for native Metal/CUDA
+  failures), so the explicit load is the opt-in.
+
+### Changed
+
+- **Requires AbstractCore 2.19.2 or newer** (`abstractcore`, `abstractcore[apple]`, `abstractcore[gpu]`).
+  It brings AbstractVision 0.3.33, whose loads report `loaded_new` (a fresh image-model load reads as
+  `loaded`, not `already_loaded`) and whose unload frees the model's memory, which the resident path
+  above relies on.
+
 ## [0.7.2] - 2026-09-29
 
 ### Changed

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: AbstractRuntime
-Version: 0.7.2
+Version: 0.7.3
 Summary: AbstractRuntime: a durable graph runner designed to pair with AbstractCore.
 Project-URL: AbstractCore (website), https://www.abstractcore.ai/
 Project-URL: AbstractRuntime (GitHub), https://github.com/lpalbou/abstractruntime
@@ -20,7 +20,7 @@ Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
 Requires-Python: >=3.10
-Requires-Dist: abstractcore>=2.19.0
+Requires-Dist: abstractcore>=2.19.2
 Requires-Dist: abstractmemory>=0.3.0
 Requires-Dist: abstractsemantics>=0.0.5
 Requires-Dist: anyio<5.0.0,>=4.12.1
@@ -35,14 +35,14 @@ Requires-Dist: reportlab<5.0.0,>=4.0.0
 Requires-Dist: restrictedpython>=7.0
 Requires-Dist: unstructured[docx,odt,pptx,rtf,xlsx]<0.19.0,>=0.18.32
 Provides-Extra: apple
-Requires-Dist: abstractcore[apple]>=2.19.0; extra == 'apple'
+Requires-Dist: abstractcore[apple]>=2.19.2; extra == 'apple'
 Requires-Dist: setuptools<82.0.0,>=80.10.2; extra == 'apple'
 Provides-Extra: docs
 Requires-Dist: mkdocs-material>=9.0.0; extra == 'docs'
 Requires-Dist: mkdocs>=1.6.0; extra == 'docs'
 Requires-Dist: pymdown-extensions>=10.0; extra == 'docs'
 Provides-Extra: gpu
-Requires-Dist: abstractcore[gpu]>=2.19.0; extra == 'gpu'
+Requires-Dist: abstractcore[gpu]>=2.19.2; extra == 'gpu'
 Requires-Dist: setuptools<82.0.0,>=77.0.3; extra == 'gpu'
 Provides-Extra: test
 Requires-Dist: pytest>=7.0.0; extra == 'test'
@@ -54,7 +54,7 @@ Description-Content-Type: text/markdown
 
 It is designed for long-running workflows that must survive restarts and explicitly model blocking (human input, timers, external events, subworkflows) without keeping Python stacks alive.
 
-**Version:** 0.7.2 • **Python:** 3.10+
+**Version:** 0.7.3 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
@@ -82,7 +82,7 @@ Remote-light runtime:
 pip install abstractruntime
 ```
 
-The base install includes AbstractCore 2.19.0 or newer (its light install:
+The base install includes AbstractCore 2.19.2 or newer (its light install:
 remote providers, tools, vision, voice, audio, and music integration), plus the
 `abstractruntime-mcp-worker` entry point. It keeps inference remote/light by
 default: local engines such as MLX, vLLM, HuggingFace/Torch, Diffusers, and
@@ -146,7 +146,7 @@ state = rt.resume(
 assert state.status.value == "completed"
 ```
 
-## What’s included (v0.7.2)
+## What’s included (v0.7.3)
 
 Kernel (import-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/README.md

@@ -4,7 +4,7 @@
 
 It is designed for long-running workflows that must survive restarts and explicitly model blocking (human input, timers, external events, subworkflows) without keeping Python stacks alive.
 
-**Version:** 0.7.2 • **Python:** 3.10+
+**Version:** 0.7.3 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
@@ -32,7 +32,7 @@ Remote-light runtime:
 pip install abstractruntime
 ```
 
-The base install includes AbstractCore 2.19.0 or newer (its light install:
+The base install includes AbstractCore 2.19.2 or newer (its light install:
 remote providers, tools, vision, voice, audio, and music integration), plus the
 `abstractruntime-mcp-worker` entry point. It keeps inference remote/light by
 default: local engines such as MLX, vLLM, HuggingFace/Torch, Diffusers, and
@@ -96,7 +96,7 @@ state = rt.resume(
 assert state.status.value == "completed"
 ```
 
-## What’s included (v0.7.2)
+## What’s included (v0.7.3)
 
 Kernel (import-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/docs/api.md

@@ -277,7 +277,7 @@ from Core route resolution and persisted from `LLM_CALL` results.
 
 ### AbstractCore (LLM + tools)
 
-Requires: `pip install abstractruntime` (AbstractCore 2.19.0 or newer is part of the base install).
+Requires: `pip install abstractruntime` (AbstractCore 2.19.2 or newer is part of the base install).
 
 Implementation: `src/abstractruntime/integrations/abstractcore/*`.
 
@@ -324,7 +324,8 @@ Multimodal support:
 - remote transcription requires one audio media item that resolves to a local file path or artifact-backed temporary file
 - generated image/video/voice/music/audio bytes require a runtime `ArtifactStore`; the result contains `artifact_id` / `artifact_ref` instead of inline bytes
 - media-only normalized results expose `runtime_provider` / `runtime_model` separately from `media_provider` / `media_model`
-- optional local media residency failures complete with `status_hint="warning"` and `degraded=true`; unsupported local media warmup for `image_generation`, `image_upscale`, `video_generation`, `text_to_video`, `image_to_video`, `tts`, `stt`, and `music_generation` reports `requires_long_lived_server=true`, and generated image/video tasks also report `execution_mode="local_one_shot_subprocess"`
+- local image/video generation runs in a one-shot subprocess (`execution_mode="local_one_shot_subprocess"`) unless every requested media model is resident (explicitly loaded with `load_model_residency`), in which case it runs in-process on the loaded pipeline (`execution_mode="resident_in_process"`, `resident_load_ids`)
+- optional local media residency failures complete with `status_hint="warning"` and `degraded=true`; local media warmup that no capability plugin can serve (`image_generation`, `image_upscale`, `video_generation`, `text_to_video`, `image_to_video`, `tts`, `stt`, `music_generation`) reports `requires_long_lived_server=true`, and image/video tasks also report `execution_mode="local_one_shot_subprocess"`
 - Gateway/hosts remain responsible for explicit Core server URLs, Core server auth headers, provider/model defaults, selected local-inference profiles, and translation of Gateway-owned env/config into explicit Runtime inputs; Runtime persists only JSON-safe routing metadata and artifact refs
 
 Prompt cache / cached sessions:

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/docs/architecture.md

@@ -1,7 +1,7 @@
 # AbstractRuntime — Architecture
 
 > Updated: 2026-09-29
-> Version: 0.7.2
+> Version: 0.7.3
 > Scope: this describes **what is implemented in this repository**.
 
 AbstractRuntime is a **durable workflow runtime**: it executes workflow graphs as a persisted state machine with explicit waits (user, time, events, jobs, subworkflows). A run can pause for hours/days and resume **without** keeping Python stacks/coroutines alive.

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/docs/automations.md

@@ -26,7 +26,8 @@ sources), `abstractruntime.automation_queries` (listing), `abstractruntime.sessi
 - **Automations are quiet.** An occurrence asks for attention only when its output says `notify`, when it still
   fails after its last retry, or while it waits on a person.
 - **Creating an automation is consent for its tools.** With the default `tool_approval: "auto"` an occurrence's tools
-  run without asking; set `"ask"` to approve them one batch at a time.
+  run without asking, except messages to anyone but the registered user (those wait for approval); set `"ask"` to
+  approve every batch.
 - **Everything is recorded.** Every admission, dispatch, retry, completion and command is an `automation.*` record in
   the controller's ledger. A crash at any point never loses an occurrence and never starts one twice.
 
@@ -413,6 +414,15 @@ returns the refusal message for a tool, or `None` when it is allowed.
   - A name outside the run's tool ceiling (`allowed_tools`) grants nothing: approval never widens the ceiling.
   - A tool outside `TOOL_EFFECT_CLASSES` (a third-party MCP tool, for example) is not in the grant and still asks.
   - A `tool_policy` that the target's own `input_data._runtime` already carries is left as it is.
+  - **Tools that message model-chosen recipients are never granted** (framework backlog 0992 WP0): every tool
+    whose inventory row carries `comms_send` (`send_email`, `send_whatsapp_message`, `send_telegram_message`,
+    `send_telegram_artifact`), even when `allowed_tools` names it. They are listed in the grant's
+    `withheld_tools` and go through the normal approval point: a `send_email` whose every recipient is the
+    registered user's address (`_runtime.operator_email`, set by the host; the gateway freezes it into the
+    target's inputs) runs; any other recipient parks the occurrence on a `tool_approval` wait, as under `"ask"`,
+    until a person approves or refuses it. An occurrence that reads untrusted text (an inbound email, a fetched
+    page) therefore cannot mail data to an address that text names. When the inventory cannot be read, every
+    `comms` tool is withheld.
 - **`"ask"`.** No grant. A tool call that needs approval waits on a `tool_approval` wait, as in a chat.
 
 The grant is frozen with the rest of the occurrence's inputs: a revision of `tool_approval` applies from the next

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/docs/faq.md

@@ -79,8 +79,12 @@ Docs: `automations.md#runs-sessions-and-history`, `api.md#sessions-and-history`.
 
 Not by default. With `policy.tool_approval: "auto"`, creating the automation is the consent: each occurrence gets a
 frozen grant for the target's tools (its `allowed_tools`, or every tool the runtime classifies). Tools the runtime
-does not classify, such as third-party MCP tools, still ask, and `ask_user` questions still wait for a person. Use
-`"ask"` to approve each tool batch; pending approvals appear in `pending_waits` as `tool_approval` waits.
+does not classify, such as third-party MCP tools, still ask, and `ask_user` questions still wait for a person.
+Tools that send messages to recipients the model chooses (`send_email`, `send_whatsapp_message`,
+`send_telegram_*`) are never in the grant: a `send_email` to the registered user's own address runs, any other
+recipient waits for approval, so text an occurrence reads (an inbound email, a web page) cannot make it mail data
+elsewhere. Use `"ask"` to approve each tool batch; pending approvals appear in `pending_waits` as `tool_approval`
+waits.
 
 Docs: `automations.md#tool-approval`, `automations.md#waits-on-a-person`.
 
@@ -282,9 +286,9 @@ Docs: `integrations/abstractcore.md`. Code: `src/abstractruntime/integrations/ab
 
 ## Why can local media residency return `ok:false` without failing the run?
 
-Because local media warmup is not always a meaningful reusable state. In particular, local image generation may execute through a one-shot subprocess isolation boundary, so a prior warmup cannot be reused by the next request. Runtime therefore reports unsupported local media residency explicitly instead of pretending success.
+Because a local media load can fail or have nothing to load into: no capability plugin serves the task, or the plugin refused the model. Runtime reports that explicitly instead of pretending success. A load that succeeds is used: local image and video requests normally run in a one-shot subprocess (crash isolation, one model load per request), but a request whose model is resident runs in-process on the loaded pipeline (`execution_mode="resident_in_process"`).
 
-For optional residency (`required=false`), the effect still completes durably but includes `status_hint="warning"` and `degraded=true`. Unsupported local media responses also report `requires_long_lived_server=true` and a `config_hint` that points at `ABSTRACTCORE_SERVER_BASE_URL`; image generation additionally reports `execution_mode="local_one_shot_subprocess"`.
+For optional residency (`required=false`), the effect still completes durably but includes `status_hint="warning"` and `degraded=true`. Unsupported local media responses also report `requires_long_lived_server=true` and a `config_hint` that points at `ABSTRACTCORE_SERVER_BASE_URL`; image generation additionally reports `execution_mode="local_one_shot_subprocess"`, the path those requests then take.
 Docs: `integrations/abstractcore.md`. Code: `src/abstractruntime/integrations/abstractcore/effect_handlers.py`, `src/abstractruntime/integrations/abstractcore/llm_client.py`.
 
 ## What are “local / remote / hybrid” execution modes?

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/docs/integrations/abstractcore.md

@@ -301,7 +301,9 @@ Media-only normalized results distinguish orchestration identity from the actual
 - `runtime_provider` / `runtime_model`: the runtime-side orchestration identity, when relevant
 - `media_provider` / `media_model`: the actual image/video/voice/music backend identity surfaced from the generated output
 
-For local one-shot subprocess image generation, runtime metadata also records `execution_mode="local_one_shot_subprocess"`.
+Local image and video generation runs in a one-shot subprocess by default: a native backend failure (a Metal abort, a CUDA crash) ends the worker, not the Gateway/Runtime process, and the worker's memory is returned when it exits. The price is a full model load per request. Runtime metadata records `execution_mode="local_one_shot_subprocess"`.
+
+A model you load explicitly (`load_model_residency(task="image_generation", provider=..., model=...)`, the Gateway's `POST /models/load`, the console Load button, a flow's model residency node) is the exception: when every media output of a request names a model resident in the client's capability residency core, the request runs in-process on that loaded pipeline, with no subprocess and no second copy of the weights. The metadata then records `execution_mode="resident_in_process"` and `resident_load_ids`. A pooled client of `create_local_runtime(...)` uses its pool's residency core. Unloading the model (`unload_model_residency`, `POST /models/unload`) returns generation to the subprocess. Requests for a model that is not resident keep the subprocess, so an explicit load is how you opt into in-process execution for that model.
 
 Long-running generated media may expose provider progress callbacks. Runtime offers a transient `on_progress` callback during `LLM_CALL` execution and persists each callback as an `EMIT_EVENT` ledger record named `abstract.progress`. The callback itself is never stored in the effect payload or run vars.
 
@@ -335,13 +337,13 @@ Remote runtimes support chat media by sending OpenAI-compatible data URL content
 
 Remote multimodal generation currently supports one `output` selector per `LLM_CALL`. Hybrid runtimes use the same remote LLM/media path as remote mode while executing tools locally. Local runtimes can use AbstractCore's in-process multimodal dispatcher for richer capability plugin behavior.
 
-Local media residency is intentionally explicit when unsupported. `MODEL_RESIDENCY` results for local `image_generation`, `image_upscale`, `video_generation`, `text_to_video`, `image_to_video`, `tts`, `stt`, and `music_generation` return:
+Local media residency goes through the installed AbstractCore capability plugins (AbstractVision for image/upscale/video, AbstractVoice for TTS/STT, AbstractMusic for music): `load_model_residency` preloads the model in-process and `list_model_residency` lists it. When no plugin can serve the task, the result is explicit rather than a pretend success:
 
 - `code="model_residency_unsupported"`
 - `requires_long_lived_server=true`
 - `config_hint` pointing to `ABSTRACTCORE_SERVER_BASE_URL`
 
-Image/video-generation residency responses also include `execution_mode="local_one_shot_subprocess"` because local generated media can be isolated into one-shot workers unless a long-lived Core server owns the media backend.
+Image/video-generation unsupported responses also include `execution_mode="local_one_shot_subprocess"`, the path those requests then take.
 
 When the workflow marks residency as optional (`required=false`), the effect still completes durably but includes `status_hint="warning"` and `degraded=true` so hosts can render the no-op honestly.
 

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/docs/troubleshooting.md

@@ -20,7 +20,7 @@ Fix:
 - Install or upgrade the base Runtime package. LLM/tools integration, common
   remote-light multimodal dependencies, and the MCP worker entry point are part
   of the base install.
-- The current AbstractCore integration expects `abstractcore>=2.19.0`.
+- The current AbstractCore integration expects `abstractcore>=2.19.2`.
 
 Verify:
 

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/llms-full.txt

@@ -52,7 +52,7 @@ See llms.txt for the linked index.
 
 It is designed for long-running workflows that must survive restarts and explicitly model blocking (human input, timers, external events, subworkflows) without keeping Python stacks alive.
 
-**Version:** 0.7.2 • **Python:** 3.10+
+**Version:** 0.7.3 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
@@ -80,7 +80,7 @@ Remote-light runtime:
 pip install abstractruntime
 ```
 
-The base install includes AbstractCore 2.19.0 or newer (its light install:
+The base install includes AbstractCore 2.19.2 or newer (its light install:
 remote providers, tools, vision, voice, audio, and music integration), plus the
 `abstractruntime-mcp-worker` entry point. It keeps inference remote/light by
 default: local engines such as MLX, vLLM, HuggingFace/Torch, Diffusers, and
@@ -144,7 +144,7 @@ state = rt.resume(
 assert state.status.value == "completed"
 ```
 
-## What’s included (v0.7.2)
+## What’s included (v0.7.3)
 
 Kernel (import-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)
@@ -430,7 +430,7 @@ rt = create_local_runtime(provider="ollama", model="qwen3:4b")
 # AbstractRuntime — Architecture
 
 > Updated: 2026-09-29
-> Version: 0.7.2
+> Version: 0.7.3
 > Scope: this describes **what is implemented in this repository**.
 
 AbstractRuntime is a **durable workflow runtime**: it executes workflow graphs as a persisted state machine with explicit waits (user, time, events, jobs, subworkflows). A run can pause for hours/days and resume **without** keeping Python stacks/coroutines alive.
@@ -1132,7 +1132,7 @@ from Core route resolution and persisted from `LLM_CALL` results.
 
 ### AbstractCore (LLM + tools)
 
-Requires: `pip install abstractruntime` (AbstractCore 2.19.0 or newer is part of the base install).
+Requires: `pip install abstractruntime` (AbstractCore 2.19.2 or newer is part of the base install).
 
 Implementation: `src/abstractruntime/integrations/abstractcore/*`.
 
@@ -1179,7 +1179,8 @@ Multimodal support:
 - remote transcription requires one audio media item that resolves to a local file path or artifact-backed temporary file
 - generated image/video/voice/music/audio bytes require a runtime `ArtifactStore`; the result contains `artifact_id` / `artifact_ref` instead of inline bytes
 - media-only normalized results expose `runtime_provider` / `runtime_model` separately from `media_provider` / `media_model`
-- optional local media residency failures complete with `status_hint="warning"` and `degraded=true`; unsupported local media warmup for `image_generation`, `image_upscale`, `video_generation`, `text_to_video`, `image_to_video`, `tts`, `stt`, and `music_generation` reports `requires_long_lived_server=true`, and generated image/video tasks also report `execution_mode="local_one_shot_subprocess"`
+- local image/video generation runs in a one-shot subprocess (`execution_mode="local_one_shot_subprocess"`) unless every requested media model is resident (explicitly loaded with `load_model_residency`), in which case it runs in-process on the loaded pipeline (`execution_mode="resident_in_process"`, `resident_load_ids`)
+- optional local media residency failures complete with `status_hint="warning"` and `degraded=true`; local media warmup that no capability plugin can serve (`image_generation`, `image_upscale`, `video_generation`, `text_to_video`, `image_to_video`, `tts`, `stt`, `music_generation`) reports `requires_long_lived_server=true`, and image/video tasks also report `execution_mode="local_one_shot_subprocess"`
 - Gateway/hosts remain responsible for explicit Core server URLs, Core server auth headers, provider/model defaults, selected local-inference profiles, and translation of Gateway-owned env/config into explicit Runtime inputs; Runtime persists only JSON-safe routing metadata and artifact refs
 
 Prompt cache / cached sessions:
@@ -1306,8 +1307,12 @@ Docs: `automations.md#runs-sessions-and-history`, `api.md#sessions-and-history`.
 
 Not by default. With `policy.tool_approval: "auto"`, creating the automation is the consent: each occurrence gets a
 frozen grant for the target's tools (its `allowed_tools`, or every tool the runtime classifies). Tools the runtime
-does not classify, such as third-party MCP tools, still ask, and `ask_user` questions still wait for a person. Use
-`"ask"` to approve each tool batch; pending approvals appear in `pending_waits` as `tool_approval` waits.
+does not classify, such as third-party MCP tools, still ask, and `ask_user` questions still wait for a person.
+Tools that send messages to recipients the model chooses (`send_email`, `send_whatsapp_message`,
+`send_telegram_*`) are never in the grant: a `send_email` to the registered user's own address runs, any other
+recipient waits for approval, so text an occurrence reads (an inbound email, a web page) cannot make it mail data
+elsewhere. Use `"ask"` to approve each tool batch; pending approvals appear in `pending_waits` as `tool_approval`
+waits.
 
 Docs: `automations.md#tool-approval`, `automations.md#waits-on-a-person`.
 
@@ -1509,9 +1514,9 @@ Docs: `integrations/abstractcore.md`. Code: `src/abstractruntime/integrations/ab
 
 ## Why can local media residency return `ok:false` without failing the run?
 
-Because local media warmup is not always a meaningful reusable state. In particular, local image generation may execute through a one-shot subprocess isolation boundary, so a prior warmup cannot be reused by the next request. Runtime therefore reports unsupported local media residency explicitly instead of pretending success.
+Because a local media load can fail or have nothing to load into: no capability plugin serves the task, or the plugin refused the model. Runtime reports that explicitly instead of pretending success. A load that succeeds is used: local image and video requests normally run in a one-shot subprocess (crash isolation, one model load per request), but a request whose model is resident runs in-process on the loaded pipeline (`execution_mode="resident_in_process"`).
 
-For optional residency (`required=false`), the effect still completes durably but includes `status_hint="warning"` and `degraded=true`. Unsupported local media responses also report `requires_long_lived_server=true` and a `config_hint` that points at `ABSTRACTCORE_SERVER_BASE_URL`; image generation additionally reports `execution_mode="local_one_shot_subprocess"`.
+For optional residency (`required=false`), the effect still completes durably but includes `status_hint="warning"` and `degraded=true`. Unsupported local media responses also report `requires_long_lived_server=true` and a `config_hint` that points at `ABSTRACTCORE_SERVER_BASE_URL`; image generation additionally reports `execution_mode="local_one_shot_subprocess"`, the path those requests then take.
 Docs: `integrations/abstractcore.md`. Code: `src/abstractruntime/integrations/abstractcore/effect_handlers.py`, `src/abstractruntime/integrations/abstractcore/llm_client.py`.
 
 ## What are “local / remote / hybrid” execution modes?
@@ -1633,7 +1638,7 @@ Fix:
 - Install or upgrade the base Runtime package. LLM/tools integration, common
   remote-light multimodal dependencies, and the MCP worker entry point are part
   of the base install.
-- The current AbstractCore integration expects `abstractcore>=2.19.0`.
+- The current AbstractCore integration expects `abstractcore>=2.19.2`.
 
 Verify:
 
@@ -2217,7 +2222,9 @@ Media-only normalized results distinguish orchestration identity from the actual
 - `runtime_provider` / `runtime_model`: the runtime-side orchestration identity, when relevant
 - `media_provider` / `media_model`: the actual image/video/voice/music backend identity surfaced from the generated output
 
-For local one-shot subprocess image generation, runtime metadata also records `execution_mode="local_one_shot_subprocess"`.
+Local image and video generation runs in a one-shot subprocess by default: a native backend failure (a Metal abort, a CUDA crash) ends the worker, not the Gateway/Runtime process, and the worker's memory is returned when it exits. The price is a full model load per request. Runtime metadata records `execution_mode="local_one_shot_subprocess"`.
+
+A model you load explicitly (`load_model_residency(task="image_generation", provider=..., model=...)`, the Gateway's `POST /models/load`, the console Load button, a flow's model residency node) is the exception: when every media output of a request names a model resident in the client's capability residency core, the request runs in-process on that loaded pipeline, with no subprocess and no second copy of the weights. The metadata then records `execution_mode="resident_in_process"` and `resident_load_ids`. A pooled client of `create_local_runtime(...)` uses its pool's residency core. Unloading the model (`unload_model_residency`, `POST /models/unload`) returns generation to the subprocess. Requests for a model that is not resident keep the subprocess, so an explicit load is how you opt into in-process execution for that model.
 
 Long-running generated media may expose provider progress callbacks. Runtime offers a transient `on_progress` callback during `LLM_CALL` execution and persists each callback as an `EMIT_EVENT` ledger record named `abstract.progress`. The callback itself is never stored in the effect payload or run vars.
 
@@ -2251,13 +2258,13 @@ Remote runtimes support chat media by sending OpenAI-compatible data URL content
 
 Remote multimodal generation currently supports one `output` selector per `LLM_CALL`. Hybrid runtimes use the same remote LLM/media path as remote mode while executing tools locally. Local runtimes can use AbstractCore's in-process multimodal dispatcher for richer capability plugin behavior.
 
-Local media residency is intentionally explicit when unsupported. `MODEL_RESIDENCY` results for local `image_generation`, `image_upscale`, `video_generation`, `text_to_video`, `image_to_video`, `tts`, `stt`, and `music_generation` return:
+Local media residency goes through the installed AbstractCore capability plugins (AbstractVision for image/upscale/video, AbstractVoice for TTS/STT, AbstractMusic for music): `load_model_residency` preloads the model in-process and `list_model_residency` lists it. When no plugin can serve the task, the result is explicit rather than a pretend success:
 
 - `code="model_residency_unsupported"`
 - `requires_long_lived_server=true`
 - `config_hint` pointing to `ABSTRACTCORE_SERVER_BASE_URL`
 
-Image/video-generation residency responses also include `execution_mode="local_one_shot_subprocess"` because local generated media can be isolated into one-shot workers unless a long-lived Core server owns the media backend.
+Image/video-generation unsupported responses also include `execution_mode="local_one_shot_subprocess"`, the path those requests then take.
 
 When the workflow marks residency as optional (`required=false`), the effect still completes durably but includes `status_hint="warning"` and `degraded=true` so hosts can render the no-op honestly.
 
@@ -3495,7 +3502,8 @@ sources), `abstractruntime.automation_queries` (listing), `abstractruntime.sessi
 - **Automations are quiet.** An occurrence asks for attention only when its output says `notify`, when it still
   fails after its last retry, or while it waits on a person.
 - **Creating an automation is consent for its tools.** With the default `tool_approval: "auto"` an occurrence's tools
-  run without asking; set `"ask"` to approve them one batch at a time.
+  run without asking, except messages to anyone but the registered user (those wait for approval); set `"ask"` to
+  approve every batch.
 - **Everything is recorded.** Every admission, dispatch, retry, completion and command is an `automation.*` record in
   the controller's ledger. A crash at any point never loses an occurrence and never starts one twice.
 
@@ -3882,6 +3890,15 @@ returns the refusal message for a tool, or `None` when it is allowed.
   - A name outside the run's tool ceiling (`allowed_tools`) grants nothing: approval never widens the ceiling.
   - A tool outside `TOOL_EFFECT_CLASSES` (a third-party MCP tool, for example) is not in the grant and still asks.
   - A `tool_policy` that the target's own `input_data._runtime` already carries is left as it is.
+  - **Tools that message model-chosen recipients are never granted** (framework backlog 0992 WP0): every tool
+    whose inventory row carries `comms_send` (`send_email`, `send_whatsapp_message`, `send_telegram_message`,
+    `send_telegram_artifact`), even when `allowed_tools` names it. They are listed in the grant's
+    `withheld_tools` and go through the normal approval point: a `send_email` whose every recipient is the
+    registered user's address (`_runtime.operator_email`, set by the host; the gateway freezes it into the
+    target's inputs) runs; any other recipient parks the occurrence on a `tool_approval` wait, as under `"ask"`,
+    until a person approves or refuses it. An occurrence that reads untrusted text (an inbound email, a fetched
+    page) therefore cannot mail data to an address that text names. When the inventory cannot be read, every
+    `comms` tool is withheld.
 - **`"ask"`.** No grant. A tool call that needs approval waits on a `tool_approval` wait, as in a chat.
 
 The grant is frozen with the rest of the occurrence's inputs: a revision of `tool_approval` applies from the next
@@ -5266,7 +5283,7 @@ The canonical dependency list lives in `pyproject.toml`.
 - **AbstractMemory** (`>=0.3.0`) — TripleStore models and store contract used by Runtime's `MEMORY_KG_*` effects. Durable/vector backend dependencies such as LanceDB remain selected by hosts.
 
 ## Runtime integrations
-- **abstractcore** (`abstractcore>=2.19.0`) — LLM, tools, media, and capability integration used by the base `abstractruntime` install (AbstractCore's light install); the `apple` and `gpu` extras select `abstractcore[apple]` / `abstractcore[gpu]` at the same floor (declared in `pyproject.toml`, implementation under `src/abstractruntime/integrations/abstractcore/*`, docs: `docs/integrations/abstractcore.md`).
+- **abstractcore** (`abstractcore>=2.19.2`) — LLM, tools, media, and capability integration used by the base `abstractruntime` install (AbstractCore's light install); the `apple` and `gpu` extras select `abstractcore[apple]` / `abstractcore[gpu]` at the same floor (declared in `pyproject.toml`, implementation under `src/abstractruntime/integrations/abstractcore/*`, docs: `docs/integrations/abstractcore.md`).
   - The AbstractCore integration uses **httpx** for remote mode (`src/abstractruntime/integrations/abstractcore/llm_client.py`) and **pydantic** for structured validation (`src/abstractruntime/integrations/abstractcore/effect_handlers.py`). These are provided by AbstractCore’s dependency set.
   - The `tools` extra of AbstractCore backs the base Runtime toolset and the `abstractruntime-mcp-worker` entry point.
 - **RestrictedPython** (`>=7.0`, core install) — sandbox for VisualFlow “Code” nodes and pin expressions (`src/abstractruntime/visualflow_compiler/visual/code_executor.py`).

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/llms.txt

@@ -3,10 +3,10 @@
 > Durable workflow runtime (interrupt → checkpoint → resume) with an append-only execution ledger.
 
 - Python: 3.10+ (see `pyproject.toml`)
-- Version: 0.7.2
+- Version: 0.7.3
 - Ecosystem: [AbstractFramework](https://github.com/lpalbou/AbstractFramework) umbrella, integrates with [AbstractCore](https://github.com/lpalbou/abstractcore)
 - Hard invariant: `RunState.vars` must be JSON-serializable (`src/abstractruntime/core/models.py`)
-- Current AbstractCore baseline: base `abstractruntime` requires AbstractCore 2.19.0 or newer with its light install (remote providers, tools and the MCP worker, media routing); `abstractruntime[apple]` and `abstractruntime[gpu]` require AbstractCore's `apple` and `gpu` settings (`pyproject.toml`)
+- Current AbstractCore baseline: base `abstractruntime` requires AbstractCore 2.19.2 or newer with its light install (remote providers, tools and the MCP worker, media routing); `abstractruntime[apple]` and `abstractruntime[gpu]` require AbstractCore's `apple` and `gpu` settings (`pyproject.toml`)
 - Install profiles: base `abstractruntime` is remote-light with MCP, generated media routing, and Runtime-owned permissive PDF read/write nodes; `abstractruntime[apple]` and `abstractruntime[gpu]` add local inferencer stacks.
 - Config boundary: Runtime does not read `ABSTRACTGATEWAY_*`; Gateway-owned config should be translated into explicit Runtime inputs or Runtime-owned env names. Hosts can attach `resolve_provider_endpoint_profile(provider_id)` to the LLM client; Runtime treats it as an optional resolver hook, injects transient provider/base URL/key params for the call, and redacts secret-like params from persisted observability.
 

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "AbstractRuntime"
-version = "0.7.2"
+version = "0.7.3"
 description = "AbstractRuntime: a durable graph runner designed to pair with AbstractCore."
 readme = "README.md"
 requires-python = ">=3.10"
@@ -50,8 +50,10 @@ dependencies = [
   # Runtime's base install is the remote-light workflow host: LLM/tool effects,
   # MCP worker support, and multimodal routing come with AbstractCore's light
   # install (remote providers, built-in tools, media inputs, voice/vision/music
-  # plugins) without selecting local inference engines.
-  "abstractcore>=2.19.0",
+  # plugins) without selecting local inference engines. 2.19.2 floors
+  # abstractvision>=0.3.33, whose resident loads report `loaded_new` and whose
+  # unload frees the pipeline (the resident media path relies on both).
+  "abstractcore>=2.19.2",
   "openai<3.0.0,>=1.109.1",
   "httpx<1.0.0,>=0.28.1",
   "anyio<5.0.0,>=4.12.1",
@@ -68,12 +70,12 @@ dependencies = [
 
 [project.optional-dependencies]
 apple = [
-  "abstractcore[apple]>=2.19.0",
+  "abstractcore[apple]>=2.19.2",
   "setuptools<82.0.0,>=80.10.2",
 ]
 
 gpu = [
-  "abstractcore[gpu]>=2.19.0",
+  "abstractcore[gpu]>=2.19.2",
   # vLLM 0.9-0.19 caps setuptools below 80; 77.0.3 is still a modern floor.
   "setuptools<82.0.0,>=77.0.3",
 ]

abstractruntime-0.7.3/release-notes.md

@@ -0,0 +1,33 @@
+### Security
+
+- **An automation's tool grant no longer pre-approves sending messages** (framework backlog 0992
+  WP0). With the default `policy.tool_approval: "auto"`, the grant listed every tool the runtime
+  classifies, `send_email` included, and an explicit name in the grant overrides the
+  `model_controlled_destination` belt: an occurrence that read an inbound email or a web page could
+  mail data to any address that text named. The grant now withholds every tool whose inventory row
+  carries `comms_send` (`send_email`, `send_whatsapp_message`, `send_telegram_message`,
+  `send_telegram_artifact`), even when the target's `allowed_tools` names it, and lists them in
+  `tool_policy.withheld_tools`. Their calls take the normal approval point: a `send_email` whose
+  every recipient is the registered user's address (`_runtime.operator_email`) still runs
+  unattended; any other recipient parks the occurrence on a `tool_approval` wait until a person
+  approves or refuses it (the behaviour of `"ask"`). Recipients named in an automation's definition
+  are not auto-approved yet; that allowlist is part of backlog 0992.
+
+### Fixed
+
+- **A resident image/video model serves generation.** After `load_model_residency(task="image_generation")`
+  (the Gateway's `POST /models/load`, the console Load button, a flow's model residency node), a local
+  image or video request whose every media output names a resident model runs in-process on the loaded
+  pipeline (`execution_mode="resident_in_process"`, `resident_load_ids`) instead of loading the model
+  again in a one-shot subprocess. Measured through AbstractGateway with FLUX.2 [klein] 4B on a 16 GB
+  NVIDIA card: 17-19 s per image on the resident pipeline against 54-59 s with a reload per request, and
+  no second copy of the weights on the GPU. Pooled clients of `create_local_runtime(...)` use their pool's residency core. Models that
+  were not explicitly loaded keep the isolated subprocess (crash isolation for native Metal/CUDA
+  failures), so the explicit load is the opt-in.
+
+### Changed
+
+- **Requires AbstractCore 2.19.2 or newer** (`abstractcore`, `abstractcore[apple]`, `abstractcore[gpu]`).
+  It brings AbstractVision 0.3.33, whose loads report `loaded_new` (a fresh image-model load reads as
+  `loaded`, not `already_loaded`) and whose unload frees the model's memory, which the resident path
+  above relies on.

{abstractruntime-0.7.2 → abstractruntime-0.7.3}/src/abstractruntime/automations/controller.py

@@ -193,6 +193,24 @@ def _render_prompt(input_data: Dict[str, Any], *, envelope: Dict[str, Any], inde
 AUTOMATION_GRANT_SOURCE = "automation-policy"
 
 
+def _grant_excludes(name: str) -> bool:
+    """True for a tool the automation grant never pre-approves: one that sends a message people
+    receive to recipients the MODEL chooses (the served row's `comms_send` fact: `send_email`,
+    `send_whatsapp_message`, `send_telegram_*`). Framework backlog 0992 WP0: an unattended
+    occurrence reading untrusted input (an inbound email, a fetched page) must not be able to mail
+    data to an address that input names. Decided on the row's typed facts, never on the name; an
+    unreadable inventory withholds every `comms` tool (fail closed)."""
+    try:
+        from ..integrations.abstractcore.effect_handlers import _risk_row_for_tool
+
+        row = _risk_row_for_tool(name)
+    except Exception:  # noqa: BLE001 - no facts: withhold the whole comms class
+        from ..integrations.abstractcore.tool_effects import COMMS, TOOL_EFFECT_CLASSES
+
+        return TOOL_EFFECT_CLASSES.get(name) == COMMS
+    return bool(row is not None and row.get("comms_send"))
+
+
 def grant_tool_approval(input_data: Dict[str, Any]) -> None:
     """`policy.tool_approval == "auto"`: pre-approve the target's tools for this occurrence.
 
@@ -204,6 +222,13 @@ def grant_tool_approval(input_data: Dict[str, Any]) -> None:
     outside the run's tool ceiling grants nothing. A tool_policy the target
     already carries is the target author's word and is left untouched.
     `ask_user` questions are not tool approvals and still wait for a person.
+
+    Never granted (listed in `withheld_tools`): tools that send messages to
+    model-chosen recipients (`_grant_excludes`). Their calls go through the
+    normal approval point: the per-call refiner still auto-approves a
+    `send_email` whose every recipient is the registered user's own address
+    (`_runtime.operator_email`, set by the host); any other recipient parks the
+    occurrence on a `tool_approval` wait, exactly as under `"ask"`.
     """
     from ..integrations.abstractcore.tool_effects import TOOL_EFFECT_CLASSES
 
@@ -212,10 +237,12 @@ def grant_tool_approval(input_data: Dict[str, Any]) -> None:
         return
     allowed = runtime_ns.get("allowed_tools")
     names = allowed if isinstance(allowed, list) else list(TOOL_EFFECT_CLASSES)
-    tools = sorted({n.strip() for n in names if isinstance(n, str) and n.strip()})
+    candidates = sorted({n.strip() for n in names if isinstance(n, str) and n.strip()})
+    withheld = [n for n in candidates if _grant_excludes(n)]
+    tools = [n for n in candidates if n not in withheld]
     input_data["_runtime"] = {
         **runtime_ns,
-        "tool_policy": {"auto_approve_tools": tools, "source": AUTOMATION_GRANT_SOURCE},
+        "tool_policy": {"auto_approve_tools": tools, "withheld_tools": withheld, "source": AUTOMATION_GRANT_SOURCE},
     }