AbstractRuntime 0.8.5__tar.gz → 0.9.1__tar.gz

{abstractruntime-0.8.5 → abstractruntime-0.9.1}/.github/workflows/ci.yml

@@ -69,6 +69,59 @@ jobs:
             tests/test_trigger_registry.py \
             tests/test_workspace_read_only.py
 
+  # The command sandbox end to end on Linux: run vars -> TOOL_CALLS handler ->
+  # `_sandbox` stamp -> AbstractCore's spawning tools inside bubblewrap. The
+  # end-to-end tests in tests/test_r12_workspace_sandbox.py skip with their
+  # reason on a host without an OS sandbox, so the job above proves nothing
+  # about Linux. This job installs bubblewrap, lets it create user namespaces
+  # (Ubuntu 24.04 restricts them through AppArmor by default), and FAILS unless
+  # every sandbox test ran and passed: a skip here is a red job, never a green one.
+  linux-sandbox:
+    name: Linux command sandbox (bubblewrap)
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+          cache: pip
+      - name: Install bubblewrap
+        run: |
+          sudo apt-get update
+          sudo apt-get install -y bubblewrap
+          # bwrap is not setuid on Ubuntu: it needs unprivileged user namespaces.
+          sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 || true
+          bwrap --version
+          bwrap --ro-bind / / --dev /dev --proc /proc -- /bin/true
+          uname -r
+      - name: Install
+        run: |
+          python -m pip install -U pip
+          python -m pip install -e ".[test]"
+      - name: Pytest (sandbox tests must run, not skip)
+        run: |
+          python -m pytest -rs -p no:cacheprovider \
+            tests/test_r12_workspace_sandbox.py tests/test_command_sandbox_host_facade.py \
+            --junitxml=sandbox-junit.xml
+      - name: Assert the sandbox tests ran
+        run: |
+          python - <<'PY'
+          import sys
+          import xml.etree.ElementTree as ET
+
+          cases = list(ET.parse("sandbox-junit.xml").getroot().iter("testcase"))
+          skipped = [c for c in cases if c.find("skipped") is not None]
+          failed = [c for c in cases if c.find("failure") is not None or c.find("error") is not None]
+          e2e = [c for c in cases if (c.get("name") or "").startswith("test_e2e_")]
+          e2e_passed = [c for c in e2e if c not in skipped and c not in failed]
+          passed = len(cases) - len(skipped) - len(failed)
+          print(f"sandbox tests: {len(cases)} collected, {passed} passed, {len(skipped)} skipped, {len(failed)} failed; end-to-end passed {len(e2e_passed)}/{len(e2e)}")
+          for c in skipped:
+              print("SKIPPED:", c.get("name"), "-", (c.find("skipped").get("message") or ""))
+          if len(e2e) < 7 or len(e2e_passed) != len(e2e) or skipped or failed:
+              sys.exit("The sandbox tests did not all run and pass inside bubblewrap on this Linux host.")
+          PY
+
   build:
     name: Build distributions
     runs-on: ubuntu-latest

{abstractruntime-0.8.5 → abstractruntime-0.9.1}/CHANGELOG.md

@@ -5,9 +5,46 @@ All notable changes to AbstractRuntime will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## [Unreleased]
+## [0.9.1] - 2026-10-08
 
-Nothing yet.
+### Security
+
+- `browser_probe`: a local target (path or `file://` URL) now carries the run's `_sandbox` stamp, the same scope the commands get. AbstractCore 2.25.1 serves the page from a loopback origin limited to that scope instead of `file://`, so a page cannot load refused files as subresources. Needs AbstractCore 2.25.1 (an older `browser_probe` refuses the unknown argument and runs nothing). Test: `tests/test_browser_probe_target_walling.py`.
+
+### Fixed
+
+- `stream_voice(...)` is never a wait. It used to start the child run parked on `WAIT_EVENT abstractcore.voice.tts.stream:<uuid>` for the whole stream: hosts folded that waiting record into the CALLER'S run (a Read aloud during a live turn read as "Waiting for an event"), and a host that died mid-stream left the child waiting forever. Now nothing durable exists while audio streams; when the stream ends (done, error, cancel or the consumer closing it) the child run is created already COMPLETED with the outcome. Its id is allocated up front: `runtime_start` carries it as `child_run_id` (schema `abstractruntime.tts_stream.start.v2`, no `wait_key`), as does the trace metadata. A stream cut by a crash leaves no run.
+- `AbstractCoreRunFacade.close_interrupted_voice_stream(child_run_id, *, reason)` finishes a legacy streamed-speech wait left by an older process (completed, `errors[0] = {"code": "interrupted", "message": reason}`); `is_interrupted_voice_stream_wait(waiting)` and `LEGACY_VOICE_STREAM_WAIT_KEY_PREFIX` recognise one (exported from `integrations.abstractcore`). AbstractGateway calls it at startup.
+
+### Changed
+
+- Requires AbstractCore 2.25.1 or newer (`abstractcore>=2.25.1` in the base install and the `[apple]`/`[gpu]` extras): the Linux command sandbox reaches an allowed folder inside a refused one, and `browser_probe` accepts the run's `_sandbox` stamp.
+
+## [0.9.0] - 2026-10-05
+
+### Added
+
+- `Runtime.set_occurrence_input_resolver(fn)`: a host hook called at each automation occurrence's admission, as `fn(definition, input_data) -> input_data`. Its answer is frozen into the occurrence's prepared inputs, so replays stay byte-identical; a non-dict answer fails the admission; with no resolver set nothing changes. AbstractGateway uses it to resolve the workspaces of an automation that follows its owner's default at each run, instead of a snapshot taken at save time. Test: `tests/test_automation_occurrence_input_resolver.py`.
+
+- Command sandbox: `execute_command`, `shell_exec`, `local_helper_start` and AbstractAgent's `execute_python` (0.3.18 or newer; an older one fails on the unknown argument and runs nothing) receive the run's effective workspace set as the hidden `_sandbox` argument (`sandbox_stamp(scope)`, built on every call from the same workspace vars the file tools read; `execute_python` starts in the stamp's private workspace; a model- or payload-supplied `_sandbox` is always replaced or dropped), and run inside AbstractCore's OS sandbox (`abstractcore.tools.sandbox`: macOS `sandbox-exec`, Linux `bwrap` or Landlock). `local_helper_start` and the entity exec tool apply it themselves (the entity's workspace and whitelisted mounts). With no sandbox on the host, or an AbstractCore without the sandbox module, the call is refused with one sentence before anything runs and the run continues.
+
+- `integrations.abstractcore.command_sandbox_host`: hosts configure the command sandbox through the runtime (`configure_host`, `host_policy`, `host_sandbox_kind`, `KIND_LABELS`, `KIND_NONE`, `reset_host_for_tests`; pure re-exports of `abstractcore.tools.sandbox`), so a host never imports AbstractCore directly. Used by AbstractGateway's `serve`.
+- `MappingToolExecutor` never drops the `_sandbox` stamp: a tool whose signature cannot take it (an AbstractAgent older than 0.3.18) gets a failed result naming the stamp and does not run. Its argument-name normalization never maps a model key (`sandbox`, `registry_namespace`, ...) onto a hidden `_`-prefixed parameter.
+- CI: a `linux-sandbox` job installs bubblewrap on Ubuntu and runs the command-sandbox tests end to end inside it (the end-to-end tests now run inside the host's OS sandbox: macOS `sandbox-exec` or Linux bubblewrap); the job fails when any of them is skipped.
+- `workspace_writable_paths`: writable exceptions inside read-only roots (`workspace_read_only_paths`), the more specific rule winning. The tool scope, `path_is_read_only` and VisualFlow writers honour them; child runs and file nodes inherit the parent's exactly and never add one. Used by AbstractGateway 0.13.0 for "Allow everything, refuse listed workspaces" with a read-only default.
+- `integrations.abstractcore.structured_facade` (also flat from `integrations.abstractcore`): `parse_response_format` and AbstractCore's own `ResponseFormatError`, so hosts check an OpenAI `response_format` without importing AbstractCore. Used by AbstractGateway 0.13.0's `/v1/chat/completions`.
+- Workspace context of a tool-using `LLM_CALL`: after the default working directory (the run's own workspace), `Allowed workspaces:` lists each allowed workspace outside it with its mode (`(read-only)` / `(read & write)`, from `workspace_read_only_paths` and `workspace_writable_paths`), and under `all_except_ignored` `Everything else: (…)`; refused paths are never listed as allowed. Used by AbstractGateway 0.13.0 on every run start.
+- `automation.unarchive`: an archived automation comes back paused with its history intact; a controller that ended because it was archived restarts and parks on its wake wait (observation `automation.unarchived`).
+
+### Changed
+
+- Workspace nesting: the most specific row wins. Among `workspace_root`, `workspace_allowed_paths` and `workspace_ignored_paths`, the longest real-path prefix of a path decides (a refusal wins a tie); a refused folder no longer refuses an allowed workspace inside it, and a refused folder inside an allowed one still refuses its subtree. Built-in protection stays absolute. Same rule as AbstractGateway's validation and the sandbox profile.
+- The workspace context now says "Shell commands run inside an OS sandbox limited to these workspaces." and describes refused paths as "Excluded paths (a more specific allowed workspace inside one stays reachable)".
+- Requires AbstractCore 2.25.0 or newer (`abstractcore>=2.25.0` in the base install and the `[apple]`/`[gpu]` extras): the command sandbox and `structured_facade` use it.
+
+### Removed
+
+- `workspace_shared_path` / `SHARED_WORKSPACE_KEY` / `shared_workspace_path` (added during 0.9.0 development, never released): AbstractGateway 0.13.0 has no shared workspace any more (round 11), so the workspace context names no "Shared workspace"; the allowed workspaces and their modes are listed as before. A stale key in a run's vars is ignored.
 
 ## [0.8.5] - 2026-10-03
 

{abstractruntime-0.8.5 → abstractruntime-0.9.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: AbstractRuntime
-Version: 0.8.5
+Version: 0.9.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.24.0
+Requires-Dist: abstractcore>=2.25.1
 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.24.0; extra == 'apple'
+Requires-Dist: abstractcore[apple]>=2.25.1; 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.24.0; extra == 'gpu'
+Requires-Dist: abstractcore[gpu]>=2.25.1; 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'

{abstractruntime-0.8.5 → abstractruntime-0.9.1}/docs/README.md

@@ -26,7 +26,7 @@ In this repo, the AbstractCore wiring lives under `src/abstractruntime/integrati
 - `faq.md` — common questions (recommended)
 - `manual_testing.md` — manual smoke tests and how to run the test suite
 - `artifacts.md` — Runtime artifact identity, descriptors, provenance, catalog search, and access stats
-- `integrations/abstractcore.md` — wiring `LLM_CALL` / `TOOL_CALLS`, the `config_facade` models/engines/host-jobs passthroughs for hosts, cached sessions with per-session prompt-cache listing/clearing, host memory snapshots, model-residency listings, locks and model switching, live token streaming, workspace-scoped tools, durable bloc prompt-cache control, media inputs, generated media outputs, video progress events, and tool approval waits via AbstractCore
+- `integrations/abstractcore.md` — wiring `LLM_CALL` / `TOOL_CALLS`, the `config_facade` models/engines/host-jobs passthroughs for hosts, the `structured_facade` response_format check for hosts, cached sessions with per-session prompt-cache listing/clearing, host memory snapshots, model-residency listings, locks and model switching, live token streaming, workspace-scoped tools, durable bloc prompt-cache control, media inputs, generated media outputs, video progress events, and tool approval waits via AbstractCore
 - `tools-comms.md` — enabling the optional comms toolset (email/WhatsApp/Telegram)
 - `email.md` — email for each user: run-scoped account binding and the host resolver, sending without asking (self and pre-authorised recipients), the durable event inbox and mail feeder, the `email.received@1` trigger, and the send-email action
 - `tool-approval.md` — tool risk tiers, the run-policy rank ceiling, and per-call refiners (the `send_email` recipient rule: self and pre-authorised recipients)

{abstractruntime-0.8.5 → abstractruntime-0.9.1}/docs/api.md

@@ -221,7 +221,7 @@ Deep dive: [automations.md](automations.md).
 
 ```python
 from abstractruntime.automations import (
-    apply_automation_command,   # pause / resume / run_now / revise / stop_current / archive
+    apply_automation_command,   # pause / resume / run_now / revise / stop_current / archive / unarchive
     create_automation,          # -> (automation_id, revision)
     drive_automation,           # standalone run loop
     get_automation,
@@ -262,6 +262,7 @@ from abstractruntime.email import (
 
 - `Runtime.set_email_context_resolver(fn)`: `fn(binding, *, use) -> EmailContext | None` (`use` is `"agent_tool"` or `"action"`; `fn(binding)` also accepted), per runtime, memory only
 - `Runtime.set_email_binding(binding | None)` / `Runtime.email_binding`: the account occurrences are bound to
+- `Runtime.set_occurrence_input_resolver(fn | None)` / `Runtime.occurrence_input_resolver`: `fn(definition, input_data) -> input_data`, called at each automation occurrence's admission (its run start) and frozen with the occurrence's inputs (a replayed dispatch stays identical); a non-dict answer fails the admission. The gateway re-resolves an automation's "Use my default" workspaces here. None (default): the definition's inputs as stored
 - `Runtime.set_event_inbox(inbox)` / `Runtime.event_inbox`: required by `email.received@1`
 - `EmailInboxFeeder(inbox, account_ref=...).poll(ctx, *, now=None, force=False) -> PollReport` and `.status()`
 - toolsets: `get_default_toolsets(..., email_enabled=True)` (also `list_default_tool_specs`, `build_default_tool_map`, `list_tool_catalog`); no env flag; `list_tool_catalog(email_enabled=False, email_off_reason="not_connected" | "admin_disabled" | "not_available" | "agent_tools_off")`
@@ -269,6 +270,7 @@ from abstractruntime.email import (
 - approval: the `send_email_recipient@v2` refiner ([tool-approval.md](tool-approval.md#per-call-refiners))
 - `adopt_legacy_schedule_projection(run)`: read-only summary of a legacy gateway `scheduled:*` root
 - read-only mounts: `_runtime.workspace_read_only_paths` (absolute folders; file write tools and VisualFlow writers refused inside, reads and command/code tools allowed); helpers `read_only_paths(vars)`, `path_is_read_only(vars, path)` and `READ_ONLY_PATHS_KEY` in `abstractruntime.utils.workspace_paths`
+- writable exceptions inside read-only roots: `workspace_writable_paths` (top-level or `_runtime`; absolute folders). A path is read-only when a read-only root contains it and no writable path inside that root contains it, so the more specific rule wins (a host sets `/` read-only plus the run's folder and its read & write folders for a read-only default). Child runs and VisualFlow file nodes get the parent's exceptions exactly; a child never adds one. Helpers: `writable_paths(vars)`, `is_read_only_target(path, read_only_roots, writable_roots)`, `WRITABLE_PATHS_KEY`.
 - read-only workspaces: run vars `workspace_read_only: true` (or `_runtime.workspace_read_only: true`); `abstractruntime.integrations.abstractcore.tool_effects.TOOL_EFFECT_CLASSES` classifies every exposable tool as `read`, `write`, `exec`, `delegate`, `comms` or `memory-write`
 
 ## Sessions and history
@@ -395,3 +397,7 @@ This provides handlers for `MEMORY_KG_*` effects (opt-in wiring layer).
 ### Host ASGI serving
 
 `abstractruntime.integrations.abstractcore.server_facade.serve_core_request(scope, receive, send, *, token: str, allow_unauthenticated: bool = False)` delegates host-admitted ASGI requests with request-scoped Core authentication. See [host-managed serving](integrations/abstractcore.md#host-managed-serving) for network and credential responsibilities.
+
+### Structured-output checks
+
+`abstractruntime.integrations.abstractcore.structured_facade.parse_response_format(raw) -> (kind, schema, name)` checks an OpenAI `response_format` and raises `ResponseFormatError` (AbstractCore's own class, with `.param`) for an unusable one. Both are also exported flat from `abstractruntime.integrations.abstractcore`. Requires AbstractCore 2.25.0 or newer. See [structured-output checks for hosts](integrations/abstractcore.md#structured-output-checks-for-hosts-structured-facade).

{abstractruntime-0.8.5 → abstractruntime-0.9.1}/docs/automations.md

@@ -34,7 +34,7 @@ sources), `abstractruntime.automation_queries` (listing), `abstractruntime.sessi
 ```mermaid
 flowchart LR
   Trigger["Trigger source<br/>schedule@1 / manual@1"] -->|"due tick or run now"| Controller["Controller run<br/>(automation id)<br/>vars._meta.automation<br/>vars._runtime.automation"]
-  Commands["apply_automation_command<br/>pause / resume / run_now /<br/>revise / stop_current / archive"] -->|"decision + wake"| Controller
+  Commands["apply_automation_command<br/>pause / resume / run_now /<br/>revise / stop_current / archive / unarchive"] -->|"decision + wake"| Controller
   Controller -->|"START_SUBWORKFLOW<br/>deterministic run_id"| Occurrence["Occurrence run<br/>role: occurrence<br/>(a session turn)"]
   Occurrence --> Descendants["Descendant runs<br/>role: descendant"]
   Occurrence -->|"output: answer, notify"| Controller
@@ -292,6 +292,7 @@ expected_revision=None, now=None)` is the only way to change an automation. It r
 | `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 |
 | `automation.stop_current` | Cancels the running occurrence tree, or its pending retry. The occurrence completes as `cancelled`, quietly. | `invalid_state` when nothing is running |
 | `automation.archive` | Stops further admissions; the current occurrence finishes and the controller then ends. History is kept and the automation stays listed. Archiving twice is an applied no-op. | — |
+| `automation.unarchive` | Lifts the archive mark and brings the automation back **paused** (send `automation.resume` to re-arm its trigger). A controller that ended because it was archived restarts at `read_definition` and parks on its wake wait; occurrences, ledger and history are untouched. An exhausted or failed automation only loses the archive mark and keeps its status. Unarchiving an automation that is not archived is an applied no-op. | — |
 
 Every command can also be rejected with:
 
@@ -305,7 +306,7 @@ Commands are idempotent per `command_id`. A `command_id` is tied to its whole co
 `expected_revision`). The `automation.command_result` record, keyed
 `automation:command_result:<automation_id>:<command_id>`, is the decision. Sending the same command again returns the
 recorded result with `duplicate: true` and repeats only the follow-ups that are safe to repeat: the observation
-record (`automation.paused`, `automation.resumed`, `automation.revised`, `automation.archived`), waking the
+record (`automation.paused`, `automation.resumed`, `automation.revised`, `automation.archived`, `automation.unarchived`), waking the
 controller, and cancelling the stopped child. A host that fails to carry out a command itself records the failure
 with `record_automation_command_result(...)`, passing the same `payload` and `expected_revision` so a later replay is
 recognized.

{abstractruntime-0.8.5 → abstractruntime-0.9.1}/docs/faq.md

@@ -51,7 +51,9 @@ Docs: `getting-started.md`. Code: `src/abstractruntime/core/runtime.py`, `src/ab
 Create an automation. An automation is a durable controller run that starts the target workflow as a child run (an
 occurrence) on each trigger: `schedule@1` (fixed UTC intervals such as `5m` or `24h`) or `manual@1` (run now only).
 `create_automation(...)` creates it, `apply_automation_command(...)` pauses, resumes, runs now, edits, stops the
-current occurrence or archives it, and the host drives it like any run (`drive_automation` does this in-process).
+current occurrence, archives it or unarchives it (it comes back paused with its history), and the host drives it
+like any run (`drive_automation` does this in-process). Nothing is deleted: an archived automation keeps its
+occurrences and history and stays listed with status `archived`.
 
 The `Scheduler` is different: it is a driver loop that resumes due waits of existing runs. It does not create runs.
 
@@ -97,9 +99,9 @@ Docs: `automations.md#tool-approval`, `automations.md#waits-on-a-person`.
 
 Not through its file tools. A discussion works in its own writable workspace and sees the automation's workspace as
 a read-only mount (`_runtime.workspace_read_only_paths`): file tools and VisualFlow writers that target a path inside
-the mount are refused, reads work. Commands and code (`execute_command`, `execute_python`) are allowed, because the
-shell cannot be sandboxed; a command can therefore still change files if it chooses to, so keep tool approval on for
-commands where that matters. Every later turn in the discussion session keeps the same setup, whoever starts it, and
+the mount are refused, reads work. Commands and code (`execute_command`, `shell_exec`, `local_helper_start`,
+AbstractAgent's `execute_python`) run inside an OS sandbox built from the same workspaces (macOS `sandbox-exec`, Linux
+`bwrap`/Landlock), so they cannot write into the mount either; on a host with no sandbox they are refused. Every later turn in the discussion session keeps the same setup, whoever starts it, and
 the discussion never writes back into the automation's session, state or ledger.
 
 Docs: `automations.md#discussions`, `automations.md#read-only-mounts`.

{abstractruntime-0.8.5 → abstractruntime-0.9.1}/docs/integrations/abstractcore.md

@@ -494,16 +494,19 @@ When a run sets `workspace_root` in its vars, file tools (`read_file`, `write_fi
 | --- | --- |
 | `workspace_root` | Base folder for relative paths and the shell's starting folder. Relative roots resolve against `ABSTRACT_WORKSPACE_BASE_DIR` when set. |
 | `workspace_access_mode` | `workspace_only` (default: paths stay under the root), `workspace_or_allowed` (also under `workspace_allowed_paths`), or `all_except_ignored` (anywhere except `workspace_ignored_paths`). |
-| `workspace_allowed_paths` | Extra folders a `workspace_or_allowed` run may use. |
-| `workspace_ignored_paths` | The operator's exclusions; always refused. |
+| `workspace_allowed_paths` | Additional workspaces a `workspace_or_allowed` run may use. |
+| `workspace_ignored_paths` | Refused workspaces. A more specific allowed workspace inside one stays reachable (see *Nesting* below). |
 | `workspace_builtin_deny_prefixes` | The host's own protected folders (for example a gateway's data folder and credential folders), as path prefixes. Anything under one is refused. |
 | `workspace_builtin_allow` | Exceptions inside the host's protected folders (for example the run's own folder inside the data folder). The operator's `workspace_ignored_paths` still win over them. |
+| `workspace_read_only_paths` / `workspace_writable_paths` | Read-only roots and the writable exceptions inside them (`"/"` = a read-only default). The more specific rule wins. |
 
 Lists accept a JSON array, a JSON array pasted as a string, or newline-separated entries.
 
-- When an `LLM_CALL` offers tools and the run has a workspace scope, the runtime appends a short description of the scope to the system prompt: the root, the access mode, the authorized roots and the operator's `workspace_ignored_paths`. The host's built-in deny prefixes and allow entries are enforced but never described to the model, so the system prompt stays identical from turn to turn while the host's folders change, and the prompt cache stays warm. A refused path is reported as `Path is not accessible (protected by the host)` without listing the host's rules.
-- Child runs (subworkflows and agent delegation) inherit all six vars unless they set their own; VisualFlow file and document nodes (`read_file`, `write_file`, `read_pdf`, `write_pdf`, `write_docx`, `write_chart`) apply the same scope.
-- Shell tools are pinned to their starting folder only. A command can still reach other paths (`cd ..`, absolute paths); the workspace scope is a file-tool policy, not a sandbox.
+- When an `LLM_CALL` offers tools and the run has a workspace scope, the runtime appends a short description of the scope to the system prompt: the root (the run's default working directory); each allowed workspace outside the root with its mode (`(read-only)` or `(read & write)`, from `workspace_read_only_paths` and `workspace_writable_paths`); under `all_except_ignored` the mode of everything else (`Everything else: (read-only)`); the access mode; the authorized roots and the operator's `workspace_ignored_paths`. The host's built-in deny prefixes and allow entries are enforced but never described to the model, so the system prompt stays identical from turn to turn while the host's folders change, and the prompt cache stays warm. A refused path is reported as `Path is not accessible (protected by the host)` without listing the host's rules.
+- Child runs (subworkflows and agent delegation) inherit the workspace vars unless they set their own; VisualFlow file and document nodes (`read_file`, `write_file`, `read_pdf`, `write_pdf`, `write_docx`, `write_chart`) apply the same scope.
+- **Nesting (most specific row wins).** For a path P (symlinks resolved), the candidates are `workspace_root` (read & write), `workspace_allowed_paths` (not under `workspace_only`) and `workspace_ignored_paths`. The longest candidate that contains P decides: a refused entry refuses, the root or an allowed entry allows; a tie between a refused entry and an allowed one (or the root) at the same path refuses; no candidate falls back to the access mode (`all_except_ignored` allows, the others refuse). The host's built-in protection is absolute: under a `workspace_builtin_deny_prefixes` entry and not under a `workspace_builtin_allow` entry is refused whatever the rows say. So refusing `/Users/me` and allowing `/Users/me/project` makes the project reachable and the rest of `/Users/me` refused; a refused folder inside an allowed one refuses that subtree. AbstractGateway applies the same rule when it validates and computes a run's workspaces.
+- **Command sandbox.** `execute_command`, `shell_exec` (the whole persistent session), `local_helper_start` and AbstractAgent's `execute_python` (0.3.18 or newer) start in the workspace and run inside an OS sandbox built from the SAME scope (`sandbox_stamp(scope)`, stamped on every call as the hidden `_sandbox` argument; a model- or payload-supplied value is always replaced). AbstractCore (`abstractcore.tools.sandbox`) applies it: macOS `sandbox-exec`, Linux `bwrap`, or Linux Landlock for "Deny everything, allow listed workspaces". Mapping: `all_except_ignored` → "Allow everything, refuse listed workspaces" (`any_except_denied`), otherwise "Deny everything, allow listed workspaces" (`allowed_only`); a `"/"` read-only root → read-only default; each allowed workspace with its mode; refused paths and the built-in protection as they are. The command string is never parsed — `cd ..`, absolute paths, `$(…)`, symlinks and scripts are stopped by the kernel. With no sandbox on the host, or an AbstractCore without `abstractcore.tools.sandbox`, the command is refused with one sentence and the run continues. The entity exec tool runs inside a sandbox limited to the entity's workspace and its whitelisted mounts. The tool result carries `sandbox: {kind, …}` and a `Sandbox: …` line; the stamp rides the tool call in the run's evidence. Hosts set the host policy (the scrubbed environment commands start from, and whether unsandboxed commands are allowed on a host with no sandbox) once at boot through `abstractruntime.integrations.abstractcore.command_sandbox_host` (`configure_host`, `host_policy`, `host_sandbox_kind`), never by importing AbstractCore.
+- **Browser probe.** A local `browser_probe` target (a path or a `file://` URL) is walled like `read_file`'s path and carries the same `_sandbox` stamp: AbstractCore 2.25.1 serves the page to the browser from a loopback origin that answers only for files this scope can read (never `file://`). Remote `http(s)://` targets carry no stamp.
 
 ## Prompt-cache control plane and durable blocs
 
@@ -1046,8 +1049,14 @@ Public durable entry points:
 These helpers create child runs under an existing parent run and execute the real
 `LLM_CALL`, `TOOL_CALLS`, or stream finalization through Runtime rather than
 doing external work in host/controller code. `stream_voice(...)` yields TTS
-stream events for progressive playback and completes the child run with the
-final audio artifact when the stream succeeds.
+stream events for progressive playback; it is never a wait: nothing durable
+exists while audio streams, and when the stream ends (done, error, cancel or
+the consumer closing it) the child run is created already completed with the
+outcome (the final audio artifact on success). The child's id is announced up
+front in the `runtime_start` event (`child_run_id`). A host that finds a
+streamed-speech wait left by a runtime before this behaviour
+(`is_interrupted_voice_stream_wait`) closes it with
+`close_interrupted_voice_stream(child_run_id, reason=...)`.
 
 Example:
 
@@ -1184,3 +1193,18 @@ Provide a nonempty token even for open access: absent Authorization is allowed w
 Anonymous callers cannot use server-held cloud credentials; explicit provider
 keys use `X-AbstractCore-Provider-API-Key`. This serving facade does not create
 durable Runtime runs. The AbstractCore server dependencies must be installed.
+
+## Structured-output checks for hosts (structured facade)
+
+A host that accepts an OpenAI `response_format` checks it before any model sees it with
+`abstractruntime.integrations.abstractcore.structured_facade` (also exported flat from
+`abstractruntime.integrations.abstractcore`):
+
+- `parse_response_format(raw)` returns `(kind, schema, name)`, where kind is `"text"`,
+  `"json_object"` or `"json_schema"` and schema is `None` unless kind is `"json_schema"`.
+- `ResponseFormatError` is AbstractCore's own error class, so `except ResponseFormatError`
+  catches exactly what Core raises; `.param` names the offending field
+  (`"response_format"` or a nested name such as `"response_format.type"`).
+
+AbstractCore is imported on first use; it needs AbstractCore 2.25.0 or newer. AbstractGateway's
+`/v1/chat/completions` uses this facade, so the gateway never imports AbstractCore itself.

{abstractruntime-0.8.5 → abstractruntime-0.9.1}/llms-full.txt

@@ -1086,7 +1086,7 @@ Deep dive: [automations.md](automations.md).
 
 ```python
 from abstractruntime.automations import (
-    apply_automation_command,   # pause / resume / run_now / revise / stop_current / archive
+    apply_automation_command,   # pause / resume / run_now / revise / stop_current / archive / unarchive
     create_automation,          # -> (automation_id, revision)
     drive_automation,           # standalone run loop
     get_automation,
@@ -1127,6 +1127,7 @@ from abstractruntime.email import (
 
 - `Runtime.set_email_context_resolver(fn)`: `fn(binding, *, use) -> EmailContext | None` (`use` is `"agent_tool"` or `"action"`; `fn(binding)` also accepted), per runtime, memory only
 - `Runtime.set_email_binding(binding | None)` / `Runtime.email_binding`: the account occurrences are bound to
+- `Runtime.set_occurrence_input_resolver(fn | None)` / `Runtime.occurrence_input_resolver`: `fn(definition, input_data) -> input_data`, called at each automation occurrence's admission (its run start) and frozen with the occurrence's inputs (a replayed dispatch stays identical); a non-dict answer fails the admission. The gateway re-resolves an automation's "Use my default" workspaces here. None (default): the definition's inputs as stored
 - `Runtime.set_event_inbox(inbox)` / `Runtime.event_inbox`: required by `email.received@1`
 - `EmailInboxFeeder(inbox, account_ref=...).poll(ctx, *, now=None, force=False) -> PollReport` and `.status()`
 - toolsets: `get_default_toolsets(..., email_enabled=True)` (also `list_default_tool_specs`, `build_default_tool_map`, `list_tool_catalog`); no env flag; `list_tool_catalog(email_enabled=False, email_off_reason="not_connected" | "admin_disabled" | "not_available" | "agent_tools_off")`
@@ -1134,6 +1135,7 @@ from abstractruntime.email import (
 - approval: the `send_email_recipient@v2` refiner ([tool-approval.md](tool-approval.md#per-call-refiners))
 - `adopt_legacy_schedule_projection(run)`: read-only summary of a legacy gateway `scheduled:*` root
 - read-only mounts: `_runtime.workspace_read_only_paths` (absolute folders; file write tools and VisualFlow writers refused inside, reads and command/code tools allowed); helpers `read_only_paths(vars)`, `path_is_read_only(vars, path)` and `READ_ONLY_PATHS_KEY` in `abstractruntime.utils.workspace_paths`
+- writable exceptions inside read-only roots: `workspace_writable_paths` (top-level or `_runtime`; absolute folders). A path is read-only when a read-only root contains it and no writable path inside that root contains it, so the more specific rule wins (a host sets `/` read-only plus the run's folder and its read & write folders for a read-only default). Child runs and VisualFlow file nodes get the parent's exceptions exactly; a child never adds one. Helpers: `writable_paths(vars)`, `is_read_only_target(path, read_only_roots, writable_roots)`, `WRITABLE_PATHS_KEY`.
 - read-only workspaces: run vars `workspace_read_only: true` (or `_runtime.workspace_read_only: true`); `abstractruntime.integrations.abstractcore.tool_effects.TOOL_EFFECT_CLASSES` classifies every exposable tool as `read`, `write`, `exec`, `delegate`, `comms` or `memory-write`
 
 ## Sessions and history
@@ -1261,6 +1263,10 @@ This provides handlers for `MEMORY_KG_*` effects (opt-in wiring layer).
 
 `abstractruntime.integrations.abstractcore.server_facade.serve_core_request(scope, receive, send, *, token: str, allow_unauthenticated: bool = False)` delegates host-admitted ASGI requests with request-scoped Core authentication. See [host-managed serving](integrations/abstractcore.md#host-managed-serving) for network and credential responsibilities.
 
+### Structured-output checks
+
+`abstractruntime.integrations.abstractcore.structured_facade.parse_response_format(raw) -> (kind, schema, name)` checks an OpenAI `response_format` and raises `ResponseFormatError` (AbstractCore's own class, with `.param`) for an unusable one. Both are also exported flat from `abstractruntime.integrations.abstractcore`. Requires AbstractCore 2.25.0 or newer. See [structured-output checks for hosts](integrations/abstractcore.md#structured-output-checks-for-hosts-structured-facade).
+
 
 ==============================================================================
 # FILE: docs/faq.md
@@ -1319,7 +1325,9 @@ Docs: `getting-started.md`. Code: `src/abstractruntime/core/runtime.py`, `src/ab
 Create an automation. An automation is a durable controller run that starts the target workflow as a child run (an
 occurrence) on each trigger: `schedule@1` (fixed UTC intervals such as `5m` or `24h`) or `manual@1` (run now only).
 `create_automation(...)` creates it, `apply_automation_command(...)` pauses, resumes, runs now, edits, stops the
-current occurrence or archives it, and the host drives it like any run (`drive_automation` does this in-process).
+current occurrence, archives it or unarchives it (it comes back paused with its history), and the host drives it
+like any run (`drive_automation` does this in-process). Nothing is deleted: an archived automation keeps its
+occurrences and history and stays listed with status `archived`.
 
 The `Scheduler` is different: it is a driver loop that resumes due waits of existing runs. It does not create runs.
 
@@ -1365,9 +1373,9 @@ Docs: `automations.md#tool-approval`, `automations.md#waits-on-a-person`.
 
 Not through its file tools. A discussion works in its own writable workspace and sees the automation's workspace as
 a read-only mount (`_runtime.workspace_read_only_paths`): file tools and VisualFlow writers that target a path inside
-the mount are refused, reads work. Commands and code (`execute_command`, `execute_python`) are allowed, because the
-shell cannot be sandboxed; a command can therefore still change files if it chooses to, so keep tool approval on for
-commands where that matters. Every later turn in the discussion session keeps the same setup, whoever starts it, and
+the mount are refused, reads work. Commands and code (`execute_command`, `shell_exec`, `local_helper_start`,
+AbstractAgent's `execute_python`) run inside an OS sandbox built from the same workspaces (macOS `sandbox-exec`, Linux
+`bwrap`/Landlock), so they cannot write into the mount either; on a host with no sandbox they are refused. Every later turn in the discussion session keeps the same setup, whoever starts it, and
 the discussion never writes back into the automation's session, state or ledger.
 
 Docs: `automations.md#discussions`, `automations.md#read-only-mounts`.
@@ -2460,16 +2468,19 @@ When a run sets `workspace_root` in its vars, file tools (`read_file`, `write_fi
 | --- | --- |
 | `workspace_root` | Base folder for relative paths and the shell's starting folder. Relative roots resolve against `ABSTRACT_WORKSPACE_BASE_DIR` when set. |
 | `workspace_access_mode` | `workspace_only` (default: paths stay under the root), `workspace_or_allowed` (also under `workspace_allowed_paths`), or `all_except_ignored` (anywhere except `workspace_ignored_paths`). |
-| `workspace_allowed_paths` | Extra folders a `workspace_or_allowed` run may use. |
-| `workspace_ignored_paths` | The operator's exclusions; always refused. |
+| `workspace_allowed_paths` | Additional workspaces a `workspace_or_allowed` run may use. |
+| `workspace_ignored_paths` | Refused workspaces. A more specific allowed workspace inside one stays reachable (see *Nesting* below). |
 | `workspace_builtin_deny_prefixes` | The host's own protected folders (for example a gateway's data folder and credential folders), as path prefixes. Anything under one is refused. |
 | `workspace_builtin_allow` | Exceptions inside the host's protected folders (for example the run's own folder inside the data folder). The operator's `workspace_ignored_paths` still win over them. |
+| `workspace_read_only_paths` / `workspace_writable_paths` | Read-only roots and the writable exceptions inside them (`"/"` = a read-only default). The more specific rule wins. |
 
 Lists accept a JSON array, a JSON array pasted as a string, or newline-separated entries.
 
-- When an `LLM_CALL` offers tools and the run has a workspace scope, the runtime appends a short description of the scope to the system prompt: the root, the access mode, the authorized roots and the operator's `workspace_ignored_paths`. The host's built-in deny prefixes and allow entries are enforced but never described to the model, so the system prompt stays identical from turn to turn while the host's folders change, and the prompt cache stays warm. A refused path is reported as `Path is not accessible (protected by the host)` without listing the host's rules.
-- Child runs (subworkflows and agent delegation) inherit all six vars unless they set their own; VisualFlow file and document nodes (`read_file`, `write_file`, `read_pdf`, `write_pdf`, `write_docx`, `write_chart`) apply the same scope.
-- Shell tools are pinned to their starting folder only. A command can still reach other paths (`cd ..`, absolute paths); the workspace scope is a file-tool policy, not a sandbox.
+- When an `LLM_CALL` offers tools and the run has a workspace scope, the runtime appends a short description of the scope to the system prompt: the root (the run's default working directory); each allowed workspace outside the root with its mode (`(read-only)` or `(read & write)`, from `workspace_read_only_paths` and `workspace_writable_paths`); under `all_except_ignored` the mode of everything else (`Everything else: (read-only)`); the access mode; the authorized roots and the operator's `workspace_ignored_paths`. The host's built-in deny prefixes and allow entries are enforced but never described to the model, so the system prompt stays identical from turn to turn while the host's folders change, and the prompt cache stays warm. A refused path is reported as `Path is not accessible (protected by the host)` without listing the host's rules.
+- Child runs (subworkflows and agent delegation) inherit the workspace vars unless they set their own; VisualFlow file and document nodes (`read_file`, `write_file`, `read_pdf`, `write_pdf`, `write_docx`, `write_chart`) apply the same scope.
+- **Nesting (most specific row wins).** For a path P (symlinks resolved), the candidates are `workspace_root` (read & write), `workspace_allowed_paths` (not under `workspace_only`) and `workspace_ignored_paths`. The longest candidate that contains P decides: a refused entry refuses, the root or an allowed entry allows; a tie between a refused entry and an allowed one (or the root) at the same path refuses; no candidate falls back to the access mode (`all_except_ignored` allows, the others refuse). The host's built-in protection is absolute: under a `workspace_builtin_deny_prefixes` entry and not under a `workspace_builtin_allow` entry is refused whatever the rows say. So refusing `/Users/me` and allowing `/Users/me/project` makes the project reachable and the rest of `/Users/me` refused; a refused folder inside an allowed one refuses that subtree. AbstractGateway applies the same rule when it validates and computes a run's workspaces.
+- **Command sandbox.** `execute_command`, `shell_exec` (the whole persistent session), `local_helper_start` and AbstractAgent's `execute_python` (0.3.18 or newer) start in the workspace and run inside an OS sandbox built from the SAME scope (`sandbox_stamp(scope)`, stamped on every call as the hidden `_sandbox` argument; a model- or payload-supplied value is always replaced). AbstractCore (`abstractcore.tools.sandbox`) applies it: macOS `sandbox-exec`, Linux `bwrap`, or Linux Landlock for "Deny everything, allow listed workspaces". Mapping: `all_except_ignored` → "Allow everything, refuse listed workspaces" (`any_except_denied`), otherwise "Deny everything, allow listed workspaces" (`allowed_only`); a `"/"` read-only root → read-only default; each allowed workspace with its mode; refused paths and the built-in protection as they are. The command string is never parsed — `cd ..`, absolute paths, `$(…)`, symlinks and scripts are stopped by the kernel. With no sandbox on the host, or an AbstractCore without `abstractcore.tools.sandbox`, the command is refused with one sentence and the run continues. The entity exec tool runs inside a sandbox limited to the entity's workspace and its whitelisted mounts. The tool result carries `sandbox: {kind, …}` and a `Sandbox: …` line; the stamp rides the tool call in the run's evidence. Hosts set the host policy (the scrubbed environment commands start from, and whether unsandboxed commands are allowed on a host with no sandbox) once at boot through `abstractruntime.integrations.abstractcore.command_sandbox_host` (`configure_host`, `host_policy`, `host_sandbox_kind`), never by importing AbstractCore.
+- **Browser probe.** A local `browser_probe` target (a path or a `file://` URL) is walled like `read_file`'s path and carries the same `_sandbox` stamp: AbstractCore 2.25.1 serves the page to the browser from a loopback origin that answers only for files this scope can read (never `file://`). Remote `http(s)://` targets carry no stamp.
 
 ## Prompt-cache control plane and durable blocs
 
@@ -3012,8 +3023,14 @@ Public durable entry points:
 These helpers create child runs under an existing parent run and execute the real
 `LLM_CALL`, `TOOL_CALLS`, or stream finalization through Runtime rather than
 doing external work in host/controller code. `stream_voice(...)` yields TTS
-stream events for progressive playback and completes the child run with the
-final audio artifact when the stream succeeds.
+stream events for progressive playback; it is never a wait: nothing durable
+exists while audio streams, and when the stream ends (done, error, cancel or
+the consumer closing it) the child run is created already completed with the
+outcome (the final audio artifact on success). The child's id is announced up
+front in the `runtime_start` event (`child_run_id`). A host that finds a
+streamed-speech wait left by a runtime before this behaviour
+(`is_interrupted_voice_stream_wait`) closes it with
+`close_interrupted_voice_stream(child_run_id, reason=...)`.
 
 Example:
 
@@ -3151,6 +3168,21 @@ Anonymous callers cannot use server-held cloud credentials; explicit provider
 keys use `X-AbstractCore-Provider-API-Key`. This serving facade does not create
 durable Runtime runs. The AbstractCore server dependencies must be installed.
 
+## Structured-output checks for hosts (structured facade)
+
+A host that accepts an OpenAI `response_format` checks it before any model sees it with
+`abstractruntime.integrations.abstractcore.structured_facade` (also exported flat from
+`abstractruntime.integrations.abstractcore`):
+
+- `parse_response_format(raw)` returns `(kind, schema, name)`, where kind is `"text"`,
+  `"json_object"` or `"json_schema"` and schema is `None` unless kind is `"json_schema"`.
+- `ResponseFormatError` is AbstractCore's own error class, so `except ResponseFormatError`
+  catches exactly what Core raises; `.param` names the offending field
+  (`"response_format"` or a nested name such as `"response_format.type"`).
+
+AbstractCore is imported on first use; it needs AbstractCore 2.25.0 or newer. AbstractGateway's
+`/v1/chat/completions` uses this facade, so the gateway never imports AbstractCore itself.
+
 
 ==============================================================================
 # FILE: docs/proposal.md
@@ -3575,7 +3607,7 @@ sources), `abstractruntime.automation_queries` (listing), `abstractruntime.sessi
 ```mermaid
 flowchart LR
   Trigger["Trigger source<br/>schedule@1 / manual@1"] -->|"due tick or run now"| Controller["Controller run<br/>(automation id)<br/>vars._meta.automation<br/>vars._runtime.automation"]
-  Commands["apply_automation_command<br/>pause / resume / run_now /<br/>revise / stop_current / archive"] -->|"decision + wake"| Controller
+  Commands["apply_automation_command<br/>pause / resume / run_now /<br/>revise / stop_current / archive / unarchive"] -->|"decision + wake"| Controller
   Controller -->|"START_SUBWORKFLOW<br/>deterministic run_id"| Occurrence["Occurrence run<br/>role: occurrence<br/>(a session turn)"]
   Occurrence --> Descendants["Descendant runs<br/>role: descendant"]
   Occurrence -->|"output: answer, notify"| Controller
@@ -3833,6 +3865,7 @@ expected_revision=None, now=None)` is the only way to change an automation. It r
 | `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 |
 | `automation.stop_current` | Cancels the running occurrence tree, or its pending retry. The occurrence completes as `cancelled`, quietly. | `invalid_state` when nothing is running |
 | `automation.archive` | Stops further admissions; the current occurrence finishes and the controller then ends. History is kept and the automation stays listed. Archiving twice is an applied no-op. | — |
+| `automation.unarchive` | Lifts the archive mark and brings the automation back **paused** (send `automation.resume` to re-arm its trigger). A controller that ended because it was archived restarts at `read_definition` and parks on its wake wait; occurrences, ledger and history are untouched. An exhausted or failed automation only loses the archive mark and keeps its status. Unarchiving an automation that is not archived is an applied no-op. | — |
 
 Every command can also be rejected with:
 
@@ -3846,7 +3879,7 @@ Commands are idempotent per `command_id`. A `command_id` is tied to its whole co
 `expected_revision`). The `automation.command_result` record, keyed
 `automation:command_result:<automation_id>:<command_id>`, is the decision. Sending the same command again returns the
 recorded result with `duplicate: true` and repeats only the follow-ups that are safe to repeat: the observation
-record (`automation.paused`, `automation.resumed`, `automation.revised`, `automation.archived`), waking the
+record (`automation.paused`, `automation.resumed`, `automation.revised`, `automation.archived`, `automation.unarchived`), waking the
 controller, and cancelling the stopped child. A host that fails to carry out a command itself records the failure
 with `record_automation_command_result(...)`, passing the same `payload` and `expected_revision` so a later replay is
 recognized.
@@ -5851,7 +5884,7 @@ In this repo, the AbstractCore wiring lives under `src/abstractruntime/integrati
 - `faq.md` — common questions (recommended)
 - `manual_testing.md` — manual smoke tests and how to run the test suite
 - `artifacts.md` — Runtime artifact identity, descriptors, provenance, catalog search, and access stats
-- `integrations/abstractcore.md` — wiring `LLM_CALL` / `TOOL_CALLS`, the `config_facade` models/engines/host-jobs passthroughs for hosts, cached sessions with per-session prompt-cache listing/clearing, host memory snapshots, model-residency listings, locks and model switching, live token streaming, workspace-scoped tools, durable bloc prompt-cache control, media inputs, generated media outputs, video progress events, and tool approval waits via AbstractCore
+- `integrations/abstractcore.md` — wiring `LLM_CALL` / `TOOL_CALLS`, the `config_facade` models/engines/host-jobs passthroughs for hosts, the `structured_facade` response_format check for hosts, cached sessions with per-session prompt-cache listing/clearing, host memory snapshots, model-residency listings, locks and model switching, live token streaming, workspace-scoped tools, durable bloc prompt-cache control, media inputs, generated media outputs, video progress events, and tool approval waits via AbstractCore
 - `tools-comms.md` — enabling the optional comms toolset (email/WhatsApp/Telegram)
 - `email.md` — email for each user: run-scoped account binding and the host resolver, sending without asking (self and pre-authorised recipients), the durable event inbox and mail feeder, the `email.received@1` trigger, and the send-email action
 - `tool-approval.md` — tool risk tiers, the run-policy rank ceiling, and per-call refiners (the `send_email` recipient rule: self and pre-authorised recipients)

{abstractruntime-0.8.5 → abstractruntime-0.9.1}/llms.txt

@@ -3,7 +3,7 @@
 > Durable workflow runtime (interrupt → checkpoint → resume) with an append-only execution ledger.
 
 - Python: 3.10+ (see `pyproject.toml`)
-- Version: 0.8.5
+- Version: 0.9.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.24.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`)
@@ -39,7 +39,7 @@
 - [Cancellation, pause and tool ceiling](docs/api.md#runtime-start--tick--resume): `Runtime.cancel_run(...)` stops the in-flight effect (recorded `cancelled`, never retried), a model unload cancels the calls using it first, `tick(..., step_gate=...)` pauses at step boundaries, and an explicit `allowed_tools` list is a run-tree ceiling approval policy cannot widen.
 - [Live token streaming](docs/integrations/abstractcore.md#live-token-streaming): `Runtime.set_live_delta_sink(sink)` plus run input `_runtime.stream: true` delivers `llm.delta` / `llm.delta_end` events (content and reasoning channels, `parent_run_id`) while an answer is generated; nothing reaches the ledger, children inherit the switch, and every call that cannot stream with a complete record says why (`reason: unavailable` + `detail`).
 - [Unloading and switching models](docs/integrations/abstractcore.md#unloading-and-switching-models): a default switch unloads the previous in-process model (MLX, HuggingFace, embeddings) unless another owner in the process claims it (pool, override, lock, building, default); a model still generating is unloaded when its call ends; diagnostics `pending_ejects` / `last_switch_ejects`; any listed row unloads by `runtime_id` (`local:<task>:<provider>:<model>`, including `local:embedding:<provider>:<model>`); `ttl_s` / `keep_alive` on in-process or already-loaded models are reported under `unsupported_options`.
-- [Workspace-scoped tools](docs/integrations/abstractcore.md#workspace-scoped-tools): `workspace_root`, `workspace_access_mode`, `workspace_allowed_paths`, `workspace_ignored_paths`, and the host-only `workspace_builtin_deny_prefixes` / `workspace_builtin_allow` (enforced, never shown to the model) scope file and shell tools; child runs inherit them.
+- [Workspace-scoped tools](docs/integrations/abstractcore.md#workspace-scoped-tools): `workspace_root`, `workspace_access_mode`, `workspace_allowed_paths`, `workspace_ignored_paths`, and the host-only `workspace_builtin_deny_prefixes` / `workspace_builtin_allow` (enforced, never shown to the model) scope file and shell tools; the most specific row wins (longest real-path prefix, a refusal wins a tie, built-ins absolute); `execute_command`/`shell_exec`/`local_helper_start`/`execute_python` get the same set stamped as the hidden `_sandbox` arg and run inside AbstractCore's OS sandbox (refused when the host has none); child runs inherit them.
 - [Execution controls](docs/integrations/abstractcore.md#execution-controls-and-local-concurrency): inherited run/node MTP controls, scoped Core defaults, actual-host execution discovery, instance-aware scheduling, per-response outcomes and cache-group batching limits.
 
 - [AbstractCore integration](docs/integrations/abstractcore.md): `LLM_CALL` / `TOOL_CALLS` / `MODEL_RESIDENCY`, local/remote/hybrid, prompt-cache and residency host controls, host memory snapshots and per-session prompt-cache listing/clearing, host-wide provider-server rows in residency listings, model-residency locks (residency-required: locking a non-resident pair refuses with `model_not_resident`; unlock never requires residency) with `force`-gated unload and context-estimate relays, modality/host-identity fields and truthful `pinned`-aliases-`locked` lock state on local residency rows, local-only prompt-cache export/import admin, durable bloc/KV prompt-cache controls, discovery snapshot queries including `list_provider_models(..., capability_route=...)` and `list_vision_adapters(...)`, durable run-scoped image/edit-image/upscale-image/text-to-video/image-to-video/voice/streamed-voice/music/STT execution, batch `count`/`n`, `seeds`, ordered `lora_adapters`, video `flow_shift`, media inputs, generated media outputs, progress ledger events, provider-key headers, host endpoint-profile resolver hooks, and tool approval waits
@@ -57,7 +57,7 @@
 - [MCP worker](docs/mcp-worker.md): `abstractruntime-mcp-worker` CLI (stdio/HTTP)
 - [Comms toolset](docs/tools-comms.md): email enabled by the host (`email_enabled=True`, no env flag); WhatsApp/Telegram env gating
 - [Email](docs/email.md): one user, one runtime, one mailbox: `_runtime.email_account` binding resolved at call time through `Runtime.set_email_context_resolver` (credentials never in vars, ledger or results), `send_email_recipient@v2` (unattended only to self or to the definition's `policy.email_allowed_recipients`), the resolver's `use` (`agent_tool` / `action`) so a host's agent-tools switch gates agent tools only, large structured tool outputs offloaded to attachments, durable event inbox (`JsonFileEventInbox`, retention 90 days / 10,000 events via `prune_email_inbox`) filled by `EmailInboxFeeder.poll` (read-only, per-message cursor, UIDVALIDITY resync, typed failures with backoff), the `email.received@1` trigger (typed filters, batches every `every`, each message once, untrusted input: messages and framed prompt stored as artifacts (refs only in the controller's records), frame markers with a per-occurrence random boundary, and "allow all tools" granting by kind only (no network egress beyond configured services, no execution, no messaging, no writes outside the workspace (the memory-writing tools included), no delegation; anything else only when named in `policy.untrusted_input_tools`, sending tools never; under "ask" nothing runs unasked but the named tools, and the executor's static defaults never decide for an untrusted run or its children)) and the send-email action (fixed-placeholder templates)
-- [Automations](docs/automations.md): configurable growing-context budgets and result email; an automation is a durable controller run that starts its target as deterministic child runs (occurrences) on `schedule@1` (fixed UTC intervals, coalesced missed ticks) or `manual@1`; `create_automation`, `apply_automation_command` (pause, resume, run_now, revise, stop_current, archive; idempotent per `command_id`), independent or growing context, `start_discussion` (fork at any occurrence N, seeded with the timeline 1..N, own writable workspace, the automation's workspace mounted read-only via `_runtime.workspace_read_only_paths`: file writes refused inside, reads and commands allowed), `policy.tool_approval` (`auto` or `ask`), `policy.email_allowed_recipients`, `notify.channels`, the `email.received@1` trigger, typed `pending_waits`, `notify` attention items and retries; storage guarantees: `create_if_absent`, `run_mutation_lock`, turn roots and `session_kind` in the run index, one writer process per store, `Runtime.start` refusing session starts it cannot attribute
+- [Automations](docs/automations.md): configurable growing-context budgets and result email; an automation is a durable controller run that starts its target as deterministic child runs (occurrences) on `schedule@1` (fixed UTC intervals, coalesced missed ticks) or `manual@1`; `create_automation`, `apply_automation_command` (pause, resume, run_now, revise, stop_current, archive, unarchive — back paused with its history, nothing deleted; idempotent per `command_id`), independent or growing context, `start_discussion` (fork at any occurrence N, seeded with the timeline 1..N, own writable workspace, the automation's workspace mounted read-only via `_runtime.workspace_read_only_paths`: file writes refused inside, reads and commands allowed), `policy.tool_approval` (`auto` or `ask`), `policy.email_allowed_recipients`, `notify.channels`, the `email.received@1` trigger, typed `pending_waits`, `notify` attention items and retries; storage guarantees: `create_if_absent`, `run_mutation_lock`, turn roots and `session_kind` in the run index, one writer process per store, `Runtime.start` refusing session starts it cannot attribute
 - [Tool approval](docs/tool-approval.md): tool risk tiers, the run-policy rank ceiling, and per-call refiners
 - [Entity runtime](docs/entity-runtime.md): per-entity runtimes, homes, the one-writer lease, act-only diary privacy, and durable visit waits
 - [Models, engines and host jobs](docs/integrations/abstractcore.md#models-engines-and-host-jobs-config-facade): `config_facade` passthroughs for hosts; `host_job_cancel(job_id, *, by="api", user=None)` records who cancelled a job

{abstractruntime-0.8.5 → abstractruntime-0.9.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "AbstractRuntime"
-version = "0.8.5"
+version = "0.9.1"
 description = "AbstractRuntime: a durable graph runner designed to pair with AbstractCore."
 readme = "README.md"
 requires-python = ">=3.10"
@@ -53,7 +53,9 @@ 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.24.0",
+  # 2.25.1: the Linux bwrap profile binds an allowed child of a refused folder,
+  # and browser_probe takes the _sandbox stamp (scoped loopback origin).
+  "abstractcore>=2.25.1",
   "openai<3.0.0,>=1.109.1",
   "httpx<1.0.0,>=0.28.1",
   "anyio<5.0.0,>=4.12.1",
@@ -70,12 +72,12 @@ dependencies = [
 
 [project.optional-dependencies]
 apple = [
-  "abstractcore[apple]>=2.24.0",
+  "abstractcore[apple]>=2.25.1",
   "setuptools<82.0.0,>=80.10.2",
 ]
 
 gpu = [
-  "abstractcore[gpu]>=2.24.0",
+  "abstractcore[gpu]>=2.25.1",
   # 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.9.1/release-notes.md

@@ -0,0 +1,12 @@
+### Security
+
+- `browser_probe`: a local target (path or `file://` URL) now carries the run's `_sandbox` stamp, the same scope the commands get. AbstractCore 2.25.1 serves the page from a loopback origin limited to that scope instead of `file://`, so a page cannot load refused files as subresources. Needs AbstractCore 2.25.1 (an older `browser_probe` refuses the unknown argument and runs nothing). Test: `tests/test_browser_probe_target_walling.py`.
+
+### Fixed
+
+- `stream_voice(...)` is never a wait. It used to start the child run parked on `WAIT_EVENT abstractcore.voice.tts.stream:<uuid>` for the whole stream: hosts folded that waiting record into the CALLER'S run (a Read aloud during a live turn read as "Waiting for an event"), and a host that died mid-stream left the child waiting forever. Now nothing durable exists while audio streams; when the stream ends (done, error, cancel or the consumer closing it) the child run is created already COMPLETED with the outcome. Its id is allocated up front: `runtime_start` carries it as `child_run_id` (schema `abstractruntime.tts_stream.start.v2`, no `wait_key`), as does the trace metadata. A stream cut by a crash leaves no run.
+- `AbstractCoreRunFacade.close_interrupted_voice_stream(child_run_id, *, reason)` finishes a legacy streamed-speech wait left by an older process (completed, `errors[0] = {"code": "interrupted", "message": reason}`); `is_interrupted_voice_stream_wait(waiting)` and `LEGACY_VOICE_STREAM_WAIT_KEY_PREFIX` recognise one (exported from `integrations.abstractcore`). AbstractGateway calls it at startup.
+
+### Changed
+
+- Requires AbstractCore 2.25.1 or newer (`abstractcore>=2.25.1` in the base install and the `[apple]`/`[gpu]` extras): the Linux command sandbox reaches an allowed folder inside a refused one, and `browser_probe` accepts the run's `_sandbox` stamp.