From c5943ac0489b4ce9a3d3916bd8458f672721734e Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 26 Jul 2026 14:51:42 +0200 Subject: [PATCH] ADR-003: scheduling and blueprint-sourcing stay rein-local Closes HARNESS-WP-0002-T04. With rein-openweights now real (not hypothetical), the two reins already sit at opposite ends of this question with no code change needed -- rein-aharness keeps its kaizen-agentic + issue-core coupling, rein-openweights has none at all. glas-harness does not become a task source or scheduler, consistent with its own INTENT.md boundary. Co-Authored-By: Claude Sonnet 5 --- ...-and-blueprint-sourcing-stay-rein-local.md | 73 +++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 docs/adr/ADR-003-scheduling-and-blueprint-sourcing-stay-rein-local.md diff --git a/docs/adr/ADR-003-scheduling-and-blueprint-sourcing-stay-rein-local.md b/docs/adr/ADR-003-scheduling-and-blueprint-sourcing-stay-rein-local.md new file mode 100644 index 0000000..e43197e --- /dev/null +++ b/docs/adr/ADR-003-scheduling-and-blueprint-sourcing-stay-rein-local.md @@ -0,0 +1,73 @@ +# ADR-003: Scheduling and blueprint-sourcing stay rein-local + +- Status: accepted +- Date: 2026-07-26 +- Deciders: Bernd Worsch + +## Context + +`HARNESS-WP-0002-T04` asked: `rein-aharness` depends directly on +`kaizen-agentic` (blueprint/persona loading via `schedule prepare`) and +`activity-core`/`issue-core` (task intake — polling, claiming, closing +issues). Once a second rein existed, should that coupling stay rein-local +(each rein wires its own scheduling/blueprint sourcing), or move into +glas-harness as a shared concern? + +`rein-openweights` now exists (`REIN-OW-WP-0001`), giving a real second +data point instead of a hypothetical one. It has **no** scheduling or +blueprint coupling at all: no kaizen-agentic persona loading, no +issue-core polling. It's purely reactive — a `title`/`description` goes +in (via CLI task-file or glas-harness's gateway), one bounded session +runs, a commit either lands or it doesn't. glas-harness's own gateway +(`run_task_through_rein`) doesn't touch kaizen-agentic or activity-core +either — it resolves a sandbox profile and hands the rein plain +`title`/`description`/`target_repo` inputs. + +So today, in practice, the two reins already sit at opposite ends of the +spectrum this question asks about: `rein-aharness` sources tasks +rein-locally via a deep, working, live integration; `rein-openweights` +doesn't source tasks at all. Neither model has glas-harness acting as a +task source. + +## Decision + +**Scheduling and blueprint-sourcing stay rein-local.** glas-harness does +not become a task source, scheduler, or blueprint loader. Each rein wires +whatever it needs — `rein-aharness` keeps its existing kaizen-agentic + +issue-core integration unchanged; `rein-openweights` stays task-file/ +caller-driven unless a real use case demands more, at which point it +builds its own, not a shared one borrowed from glas-harness. + +This isn't really a new boundary so much as confirming one glas-harness's +own `INTENT.md` already draws: its "What it is not" table lists +`activity-core` as the owner of *when jobs run*, explicitly out of scope +for glas-harness. `docs/harness-contract.md`'s open questions section +already flagged this as unresolved; this ADR resolves it. + +Rationale, same shape as ADR-002's credential-brokering decision: + +1. **Consistency with existing precedent.** `rein-aharness`'s coupling is + live, working, and load-bearing for `binky-control`'s actual schedule + today. Retrofitting it onto a shared glas-harness mechanism would be + surgery on a live dependency for no operational gain. +2. **One real data point, not two.** Only `rein-aharness` has this + coupling; `rein-openweights` has none. Generalizing a shared + scheduling concern from a single example repeats the premature- + generalization mistake ADR-001 was written to avoid. +3. **Charter consistency.** Centralizing scheduling in glas-harness would + directly contradict its own stated boundary (`INTENT.md`: "Not a + scheduler. Triggering and task emission stay in activity-core."). + +## Consequences + +- `HARNESS-WP-0002-T04` is closed by this ADR — no code change required, + since current behavior already matches the decision. +- Future reins are free to have arbitrarily different triggering models + (a channel-bot rein reacting to chat messages, a cron-polling rein, a + purely synchronous one like today's `rein-openweights`) without + glas-harness needing a unified scheduling abstraction to support them. +- If a third rein ever wants kaizen-agentic-style persona loading or + issue-core-style intake, it can copy the pattern from `rein-aharness` + directly (it's a small, self-contained integration — `persona.py` is + 39 lines, `intake.py` a few hundred) rather than waiting on a shared + glas-harness mechanism that doesn't exist and isn't planned.