# 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.