AbstractRuntime 0.4.7__tar.gz → 0.4.9__tar.gz

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/ACKNOWLEDGMENTS.md

@@ -7,14 +7,15 @@ The canonical dependency list lives in `pyproject.toml`.
 
 ## Runtime dependencies (core install)
 
-- **abstractsemantics** (`>=0.0.2`) — structured schema registry support (declared in `pyproject.toml`, used in `src/abstractruntime/integrations/abstractmemory/effect_handlers.py` and VisualFlow execution wiring).
+- **abstractsemantics** (`>=0.0.3`) — structured schema registry support (declared in `pyproject.toml`, used in `src/abstractruntime/integrations/abstractmemory/effect_handlers.py` and VisualFlow execution wiring).
+- **AbstractMemory** (`>=0.2.6`) — TripleStore models and store contract used by Runtime's `MEMORY_KG_*` effects. Durable/vector backend dependencies such as LanceDB remain selected by hosts.
 
 ## Optional integrations (extras)
 
 Installed only when you opt in to extras:
-- **abstractcore** (`>=2.11.8`) — LLM + tools integration used by `abstractruntime[abstractcore]` (declared in `pyproject.toml`, implementation under `src/abstractruntime/integrations/abstractcore/*`, docs: `docs/integrations/abstractcore.md`).
+- **abstractcore** (`>=2.13.12`) — LLM + tools integration used by `abstractruntime[abstractcore]` (declared in `pyproject.toml`, implementation under `src/abstractruntime/integrations/abstractcore/*`, docs: `docs/integrations/abstractcore.md`).
   - The AbstractCore integration uses **httpx** for remote mode (`src/abstractruntime/integrations/abstractcore/llm_client.py`) and **pydantic** for structured validation (`src/abstractruntime/integrations/abstractcore/effect_handlers.py`). These are provided by AbstractCore’s dependency set.
-- **abstractcore[tools]** (`>=2.11.8`) — toolchain extra used by `abstractruntime[mcp-worker]` (declared in `pyproject.toml`) and intended to include HTML parsing dependencies (see comments in `pyproject.toml`).
+- **abstractcore[tools]** (`>=2.13.12`) — toolchain extra used by `abstractruntime[mcp-worker]` (declared in `pyproject.toml`) and intended to include HTML parsing dependencies (see comments in `pyproject.toml`).
 - **RestrictedPython** (optional) — used for sandboxed execution of VisualFlow “Code” nodes when available (`src/abstractruntime/visualflow_compiler/visual/code_executor.py`).
 
 ## Build & test tooling

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/CHANGELOG.md

@@ -7,6 +7,32 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.4.9] - 2026-05-09
+
+### Changed
+- Added `AbstractMemory>=0.2.6` as a base dependency so Runtime's
+  `MEMORY_KG_*` effect contract always has the AbstractMemory TripleStore
+  models available.
+
+### Notes
+- Runtime still does not depend on `AbstractMemory[lancedb]`. Hosts such as
+  AbstractGateway choose the durable/vector memory backend, path, embeddings,
+  and readiness policy.
+
+## [0.4.8] - 2026-05-08
+
+### Changed
+- Minimum `abstractcore` optional dependency increased to `>=2.13.12`, and the
+  semantics floor increased to `abstractsemantics>=0.0.3`.
+- Added explicit hardware-profile cascade extras:
+  `abstractruntime[apple]`, `abstractruntime[gpu]`,
+  `abstractruntime[all-apple]`, and `abstractruntime[all-gpu]`.
+
+### Notes
+- Runtime still owns durable execution, not local model engines. These extras
+  delegate to the matching AbstractCore profile so Gateway and root aggregate
+  installs can compose a single profile vocabulary.
+
 ## [0.4.7] - 2026-05-08
 
 ### Changed

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: AbstractRuntime
-Version: 0.4.7
+Version: 0.4.9
 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,17 +20,26 @@ Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
 Requires-Python: >=3.10
-Requires-Dist: abstractsemantics>=0.0.2
+Requires-Dist: abstractmemory>=0.2.6
+Requires-Dist: abstractsemantics>=0.0.3
 Provides-Extra: abstractcore
-Requires-Dist: abstractcore>=2.13.11; extra == 'abstractcore'
+Requires-Dist: abstractcore>=2.13.12; extra == 'abstractcore'
+Provides-Extra: all-apple
+Requires-Dist: abstractcore[all-apple]>=2.13.12; extra == 'all-apple'
+Provides-Extra: all-gpu
+Requires-Dist: abstractcore[all-gpu]>=2.13.12; extra == 'all-gpu'
+Provides-Extra: apple
+Requires-Dist: abstractcore[apple]>=2.13.12; 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.13.12; extra == 'gpu'
 Provides-Extra: mcp-worker
-Requires-Dist: abstractcore[tools]>=2.13.11; extra == 'mcp-worker'
+Requires-Dist: abstractcore[tools]>=2.13.12; extra == 'mcp-worker'
 Provides-Extra: multimodal
-Requires-Dist: abstractcore[audio,media,openai,vision,voice]>=2.13.11; extra == 'multimodal'
+Requires-Dist: abstractcore[audio,media,openai,vision,voice]>=2.13.12; extra == 'multimodal'
 Provides-Extra: test
 Requires-Dist: pytest>=7.0.0; extra == 'test'
 Description-Content-Type: text/markdown
@@ -41,7 +50,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.4.7 • **Python:** 3.10+
+**Version:** 0.4.9 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
@@ -75,7 +84,12 @@ AbstractCore integration (LLM + tools):
 pip install "abstractruntime[abstractcore]"
 ```
 
-The `abstractcore` extra installs AbstractCore 2.13.11 or newer so the hardened server auth model, provider-key header routing, generated-media contracts, capability catalog, prompt-cache control plane, current tool catalog, public output-selector contract, and async/sync text-generation output-selector parity are available. Use `abstractruntime[multimodal]` when you need common media, vision, voice, and audio dependencies.
+The `abstractcore` extra installs AbstractCore 2.13.12 or newer so the hardened server auth model, provider-key header routing, generated-media contracts, capability catalog, prompt-cache control plane, current tool catalog, public output-selector contract, and async/sync text-generation output-selector parity are available. Use `abstractruntime[multimodal]` when you need common media, vision, voice, and audio dependencies.
+
+Hardware profile cascades are available for native Python installs:
+`abstractruntime[apple]`, `abstractruntime[gpu]`, `abstractruntime[all-apple]`,
+and `abstractruntime[all-gpu]` delegate to the matching AbstractCore profile
+without making the runtime kernel itself hardware-specific.
 
 MCP worker entrypoint (default toolsets over stdio):
 
@@ -124,7 +138,7 @@ state = rt.resume(
 assert state.status.value == "completed"
 ```
 
-## What’s included (v0.4.7)
+## What’s included (v0.4.9)
 
 Kernel (dependency-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)
@@ -149,6 +163,9 @@ Drivers + distribution:
 
 Optional integrations:
 - AbstractCore (LLM + tools, cached sessions/prompt cache, media inputs, generated media, tool approval waits): `docs/integrations/abstractcore.md`
+- AbstractMemory TripleStore integration for `MEMORY_KG_*` effects. Runtime
+  depends on the light AbstractMemory contract; hosts choose storage backends
+  such as LanceDB, SQLite, or in-memory stores.
 - comms toolset gating (email/WhatsApp/Telegram): `docs/tools-comms.md`
 
 ## Built-in scheduler (zero-config)

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/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.4.7 • **Python:** 3.10+
+**Version:** 0.4.9 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
@@ -38,7 +38,12 @@ AbstractCore integration (LLM + tools):
 pip install "abstractruntime[abstractcore]"
 ```
 
-The `abstractcore` extra installs AbstractCore 2.13.11 or newer so the hardened server auth model, provider-key header routing, generated-media contracts, capability catalog, prompt-cache control plane, current tool catalog, public output-selector contract, and async/sync text-generation output-selector parity are available. Use `abstractruntime[multimodal]` when you need common media, vision, voice, and audio dependencies.
+The `abstractcore` extra installs AbstractCore 2.13.12 or newer so the hardened server auth model, provider-key header routing, generated-media contracts, capability catalog, prompt-cache control plane, current tool catalog, public output-selector contract, and async/sync text-generation output-selector parity are available. Use `abstractruntime[multimodal]` when you need common media, vision, voice, and audio dependencies.
+
+Hardware profile cascades are available for native Python installs:
+`abstractruntime[apple]`, `abstractruntime[gpu]`, `abstractruntime[all-apple]`,
+and `abstractruntime[all-gpu]` delegate to the matching AbstractCore profile
+without making the runtime kernel itself hardware-specific.
 
 MCP worker entrypoint (default toolsets over stdio):
 
@@ -87,7 +92,7 @@ state = rt.resume(
 assert state.status.value == "completed"
 ```
 
-## What’s included (v0.4.7)
+## What’s included (v0.4.9)
 
 Kernel (dependency-light):
 - workflow graphs: `WorkflowSpec` (`src/abstractruntime/core/spec.py`)
@@ -112,6 +117,9 @@ Drivers + distribution:
 
 Optional integrations:
 - AbstractCore (LLM + tools, cached sessions/prompt cache, media inputs, generated media, tool approval waits): `docs/integrations/abstractcore.md`
+- AbstractMemory TripleStore integration for `MEMORY_KG_*` effects. Runtime
+  depends on the light AbstractMemory contract; hosts choose storage backends
+  such as LanceDB, SQLite, or in-memory stores.
 - comms toolset gating (email/WhatsApp/Telegram): `docs/tools-comms.md`
 
 ## Built-in scheduler (zero-config)

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/docs/api.md

@@ -176,7 +176,7 @@ This produces a portable record of a run’s state + ledger + artifacts suitable
 
 ### AbstractCore (LLM + tools)
 
-Requires: `pip install "abstractruntime[abstractcore]"` (AbstractCore 2.13.11 or newer).
+Requires: `pip install "abstractruntime[abstractcore]"` (AbstractCore 2.13.12 or newer).
 
 Implementation: `src/abstractruntime/integrations/abstractcore/*`.
 

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/docs/architecture.md

@@ -1,7 +1,7 @@
 # AbstractRuntime — Architecture
 
 > Updated: 2026-05-08
-> Version: 0.4.7
+> Version: 0.4.9
 > 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.
@@ -12,7 +12,7 @@ AbstractRuntime is the durable execution kernel inside the wider AbstractFramewo
 - AbstractFramework umbrella: [lpalbou/AbstractFramework](https://github.com/lpalbou/AbstractFramework)
 - AbstractCore (LLM + tools): [lpalbou/abstractcore](https://github.com/lpalbou/abstractcore)
 
-The runtime stays dependency-light and delegates LLM/tool execution to integrations (notably AbstractCore): `src/abstractruntime/integrations/abstractcore/*`.
+The runtime stays dependency-light and delegates LLM/tool execution to integrations (notably AbstractCore): `src/abstractruntime/integrations/abstractcore/*`. Runtime also depends on the light AbstractMemory contract so `MEMORY_KG_*` effects always have the TripleStore model types available; hosts still choose the concrete memory backend.
 
 ```mermaid
 flowchart LR
@@ -37,7 +37,7 @@ The boundary is intentionally narrow:
 - Remote chat media is sent to AbstractCore Server as provider-ready content arrays, but persisted provider-request metadata redacts data URLs so checkpoints and ledgers do not embed media bytes.
 - Provider sessions and prompt-cache objects are not runtime state. Runtime may carry stable cache keys, while AbstractCore clients/servers manage warm caches.
 - Local execution can use richer AbstractCore capability plugins. Remote and hybrid execution map the common media cases to AbstractCore Server endpoints and OpenAI-compatible content arrays, while hybrid keeps tool execution local.
-- Gateway and other hosts compose Runtime with the desired Core/capability/memory profile. Runtime's base package does not expose hardware profile extras such as `apple`, `gpu`, `all-apple`, or `all-gpu`; those cascade through AbstractCore when a host selects them.
+- Gateway and other hosts compose Runtime with the desired Core/capability/memory profile. Runtime's base package includes the AbstractMemory contract but not backend extras such as LanceDB; hosts choose storage, embeddings, and readiness policy. Hardware profile extras such as `apple`, `gpu`, `all-apple`, and `all-gpu` cascade through AbstractCore when a host selects them.
 - Remote and hybrid clients use explicit Core server URLs and auth headers supplied by the host. Runtime does not read Gateway auth environment variables for provider/model/auth decisions or treat Gateway bearer tokens as Core server/provider credentials.
 
 This keeps the runtime usable by `../abstractgateway` and application layers such as `../abstractflow`, `../abstractassistant`, `../abstractobserver`, and `../abstractcode` without embedding provider-specific model logic in the durable kernel.

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/docs/backlog/proposed/2026-05-08_runtime_gateway_env_namespace_cleanup.md

@@ -20,11 +20,11 @@ This matters for the two-entry-point design:
 
 ## Current Code Reality
 
-Runtime 0.4.7 largely carried out the install-boundary work:
+Runtime 0.4.8 carries the current install-boundary work:
 
-- `pyproject.toml` now points Runtime AbstractCore extras at `abstractcore>=2.13.11`.
-- Runtime does not expose `apple`, `gpu`, `all-apple`, or `all-gpu` extras.
-- `tests/test_packaging_extras.py` verifies the Core floor and absence of fake hardware extras.
+- `pyproject.toml` now points Runtime AbstractCore extras at `abstractcore>=2.13.12`.
+- Runtime exposes `apple`, `gpu`, `all-apple`, and `all-gpu` as explicit Core profile cascades.
+- `tests/test_packaging_extras.py` verifies the Core floor and profile cascade dependencies.
 - `tests/test_runtime_install_boundary.py` verifies the package root/kernel import boundary.
 - `tests/test_remote_llm_client.py` verifies remote AbstractCore clients do not inherit Gateway auth
   or provider-key env vars.

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/docs/backlog/proposed/2026-05-08_runtime_gateway_install_boundary.md

@@ -13,17 +13,19 @@ deployments pull in Core, agents, media, memory, tools, and provider SDKs.
 
 ## Current Code Reality
 
-- Runtime base depends on `abstractsemantics>=0.0.2`.
+- Runtime base depends on `abstractsemantics>=0.0.3`.
 - AbstractCore integration is explicit through `abstractruntime[abstractcore]`.
 - Multimodal helper dependencies are explicit through `abstractruntime[multimodal]`.
 - Runtime does not directly depend on AbstractMemory; memory effects are integration/host-wired.
 - Runtime config contains run-level defaults and limits, not deployment auth or provider secrets.
-- As of the AbstractCore `2.13.11` release, Core exposes the canonical install-profile aliases
+- As of the AbstractCore `2.13.12` release, Core exposes the canonical install-profile aliases
   `abstractcore[apple]`, `abstractcore[gpu]`, `abstractcore[all-apple]`, and
   `abstractcore[all-gpu]`, plus the released Voice/Vision catalog-capable floors
-  `abstractvoice>=0.9.1` and `abstractvision>=0.3.2`.
-- Runtime's package metadata now points its AbstractCore extras at `abstractcore>=2.13.11`
+  `abstractvoice>=0.9.2` and `abstractvision>=0.3.3`.
+- Runtime's package metadata now points its AbstractCore extras at `abstractcore>=2.13.12`
   for Gateway deployment alignment.
+- Runtime exposes pass-through profile extras `apple`, `gpu`, `all-apple`, and `all-gpu` so
+  Gateway/root aggregate installs can cascade through Core without Runtime owning hardware engines.
 
 ## Problem
 
@@ -43,12 +45,13 @@ Profile guidance:
 
 - `abstractruntime`: durable kernel plus Semantics schema refs.
 - `abstractruntime[abstractcore]`: LLM/tool integration, with a floor of
-  `abstractcore>=2.13.11` so Gateway receives the current Core server-auth, provider-key,
+  `abstractcore>=2.13.12` so Gateway receives the current Core server-auth, provider-key,
   generated-media, and capability-catalog contracts.
 - `abstractruntime[multimodal]`: Core media/capability helpers for generated images, voice/audio,
-  and media inputs, also with `abstractcore>=2.13.11`.
-- Do not add `apple`, `gpu`, `all-apple`, or `all-gpu` to Runtime unless Runtime itself owns a
-  hardware-specific dependency, which it currently does not.
+  and media inputs, also with `abstractcore>=2.13.12`.
+- `abstractruntime[apple]`, `abstractruntime[gpu]`, `abstractruntime[all-apple]`, and
+  `abstractruntime[all-gpu]`: pass-through Core profile cascades. Runtime still owns no
+  hardware-specific engine.
 
 Gateway should compose Runtime with the selected Core/capability/memory profile. The cascade belongs
 to Gateway, not Runtime.
@@ -93,11 +96,20 @@ Related package guidance remains:
 - Gateway should keep Runtime base as the dependency for minimal installs.
 - Gateway server profiles may choose `AbstractRuntime[multimodal]`.
 - Gateway Apple/GPU profiles should cascade through Core profile names such as
-  `abstractcore[all-apple]` or `abstractcore[all-gpu]`; Runtime should remain unchanged.
+  `abstractcore[all-apple]` or `abstractcore[all-gpu]`.
 - Root `abstractframework` should update Runtime version floors to match the current Gateway/Core
   integration baseline.
 - AbstractAgent should tighten its Runtime dependency floor.
 
+What changed in Runtime 0.4.8:
+
+- `abstractruntime[abstractcore]`, `abstractruntime[multimodal]`, and
+  `abstractruntime[mcp-worker]` now require `abstractcore>=2.13.12`.
+- `abstractruntime[apple]` and `abstractruntime[gpu]` delegate to matching Core local-engine
+  aliases.
+- `abstractruntime[all-apple]` and `abstractruntime[all-gpu]` delegate to matching Core aggregate
+  profiles.
+
 ## Promotion Criteria
 
 Promoted because the Runtime release needed package metadata alignment, clearer install-boundary
@@ -111,7 +123,6 @@ docs, and regression tests for the Gateway handoff.
 - [x] Runtime LLM/media integration tests gated behind extras.
 - [x] Static import checks that Runtime kernel modules do not import Core, Vision, Voice, Memory, or
   Music.
-- [x] Package metadata test proving Runtime exposes no fake `apple`, `gpu`, `all-apple`, or `all-gpu`
-  extras.
+- [x] Package metadata test proving Runtime profile extras are explicit Core cascades.
 - [x] Package metadata test proving `abstractruntime[abstractcore]` and `abstractruntime[multimodal]`
-  depend on `abstractcore>=2.13.11`.
+  depend on `abstractcore>=2.13.12`.

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/docs/getting-started.md

@@ -18,7 +18,7 @@ Optional (LLM + tools via AbstractCore):
 pip install "abstractruntime[abstractcore]"
 ```
 
-This installs AbstractCore 2.13.11 or newer, which matches the documented server auth, provider-key header routing, generated-media contracts, capability catalog, prompt-cache control plane, current tool behavior, public output-selector contract, and async/sync text-generation output-selector parity. Use `abstractruntime[multimodal]` when your workflows need common media, vision, voice, or audio dependencies.
+This installs AbstractCore 2.13.12 or newer, which matches the documented server auth, provider-key header routing, generated-media contracts, capability catalog, prompt-cache control plane, current tool behavior, public output-selector contract, and async/sync text-generation output-selector parity. Use `abstractruntime[multimodal]` when your workflows need common media, vision, voice, or audio dependencies.
 
 ## Mental model (source of truth)
 

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/docs/integrations/abstractcore.md

@@ -16,7 +16,7 @@ Implementation pointers (this repo):
 pip install "abstractruntime[abstractcore]"
 ```
 
-This extra installs AbstractCore 2.13.11 or newer. That is the supported baseline for the current server auth split (`Authorization` for server auth, `X-AbstractCore-Provider-API-Key` for provider overrides), generated-media contracts, capability catalog, prompt-cache control-plane endpoints, current tool catalog, AbstractCore's public output-selector contract, and async/sync text-generation output-selector parity.
+This extra installs AbstractCore 2.13.12 or newer. That is the supported baseline for the current server auth split (`Authorization` for server auth, `X-AbstractCore-Provider-API-Key` for provider overrides), generated-media contracts, capability catalog, prompt-cache control-plane endpoints, current tool catalog, AbstractCore's public output-selector contract, and async/sync text-generation output-selector parity.
 
 For AbstractCore's multimodal `generate(..., output=...)` path, use the newer baseline and optional media packages:
 
@@ -24,7 +24,7 @@ For AbstractCore's multimodal `generate(..., output=...)` path, use the newer ba
 pip install "abstractruntime[multimodal]"
 ```
 
-This installs `abstractcore[media,openai,vision,voice,audio]>=2.13.11`. Local image/voice generation still depends on the configured AbstractCore capability backends (for example AbstractVision and AbstractVoice, or OpenAI/OpenAI-compatible remote engines).
+This installs `abstractcore[media,openai,vision,voice,audio]>=2.13.12`. Local image/voice generation still depends on the configured AbstractCore capability backends (for example AbstractVision and AbstractVoice, or OpenAI/OpenAI-compatible remote engines).
 
 The MCP worker entrypoint uses the `mcp-worker` extra:
 

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/docs/limits.md

@@ -62,7 +62,7 @@ Returns a structured dict for UI/status display. (`src/abstractruntime/core/runt
 
 Returns a list of `LimitWarning` objects for limits approaching/exceeded. (`src/abstractruntime/core/models.py`, `src/abstractruntime/core/runtime.py`)
 
-As of v0.4.7, warnings are computed for:
+As of v0.4.9, warnings are computed for:
 - `iterations` (`current_iteration` vs `max_iterations`)
 - `tokens` (`estimated_tokens_used` vs `max_tokens`)
 

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/docs/proposal.md

@@ -79,7 +79,7 @@ AbstractRuntime stays dependency-light at the kernel level; concrete integration
 
 ## Status (implemented in this repository)
 
-As of v0.4.7:
+As of v0.4.9:
 - durable kernel: `RunState`, `WaitState`, `Runtime.start/tick/resume`
 - built-in waits + events: `WAIT_EVENT`, `WAIT_UNTIL`, `ASK_USER`, `EMIT_EVENT`
 - persistence backends: in-memory, JSON/JSONL, SQLite

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/docs/provenance.md

@@ -8,7 +8,7 @@ Implementation pointers:
 - model fields: `src/abstractruntime/core/models.py` (`StepRecord.prev_hash`, `StepRecord.record_hash`, `StepRecord.signature`)
 - hash-chain decorator + verifier: `src/abstractruntime/storage/ledger_chain.py`
 
-## What is implemented (v0.4.7)
+## What is implemented (v0.4.9)
 
 - `HashChainedLedgerStore(inner_store)` — wraps any `LedgerStore` to compute hashes on append
 - `verify_ledger_chain(records)` — validates the chain and returns a verification report

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "AbstractRuntime"
-version = "0.4.7"
+version = "0.4.9"
 description = "AbstractRuntime: a durable graph runner designed to pair with AbstractCore."
 readme = "README.md"
 requires-python = ">=3.10"
@@ -36,24 +36,44 @@ classifiers = [
 dependencies = [
   # Required to resolve stable structured-output schema refs like:
   # {"$ref":"abstractsemantics:kg_assertion_schema_v0"}
-  "abstractsemantics>=0.0.2",
+  "abstractsemantics>=0.0.3",
+  # Required for the Runtime-owned MEMORY_KG_* effect contract and TripleStore
+  # model types. Durable/vector backend dependencies such as LanceDB remain
+  # package extras owned by AbstractMemory and selected by hosts such as Gateway.
+  "AbstractMemory>=0.2.6",
 ]
 
 [project.optional-dependencies]
 # Enables `abstractruntime.integrations.abstractcore.*` imports.
 abstractcore = [
-  "abstractcore>=2.13.11",
+  "abstractcore>=2.13.12",
+]
+
+apple = [
+  "abstractcore[apple]>=2.13.12",
+]
+
+gpu = [
+  "abstractcore[gpu]>=2.13.12",
+]
+
+all-apple = [
+  "abstractcore[all-apple]>=2.13.12",
+]
+
+all-gpu = [
+  "abstractcore[all-gpu]>=2.13.12",
 ]
 
 # Enables AbstractCore multimodal generation helpers with common OpenAI-backed
 # image/voice capability packages.
 multimodal = [
-  "abstractcore[media,openai,vision,voice,audio]>=2.13.11",
+  "abstractcore[media,openai,vision,voice,audio]>=2.13.12",
 ]
 
 # Enables `abstractruntime-mcp-worker` with the default toolsets (includes bs4/lxml).
 mcp-worker = [
-  "abstractcore[tools]>=2.13.11",
+  "abstractcore[tools]>=2.13.12",
 ]
 
 # CI/test dependencies. The workflow runs the basic contract suite plus focused

abstractruntime-0.4.9/release-notes.md

@@ -0,0 +1,9 @@
+### Changed
+- Added `AbstractMemory>=0.2.6` as a base dependency so Runtime's
+  `MEMORY_KG_*` effect contract always has the AbstractMemory TripleStore
+  models available.
+
+### Notes
+- Runtime still does not depend on `AbstractMemory[lancedb]`. Hosts such as
+  AbstractGateway choose the durable/vector memory backend, path, embeddings,
+  and readiness policy.

{abstractruntime-0.4.7 → abstractruntime-0.4.9}/tests/test_packaging_extras.py

@@ -43,23 +43,36 @@ def test_runtime_exposes_abstractcore_and_worker_extras_with_gateway_aligned_flo
     pyproject = Path(__file__).resolve().parents[1] / "pyproject.toml"
     text = pyproject.read_text(encoding="utf-8")
 
+    assert '"abstractsemantics>=0.0.3"' in text
+    assert '"AbstractMemory>=0.2.6"' in text
+    assert '"AbstractMemory[lancedb]' not in text
     assert "[project.optional-dependencies]" in text
     assert "abstractcore = [" in text
     assert "mcp-worker = [" in text
-    assert '"abstractcore>=2.13.11"' in text
-    assert '"abstractcore[media,openai,vision,voice,audio]>=2.13.11"' in text
+    assert '"abstractcore>=2.13.12"' in text
+    assert '"abstractcore[media,openai,vision,voice,audio]>=2.13.12"' in text
 
     worker_block = _extract_optional_dependency_block(text, key="mcp-worker")
-    assert '"abstractcore[tools]>=2.13.11"' in worker_block
+    assert '"abstractcore[tools]>=2.13.12"' in worker_block
 
 
-def test_runtime_does_not_expose_hardware_profile_extras() -> None:
+def test_runtime_exposes_python_install_hardware_profile_cascades() -> None:
     pyproject = Path(__file__).resolve().parents[1] / "pyproject.toml"
     text = pyproject.read_text(encoding="utf-8")
 
     optional_keys = _extract_optional_dependency_keys(text)
 
-    assert "apple" not in optional_keys
-    assert "gpu" not in optional_keys
-    assert "all-apple" not in optional_keys
-    assert "all-gpu" not in optional_keys
+    assert "apple" in optional_keys
+    assert "gpu" in optional_keys
+    assert "all-apple" in optional_keys
+    assert "all-gpu" in optional_keys
+
+    apple_block = _extract_optional_dependency_block(text, key="apple")
+    gpu_block = _extract_optional_dependency_block(text, key="gpu")
+    all_apple_block = _extract_optional_dependency_block(text, key="all-apple")
+    all_gpu_block = _extract_optional_dependency_block(text, key="all-gpu")
+
+    assert '"abstractcore[apple]>=2.13.12"' in apple_block
+    assert '"abstractcore[gpu]>=2.13.12"' in gpu_block
+    assert '"abstractcore[all-apple]>=2.13.12"' in all_apple_block
+    assert '"abstractcore[all-gpu]>=2.13.12"' in all_gpu_block

abstractruntime-0.4.7/release-notes.md

@@ -1,11 +0,0 @@
-### Changed
-- Minimum `abstractcore` optional dependency increased to `>=2.13.11` for the `abstractcore`, `multimodal`, and `mcp-worker` extras so Runtime aligns with the current Core server-auth, provider-key, generated-media, and capability-catalog contracts.
-- AbstractCore integration imports now fail fast when a stale local AbstractCore install is older than the 2.13.11 Gateway/Core deployment baseline.
-- Documentation now makes the Gateway handoff explicit: hosts choose Runtime plus the Core/capability/memory profile, pass Core server URLs/auth headers deliberately, and keep provider clients, auth objects, model handles, and sessions out of durable runtime state.
-- Runtime no longer reads Gateway-owned environment variables directly. Prompt-cache defaults use explicit Runtime state or `ABSTRACTRUNTIME_PROMPT_CACHE`, read-file attachment registration limits use explicit Runtime state/payload values or `ABSTRACTRUNTIME_MAX_ATTACHMENT_BYTES`, and workflow bundle registries use shared/framework or explicit directories.
-
-### Testing
-- Added packaging boundary coverage proving Runtime exposes no fake hardware profile extras (`apple`, `gpu`, `all-apple`, `all-gpu`) and keeps the Core floors aligned.
-- Added import-boundary coverage proving the runtime kernel and package root do not import optional Core/Vision/Voice/Memory/Music stacks.
-- Added a remote client regression test proving Gateway auth/provider-key environment variables are not inherited as AbstractCore server auth or provider-key headers.
-- Added regression tests proving Gateway env vars alone do not enable prompt-cache keys, shrink attachment registration limits, or select workflow bundle registry directories.