AbstractRuntime 0.8.0__tar.gz → 0.8.1__tar.gz

{abstractruntime-0.8.0 → abstractruntime-0.8.1}/CHANGELOG.md

@@ -7,6 +7,42 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.8.1] - 2026-09-30
+
+Email automations never trigger themselves, speech and images work without a buildable text model,
+and a chat's mail to its owner runs without asking. Requires AbstractCore 2.20.2.
+
+### Added
+- Mail sent by an automation run (controller, occurrence, any run it starts, the send-email action)
+  is automatic mail: the run's `EmailContext` gets `automation_marker =
+  "automation:<automation id>/run:<run id>"`, so every send carries `Auto-Submitted` and
+  `X-AbstractFramework-Automation`. `automation_marker_for(vars, run_id)` is exported from
+  `abstractruntime.email.binding`. Chats and discussions send ordinary mail.
+- `email.received@1` config `auto_submitted`: `"skip"` (default) never admits a message whose
+  `Auto-Submitted` header is present and not `no`; `"admit"` lets it reach the filters. Stored
+  configs without the key behave like `"skip"`.
+- `EmailInboxFeeder(..., is_own_sent=callable)` and `PollReport.own_automatic`: the account's own
+  automatic mail (the framework marker from its own address, or a Message-ID the host recorded as
+  sent) never enters the event inbox.
+- `abstractruntime.integrations.abstractcore.run_facade.inline_run_active(run_id)`: true while the
+  run facade executes a child run in this process; host runners skip such runs.
+- `ToolApprovalPolicy.default_require_approval_tools`: the names on the require list only because
+  no list was given (the default caution list).
+
+### Changed
+- The pooled local client runs media-only requests (image, video, voice, music, transcription, no
+  tools) and streaming TTS on AbstractCore's capability host instead of building the default text
+  client: text-to-speech no longer fails when the text default cannot be built (for example an
+  MLX route on an install without MLX), and no text model is loaded for a media request.
+- Without a per-run tool policy, the `send_email_recipient@v2` refiner now also lowers a name that
+  is on the executor's default caution list (`send_email` under `ToolApprovalPolicy()`): a chat
+  run's send to its owner's own address runs without an approval wait. An explicitly passed
+  require list and a per-run policy's still win; email-triggered runs under `approval: "ask"` are
+  unchanged.
+
+### Dependencies
+- `abstractcore>=2.20.2` (also `[apple]` and `[gpu]`).
+
 ## [0.8.0] - 2026-09-30
 
 ### Added

{abstractruntime-0.8.0 → abstractruntime-0.8.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: AbstractRuntime
-Version: 0.8.0
+Version: 0.8.1
 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.20.0
+Requires-Dist: abstractcore>=2.20.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.20.0; extra == 'apple'
+Requires-Dist: abstractcore[apple]>=2.20.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.20.0; extra == 'gpu'
+Requires-Dist: abstractcore[gpu]>=2.20.2; extra == 'gpu'
 Requires-Dist: setuptools<82.0.0,>=77.0.3; extra == 'gpu'
 Provides-Extra: test
 Requires-Dist: aiosmtpd<2.0.0,>=1.4.4; extra == 'test'
@@ -55,7 +55,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.8.0 • **Python:** 3.10+
+**Version:** 0.8.1 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
@@ -83,7 +83,7 @@ Remote-light runtime:
 pip install abstractruntime
 ```
 
-The base install includes AbstractCore 2.20.0 or newer (its light install:
+The base install includes AbstractCore 2.20.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
@@ -147,7 +147,7 @@ state = rt.resume(
 assert state.status.value == "completed"
 ```
 
-## What’s included (v0.8.0)
+## What’s included (v0.8.1)
 
 Kernel (import-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)

{abstractruntime-0.8.0 → abstractruntime-0.8.1}/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.8.0 • **Python:** 3.10+
+**Version:** 0.8.1 • **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.20.0 or newer (its light install:
+The base install includes AbstractCore 2.20.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.8.0)
+## What’s included (v0.8.1)
 
 Kernel (import-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)

{abstractruntime-0.8.0 → abstractruntime-0.8.1}/docs/api.md

@@ -302,7 +302,7 @@ from Core route resolution and persisted from `LLM_CALL` results.
 
 ### AbstractCore (LLM + tools)
 
-Requires: `pip install abstractruntime` (AbstractCore 2.20.0 or newer is part of the base install).
+Requires: `pip install abstractruntime` (AbstractCore 2.20.2 or newer is part of the base install).
 
 Implementation: `src/abstractruntime/integrations/abstractcore/*`.
 
@@ -312,7 +312,7 @@ Entry points:
 - public host facade: `AbstractCoreHostFacade`, `get_abstractcore_host_facade(...)` (`src/abstractruntime/integrations/abstractcore/host_facade.py`)
 - email facade: `email_facade` (AbstractCore's mail library for hosts; see [Email](#email))
 - public Telegram host wrappers: `TelegramTdlibNotAvailable`, `bootstrap_telegram_auth_from_env(...)`, `get_global_telegram_client(...)`, `stop_global_telegram_client()`, `send_telegram_message(...)` (`src/abstractruntime/integrations/abstractcore/telegram_facade.py`)
-- public durable run facade: `AbstractCoreRunFacade`, `get_abstractcore_run_facade(...)` (`src/abstractruntime/integrations/abstractcore/run_facade.py`)
+- public durable run facade: `AbstractCoreRunFacade`, `get_abstractcore_run_facade(...)` (`src/abstractruntime/integrations/abstractcore/run_facade.py`); `inline_run_active(run_id)` is true while the facade executes a child run in this process (its workflow exists only inside that call), so a host runner that scans `RUNNING` runs skips it
 - effect handler wiring: `build_effect_handlers(...)` (`src/abstractruntime/integrations/abstractcore/effect_handlers.py`)
 - tool executors: `MappingToolExecutor`, `AbstractCoreToolExecutor`, `PassthroughToolExecutor`, `ApprovalToolExecutor`, `ToolApprovalPolicy` (`src/abstractruntime/integrations/abstractcore/tool_executor.py`)
 - discovery-facade delegation is implemented by the configured AbstractCore LLM clients in `src/abstractruntime/integrations/abstractcore/llm_client.py` (`list_providers`, `list_provider_models`, `get_voice_catalog`, `list_tts_models`, `list_stt_models`, `list_music_providers`, `list_music_models`, `list_vision_provider_models`, `list_cached_vision_models`, `list_vision_adapters`)
@@ -348,6 +348,7 @@ Multimodal support:
 - remote and hybrid clients support AbstractCore Server chat media content arrays plus image generation, image edits, image upscaling, text-to-video, image-to-video, speech, music generation, and transcription endpoints; pass an output-specific `model` for remote media provider routing, otherwise the server endpoint can use its configured capability default
 - 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
+- with the pooled local client (`MultiLocalAbstractCoreLLMClient`), a request whose outputs are all non-text (image, video, voice, music, transcription) and that carries no tools never builds the text client: it runs on AbstractCore's capability host (`CapabilityHostProvider`, no text model), and so does streaming TTS. A text default that cannot be built (an engine not installed) therefore never blocks speech or image generation
 - media-only normalized results expose `runtime_provider` / `runtime_model` separately from `media_provider` / `media_model`
 - 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"`

{abstractruntime-0.8.0 → abstractruntime-0.8.1}/docs/architecture.md

@@ -1,7 +1,7 @@
 # AbstractRuntime — Architecture
 
 > Updated: 2026-09-29
-> Version: 0.8.0
+> Version: 0.8.1
 > 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.8.0 → abstractruntime-0.8.1}/docs/email.md

@@ -108,7 +108,9 @@ stored ids in `output_offloaded_artifact_ids`.
 
 Any other recipient, a `reply_email` call (its recipients come from the original message), or a call the refiner
 cannot read waits for a person on a `tool_approval` wait. The rule applies whether or not the run carries a per-run
-tool policy (`_runtime.tool_policy`); an executor's explicit `require_approval_tools` entry still wins. In a batch,
+tool policy (`_runtime.tool_policy`), including under the executor's default policy (`ToolApprovalPolicy()`, whose
+default caution list names `send_email`); a `require_approval_tools` list the host passes explicitly, or a per-run
+policy's, still wins. Email-triggered runs under `approval: "ask"` never use the refiner. In a batch,
 one `send_email` that needs a person makes every `send_email` of that batch wait.
 
 Approval is separate from the account's recipient policy (allowlist or denylist): AbstractCore's `guarded_send`
@@ -118,6 +120,15 @@ control that decides who can receive mail at all. A client that approves every t
 the approval wait for that user's own runs, never the recipient policy. See
 [tool-approval.md](tool-approval.md#per-call-refiners).
 
+## Mail sent by automations
+
+Every message a run of an automation sends (its controller, an occurrence or any run it starts, including the
+send-email action) is automatic mail: the runtime hands AbstractCore the run's account with
+`EmailContext.automation_marker = "automation:<automation id>/run:<run id>"`, so each send carries
+`Auto-Submitted: auto-generated` (`auto-replied` for a reply) and `X-AbstractFramework-Automation`. Chats and
+discussions (a person is there) send ordinary mail. The marker is decided on the run's automation attribution, which
+the runtime sets and a client cannot write (`automation_marker_for(vars, run_id)`).
+
 ## Running an automation when mail arrives
 
 ### The inbox and the watcher
@@ -155,6 +166,10 @@ if email_trigger_consumers(runtime):          # at least one email automation
   `Body (not fetched):` with the cause and fix.
 - A message that cannot be fetched on three polls in a row is recorded in `feeder.status()["unprocessable"]` with its
   code, cause and fix, and the feeder moves past it.
+- The account's own automatic mail never becomes an event, so an automation can never trigger itself: a message
+  that carries the framework marker (`X-AbstractFramework-Automation`) and comes from the account's own address, or
+  whose Message-ID the host reports as sent by the framework (`EmailInboxFeeder(..., is_own_sent=callable)`), is
+  passed before its body is fetched and counted in `report.own_automatic`.
 - A connection or sign-in failure never raises: the report and `feeder.status()` carry `{code, cause, fix,
   retryable}`, and the next poll waits 60 seconds, doubling up to 15 minutes (`poll(..., force=True)` polls at once).
   No automation is paused.
@@ -174,6 +189,7 @@ trigger = {
         "every": "1h",               # batch interval, at least "60s"
         "folder": "INBOX",
         "max_batch": 100,
+        "auto_submitted": "skip",    # default; "admit" runs on automatic mail too
         "filter": {"from_domain_in": ["example.test"], "subject_contains": "invoice"},
     },
 }
@@ -182,6 +198,9 @@ trigger = {
 - **Filters** are typed: `from_in` (addresses), `from_domain_in` (exact domains; list a subdomain to match it),
   `to_in` (any To or Cc address), `subject_contains` (one literal, case-insensitive substring) and `has_attachment`.
   There are no patterns or expressions.
+- **Automatic mail** (RFC 3834): with `auto_submitted: "skip"` (the default) a message whose `Auto-Submitted` header
+  is present and not `no` (auto-responders, notifications, other automations) is never admitted; `"admit"` lets it
+  reach the filters. The account's own automatic mail is kept out of the inbox whatever this option says.
 - **Batches**: the automation runs at most once per `every`, with every matching message received since its previous
   run (up to `max_batch`; the rest go to the next run). An automation that runs a model defaults to once an hour; one
   that needs no model defaults to every minute.

{abstractruntime-0.8.0 → abstractruntime-0.8.1}/docs/getting-started.md

@@ -12,7 +12,7 @@ Remote-light runtime:
 pip install abstractruntime
 ```
 
-This installs AbstractCore 2.20.0 or newer with remote provider, vision,
+This installs AbstractCore 2.20.2 or newer with remote provider, vision,
 voice, audio, music, tool, and MCP-worker support. The base install is
 remote-light: it can route multimodal workflows to hosted or OpenAI-compatible
 endpoints, but it does not select local inferencer stacks such as MLX, vLLM,

{abstractruntime-0.8.0 → abstractruntime-0.8.1}/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.20.0`.
+- The current AbstractCore integration expects `abstractcore>=2.20.2`.
 
 Verify:
 

{abstractruntime-0.8.0 → abstractruntime-0.8.1}/llms-full.txt

@@ -53,7 +53,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.8.0 • **Python:** 3.10+
+**Version:** 0.8.1 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
@@ -81,7 +81,7 @@ Remote-light runtime:
 pip install abstractruntime
 ```
 
-The base install includes AbstractCore 2.20.0 or newer (its light install:
+The base install includes AbstractCore 2.20.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
@@ -145,7 +145,7 @@ state = rt.resume(
 assert state.status.value == "completed"
 ```
 
-## What’s included (v0.8.0)
+## What’s included (v0.8.1)
 
 Kernel (import-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)
@@ -287,7 +287,7 @@ Remote-light runtime:
 pip install abstractruntime
 ```
 
-This installs AbstractCore 2.20.0 or newer with remote provider, vision,
+This installs AbstractCore 2.20.2 or newer with remote provider, vision,
 voice, audio, music, tool, and MCP-worker support. The base install is
 remote-light: it can route multimodal workflows to hosted or OpenAI-compatible
 endpoints, but it does not select local inferencer stacks such as MLX, vLLM,
@@ -432,7 +432,7 @@ rt = create_local_runtime(provider="ollama", model="qwen3:4b")
 # AbstractRuntime — Architecture
 
 > Updated: 2026-09-29
-> Version: 0.8.0
+> Version: 0.8.1
 > 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.
@@ -1167,7 +1167,7 @@ from Core route resolution and persisted from `LLM_CALL` results.
 
 ### AbstractCore (LLM + tools)
 
-Requires: `pip install abstractruntime` (AbstractCore 2.20.0 or newer is part of the base install).
+Requires: `pip install abstractruntime` (AbstractCore 2.20.2 or newer is part of the base install).
 
 Implementation: `src/abstractruntime/integrations/abstractcore/*`.
 
@@ -1177,7 +1177,7 @@ Entry points:
 - public host facade: `AbstractCoreHostFacade`, `get_abstractcore_host_facade(...)` (`src/abstractruntime/integrations/abstractcore/host_facade.py`)
 - email facade: `email_facade` (AbstractCore's mail library for hosts; see [Email](#email))
 - public Telegram host wrappers: `TelegramTdlibNotAvailable`, `bootstrap_telegram_auth_from_env(...)`, `get_global_telegram_client(...)`, `stop_global_telegram_client()`, `send_telegram_message(...)` (`src/abstractruntime/integrations/abstractcore/telegram_facade.py`)
-- public durable run facade: `AbstractCoreRunFacade`, `get_abstractcore_run_facade(...)` (`src/abstractruntime/integrations/abstractcore/run_facade.py`)
+- public durable run facade: `AbstractCoreRunFacade`, `get_abstractcore_run_facade(...)` (`src/abstractruntime/integrations/abstractcore/run_facade.py`); `inline_run_active(run_id)` is true while the facade executes a child run in this process (its workflow exists only inside that call), so a host runner that scans `RUNNING` runs skips it
 - effect handler wiring: `build_effect_handlers(...)` (`src/abstractruntime/integrations/abstractcore/effect_handlers.py`)
 - tool executors: `MappingToolExecutor`, `AbstractCoreToolExecutor`, `PassthroughToolExecutor`, `ApprovalToolExecutor`, `ToolApprovalPolicy` (`src/abstractruntime/integrations/abstractcore/tool_executor.py`)
 - discovery-facade delegation is implemented by the configured AbstractCore LLM clients in `src/abstractruntime/integrations/abstractcore/llm_client.py` (`list_providers`, `list_provider_models`, `get_voice_catalog`, `list_tts_models`, `list_stt_models`, `list_music_providers`, `list_music_models`, `list_vision_provider_models`, `list_cached_vision_models`, `list_vision_adapters`)
@@ -1213,6 +1213,7 @@ Multimodal support:
 - remote and hybrid clients support AbstractCore Server chat media content arrays plus image generation, image edits, image upscaling, text-to-video, image-to-video, speech, music generation, and transcription endpoints; pass an output-specific `model` for remote media provider routing, otherwise the server endpoint can use its configured capability default
 - 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
+- with the pooled local client (`MultiLocalAbstractCoreLLMClient`), a request whose outputs are all non-text (image, video, voice, music, transcription) and that carries no tools never builds the text client: it runs on AbstractCore's capability host (`CapabilityHostProvider`, no text model), and so does streaming TTS. A text default that cannot be built (an engine not installed) therefore never blocks speech or image generation
 - media-only normalized results expose `runtime_provider` / `runtime_model` separately from `media_provider` / `media_model`
 - 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"`
@@ -1678,7 +1679,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.20.0`.
+- The current AbstractCore integration expects `abstractcore>=2.20.2`.
 
 Verify:
 
@@ -4566,7 +4567,9 @@ stored ids in `output_offloaded_artifact_ids`.
 
 Any other recipient, a `reply_email` call (its recipients come from the original message), or a call the refiner
 cannot read waits for a person on a `tool_approval` wait. The rule applies whether or not the run carries a per-run
-tool policy (`_runtime.tool_policy`); an executor's explicit `require_approval_tools` entry still wins. In a batch,
+tool policy (`_runtime.tool_policy`), including under the executor's default policy (`ToolApprovalPolicy()`, whose
+default caution list names `send_email`); a `require_approval_tools` list the host passes explicitly, or a per-run
+policy's, still wins. Email-triggered runs under `approval: "ask"` never use the refiner. In a batch,
 one `send_email` that needs a person makes every `send_email` of that batch wait.
 
 Approval is separate from the account's recipient policy (allowlist or denylist): AbstractCore's `guarded_send`
@@ -4576,6 +4579,15 @@ control that decides who can receive mail at all. A client that approves every t
 the approval wait for that user's own runs, never the recipient policy. See
 [tool-approval.md](tool-approval.md#per-call-refiners).
 
+## Mail sent by automations
+
+Every message a run of an automation sends (its controller, an occurrence or any run it starts, including the
+send-email action) is automatic mail: the runtime hands AbstractCore the run's account with
+`EmailContext.automation_marker = "automation:<automation id>/run:<run id>"`, so each send carries
+`Auto-Submitted: auto-generated` (`auto-replied` for a reply) and `X-AbstractFramework-Automation`. Chats and
+discussions (a person is there) send ordinary mail. The marker is decided on the run's automation attribution, which
+the runtime sets and a client cannot write (`automation_marker_for(vars, run_id)`).
+
 ## Running an automation when mail arrives
 
 ### The inbox and the watcher
@@ -4613,6 +4625,10 @@ if email_trigger_consumers(runtime):          # at least one email automation
   `Body (not fetched):` with the cause and fix.
 - A message that cannot be fetched on three polls in a row is recorded in `feeder.status()["unprocessable"]` with its
   code, cause and fix, and the feeder moves past it.
+- The account's own automatic mail never becomes an event, so an automation can never trigger itself: a message
+  that carries the framework marker (`X-AbstractFramework-Automation`) and comes from the account's own address, or
+  whose Message-ID the host reports as sent by the framework (`EmailInboxFeeder(..., is_own_sent=callable)`), is
+  passed before its body is fetched and counted in `report.own_automatic`.
 - A connection or sign-in failure never raises: the report and `feeder.status()` carry `{code, cause, fix,
   retryable}`, and the next poll waits 60 seconds, doubling up to 15 minutes (`poll(..., force=True)` polls at once).
   No automation is paused.
@@ -4632,6 +4648,7 @@ trigger = {
         "every": "1h",               # batch interval, at least "60s"
         "folder": "INBOX",
         "max_batch": 100,
+        "auto_submitted": "skip",    # default; "admit" runs on automatic mail too
         "filter": {"from_domain_in": ["example.test"], "subject_contains": "invoice"},
     },
 }
@@ -4640,6 +4657,9 @@ trigger = {
 - **Filters** are typed: `from_in` (addresses), `from_domain_in` (exact domains; list a subdomain to match it),
   `to_in` (any To or Cc address), `subject_contains` (one literal, case-insensitive substring) and `has_attachment`.
   There are no patterns or expressions.
+- **Automatic mail** (RFC 3834): with `auto_submitted: "skip"` (the default) a message whose `Auto-Submitted` header
+  is present and not `no` (auto-responders, notifications, other automations) is never admitted; `"admit"` lets it
+  reach the filters. The account's own automatic mail is kept out of the inbox whatever this option says.
 - **Batches**: the automation runs at most once per `every`, with every matching message received since its previous
   run (up to `max_batch`; the rest go to the next run). An automation that runs a model defaults to once an hour; one
   that needs no model defaults to every minute.

{abstractruntime-0.8.0 → abstractruntime-0.8.1}/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.8.0
+- Version: 0.8.1
 - 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.20.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.20.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.8.0 → abstractruntime-0.8.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "AbstractRuntime"
-version = "0.8.0"
+version = "0.8.1"
 description = "AbstractRuntime: a durable graph runner designed to pair with AbstractCore."
 readme = "README.md"
 requires-python = ">=3.10"
@@ -53,7 +53,7 @@ dependencies = [
   # 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.20.0",
+  "abstractcore>=2.20.2",
   "openai<3.0.0,>=1.109.1",
   "httpx<1.0.0,>=0.28.1",
   "anyio<5.0.0,>=4.12.1",
@@ -70,12 +70,12 @@ dependencies = [
 
 [project.optional-dependencies]
 apple = [
-  "abstractcore[apple]>=2.20.0",
+  "abstractcore[apple]>=2.20.2",
   "setuptools<82.0.0,>=80.10.2",
 ]
 
 gpu = [
-  "abstractcore[gpu]>=2.20.0",
+  "abstractcore[gpu]>=2.20.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.8.1/release-notes.md

@@ -0,0 +1,33 @@
+Email automations never trigger themselves, speech and images work without a buildable text model,
+and a chat's mail to its owner runs without asking. Requires AbstractCore 2.20.2.
+
+### Added
+- Mail sent by an automation run (controller, occurrence, any run it starts, the send-email action)
+  is automatic mail: the run's `EmailContext` gets `automation_marker =
+  "automation:<automation id>/run:<run id>"`, so every send carries `Auto-Submitted` and
+  `X-AbstractFramework-Automation`. `automation_marker_for(vars, run_id)` is exported from
+  `abstractruntime.email.binding`. Chats and discussions send ordinary mail.
+- `email.received@1` config `auto_submitted`: `"skip"` (default) never admits a message whose
+  `Auto-Submitted` header is present and not `no`; `"admit"` lets it reach the filters. Stored
+  configs without the key behave like `"skip"`.
+- `EmailInboxFeeder(..., is_own_sent=callable)` and `PollReport.own_automatic`: the account's own
+  automatic mail (the framework marker from its own address, or a Message-ID the host recorded as
+  sent) never enters the event inbox.
+- `abstractruntime.integrations.abstractcore.run_facade.inline_run_active(run_id)`: true while the
+  run facade executes a child run in this process; host runners skip such runs.
+- `ToolApprovalPolicy.default_require_approval_tools`: the names on the require list only because
+  no list was given (the default caution list).
+
+### Changed
+- The pooled local client runs media-only requests (image, video, voice, music, transcription, no
+  tools) and streaming TTS on AbstractCore's capability host instead of building the default text
+  client: text-to-speech no longer fails when the text default cannot be built (for example an
+  MLX route on an install without MLX), and no text model is loaded for a media request.
+- Without a per-run tool policy, the `send_email_recipient@v2` refiner now also lowers a name that
+  is on the executor's default caution list (`send_email` under `ToolApprovalPolicy()`): a chat
+  run's send to its owner's own address runs without an approval wait. An explicitly passed
+  require list and a per-run policy's still win; email-triggered runs under `approval: "ask"` are
+  unchanged.
+
+### Dependencies
+- `abstractcore>=2.20.2` (also `[apple]` and `[gpu]`).

{abstractruntime-0.8.0 → abstractruntime-0.8.1}/src/abstractruntime/email/binding.py

@@ -129,11 +129,59 @@ def bind_email_account(
 
 Resolver = Callable[[EmailBinding], Any]
 
-# (resolver of the executing run's Runtime, the run's binding, the use). Unset outside a tool batch.
-_SCOPE: "ContextVar[Optional[Tuple[Optional[Resolver], Optional[EmailBinding], str]]]" = ContextVar(
+# (resolver of the executing run's Runtime, the run's binding, the use, the automation marker).
+# Unset outside a tool batch.
+_SCOPE: "ContextVar[Optional[Tuple[Optional[Resolver], Optional[EmailBinding], str, str]]]" = ContextVar(
     "abstractruntime_email_scope", default=None
 )
 
+AUTOMATION_MARKER_MAX = 200
+
+
+def automation_marker_for(vars_obj: Any, run_id: Any = None) -> str:
+    """The framework marker for mail a run sends automatically, or "" for a person's run.
+
+    A run of an automation (its controller, an occurrence or any descendant of one, decided on
+    the runtime-set attribution in `_meta`, which a client cannot write) sends automatically:
+    `automation:<automation id>/run:<run id>`; a legacy scheduled run: `schedule:<run id>`.
+    Chats and discussions (a person is there) get "" and their mail is sent unmarked.
+    AbstractCore stamps the marker and RFC 3834 `Auto-Submitted` on every message sent through
+    the run's `EmailContext`, and the mail watcher never admits them back (no self-trigger).
+    """
+    from ..core.run_attribution import automation_index_fields
+
+    rid = str(run_id or "").strip()
+    fields = automation_index_fields(vars_obj, run_id=rid or None)
+    role = fields.get("role")
+    if role in ("controller", "occurrence", "descendant"):
+        aid = str(fields.get("automation_id") or "").strip()
+        marker = f"automation:{aid}/run:{rid}" if rid else f"automation:{aid}"
+    elif role == "legacy_schedule":
+        marker = f"schedule:{rid}"
+    else:
+        return ""
+    if len(marker) > AUTOMATION_MARKER_MAX or any(not (32 <= ord(c) < 127) for c in marker):
+        return "automation"
+    return marker
+
+
+def _with_marker(ctx: Any, marker: str) -> Any:
+    """`ctx` carrying `automation_marker` (a copy; the host's object is never changed)."""
+    if not marker or ctx is None:
+        return ctx
+    import dataclasses
+
+    if not dataclasses.is_dataclass(ctx) or "automation_marker" not in {f.name for f in dataclasses.fields(ctx)}:
+        # An AbstractCore without the marker field would send automatic mail unmarked and the
+        # watcher would admit it again: refuse loudly instead of looping silently.
+        raise RuntimeError(
+            "This AbstractCore cannot mark automatic mail (EmailContext.automation_marker is missing); "
+            "upgrade abstractcore to 2.20.2 or later."
+        )
+    if getattr(ctx, "automation_marker", ""):
+        return ctx
+    return dataclasses.replace(ctx, automation_marker=marker)
+
 
 def resolver_accepts_use(resolver: Any) -> bool:
     """True when `resolver` takes a `use` keyword (or `**kwargs`); decided on its signature."""
@@ -175,7 +223,7 @@ def resolve_scoped_context() -> Any:
     scope = _SCOPE.get()
     if scope is None:
         return None
-    resolver, binding, use = scope
+    resolver, binding, use, marker = scope
     if resolver is None or binding is None:
         return None
     from abstractcore.comms.email import EmailError, EmailSecretUnavailable
@@ -189,7 +237,7 @@ def resolve_scoped_context() -> Any:
             "The email account of this run could not be loaded.",
             "Open Settings -> Email and Test the account; connect it again if the test fails.",
         ) from None
-    return ctx
+    return _with_marker(ctx, marker)
 
 
 def install_core_resolver() -> None:
@@ -242,7 +290,8 @@ def email_run_scope(run: Any, *, resolver: Optional[Resolver] = None, use: Optio
     if use not in EMAIL_USES:
         raise ValueError(f"use must be one of {EMAIL_USES}, got {use!r}")
     vars_obj = getattr(run, "vars", None)
-    token = _SCOPE.set((resolver if callable(resolver) else None, binding_of(vars_obj), use))
+    marker = automation_marker_for(vars_obj, getattr(run, "run_id", None))
+    token = _SCOPE.set((resolver if callable(resolver) else None, binding_of(vars_obj), use, marker))
     try:
         yield
     finally:
@@ -270,6 +319,7 @@ __all__ = [
     "EMAIL_USE_ACTION",
     "EMAIL_USE_AGENT_TOOL",
     "EmailBinding",
+    "automation_marker_for",
     "bind_email_account",
     "binding_of",
     "core_resolver_installed",