AbstractRuntime 0.8.0__tar.gz → 0.8.2__tar.gz

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

@@ -7,6 +7,56 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.8.2] - 2026-10-01
+
+Pausing an automation also stops its retries. Requires AbstractCore 2.20.2 (unchanged).
+
+### Changed
+- `automation.pause` also stops retries: an occurrence waiting in retry backoff is cancelled
+  (quietly, like `stop_current`), and a scheduled attempt that fails while the automation is paused
+  completes `failed` without a retry. An attempt already running still finishes, and a manual run
+  (`run_now`, allowed while paused) keeps its retries.
+
+### Notes
+- A retry that is waiting in backoff when you pause an automation is cancelled instead of starting
+  after its backoff. Resume the automation, or use `run_now`, to run it again.
+
+## [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.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: AbstractRuntime
-Version: 0.8.0
+Version: 0.8.2
 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.2 • **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.2)
 
 Kernel (import-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)

{abstractruntime-0.8.0 → abstractruntime-0.8.2}/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.2 • **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.2)
 
 Kernel (import-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)

{abstractruntime-0.8.0 → abstractruntime-0.8.2}/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.2}/docs/architecture.md

@@ -1,7 +1,7 @@
 # AbstractRuntime — Architecture
 
-> Updated: 2026-09-29
-> Version: 0.8.0
+> Updated: 2026-10-01
+> Version: 0.8.2
 > 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.2}/docs/automations.md

@@ -286,7 +286,7 @@ expected_revision=None, now=None)` is the only way to change an automation. It r
 
 | Type | Effect | Rejected with |
 |---|---|---|
-| `automation.pause` | Stops **scheduled** admissions. The current occurrence and its retries finish, and `run_now` still works. This is separate from the runtime's own pause. | `invalid_state` when archived or finished |
+| `automation.pause` | Stops **scheduled** admissions. An attempt already running finishes, but no retry follows: an occurrence waiting in retry backoff is cancelled (quietly), and a scheduled attempt that fails while paused completes `failed` without a retry. `run_now` still works (a manual run keeps its retries). This is separate from the runtime's own pause. | `invalid_state` when archived or finished |
 | `automation.resume` | Re-arms the schedule at the first tick after now. It never fires on resume and never catches up the paused time. Resuming an automation that is not paused is an applied no-op. | `invalid_state` when archived or finished |
 | `automation.run_now` | Runs one occurrence at the controller's next step, even while paused (the automation stays paused). There is no queue. | `automation_busy` while an occurrence or a manual run is pending; `invalid_state` when archived, finished or exhausted |
 | `automation.revise` | `payload.changes = {title?, target?, trigger?, context?, policy?}` (at least one). `title`, `target`, `trigger` and `context` are replaced whole; `policy` fields are merged, so a field you do not send keeps its value. The next revision applies from the controller's next step. A changed trigger gets a new binding and is re-armed after now, so no past tick fires; an unchanged trigger keeps its binding. | `invalid_state` when archived or finished; the definition's own reason codes for invalid changes |

{abstractruntime-0.8.0 → abstractruntime-0.8.2}/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.2}/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.2}/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.2}/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.2 • **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.2)
 
 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,
@@ -431,8 +431,8 @@ rt = create_local_runtime(provider="ollama", model="qwen3:4b")
 
 # AbstractRuntime — Architecture
 
-> Updated: 2026-09-29
-> Version: 0.8.0
+> Updated: 2026-10-01
+> Version: 0.8.2
 > 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:
 
@@ -3806,7 +3807,7 @@ expected_revision=None, now=None)` is the only way to change an automation. It r
 
 | Type | Effect | Rejected with |
 |---|---|---|
-| `automation.pause` | Stops **scheduled** admissions. The current occurrence and its retries finish, and `run_now` still works. This is separate from the runtime's own pause. | `invalid_state` when archived or finished |
+| `automation.pause` | Stops **scheduled** admissions. An attempt already running finishes, but no retry follows: an occurrence waiting in retry backoff is cancelled (quietly), and a scheduled attempt that fails while paused completes `failed` without a retry. `run_now` still works (a manual run keeps its retries). This is separate from the runtime's own pause. | `invalid_state` when archived or finished |
 | `automation.resume` | Re-arms the schedule at the first tick after now. It never fires on resume and never catches up the paused time. Resuming an automation that is not paused is an applied no-op. | `invalid_state` when archived or finished |
 | `automation.run_now` | Runs one occurrence at the controller's next step, even while paused (the automation stays paused). There is no queue. | `automation_busy` while an occurrence or a manual run is pending; `invalid_state` when archived, finished or exhausted |
 | `automation.revise` | `payload.changes = {title?, target?, trigger?, context?, policy?}` (at least one). `title`, `target`, `trigger` and `context` are replaced whole; `policy` fields are merged, so a field you do not send keeps its value. The next revision applies from the controller's next step. A changed trigger gets a new binding and is re-armed after now, so no past tick fires; an unchanged trigger keeps its binding. | `invalid_state` when archived or finished; the definition's own reason codes for invalid changes |
@@ -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.2}/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.2
 - 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.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "AbstractRuntime"
-version = "0.8.0"
+version = "0.8.2"
 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.2/release-notes.md

@@ -0,0 +1,11 @@
+Pausing an automation also stops its retries. Requires AbstractCore 2.20.2 (unchanged).
+
+### Changed
+- `automation.pause` also stops retries: an occurrence waiting in retry backoff is cancelled
+  (quietly, like `stop_current`), and a scheduled attempt that fails while the automation is paused
+  completes `failed` without a retry. An attempt already running still finishes, and a manual run
+  (`run_now`, allowed while paused) keeps its retries.
+
+### Notes
+- A retry that is waiting in backoff when you pause an automation is cancelled instead of starting
+  after its backoff. Resume the automation, or use `run_now`, to run it again.

{abstractruntime-0.8.0 → abstractruntime-0.8.2}/src/abstractruntime/automations/commands.py

@@ -13,8 +13,11 @@ record, controller wake, child cancellation), so a crash after the decision
 never loses them. Domain rejections are returned, never raised.
 
 Semantics:
-- pause: gates SCHEDULED admission only (never the runtime pause gate); the
-  current occurrence, including its retries, finishes; run_now stays allowed.
+- pause: gates SCHEDULED admission (never the runtime pause gate); an attempt
+  already running finishes, but no retry follows while paused: an occurrence
+  waiting in retry backoff is cancelled (quiet), and a scheduled attempt that
+  fails while paused completes `failed` without a retry. run_now stays allowed
+  (a manual occurrence started while paused keeps its retries).
 - resume: re-arms the trigger at the first tick after now; never fires.
 - run_now: records `manual_pending` (admitted at the controller's next
   boundary); rejected `automation_busy` while an occurrence or a manual run is
@@ -91,7 +94,13 @@ def _decide(
     if command_type == "automation.pause":
         if archived or terminal:
             return _reject("invalid_state", "An archived or finished automation cannot be paused.")
-        return {"delta": {"state": {"paused": True}}}
+        pause_state: Dict[str, Any] = {"paused": True}
+        pending = state.get("pending_occurrence")
+        if not state.get("paused") and isinstance(pending, dict) and pending.get("phase") == "backoff":
+            # A retry only waiting for its backoff never starts after a pause (N3): the
+            # occurrence is cancelled at the controller's next boundary, like stop_current.
+            pause_state["pending_occurrence"] = {**pending, "stop_requested": True}
+        return {"delta": {"state": pause_state}}
 
     if command_type == "automation.resume":
         if archived or terminal:

{abstractruntime-0.8.0 → abstractruntime-0.8.2}/src/abstractruntime/automations/controller.py

@@ -856,7 +856,10 @@ def record_outcome(turn: Turn) -> str:
         return "next"
     retry = pending.get("retry") or {"max_attempts": 1}
     attempt = int(pending["attempt"])
-    if attempt < int(retry["max_attempts"]):
+    # Paused: a SCHEDULED occurrence gets no further attempt (N3); a manual one (run_now,
+    # allowed while paused, `command_id` set) keeps its retries.
+    retry_blocked = bool(state.get("paused")) and pending.get("command_id") is None
+    if attempt < int(retry["max_attempts"]) and not retry_blocked:
         retry_at = add_delay(turn.now, backoff_delay({"retry": retry}, attempt))
         turn.decide(
             "automation.retry_scheduled",

{abstractruntime-0.8.0 → abstractruntime-0.8.2}/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",