AbstractRuntime 0.9.1__tar.gz → 0.10.0__tar.gz

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

@@ -5,6 +5,29 @@ 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).
 
+## [0.10.0] - 2026-10-15
+
+### Added
+
+- Trigger source `schedule@2`: `{kind: "daily", at: "HH:MM"}`, `{kind: "weekly", days: [...], at}` and `{kind: "monthly", day: 1..31 | "last", at}` evaluated on wall time in the config's `time_zone` (IANA, converted with `zoneinfo`: a skipped wall time runs at the shifted instant, a repeated one runs once; a day beyond the month's length runs on its last day), plus `{kind: "every"}` and `{kind: "once"}` with `schedule@1`'s meaning (a `once` may give a wall time `at` in `time_zone`). Same coalescing and pause policy as `schedule@1`; event ids `schedule@2:<binding_id>:<tick>`. `validate_time_zone(name)` and `time_zone_names()` are exported from `abstractruntime.triggers`. See `docs/automations.md`.
+- `integrations.abstractcore.config_facade.voice_input_hint(route, host=None)`: AbstractCore's served one-line hint for a configured speech-input route (`abstractcore.config.recommendations.voice_input_hint`, AbstractCore >= 2.26.0), so a host such as AbstractGateway serves it without importing AbstractCore itself. The AbstractCore floor is 2.26.0.
+- A limit on an execution wire: `edge.data.loopLimit = {"max": N}` (the editor's ↺N badge on a wire that makes execution repeat). Before compile, `visual/loop_limit_lowering.py` turns it into a `loop_limit` node on that wire (`again` to the wire's target; `limit_reached` to the other branch when the wire leaves an If/Else and that branch is not itself a limited wire, else nothing: the path ends at the limit), re-keying the target's per-path values and entry list. A run tree shows the lowered node as "Loop limit N". `VisualEdge` now carries `data` (older runtimes never read it, so a limited flow runs unlimited there).
+- VisualFlow `get_vars` node (Get Variables): a data node with one output per variable, its pin id the variable name (dotted paths allowed); each output reads the run variable's current value, or null when it is not set.
+- VisualFlow `loop_limit` node (Loop Limit): exec outputs `again` (taken while fewer than `max` passes were let through) and `limit_reached` (then the count starts again from 0), data output `count` (the pass number). The count lives in `run.vars._temp.loop_limits.<node id>`, so it survives pause/resume. It belongs to the current iteration of the enclosing ForEach / For / While (each item, and each new entry of that loop, starts from 0); with no enclosing loop, to the run. Its `max` comes only from its own pin, never from the previous step's output.
+- VisualFlow `add_to_list` node (Add to List Variable): `name`, `item` (added as one element), `items` (each element added); a missing or null variable starts as `[]`; a variable that holds something else, or `items` that is not a list, fails the step naming it; reads and writes in one step; output `list`.
+- String Template: a placeholder reads an input pin of its name, then the `vars` object, then the run variable (top-level names not starting with `_`). A list or object with no filter is written as JSON (it was Python's `str()`).
+
+### Changed
+
+- An execution wire that loops back out of a ForEach / For / While body (from inside the body to the loop node itself or to anything before it) is refused when the flow compiles: "Wire <source>.<pin> -> <target> goes back out of <loop>'s loop body: the run would never end. A path inside a loop body can only repeat within the body; to repeat the whole loop, wire the loop-back after the loop's done." Such a wire re-entered the loop with its frame still on the control stack, so the stack grew by one frame per pass and the run never ended (a Loop Limit on it never reached its max). A loop-back that goes through the loop's `done`, or that stays inside the body, is unchanged (`visual/loop_back_check.py`).
+- `schedule@1` is unchanged: its configs normalize byte for byte as before and existing automations keep their tick grid (`tests/test_schedule_v1_corpus.py` freezes the 0.9.1 answers on real automation configs).
+
+### Fixed
+
+- Set Variables (and Add to List Variable) only take what their own pins carry (a wire, a value set on the node, an expression). Before, keys of the previous step's output were written as variables too.
+- Set Variables (`set_vars`): every data input pin besides `updates` is one variable, written under the pin's id (dotted paths nest) with its value: a wire, else the pin's default. These win over the same name in the `updates` object. AbstractFlow edits them as rows (name, type, value), so one node initialises several variables, wired or literal. A flow using such rows needs this runtime: an older one writes only `updates`. Test: `tests/test_visual_set_vars_pins.py`.
+- VisualFlow reroute ("relay") nodes: a dot in AbstractFlow that lets one output feed several inputs along a tidy path. They are visual only: before compiling, every chain `source -> reroute (-> reroute ...) -> target` is rewired `source -> target` and the reroutes are removed (`visualflow_compiler/visual/reroute_lowering.py`, run before the multi-entry lowering). A reroute with no source feeds nothing (its targets keep their defaults); per-path values that name a reroute point at its real source. Data wires only: an execution wire through a reroute, a second input into one, or a cycle of reroutes is refused with a message naming the wire. A flow with a connected reroute needs this runtime (older ones refuse the unknown node type). Test: `tests/test_visual_reroute_lowering.py`.
+
 ## [0.9.1] - 2026-10-08
 
 ### Security

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: AbstractRuntime
-Version: 0.9.1
+Version: 0.10.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
@@ -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.25.1
+Requires-Dist: abstractcore>=2.26.0
 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.25.1; extra == 'apple'
+Requires-Dist: abstractcore[apple]>=2.26.0; 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.25.1; extra == 'gpu'
+Requires-Dist: abstractcore[gpu]>=2.26.0; 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'
@@ -159,7 +159,7 @@ Kernel (import-light):
 - Stop that reaches the running effect: `Runtime.cancel_run(...)` signals the in-flight model or tool call, which ends as a `cancelled` ledger record (never retried); a model unload stops the calls using that model first (`docs/api.md`)
 - host pause at step boundaries: `Runtime.tick(..., step_gate=...)`
 - run-tree tool ceiling: an explicit `allowed_tools` list can only narrow across child runs, and approval policy never widens it
-- automations: run a workflow on a schedule (`schedule@1`, fixed UTC intervals), when mail arrives (`email.received@1`, `docs/email.md`) or on request (`manual@1`) as a durable controller run whose occurrences are deterministic child runs and session turns, with commands, independent or growing context, discussions forked at any occurrence (own workspace, automation workspace mounted read-only), tool approval, typed waits and quiet-by-default notifications (`docs/automations.md`)
+- automations: run a workflow on a schedule (`schedule@1` fixed UTC intervals; `schedule@2` adds daily, weekly and monthly rules at a wall time in an IANA time zone), when mail arrives (`email.received@1`, `docs/email.md`) or on request (`manual@1`) as a durable controller run whose occurrences are deterministic child runs and session turns, with commands, independent or growing context, discussions forked at any occurrence (own workspace, automation workspace mounted read-only), tool approval, typed waits and quiet-by-default notifications (`docs/automations.md`)
 - explicit run ids: `Runtime.start(..., run_id=...)` creates a run only if the id is free (`RunStore.create_if_absent`), and `run_mutation_lock(run_id)` serializes a run's writers in a process
 
 Durability + storage:

{abstractruntime-0.9.1 → abstractruntime-0.10.0}/README.md

@@ -108,7 +108,7 @@ Kernel (import-light):
 - Stop that reaches the running effect: `Runtime.cancel_run(...)` signals the in-flight model or tool call, which ends as a `cancelled` ledger record (never retried); a model unload stops the calls using that model first (`docs/api.md`)
 - host pause at step boundaries: `Runtime.tick(..., step_gate=...)`
 - run-tree tool ceiling: an explicit `allowed_tools` list can only narrow across child runs, and approval policy never widens it
-- automations: run a workflow on a schedule (`schedule@1`, fixed UTC intervals), when mail arrives (`email.received@1`, `docs/email.md`) or on request (`manual@1`) as a durable controller run whose occurrences are deterministic child runs and session turns, with commands, independent or growing context, discussions forked at any occurrence (own workspace, automation workspace mounted read-only), tool approval, typed waits and quiet-by-default notifications (`docs/automations.md`)
+- automations: run a workflow on a schedule (`schedule@1` fixed UTC intervals; `schedule@2` adds daily, weekly and monthly rules at a wall time in an IANA time zone), when mail arrives (`email.received@1`, `docs/email.md`) or on request (`manual@1`) as a durable controller run whose occurrences are deterministic child runs and session turns, with commands, independent or growing context, discussions forked at any occurrence (own workspace, automation workspace mounted read-only), tool approval, typed waits and quiet-by-default notifications (`docs/automations.md`)
 - explicit run ids: `Runtime.start(..., run_id=...)` creates a run only if the id is free (`RunStore.create_if_absent`), and `run_mutation_lock(run_id)` serializes a run's writers in a process
 
 Durability + storage:

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

@@ -36,7 +36,7 @@ In this repo, the AbstractCore wiring lives under `src/abstractruntime/integrati
 
 ## Features (reference)
 
-- `automations.md` — automations: a workflow run on a schedule or on request as a durable controller run; triggers (`schedule@1`, `manual@1`, `email.received@1`, entry-point sources), commands, independent or growing context, discussions forked at any occurrence (own writable workspace, the automation's workspace mounted read-only), tool approval, typed waits, notifications and retries, and the storage guarantees (create-if-absent, per-run lock, turn roots, session kinds, one writer process per store)
+- `automations.md` — automations: a workflow run on a schedule or on request as a durable controller run; triggers (`schedule@1`, `schedule@2` calendar rules in a time zone, `manual@1`, `email.received@1`, entry-point sources), commands, independent or growing context, discussions forked at any occurrence (own writable workspace, the automation's workspace mounted read-only), tool approval, typed waits, notifications and retries, and the storage guarantees (create-if-absent, per-run lock, turn roots, session kinds, one writer process per store)
 - `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`)

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

@@ -241,7 +241,7 @@ from abstractruntime.triggers import get_trigger_adapter, trigger_sources
 - reads: `get_automation(run_store, id)`, `list_occurrences(runtime, id, cursor=, limit=)`, `list_attention(ledger_store, id, after_seq=, cursor=, limit=)`, `pending_waits(run_store, id, limit=)` with typed waits (`ask_user`, `tool_approval`, `event`) and `ANSWER_PAYLOADS`; `list_automations(run_store, status=, cursor=, limit=)`, `automation_summary(run)`, `latest_occurrence(run_store, id)`
 - `start_discussion(runtime, *, automation_id, occurrence_index, request_id, prompt, workspace_root, actor_id=None)`: a separate conversation forked at any occurrence N, seeded with the automation's whole timeline 1..N, working in its own writable `workspace_root` with the automation's workspace mounted read-only
 - controller bundle: `register_controller_bundle(registry)`, `controller_workflow_spec()`, `controller_bundle_path()`; `CONTROLLER_WORKFLOW_ID` is `abstractframework.automation-controller@1.0.0:controller`
-- trigger sources: `trigger_sources()`, `get_trigger_adapter(id, version)`, built-ins `schedule@1`, `manual@1` and `email.received@1`, third-party sources through the `abstractruntime.trigger_sources` entry-point group
+- trigger sources: `trigger_sources()`, `get_trigger_adapter(id, version)`, built-ins `schedule@1`, `schedule@2` (daily/weekly/monthly rules in an IANA time zone; `validate_time_zone`, `time_zone_names`), `manual@1` and `email.received@1`, third-party sources through the `abstractruntime.trigger_sources` entry-point group
 - definition v2: `policy.email_allowed_recipients` (default `["self"]`), `policy.untrusted_input_tools` (default `[]`) and `notify.channels` (default `["console"]`); attention items carry `channels`
 
 ## Email

{abstractruntime-0.9.1 → abstractruntime-0.10.0}/docs/architecture.md

@@ -332,7 +332,7 @@ flowchart LR
   subgraph Automations["automations/ + triggers/"]
     Commands["apply_automation_command"]
     Controller["controller run<br/>(automation-controller@1.0.0)"]
-    Triggers["trigger registry<br/>schedule@1, manual@1, email.received@1,<br/>entry-point sources"]
+    Triggers["trigger registry<br/>schedule@1, schedule@2, manual@1,<br/>email.received@1, entry-point sources"]
     Inbox["event inbox<br/>(email/, filled by the host's watcher)"]
     Queries["get_automation / list_occurrences /<br/>list_attention / pending_waits /<br/>list_automations"]
   end
@@ -403,6 +403,7 @@ Invariants the design rests on:
 
 AbstractRuntime includes a compiler and a portable bundle format:
 - VisualFlow compiler: `src/abstractruntime/visualflow_compiler/*` (VisualFlow JSON -> `WorkflowSpec`)
+- Reroute (relay) nodes are lowered first and disappear: each chain `source -> reroute (-> reroute) -> target` becomes `source -> target` (`visualflow_compiler/visual/reroute_lowering.py`), so the editor's dots are visual only. Data wires only; an execution wire through a reroute, two inputs into one, or a cycle of reroutes is refused when the flow compiles. A flow with a connected reroute needs this runtime: older ones refuse the unknown node type.
 - Multi-entry VisualFlow authoring routes are lowered into internal `join_exec` and `path_mux` nodes when a target has multiple incoming `exec-in` edges plus per-route input overrides. This keeps authoring JSON clean while making runtime behavior explicit and restart-safe. See `workflow-bundles.md` for the concrete metadata shape.
 - VisualFlow document nodes include `read_pdf`, `write_pdf`, and `write_docx`.
   They use workspace-scoped paths, keep document bytes out of checkpoints, and

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

@@ -33,7 +33,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"]
+  Trigger["Trigger source<br/>schedule@1 / schedule@2 / 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 / 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"]
@@ -172,6 +172,35 @@ Config: `{start_at?, every?, until?, count?, anchor?}`.
 - The event id of a scheduled tick is `schedule@1:<binding_id>:<tick>`. A revision that changes the trigger gets a
   new `binding_id`, so the new schedule never reuses an old event id.
 
+### `schedule@2`
+
+`schedule@2` adds calendar rules on wall time in a time zone. `schedule@1` stays registered and unchanged: its
+configs normalize byte for byte as before and its automations keep their tick grid. Use `schedule@2` for new
+automations.
+
+Config: `{kind, at?, days?, day?, time_zone?, start_at?, every?, until?, count?}`. The normalized config always
+carries `kind`, then the rule fields, `time_zone`, `start_at`, `anchor` (= `start_at`) and the bounds.
+
+| `kind` | Rule fields | Meaning |
+| --- | --- | --- |
+| `every` | `every` (`8h`, `7d`, ...) | Exactly `schedule@1`'s fixed UTC interval from `start_at`. `time_zone` is optional and only labels the schedule. |
+| `once` | `start_at`, or `at: "YYYY-MM-DDTHH:MM"` with `time_zone` | One run. A wall time `at` is converted to `start_at` in `time_zone`. |
+| `daily` | `at: "HH:MM"` | Every day at that wall time. |
+| `weekly` | `days` (non-empty subset of `mon`..`sun`), `at` | Those weekdays at that wall time. `days` is normalized to Monday-first order without duplicates. |
+| `monthly` | `day` (1..31 or `"last"`), `at` | That day of each month; a day beyond the month's length runs on the month's last day (day 31 runs on 28 or 29 February). |
+
+- Calendar rules (`daily`, `weekly`, `monthly`) require `time_zone`, an IANA name such as `Europe/Paris`
+  (`validate_time_zone(name)`; `time_zone_names()` lists the names the host knows). They take no `every`.
+- Wall times convert to UTC with `zoneinfo`. A wall time that does not exist that day (spring forward) runs at the
+  shifted instant: a 02:30 rule runs at 03:30 on that day and at 02:30 afterwards. A wall time that happens twice
+  (fall back) runs once, at its first occurrence. A daily 08:00 stays at 08:00 local time across both transitions.
+- Tick 0 is the first rule time at or after `start_at` (default: the creation time). `count` and `until` bound the
+  ticks as in `schedule@1`.
+- Missed ticks coalesce and a resume after a pause skips the ticks that passed, exactly as in `schedule@1`. The event
+  id of a tick is `schedule@2:<binding_id>:<tick>`.
+- Every instant is computed from its tick index in constant time, so an automation that was down for years catches up
+  with one occurrence without walking the missed ticks.
+
 ### `manual@1`
 
 Config: `{}`. The automation runs only when asked with `automation.run_now`. A manual run of any automation, whatever
@@ -680,9 +709,9 @@ receives its result directly.
 
 ## Limits in v1
 
-- Schedules are fixed UTC intervals (`s`, `m`, `h`, `d`, at most `366d`). There are no cron expressions, calendar
-  months, time zones or daylight-saving rules, and `anchor` must equal `start_at`.
-- The shipped trigger sources are `schedule@1`, `manual@1` and `email.received@1`. There is no generic external
+- Schedules are fixed UTC intervals (`schedule@1`, `schedule@2` `every`) or daily, weekly and monthly wall-time rules
+  in an IANA time zone (`schedule@2`). There are no cron expressions, and `anchor` must equal `start_at`.
+- The shipped trigger sources are `schedule@1`, `schedule@2`, `manual@1` and `email.received@1`. There is no generic external
   event source yet.
 - Occurrences run one at a time (`serial`), missed ticks coalesce, and a failed occurrence never stops the
   automation (`failure: "continue"`). These policies cannot be changed.

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

@@ -49,7 +49,7 @@ Docs: `getting-started.md`. Code: `src/abstractruntime/core/runtime.py`, `src/ab
 ## How do I run a workflow on a schedule or on request?
 
 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).
+occurrence) on each trigger: `schedule@1` (fixed UTC intervals such as `5m` or `24h`), `schedule@2` (the same intervals plus daily, weekly and monthly rules at a wall time in an IANA time zone, daylight-saving correct) or `manual@1` (run now only).
 `create_automation(...)` creates it, `apply_automation_command(...)` pauses, resumes, runs now, edits, stops the
 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

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

@@ -157,7 +157,7 @@ Kernel (import-light):
 - Stop that reaches the running effect: `Runtime.cancel_run(...)` signals the in-flight model or tool call, which ends as a `cancelled` ledger record (never retried); a model unload stops the calls using that model first (`docs/api.md`)
 - host pause at step boundaries: `Runtime.tick(..., step_gate=...)`
 - run-tree tool ceiling: an explicit `allowed_tools` list can only narrow across child runs, and approval policy never widens it
-- automations: run a workflow on a schedule (`schedule@1`, fixed UTC intervals), when mail arrives (`email.received@1`, `docs/email.md`) or on request (`manual@1`) as a durable controller run whose occurrences are deterministic child runs and session turns, with commands, independent or growing context, discussions forked at any occurrence (own workspace, automation workspace mounted read-only), tool approval, typed waits and quiet-by-default notifications (`docs/automations.md`)
+- automations: run a workflow on a schedule (`schedule@1` fixed UTC intervals; `schedule@2` adds daily, weekly and monthly rules at a wall time in an IANA time zone), when mail arrives (`email.received@1`, `docs/email.md`) or on request (`manual@1`) as a durable controller run whose occurrences are deterministic child runs and session turns, with commands, independent or growing context, discussions forked at any occurrence (own workspace, automation workspace mounted read-only), tool approval, typed waits and quiet-by-default notifications (`docs/automations.md`)
 - explicit run ids: `Runtime.start(..., run_id=...)` creates a run only if the id is free (`RunStore.create_if_absent`), and `run_mutation_lock(run_id)` serializes a run's writers in a process
 
 Durability + storage:
@@ -763,7 +763,7 @@ flowchart LR
   subgraph Automations["automations/ + triggers/"]
     Commands["apply_automation_command"]
     Controller["controller run<br/>(automation-controller@1.0.0)"]
-    Triggers["trigger registry<br/>schedule@1, manual@1, email.received@1,<br/>entry-point sources"]
+    Triggers["trigger registry<br/>schedule@1, schedule@2, manual@1,<br/>email.received@1, entry-point sources"]
     Inbox["event inbox<br/>(email/, filled by the host's watcher)"]
     Queries["get_automation / list_occurrences /<br/>list_attention / pending_waits /<br/>list_automations"]
   end
@@ -834,6 +834,7 @@ Invariants the design rests on:
 
 AbstractRuntime includes a compiler and a portable bundle format:
 - VisualFlow compiler: `src/abstractruntime/visualflow_compiler/*` (VisualFlow JSON -> `WorkflowSpec`)
+- Reroute (relay) nodes are lowered first and disappear: each chain `source -> reroute (-> reroute) -> target` becomes `source -> target` (`visualflow_compiler/visual/reroute_lowering.py`), so the editor's dots are visual only. Data wires only; an execution wire through a reroute, two inputs into one, or a cycle of reroutes is refused when the flow compiles. A flow with a connected reroute needs this runtime: older ones refuse the unknown node type.
 - Multi-entry VisualFlow authoring routes are lowered into internal `join_exec` and `path_mux` nodes when a target has multiple incoming `exec-in` edges plus per-route input overrides. This keeps authoring JSON clean while making runtime behavior explicit and restart-safe. See `workflow-bundles.md` for the concrete metadata shape.
 - VisualFlow document nodes include `read_pdf`, `write_pdf`, and `write_docx`.
   They use workspace-scoped paths, keep document bytes out of checkpoints, and
@@ -1106,7 +1107,7 @@ from abstractruntime.triggers import get_trigger_adapter, trigger_sources
 - reads: `get_automation(run_store, id)`, `list_occurrences(runtime, id, cursor=, limit=)`, `list_attention(ledger_store, id, after_seq=, cursor=, limit=)`, `pending_waits(run_store, id, limit=)` with typed waits (`ask_user`, `tool_approval`, `event`) and `ANSWER_PAYLOADS`; `list_automations(run_store, status=, cursor=, limit=)`, `automation_summary(run)`, `latest_occurrence(run_store, id)`
 - `start_discussion(runtime, *, automation_id, occurrence_index, request_id, prompt, workspace_root, actor_id=None)`: a separate conversation forked at any occurrence N, seeded with the automation's whole timeline 1..N, working in its own writable `workspace_root` with the automation's workspace mounted read-only
 - controller bundle: `register_controller_bundle(registry)`, `controller_workflow_spec()`, `controller_bundle_path()`; `CONTROLLER_WORKFLOW_ID` is `abstractframework.automation-controller@1.0.0:controller`
-- trigger sources: `trigger_sources()`, `get_trigger_adapter(id, version)`, built-ins `schedule@1`, `manual@1` and `email.received@1`, third-party sources through the `abstractruntime.trigger_sources` entry-point group
+- trigger sources: `trigger_sources()`, `get_trigger_adapter(id, version)`, built-ins `schedule@1`, `schedule@2` (daily/weekly/monthly rules in an IANA time zone; `validate_time_zone`, `time_zone_names`), `manual@1` and `email.received@1`, third-party sources through the `abstractruntime.trigger_sources` entry-point group
 - definition v2: `policy.email_allowed_recipients` (default `["self"]`), `policy.untrusted_input_tools` (default `[]`) and `notify.channels` (default `["console"]`); attention items carry `channels`
 
 ## Email
@@ -1323,7 +1324,7 @@ Docs: `getting-started.md`. Code: `src/abstractruntime/core/runtime.py`, `src/ab
 ## How do I run a workflow on a schedule or on request?
 
 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).
+occurrence) on each trigger: `schedule@1` (fixed UTC intervals such as `5m` or `24h`), `schedule@2` (the same intervals plus daily, weekly and monthly rules at a wall time in an IANA time zone, daylight-saving correct) or `manual@1` (run now only).
 `create_automation(...)` creates it, `apply_automation_command(...)` pauses, resumes, runs now, edits, stops the
 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
@@ -3606,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"]
+  Trigger["Trigger source<br/>schedule@1 / schedule@2 / 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 / 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"]
@@ -3745,6 +3746,35 @@ Config: `{start_at?, every?, until?, count?, anchor?}`.
 - The event id of a scheduled tick is `schedule@1:<binding_id>:<tick>`. A revision that changes the trigger gets a
   new `binding_id`, so the new schedule never reuses an old event id.
 
+### `schedule@2`
+
+`schedule@2` adds calendar rules on wall time in a time zone. `schedule@1` stays registered and unchanged: its
+configs normalize byte for byte as before and its automations keep their tick grid. Use `schedule@2` for new
+automations.
+
+Config: `{kind, at?, days?, day?, time_zone?, start_at?, every?, until?, count?}`. The normalized config always
+carries `kind`, then the rule fields, `time_zone`, `start_at`, `anchor` (= `start_at`) and the bounds.
+
+| `kind` | Rule fields | Meaning |
+| --- | --- | --- |
+| `every` | `every` (`8h`, `7d`, ...) | Exactly `schedule@1`'s fixed UTC interval from `start_at`. `time_zone` is optional and only labels the schedule. |
+| `once` | `start_at`, or `at: "YYYY-MM-DDTHH:MM"` with `time_zone` | One run. A wall time `at` is converted to `start_at` in `time_zone`. |
+| `daily` | `at: "HH:MM"` | Every day at that wall time. |
+| `weekly` | `days` (non-empty subset of `mon`..`sun`), `at` | Those weekdays at that wall time. `days` is normalized to Monday-first order without duplicates. |
+| `monthly` | `day` (1..31 or `"last"`), `at` | That day of each month; a day beyond the month's length runs on the month's last day (day 31 runs on 28 or 29 February). |
+
+- Calendar rules (`daily`, `weekly`, `monthly`) require `time_zone`, an IANA name such as `Europe/Paris`
+  (`validate_time_zone(name)`; `time_zone_names()` lists the names the host knows). They take no `every`.
+- Wall times convert to UTC with `zoneinfo`. A wall time that does not exist that day (spring forward) runs at the
+  shifted instant: a 02:30 rule runs at 03:30 on that day and at 02:30 afterwards. A wall time that happens twice
+  (fall back) runs once, at its first occurrence. A daily 08:00 stays at 08:00 local time across both transitions.
+- Tick 0 is the first rule time at or after `start_at` (default: the creation time). `count` and `until` bound the
+  ticks as in `schedule@1`.
+- Missed ticks coalesce and a resume after a pause skips the ticks that passed, exactly as in `schedule@1`. The event
+  id of a tick is `schedule@2:<binding_id>:<tick>`.
+- Every instant is computed from its tick index in constant time, so an automation that was down for years catches up
+  with one occurrence without walking the missed ticks.
+
 ### `manual@1`
 
 Config: `{}`. The automation runs only when asked with `automation.run_now`. A manual run of any automation, whatever
@@ -4253,9 +4283,9 @@ receives its result directly.
 
 ## Limits in v1
 
-- Schedules are fixed UTC intervals (`s`, `m`, `h`, `d`, at most `366d`). There are no cron expressions, calendar
-  months, time zones or daylight-saving rules, and `anchor` must equal `start_at`.
-- The shipped trigger sources are `schedule@1`, `manual@1` and `email.received@1`. There is no generic external
+- Schedules are fixed UTC intervals (`schedule@1`, `schedule@2` `every`) or daily, weekly and monthly wall-time rules
+  in an IANA time zone (`schedule@2`). There are no cron expressions, and `anchor` must equal `start_at`.
+- The shipped trigger sources are `schedule@1`, `schedule@2`, `manual@1` and `email.received@1`. There is no generic external
   event source yet.
 - Occurrences run one at a time (`serial`), missed ticks coalesce, and a failed occurrence never stops the
   automation (`failure: "continue"`). These policies cannot be changed.
@@ -5894,7 +5924,7 @@ In this repo, the AbstractCore wiring lives under `src/abstractruntime/integrati
 
 ## Features (reference)
 
-- `automations.md` — automations: a workflow run on a schedule or on request as a durable controller run; triggers (`schedule@1`, `manual@1`, `email.received@1`, entry-point sources), commands, independent or growing context, discussions forked at any occurrence (own writable workspace, the automation's workspace mounted read-only), tool approval, typed waits, notifications and retries, and the storage guarantees (create-if-absent, per-run lock, turn roots, session kinds, one writer process per store)
+- `automations.md` — automations: a workflow run on a schedule or on request as a durable controller run; triggers (`schedule@1`, `schedule@2` calendar rules in a time zone, `manual@1`, `email.received@1`, entry-point sources), commands, independent or growing context, discussions forked at any occurrence (own writable workspace, the automation's workspace mounted read-only), tool approval, typed waits, notifications and retries, and the storage guarantees (create-if-absent, per-run lock, turn roots, session kinds, one writer process per store)
 - `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`)

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

@@ -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, 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
+- [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), `schedule@2` (the same plus daily/weekly/monthly wall-time rules in an IANA time zone, DST-correct) 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.9.1 → abstractruntime-0.10.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "AbstractRuntime"
-version = "0.9.1"
+version = "0.10.0"
 description = "AbstractRuntime: a durable graph runner designed to pair with AbstractCore."
 readme = "README.md"
 requires-python = ">=3.10"
@@ -55,7 +55,9 @@ dependencies = [
   # unload frees the pipeline (the resident media path relies on both).
   # 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",
+  # 2.26.0: `abstractcore.config.recommendations.voice_input_hint`, served through
+  # `config_facade.voice_input_hint` (the speech-input row's hint; round 16).
+  "abstractcore>=2.26.0",
   "openai<3.0.0,>=1.109.1",
   "httpx<1.0.0,>=0.28.1",
   "anyio<5.0.0,>=4.12.1",
@@ -72,12 +74,12 @@ dependencies = [
 
 [project.optional-dependencies]
 apple = [
-  "abstractcore[apple]>=2.25.1",
+  "abstractcore[apple]>=2.26.0",
   "setuptools<82.0.0,>=80.10.2",
 ]
 
 gpu = [
-  "abstractcore[gpu]>=2.25.1",
+  "abstractcore[gpu]>=2.26.0",
   # 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.10.0/release-notes.md

@@ -0,0 +1,20 @@
+### Added
+
+- Trigger source `schedule@2`: `{kind: "daily", at: "HH:MM"}`, `{kind: "weekly", days: [...], at}` and `{kind: "monthly", day: 1..31 | "last", at}` evaluated on wall time in the config's `time_zone` (IANA, converted with `zoneinfo`: a skipped wall time runs at the shifted instant, a repeated one runs once; a day beyond the month's length runs on its last day), plus `{kind: "every"}` and `{kind: "once"}` with `schedule@1`'s meaning (a `once` may give a wall time `at` in `time_zone`). Same coalescing and pause policy as `schedule@1`; event ids `schedule@2:<binding_id>:<tick>`. `validate_time_zone(name)` and `time_zone_names()` are exported from `abstractruntime.triggers`. See `docs/automations.md`.
+- `integrations.abstractcore.config_facade.voice_input_hint(route, host=None)`: AbstractCore's served one-line hint for a configured speech-input route (`abstractcore.config.recommendations.voice_input_hint`, AbstractCore >= 2.26.0), so a host such as AbstractGateway serves it without importing AbstractCore itself. The AbstractCore floor is 2.26.0.
+- A limit on an execution wire: `edge.data.loopLimit = {"max": N}` (the editor's ↺N badge on a wire that makes execution repeat). Before compile, `visual/loop_limit_lowering.py` turns it into a `loop_limit` node on that wire (`again` to the wire's target; `limit_reached` to the other branch when the wire leaves an If/Else and that branch is not itself a limited wire, else nothing: the path ends at the limit), re-keying the target's per-path values and entry list. A run tree shows the lowered node as "Loop limit N". `VisualEdge` now carries `data` (older runtimes never read it, so a limited flow runs unlimited there).
+- VisualFlow `get_vars` node (Get Variables): a data node with one output per variable, its pin id the variable name (dotted paths allowed); each output reads the run variable's current value, or null when it is not set.
+- VisualFlow `loop_limit` node (Loop Limit): exec outputs `again` (taken while fewer than `max` passes were let through) and `limit_reached` (then the count starts again from 0), data output `count` (the pass number). The count lives in `run.vars._temp.loop_limits.<node id>`, so it survives pause/resume. It belongs to the current iteration of the enclosing ForEach / For / While (each item, and each new entry of that loop, starts from 0); with no enclosing loop, to the run. Its `max` comes only from its own pin, never from the previous step's output.
+- VisualFlow `add_to_list` node (Add to List Variable): `name`, `item` (added as one element), `items` (each element added); a missing or null variable starts as `[]`; a variable that holds something else, or `items` that is not a list, fails the step naming it; reads and writes in one step; output `list`.
+- String Template: a placeholder reads an input pin of its name, then the `vars` object, then the run variable (top-level names not starting with `_`). A list or object with no filter is written as JSON (it was Python's `str()`).
+
+### Changed
+
+- An execution wire that loops back out of a ForEach / For / While body (from inside the body to the loop node itself or to anything before it) is refused when the flow compiles: "Wire <source>.<pin> -> <target> goes back out of <loop>'s loop body: the run would never end. A path inside a loop body can only repeat within the body; to repeat the whole loop, wire the loop-back after the loop's done." Such a wire re-entered the loop with its frame still on the control stack, so the stack grew by one frame per pass and the run never ended (a Loop Limit on it never reached its max). A loop-back that goes through the loop's `done`, or that stays inside the body, is unchanged (`visual/loop_back_check.py`).
+- `schedule@1` is unchanged: its configs normalize byte for byte as before and existing automations keep their tick grid (`tests/test_schedule_v1_corpus.py` freezes the 0.9.1 answers on real automation configs).
+
+### Fixed
+
+- Set Variables (and Add to List Variable) only take what their own pins carry (a wire, a value set on the node, an expression). Before, keys of the previous step's output were written as variables too.
+- Set Variables (`set_vars`): every data input pin besides `updates` is one variable, written under the pin's id (dotted paths nest) with its value: a wire, else the pin's default. These win over the same name in the `updates` object. AbstractFlow edits them as rows (name, type, value), so one node initialises several variables, wired or literal. A flow using such rows needs this runtime: an older one writes only `updates`. Test: `tests/test_visual_set_vars_pins.py`.
+- VisualFlow reroute ("relay") nodes: a dot in AbstractFlow that lets one output feed several inputs along a tidy path. They are visual only: before compiling, every chain `source -> reroute (-> reroute ...) -> target` is rewired `source -> target` and the reroutes are removed (`visualflow_compiler/visual/reroute_lowering.py`, run before the multi-entry lowering). A reroute with no source feeds nothing (its targets keep their defaults); per-path values that name a reroute point at its real source. Data wires only: an execution wire through a reroute, a second input into one, or a cycle of reroutes is refused with a message naming the wire. A flow with a connected reroute needs this runtime (older ones refuse the unknown node type). Test: `tests/test_visual_reroute_lowering.py`.

{abstractruntime-0.9.1 → abstractruntime-0.10.0}/src/abstractruntime/integrations/abstractcore/config_facade.py

@@ -11,6 +11,7 @@ Scope:
   use scoped per-principal config files)
 - resolve the effective AbstractCore config file path
 - enumerate capability-default route specs (the catalog of known routes)
+- the served speech-input hint for a configured route (`voice_input_hint`, AbstractCore >= 2.26.0)
 - read a provider API key from a specific AbstractCore config file
 - read AbstractCore's stored mail (IMAP/SMTP) and maintenance-triage settings
 - model weights: availability probes and single downloads (`model_materializer`)
@@ -221,6 +222,30 @@ def recommended_capability_selectors() -> List[str]:
         return []
 
 
+def voice_input_hint(
+    route: Dict[str, Any], host: Optional[Dict[str, Any]] = None
+) -> Optional[Dict[str, Any]]:
+    """AbstractCore's served one-line hint for a CONFIGURED speech-input route, or None.
+
+    `abstractcore.config.recommendations.voice_input_hint` (AbstractCore >= 2.26.0):
+    THE sentence clients show next to the Voice input row, verbatim -- for example
+    a faster-whisper route on Apple silicon runs on the processor while mlx-whisper
+    runs the same model on the GPU. Computed from the host and the installed
+    engines, never in a client; it never changes the route. Raises when
+    AbstractCore is too old: a host serving the speech-input row without its hint
+    would be a silent regression.
+    """
+    try:
+        from abstractcore.config.recommendations import voice_input_hint as _core_voice_input_hint
+    except Exception as exc:
+        raise RuntimeError(
+            "AbstractCore's speech-input hint is unavailable "
+            "(abstractcore.config.recommendations.voice_input_hint needs AbstractCore >= 2.26.0)."
+        ) from exc
+    answer = _core_voice_input_hint(dict(route), host)
+    return dict(answer) if answer else None
+
+
 def capability_default_specs() -> Dict[str, Dict[str, Any]]:
     """Return {route_key -> spec dict} for all known capability-default routes."""
     try:

{abstractruntime-0.9.1 → abstractruntime-0.10.0}/src/abstractruntime/triggers/__init__.py

@@ -26,7 +26,7 @@ from .registry import (
     reset_trigger_registry,
     trigger_sources,
 )
-from .schedule import ScheduleTriggerAdapter
+from .schedule import ScheduleTriggerAdapter, ScheduleV2TriggerAdapter, time_zone_names, validate_time_zone
 
 __all__ = [
     "BUILTIN_TRIGGER_SOURCES",
@@ -34,6 +34,9 @@ __all__ = [
     "EmailReceivedTriggerAdapter",
     "ManualTriggerAdapter",
     "ScheduleTriggerAdapter",
+    "ScheduleV2TriggerAdapter",
+    "time_zone_names",
+    "validate_time_zone",
     "TRIGGER_STATE_KEYS",
     "TriggerAdapter",
     "TriggerAdmission",

{abstractruntime-0.9.1 → abstractruntime-0.10.0}/src/abstractruntime/triggers/registry.py

@@ -2,7 +2,8 @@
 
 Sources come from two places:
 
-- the built-ins `schedule@1`, `manual@1` and `email.received@1`, shipped in this package. They are
+- the built-ins `schedule@1`, `schedule@2`, `manual@1` and `email.received@1`, shipped in this
+  package (`schedule@2` is a second version of the built-in `schedule` source). They are
   a REQUIRED seam: if one cannot be loaded, or no longer describes itself as
   expected, discovery raises `TriggerRegistryError` — automations must not
   start on a runtime that silently lost its scheduler;
@@ -34,6 +35,13 @@ BUILTIN_TRIGGER_SOURCES: Dict[str, str] = {
     "email.received": "abstractruntime.triggers.email_received:EmailReceivedTriggerAdapter",
 }
 
+# Further versions of a built-in source (same entry-point name, one more adapter each): loaded
+# with the same required-seam rule as the built-ins above.
+BUILTIN_TRIGGER_SOURCE_VERSIONS: Tuple[Tuple[str, str], ...] = (
+    # R16.1: calendar rules (daily/weekly/monthly) in a time zone; schedule@1 stays unchanged.
+    ("schedule", "abstractruntime.triggers.schedule:ScheduleV2TriggerAdapter"),
+)
+
 _ADAPTER_METHODS = ("validate", "initial_state", "prepare", "admit", "rearm", "normalize")
 _DESCRIPTOR_KEYS = ("id", "version", "label", "config_schema", "event_schema", "capabilities")
 
@@ -111,7 +119,11 @@ class _Registry:
         rows: List[Dict[str, Any]] = []
         adapters: Dict[Tuple[str, int], Any] = {}
 
+        builtins = []
         for name, target in BUILTIN_TRIGGER_SOURCES.items():
+            builtins.append((name, target))
+            builtins.extend(v for v in BUILTIN_TRIGGER_SOURCE_VERSIONS if v[0] == name)
+        for name, target in builtins:
             try:
                 adapter = _instantiate(_load_target(target))
                 descriptor = _check_adapter(name, adapter)
@@ -119,7 +131,10 @@ class _Registry:
                 raise TriggerRegistryError(
                     f"built-in trigger source {name!r} ({target}) is missing or broken: {exc}"
                 ) from exc
-            adapters[(descriptor["id"], int(descriptor["version"]))] = adapter
+            key = (descriptor["id"], int(descriptor["version"]))
+            if key in adapters:
+                raise TriggerRegistryError(f"built-in trigger source {key[0]}@{key[1]} is declared twice ({target})")
+            adapters[key] = adapter
             rows.append({"descriptor": descriptor, "available": True})
 
         for name, target in _entry_points():
@@ -195,6 +210,7 @@ def reset_trigger_registry() -> None:
 
 __all__ = [
     "BUILTIN_TRIGGER_SOURCES",
+    "BUILTIN_TRIGGER_SOURCE_VERSIONS",
     "ENTRY_POINT_GROUP",
     "TriggerRegistryError",
     "UnknownTriggerSource",