glas-harness/docs/adr/ADR-003-scheduling-and-blueprint-sourcing-stay-rein-local.md

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.