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 <noreply@anthropic.com>

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.