tegwick
c5943ac048
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>
73 lines
3.7 KiB
Markdown
73 lines
3.7 KiB
Markdown
# 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.
|