AbstractRuntime 0.13.0__tar.gz → 0.14.0__tar.gz

{abstractruntime-0.13.0 → abstractruntime-0.14.0}/CHANGELOG.md

@@ -7,6 +7,83 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.14.0] - 2026-10-27
+
+Two features: the replay view with a durable per-run ledger cursor, and the session tool policy.
+Upgrade note (one way): hash-chained JSONL ledgers written by 0.14.0 carry `seq` on each line, and
+an older `verify_ledger_chain` reports those lines as tampered. Upgrade writers and verifiers together.
+
+### Added
+
+- **Replay view** (`abstractruntime.replay`, ADR 0010, backlog 0854; framework root 0993). One
+  pure, deterministic reducer turns a run tree's ledger records and snapshots into the view every
+  client renders (`replay_view_v1`).
+  - What the view holds:
+    - the run tree through delegation waits, with the workflow each run executes (bundle,
+      version, flow, the root's entrypoint);
+    - the status;
+    - the person-facing interaction: a delegated child's approval, a question, or a prompted
+      event, with the resume command to send;
+    - verbatim messages with their provenance (run, steps, seqs, artifacts);
+    - one activity per node execution (AbstractFlow's `executionIdFor` rules), with tool calls
+      matched to results;
+    - artifacts and usage.
+  - `$slim` pointers are resolved, and a windowed history is named in `warnings`.
+  - A wait is over when a resume OR a later step of the same run exists.
+  - `ReplayView.apply` folds newer records and returns a delta. `apply_delta` and `diff_views`
+    are the client side. `replay(all)` equals the fold of any chunking.
+  - Wait kinds agree with `automations.attention`. The person-facing kinds are tool_approval,
+    ask_user, and an event that carries a prompt. The non-person-facing kinds are delegation,
+    timer, job, pause, automation_wake and signal. The interaction carries `answer_payload`.
+  - A session tool policy's `abstract.tool_policy_decision` record is an activity
+    (`tool_policy`: allowed or denied by the conversation's policy, its revision and who set it),
+    never an interaction. The tool rows it names carry `decided_by: "session_policy"`.
+  - Every delta carries typed `changes` (status, interaction opened or closed, run, message,
+    activity, artifact, each with its run and seq), for push dispatch.
+  - Cursor tokens name each run by a collision-free prefix that is safe in a header.
+    `resolve_cursor_token` maps a token back.
+  - The conformance cases ship with the package (`abstractruntime.replay.conformance`), so a host
+    or a client port can run them. Guide: `docs/replay.md`.
+- **Durable ledger cursor** (gateway backlog 0082). A JSONL append after a torn last line (a
+  crash mid-write) now starts a new line; before, the fragment and the whole new record were
+  dropped together:
+  - Every ledger store numbers a run's records (`seq`). `JsonlLedgerStore` persists the number
+    on each line, allocated under an advisory file lock, so two processes never take the same
+    seq. Lines written before the field existed read as their position.
+  - `LedgerStore.list_after(run_id=, after=, limit=)` works on every store: an indexed read on
+    SQLite, a byte-offset seek on JSONL. `append()` returns the seq.
+  - `ObservableLedgerStore` passes `seq` to subscribers.
+  - `SqliteLedgerStore.import_records` copies a ledger in and keeps its `seq` values (migration).
+
+- **Session tool policy**: a conversation's standing "approve / deny without asking", applied before any approval
+  wait. `abstractruntime.storage.session_tool_policy` (`SqliteSessionToolPolicyStore`,
+  `InMemorySessionToolPolicyStore`, `session_policy_names`), `Runtime(session_tool_policy_store=...)` /
+  `Runtime.set_session_tool_policy_store()`. The TOOL_CALLS handler reads the run's session row once per batch: an
+  approved call runs with no wait, a denied call is refused with no wait, and each decision writes an
+  `abstract.tool_policy_decision` ledger record (who set the policy, when, which selector matched). It applies to
+  every run of the session (the run tree's root session: delegated children, resumes, restarts); approvals never
+  reach untrusted-input runs or automation occurrences (a deny does, and also wins over an approval that was shown
+  before it); never beyond the run's `allowed_tools`. Before this, "approve all" lived in each
+  client, which answered the wait after it arrived: the gate flashed in every app and in the ledger. See
+  [tool-approval.md](docs/tool-approval.md#session-tool-policy-a-conversations-standing-word).
+
+### Changed
+
+- Hash-chained ledgers: `seq` is persisted on each JSONL line and excluded from the hash by this
+  version's `compute_record_hash`. A verifier from an older version includes it, so it reports
+  every line written by this version as tampered. Upgrade every process that verifies a chain
+  (`verify_ledger_chain`) together with the writers.
+- `LedgerStore.list()` records carry `seq`. A consumer that compared records to `asdict(record)`
+  sees one more key. The hash chain excludes `seq` (it is the store's position, assigned after
+  the hash).
+
+## [0.13.1] - 2026-10-27
+
+### Added
+
+- `email_facade.resolve_srv_default` (AbstractCore's mailbox SRV lookup) is re-exported, so a host's mail code imports
+  it from the runtime facade like every other mail name.
+
 ## [0.13.0] - 2026-10-27
 
 Requires AbstractCore 2.30.0 or newer. Personal voice stores need AbstractVoice 0.19.0.

{abstractruntime-0.13.0 → abstractruntime-0.14.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: AbstractRuntime
-Version: 0.13.0
+Version: 0.14.0
 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
@@ -55,10 +55,22 @@ Description-Content-Type: text/markdown
 
 It is designed for long-running workflows that must survive restarts and explicitly model blocking (human input, timers, external events, subworkflows) without keeping Python stacks alive.
 
-**Version:** 0.8.2 • **Python:** 3.10+
+**Version:** 0.14.0 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
+## What's new in 0.14.0
+
+- **Replay view** (`abstractruntime.replay`): one deterministic reducer turns a run tree's ledger
+  into the view every client renders (status, the interaction to answer, messages, activities,
+  artifacts), with incremental deltas. Every ledger store now numbers records with a durable
+  per-run `seq` cursor (`list_after`). See [docs/replay.md](docs/replay.md).
+- **Session tool policy**: a conversation's standing approve/deny is applied before any approval
+  wait, with an `abstract.tool_policy_decision` audit record. See
+  [docs/tool-approval.md](docs/tool-approval.md#session-tool-policy-a-conversations-standing-word).
+- Upgrade note: hash-chained JSONL ledgers written by 0.14.0 fail an older `verify_ledger_chain`;
+  upgrade writers and verifiers together.
+
 ## AbstractFramework ecosystem
 
 AbstractRuntime is one component of the wider [AbstractFramework](https://github.com/lpalbou/AbstractFramework) ecosystem:

{abstractruntime-0.13.0 → abstractruntime-0.14.0}/README.md

@@ -4,10 +4,22 @@
 
 It is designed for long-running workflows that must survive restarts and explicitly model blocking (human input, timers, external events, subworkflows) without keeping Python stacks alive.
 
-**Version:** 0.8.2 • **Python:** 3.10+
+**Version:** 0.14.0 • **Python:** 3.10+
 
 **Status:** pre-1.0 (API may evolve). For production use, pin versions and follow `CHANGELOG.md`.
 
+## What's new in 0.14.0
+
+- **Replay view** (`abstractruntime.replay`): one deterministic reducer turns a run tree's ledger
+  into the view every client renders (status, the interaction to answer, messages, activities,
+  artifacts), with incremental deltas. Every ledger store now numbers records with a durable
+  per-run `seq` cursor (`list_after`). See [docs/replay.md](docs/replay.md).
+- **Session tool policy**: a conversation's standing approve/deny is applied before any approval
+  wait, with an `abstract.tool_policy_decision` audit record. See
+  [docs/tool-approval.md](docs/tool-approval.md#session-tool-policy-a-conversations-standing-word).
+- Upgrade note: hash-chained JSONL ledgers written by 0.14.0 fail an older `verify_ledger_chain`;
+  upgrade writers and verifiers together.
+
 ## AbstractFramework ecosystem
 
 AbstractRuntime is one component of the wider [AbstractFramework](https://github.com/lpalbou/AbstractFramework) ecosystem:

{abstractruntime-0.13.0 → abstractruntime-0.14.0}/docs/README.md

@@ -29,7 +29,7 @@ In this repo, the AbstractCore wiring lives under `src/abstractruntime/integrati
 - `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 on the primary or any other mailbox of the user, mail verbs for flows (changes and sends only on a Read and write mailbox: `email_mailbox_read_only`, `email_mailbox_cannot_send`), 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)
+- `tool-approval.md` — tool risk tiers, the run-policy rank ceiling, the session tool policy (a conversation's standing approve/deny, applied before any approval wait), and per-call refiners (the `send_email` recipient rule: self and pre-authorised recipients)
 - `api.md#workflowbundles-flow-and-visualflow-distribution` — VisualFlow compiler APIs, media nodes, and document nodes (`read_pdf` / `write_pdf` / `write_docx`)
 - `api.md#sessions-and-history` — session history replay: one window, the most recent 50,000 tokens of whole turns (`HISTORY_REPLAY_MAX_TOKENS`), returned as a `ReplayedHistory` whose `.report` records what was replayed and dropped
 - `api.md#conversation-search` — keyword search over a plane's conversations (`ConversationSearch`): questions, answers and the turn's artifacts, one SQLite FTS5 trigram index per plane, incremental `sync` with a time budget, exact then fuzzy matching
@@ -41,6 +41,7 @@ In this repo, the AbstractCore wiring lives under `src/abstractruntime/integrati
 - `entity-runtime.md` — per-entity runtimes for summoned entities: homes, the one-writer lease, act-only diary privacy (`$act_only` refs), durable visit waits with deadlines
 - `evidence.md` — artifact-backed evidence capture for external-boundary tools
 - `mcp-worker.md` — MCP worker CLI (`abstractruntime-mcp-worker`)
+- `replay.md` — the replay view: one reconstruction of a run tree (status, the interaction to answer, messages, one activity per execution, artifacts, usage, the workflow it executes) that every client renders; the durable cursor (`seq`, `list_after`); conformance fixtures
 - `snapshots.md` — snapshot/bookmark model and stores
 - `provenance.md` — tamper-evident hash-chained ledger
 - `limits.md` — runtime-aware `_limits` namespace and APIs

abstractruntime-0.14.0/docs/adr/0008_integration_facades_are_the_complete_host_surface.md

@@ -0,0 +1,80 @@
+# ADR 0008: Runtime integration facades are the complete host surface for AbstractCore
+
+Status: Accepted.
+Date: 2026-10-27
+
+## Context
+
+Hosts (AbstractGateway first) depend on AbstractRuntime, and AbstractRuntime owns the
+AbstractCore integration (ADR 0001, 0004-0007). The gateway enforces its side with a test that
+fails on any direct `abstractcore` import. That rule only holds if every AbstractCore name a host
+legitimately needs is reachable through a runtime facade. On 2026-10-27 the gateway's mailbox
+code needed AbstractCore's SRV lookup (`resolve_srv_default`), the email facade did not re-export
+it, and the host imported AbstractCore directly: the boundary test went red and stayed red
+across a release line. The hole was not the import; it was a facade that lagged behind what the
+host needed, with no rule saying whose job it was to close the gap.
+
+## Decision
+
+1. The modules under `abstractruntime.integrations.abstractcore` whose name ends in `_facade`
+   (discovery, host, config, run, email, structured, voice, telegram, comms, mcp, tool inventory,
+   server, data registry) are the ONLY surface through which a host reaches AbstractCore. They
+   are complete by contract: a name a host needs and cannot import from a facade is a runtime
+   defect, fixed by adding the re-export or method in the runtime and cutting a patch release.
+2. A host never works around a missing name by importing `abstractcore` directly, vendoring the
+   code, or guessing a replacement. It raises the gap to the runtime (backlog item or PR) and
+   pins the runtime floor that carries the fix.
+   The same holds one level down and for whole capabilities, not only names: when a host finds
+   a FEATURE or CAPABILITY missing (a voice operation, a mail verb, a media task, a lookup), the
+   runtime, which does the integration, surfaces it through a facade, a typed refusal
+   (`CapabilityUnavailableError`, a 501 with the install hint) or a backlog item. A missing
+   capability is never a reason for a host to import a lower-level package (AbstractCore,
+   AbstractVoice, AbstractMemory, their dependencies) directly.
+3. A re-export is unchanged in identity (`facade.name is abstractcore.module.name`) and listed in
+   the facade's `__all__`; the facade documents which AbstractCore version introduced the name.
+4. The facades are additive within a minor line: a name, once exported, is not removed without
+   a deprecation note and a major or minor bump.
+
+## Consequences
+
+### Positive
+- The host's boundary test is a true gate: green means every AbstractCore access is a runtime
+  facade, so a Core change breaks at most one package.
+- Version floors stay layered: a host pins the runtime, the runtime pins Core.
+
+### Negative
+- A host feature that needs one new Core name waits for a runtime patch release (about 20
+  minutes with the release workflow), and the host's runtime floor moves with it.
+- The runtime carries thin re-exports it does not use itself.
+
+### Neutral
+- Patch releases of the runtime for facade additions are normal, not exceptional.
+
+## Enforcement
+- Code review: a runtime PR that adds a host-facing Core name adds it to the facade's `__all__`
+  (and to a names list such as `email_facade.GATEWAY_NAMES` where one exists) with a one-line
+  comment naming the Core version and the host need.
+- Hosts cite this ADR in their own boundary rule (AbstractGateway ADR 0001) and never add an
+  exemption to their import-boundary test for a name a facade could carry.
+- A facade gap found during host work becomes a runtime backlog item or PR before the host
+  ships; the host's changelog names the runtime version that closes it.
+
+## Validation
+- `tests/test_email_review_fixes.py`: the email facade's export set equals Core's plus the
+  runtime's additions, every `GATEWAY_NAMES` entry imports, and re-exports keep identity.
+- AbstractGateway `tests/test_gateway_import_boundary.py` stays green against the released
+  runtime floor the gateway pins.
+- Release check: the runtime's docs list each facade's host-facing names
+  (`docs/integrations/abstractcore.md`, `docs/api.md`).
+
+## Backlog links
+- Originating: AbstractGateway backlog 1044 (mailbox Read and write access) needed
+  `resolve_srv_default`; closed by runtime 0.13.1 (`email_facade.resolve_srv_default`).
+- Adoption: AbstractGateway `tests/test_gateway_import_boundary.py` (backlog 0059).
+
+## Related
+- ADR 0001 (layered coupling), 0004 (media execution), 0005 (discovery queries), 0006 (bloc
+  prompt cache): the per-area facades this ADR generalises.
+- `src/abstractruntime/integrations/abstractcore/email_facade.py`, `voice_facade.py`,
+  `discovery_facade.py`.
+- AbstractGateway ADR 0001: AbstractCore access goes through AbstractRuntime facades.

abstractruntime-0.14.0/docs/adr/0010_one_replay_many_views.md

@@ -0,0 +1,104 @@
+# ADR 0010: One replay of the ledger, many views
+
+Status: Accepted.
+Date: 2026-10-27
+
+## Context
+
+The run ledger is the record of a run. Every client that shows a run needs the same few facts
+about it: its status, the approval or question it is waiting on, the replies, the tool calls and
+the steps. Until this decision, each client worked those facts out for itself from raw ledger
+records, run snapshots and its own memory. Panel-chat, the AbstractCode terminal client, the
+desktop Assistant, the iPhone and watch apps, the Observer, AbstractFlow and both gateway
+consoles each had their own reconstruction. The inventory, with file:line anchors, is in
+[backlog 0854](../backlog/planned/0854_replay_view.md). The reconstructions disagreed on the same
+run:
+
+- 2026-09-29: a delegated child's tool approval showed as "Approval needed" on one client and as
+  "Running a tool" on another. A delegation wait displaced the person-facing wait, and a `$slim`
+  dedup pointer was left unresolved.
+- 2026-10-04: a `wait_until` timer with no resume record left 182 of 3,278 runs showing "Waiting
+  for you" after they had completed.
+- 2026-10-11: one Agent node execution showed as two steps, because nothing in the records names
+  the execution.
+
+The operator's ruling (framework root backlog 0993,
+`abstractframework/docs/backlog/planned/0993_one_ledger_replay_many_views.md`): "there should be
+only one unified way to replay the ledger, on top of which we could have different views", and
+"logic should not be in the thin client". Each client decides what to show and how to forward
+the requests of the users and entities it serves.
+
+Durability had a gap of its own. The SQLite ledger had a per-run `seq` and the JSONL ledger had
+none. The gateway's cursor was a list position, and the file-to-SQLite migration renumbered
+records (gateway backlog 0082).
+
+## Decision
+
+1. **One reducer, in the runtime.** `abstractruntime.replay` is the only code that turns ledger
+   records into run state for display:
+   - `replay(records_by_run, runs_by_id)` folds a run tree's records and durable snapshots into a
+     `ReplayView`.
+   - `ReplayView.apply(records)` folds newer records into it and returns the delta.
+   - `replay(all)` is `apply` over every record, so it equals folding the same records in chunks.
+
+   The reducer is pure and deterministic: no I/O and no clock, and its input is records plus
+   snapshots. Its JSON is versioned (`replay_view_v1`). A change in meaning is a new version,
+   never a silent change.
+2. **The reducer owns these rules.** Each rule below was a divergence between clients:
+   - The run tree comes from delegation waits (`subworkflow:<id>`), `start_subworkflow` results
+     and the snapshots' `parent_run_id`. When the two disagree, the ledger's link wins.
+   - A wait is over when its run records a `resume` for its key OR any later step of the same run
+     exists. Observability events are not steps.
+   - The person-facing interaction is the newest open approval, question or prompted event
+     anywhere in the tree. A delegation, a timer or a pause never is one.
+   - Status precedence: a terminal snapshot, then the ledger's terminal record, then an open wait,
+     then running.
+   - `$slim` pointers are resolved against the STARTED record. A pointer that cannot be resolved
+     is dropped and named in `warnings`.
+   - Executions follow AbstractFlow's `executionIdFor` rules.
+   - Each run names the workflow it executes (`bundle_id@version:flow_id`; the root's flow is its
+     entrypoint). Workflows are the framework's native unit.
+3. **The durable cursor is the per-run ledger `seq`.**
+   - Every ledger store numbers records 1, 2, 3, … per run. JSONL persists the number on append,
+     allocated under an advisory file lock. A line written before the field existed is numbered
+     by its position.
+   - Every store answers `list_after(run_id, after, limit)`.
+   - `SqliteLedgerStore.import_records` keeps `seq` across a migration.
+   - A view's cursor is the seq of each run in its tree. Its token `<run id prefix>:<seq>.…` is
+     the view's ETag and the SSE event id.
+4. **Hosts serve the view, and clients render it.**
+   - AbstractGateway serves `GET /runs/{id}/view` (ETag, 304, `?at=<token>`) and
+     `GET /runs/{id}/view/stream` (one `view`, then `delta` events, `Last-Event-ID`). There is
+     one cached view per run tree, folded once per appended record and fanned out to every
+     subscriber, with no timed re-parse.
+   - Clients act through the host's commands. The view's `interaction.command` is the resume to
+     send. Clients hold no run state that the server could replay.
+   - A client may keep a local view only as a cache of these deltas (`apply_delta`). It never
+     builds one from raw records.
+
+## Enforcement
+
+- A client or host change that derives status, waits, tool rows or messages from raw ledger
+  records, outside `abstractruntime.replay`, conflicts with this ADR. The fix is a reducer change
+  with a fixture, or a view field.
+- A reducer change that alters an existing fixture's expected view needs one of two things: the
+  fixture's diff in the PR and its reason, or a new `replay_view_vN` when the meaning of a field
+  changes.
+- A new ledger store implements `list_after`, and its records carry `seq`. A migration between
+  stores preserves `seq`.
+
+## Validation
+
+- `tests/test_replay_conformance.py`: the conformance cases shipped in
+  `abstractruntime.replay.conformance` (redacted real ledgers and synthetic cases), each with its
+  expected view and hand-written semantic checks.
+- `tests/test_replay_invariants.py`: replay equals fold over any chunking and interleaving,
+  idempotence, delta round trips, and header-safe cursor tokens.
+- `tests/test_ledger_cursor_invariants.py` and `tests/test_jsonl_ledger_seq_cross_process.py`:
+  the invariants of gateway backlog 0082 at store level (completeness, `list_after` equals a
+  replay from the same cursor, cursor stability across reopen and migration, recovery), and dense
+  seqs under concurrent processes.
+- AbstractGateway `tests/test_gateway_replay_view.py`, `tests/test_migrate_preserves_ledger_seq.py`
+  and the principal isolation matrix: the routes through the real app.
+- Every client that renders runs runs the conformance fixtures in its CI once it migrates
+  (backlog 0854).

{abstractruntime-0.13.0 → abstractruntime-0.14.0}/docs/adr/README.md

@@ -20,6 +20,8 @@ When you ask "why is it designed this way?", the answer is in an ADR. ADRs are:
 | 0005 | [Runtime Owns AbstractCore Host Discovery Queries](0005_runtime_owns_abstractcore_host_discovery_queries.md) | Accepted | 2026-05-20 | Hosts should ask Runtime for Core discovery/catalog snapshots |
 | 0006 | [Runtime Owns Durable AbstractCore Bloc Prompt-Cache Control](0006_runtime_owns_durable_abstractcore_bloc_prompt_cache.md) | Accepted | 2026-05-20 | Hosts should use Runtime for durable bloc/KV controls and binding-aware execution |
 | 0007 | [Runtime Relays Core-Owned Model Residency Truth](0007_runtime_relays_core_owned_model_residency_truth.md) | Accepted | 2026-05-21 | Runtime reports loaded state only from AbstractCore residency truth |
+| 0008 | [Integration Facades Are the Complete Host Surface](0008_integration_facades_are_the_complete_host_surface.md) | Accepted | 2026-10-27 | Every AbstractCore name or capability a host needs is surfaced by the runtime (facade re-export, typed refusal, backlog); a gap is a runtime patch, never a host import of a lower-level package |
+| 0010 | [One Replay of the Ledger, Many Views](0010_one_replay_many_views.md) | Accepted | 2026-10-27 | `abstractruntime.replay` is the only reconstruction of run state from the ledger; hosts serve its view, clients render it; the per-run ledger `seq` is the durable cursor |
 
 ## Relationship to Backlog
 
@@ -34,6 +36,8 @@ ADRs explain *why*. Backlog items explain *what* and *how*.
 | 0005 | `backlog/completed/026_runtime_host_discovery_facade_for_core_catalogs.md` |
 | 0006 | `backlog/completed/027_runtime_durable_bloc_prompt_cache_facade.md` |
 | 0007 | `backlog/completed/0035_model_residency_provider_truth_for_local_http_clients.md`, `backlog/proposed/0036_local_media_residency_bridge_to_core_residency.md` |
+| 0008 | AbstractGateway backlog 1044 (mailbox access) and `tests/test_gateway_import_boundary.py`; runtime 0.13.1 `email_facade.resolve_srv_default` |
+| 0010 | `backlog/planned/0854_replay_view.md`; AbstractGateway backlog 0943 (view routes), 0082 (durable cursor); framework root 0993 |
 
 ## Adding New ADRs
 

{abstractruntime-0.13.0 → abstractruntime-0.14.0}/docs/api.md

@@ -133,6 +133,12 @@ Run index and creation (all built-in run stores, including the offloading wrappe
 - `JsonFileRunStore` event-wait and mailbox indexes (`list_event_waiters`, `list_event_waiters_by_prefix`, `list_mailbox_runs`) see what another process saved on the same folder (a split gateway: API process + runner process). Before each lookup the store reads its change signal (the creation log's size and the folder's mtime): when either moved, or at least every `EVENT_INDEX_REFRESH_S` (2 s), it stats each running or waiting run and re-reads the ones whose file changed since it last filed them. An idle store pays two stats per lookup; its own saves are never re-read. `event_index_stats()` returns `{refreshes, refiled, tracked}`.
 - `JsonFileRunStore.change_token()` answers "did any run of this folder change?" with one stat: `(creation-log size, active-index counter)`. Every save, create and delete through the store moves the counter; another process's create, delete or became-active line moves the log size. Not seen: another process re-saving a run that stays active (one ticking process per folder); ending a run, or re-saving a finished one, writes `=<run_id>`. `changed_run_ids(token)` names the runs this store changed since `token`, or `None` when that is unknown (the log moved, or more than 8,192 changes ago). `ObservableLedgerStore.change_token()` / `changed_run_ids(token)` do the same for ledger appends (process-local). The gateway runner's scan gate and its mail notification check compare these tokens instead of reading the directory.
 
+The durable cursor (ADR 0010):
+- Every ledger store numbers a run's records 1, 2, 3, … and `list()` returns each record with its `seq`. `JsonlLedgerStore` writes it on each line, allocated under an advisory file lock that spans the head read and the write, so another process appending to the same run never takes the same number. A line written before the field existed is numbered by its position. `append()` returns the seq.
+- `LedgerStore.list_after(*, run_id, after, limit=1000) -> (records, last_seq)`: the records after a seq. SQLite does an indexed read; JSONL seeks to the byte offset where the previous read ended; the default implementation filters `list()`. The decorators (observable, hash-chained, offloading) delegate it.
+- `ObservableLedgerStore` hands subscribers the record with its `seq`.
+- `SqliteLedgerStore.import_records(run_id, records)` copies a run's ledger in, keeping each `seq`. A migration from files to SQLite therefore keeps every cursor valid. It refuses a run that already has records.
+
 Common decorators:
 - `ObservableLedgerStore` for subscriptions (`src/abstractruntime/storage/observable.py`)
 - `HashChainedLedgerStore` + `verify_ledger_chain(...)` for tamper-evidence (`src/abstractruntime/storage/ledger_chain.py`)
@@ -326,6 +332,25 @@ This produces a portable record of a run’s state + ledger + artifacts suitable
 When available, it also includes `resolved_actions`: bounded capability/action summaries derived
 from Core route resolution and persisted from `LLM_CALL` results.
 
+## Replay view (one reconstruction of a run, every client)
+
+Implementation: `src/abstractruntime/replay/` (ADR 0010). Guide: [replay.md](replay.md).
+
+- `replay(records_by_run, runs_by_id=None, *, root_run_id=None) -> ReplayView`: folds a run
+  tree's ledger records (`{run_id: [records in ledger order]}`) and durable snapshots
+  (`RunState` or dicts) into a view. Pure and deterministic.
+- `ReplayView.apply(records, *, runs_by_id=None) -> delta`: folds newer records and snapshots.
+  The same delta is kept as `view.last_delta`. `apply(view, records)` is the module-level form.
+- `ReplayView.to_json()`: the view, `replay_view_v1` (status, `interaction`, `open_waits`,
+  `runs`, `messages`, `activities`, `artifacts`, `usage`, `workflow`, `cursor`, `warnings`).
+  Other reads: `cursor`, `run_ids`, `last_seq(run_id)`, `status()`, `run_statuses()` and
+  `is_terminal()`.
+- `apply_delta(view_json, delta)`, `diff_views(old, new)` and `parse_cursor_token(token)`: the
+  client side of a delta, the delta between two views, and a cursor token as `{run id prefix:
+  seq}`.
+- `wait_kind(wait)`, `workflow_ref(workflow_id)`, `PERSON_FACING_KINDS`,
+  `TERMINAL_STATUSES`, `REPLAY_VIEW_VERSION`.
+
 ## Runtime-owned integrations
 
 ### AbstractCore (LLM + tools)

{abstractruntime-0.13.0 → abstractruntime-0.14.0}/docs/backlog/README.md

@@ -12,7 +12,7 @@ If you are new to the project, start with `../README.md` and `../architecture.md
 
 ## Counts
 
-- Planned: 29
+- Planned: 31
 - Proposed: 14
 - Completed: 37
 - Deprecated: 13
@@ -145,6 +145,8 @@ mtime). The anticipated ADR ("an automation is its controller root run") is not
 | 028* | `planned/028_selective_artifact_rehydration.md` |
 | 0070 | `planned/0070_standalone_wui_browser_session_security_contract.md` |
 | 0848 | `planned/0848_automations_v2_external_event_inbox_and_run_triggers.md` (P2, after 0847's release; contracts pass 2026-09-27) |
+| 0853 | `planned/0853_session_tool_policy_before_the_approval_wait.md` (P1; abstractruntime 0.14.0: a conversation's approve/deny stored per session and applied before any approval wait, with an `abstract.tool_policy_decision` ledger record; gateway routes and client wiring remain) |
+| 0854 | `planned/0854_replay_view.md` (P0; abstractruntime 0.14.0 carries the reducer, the durable per-run `seq` cursor and the conformance cases; gateway routes and client migration remain; ADR 0010) |
 | 0044 | `planned/runtime_systemic_reliability/0044_meta_analysis_record.md` (track source record) |
 | 0045 | `planned/runtime_systemic_reliability/0045_crash_replay_harness_and_ordering_invariant.md` |
 | 0046 | `planned/runtime_systemic_reliability/0046_per_run_driver_exclusion.md` |

abstractruntime-0.14.0/docs/backlog/planned/0853_session_tool_policy_before_the_approval_wait.md

@@ -0,0 +1,59 @@
+# 0853-abstractruntime: [FEATURE] Session tool policy: a conversation's approve/deny applied before the approval wait
+
+> Created: 2026-10-27
+> Status: Planned (released in abstractruntime 0.14.0, 2026-10-27, PR #7 merge `ecfbb28`; remaining: the gateway floor and the follow-ups below)
+> Type: feature
+> Priority: P1
+> Labels: tool-approval, ledger, replay, sessions
+> Root: framework 1061 (cross-repo); related framework 0993 (one ledger replay, many views)
+
+## Summary
+
+"Approve all" / "approve this kind" becomes a durable, server-side session policy that the
+TOOL_CALLS handler consults before deciding whether a batch waits. Covered calls run with no wait
+and no interaction; denied calls are refused with no wait. Each decision is an
+`abstract.tool_policy_decision` ledger record.
+
+## Why
+
+Operator, 2026-10-27, verbatim: "when a user gives permission to either all tools of a kind (e.g.
+fetch url) OR all tools (all available/authorized for the user and authorized by the gateway), I
+still see very quickly the gate approval showing up in apps and disappearing. Before sending the
+gate approval, check whether the tool is already approved for the current session, and if so, do
+not send the gate approval at all."
+
+Before: the runtime knew only the start-time `_runtime.tool_policy`
+(`effect_handlers.py` `_execute_with_run_policy_unscoped`), so it emitted `approval_required` for
+every gated call; clients answered it after it arrived (panel-chat `autoApproveCurrentWait`,
+desktop `should_auto_approve_tool_batch`, iPhone `applyConversationTrust`). The gate showed in
+every client and in the replayable ledger.
+
+## What ships (branch `feat/session-tool-policy`)
+
+- `src/abstractruntime/storage/session_tool_policy.py`: `SessionToolPolicyStore` protocol,
+  `InMemorySessionToolPolicyStore`, `SqliteSessionToolPolicyStore` (revision, `if_revision`
+  conflicts, append-only history), `session_policy_names`.
+- `Runtime(session_tool_policy_store=...)`, `Runtime.set_session_tool_policy_store()`; the tick
+  attaches it to the run (`_runtime_session_tool_policy_store`).
+- `effect_handlers.py`: `_session_tool_policy_for_run` (scope rules), deny in the pre-pass,
+  approve inside `_execute_with_run_policy` (both the run-policy and the static branch),
+  `_append_tool_policy_record` (no record, no auto-approval).
+- Docs: `docs/tool-approval.md#session-tool-policy-a-conversations-standing-word`.
+- Tests: `tests/test_session_tool_policy.py` (no wait + audit record, delegated child, mid-run
+  change with the one-off path intact, deny, mixed batch still waits, start-time require list
+  overridden, out-of-scope runs keep asking, reset, restart via sqlite, no record means no
+  auto-approval, store revisions/history). Mutation-checked.
+
+## Remaining
+
+- The gateway's `ABSTRACTRUNTIME_FLOOR` raised to 0.14.0 (released 2026-10-27).
+- Covering tools enabled after an `all` grant (today they ask until the person grants again).
+- Answering waits that already exist when a policy is written (today the client answers the shown
+  one).
+
+## Acceptance criteria
+
+- [x] No `approval_required` wait for a session-approved call, in the root run or a delegated
+      child; an audit record instead.
+- [x] Deny refuses with no wait; out-of-scope runs unchanged.
+- [ ] Released, and the gateway floor raised.