coulomb/rein-aharness
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Inventory legacy tenant runtime routes

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02b6f-7db1-7222-918b-e813a6bda38d
This commit is contained in:
tegwick 2026-08-23 12:02:14 +02:00
parent 6e0e23c637
commit e4b73a8a78
3 changed files with 208 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

8
docs/adr/ADR-002-governed-execution-responsibility-chain.md
View file

@ -170,3 +170,11 @@ Before changing this ADR to `accepted`, record owner acknowledgements for:
Any owner objection changes the matrix before acceptance; silence is not
approval.
Acknowledgements received:
- Glas — message `006fa46f-9419-4f61-90ff-0c3b6bc294c1`: exact selection,
readiness, outer lifecycle/evidence, rein-local credential resolution, and
no-fallback semantics approved with no edits.
Pending: Activity Core, sand-boxer, and llm-connect.

189
docs/legacy-runtime-inventory.md Normal file
View file

@ -0,0 +1,189 @@
# Legacy profile-absent runtime inventory
Status: preparatory inventory for `HARNESS-WP-0003-T04`
Captured: 2026-08-23
Runtime behavior source: rein-aharness `6e0e23c`
This inventory records the tenant-specific execution paths selected when an
Activity Core `ops_run` has no `harness_profile_ref`. It is deliberately
read-only preparation: T04 remains `wait` until ADR-002 is accepted, and this
document neither enables a definition nor changes a production route.
The definition state below is the committed file state in Activity Core,
freedom-intelligence, and binky-control. Live schedule projection, timer state,
and deployed revisions must be reverified before a migration or rollback.
## Shared compatibility dispatcher
`rein_aharness/claim_loop.py` sends every profile-absent row through
`select_approach()` in `rein_aharness/approaches.py`. Selection is first-match
and may use an explicit `approach_hint`, labels, or substrings from definition
id, title, hint, labels, source id, and target repo.
None of the four committed definitions below declares `harness_profile_ref` or
`approach_hint`; their current route therefore depends on labels and substring
matching. A present profile ref bypasses this table and must never fall back to
it.
| Selector | Tenant coupling | Direct executor |
|---|---|---|
| `fi-research-brief` | FI labels, names, output schema, completion event, literal result repo, default push | `fi_research_brief.run_fi_research_brief` |
| `brief-daily` | Binky labels, files, prompt/output schema, completion event, literal result repo | `brief_daily.run_brief_daily` |
| `brief-weekly` | Binky labels, milestone/RISK-005 semantics, completion event, literal result repo | `brief_weekly.run_brief_weekly` |
| `mail-scan+triage` | Binky labels, mailbox config/path, OpenBao path, report/log schema and events | `mailscan.run_mail_scan` then `mail_triage.run_mail_triage` |
| `mail-scan` / `mail-triage` | Same Binky internals, exposed as separately callable compatibility commands | The corresponding half of the pipeline |
| `agent-session` | Generic-looking entry with Binky-specific agent/event inference in `intake.py` | `runner.run_task` through `ops_run_to_taskspec` |
An unmatched route fails terminally. Most matched executor failures set
`reopen=true`; an unexpected exception also reopens. Activity Core applies its
attempt limit, but the harness currently has no shared repository transaction
identity with which to distinguish a safe retry from a repeat after partial
mutation.
## Scheduled definitions
### Freedom Intelligence daily research brief
| Field | Current contract |
|---|---|
| Definition authority | `freedom-intelligence/activity-definitions/fi-daily-research-brief.md`; owner `custodian-agent`, governance `custodian` |
| File-state cadence | Enabled/active; weekdays 07:30 Europe/Berlin; skip misfires |
| Current selection | Labels `freedom-intelligence`, `research-brief`, `automated` select `fi-research-brief` |
| Inputs | FI sources allowlist, daily playbook, reserve status, two fixed research baselines/plans, recent briefs, and recent git log |
| Model/credential lane | HTTP `LLM_CONNECT_URL`; model from `FI_RESEARCH_BRIEF_MODEL`, then Binky-named `BRIEF_DAILY_MODEL` / `MAIL_TRIAGE_MODEL`; provider credential remains behind llm-connect |
| Output | `briefs/YYYY/MM/YYYY-MM-DD.md`; model JSON is rendered deterministically |
| Repository mutation | Stages only the brief path and creates one local commit |
| Publication | **Pushes `origin HEAD` by default** unless `FI_RESEARCH_BRIEF_PUSH` is false; push failure is swallowed and the run remains successful |
| Completion | Best-effort State Hub `fi_daily_brief` with path/date/candidate count; `fi_brief_status` uses it to clear due state |
| Failure/retry | Normal generation/commit failure reopens; an existing daily path succeeds idempotently |
| Current rollback material | Disable/pause the Activity Core definition. FI documents a disabled 07:35 host timer as break-glass, but its installer still enables that timer and must not be invoked casually |
Migration must remove the implicit push. Publication, if still needed, becomes
a separately named and granted capability with remote-ref and result evidence.
The Binky-named fallback model environment variables must not survive in an FI
owned declaration.
### Binky daily operating rhythm
| Field | Current contract |
|---|---|
| Definition authority | `activity-core/activity-definitions/binky-daily-rhythm.md`; owner `custodian-agent`, governance `custodian` |
| File-state cadence | Enabled/active; weekdays 08:23 Europe/Berlin; skip misfires |
| Current selection | Labels `binky`, `rhythm`, `automated` select `brief-daily` |
| Inputs | `DecisionQueue.md`, `OfficeHourQueue.md`, `AutopilotWorkQueue.md`, `RiskRegister.md`, `SuccessMilestones.md`, `WORK-RECORDS.md`, recent briefs, and git log |
| Model/credential lane | HTTP `LLM_CONNECT_URL`; `BRIEF_DAILY_MODEL` falling back to `MAIL_TRIAGE_MODEL`; provider credential remains behind llm-connect |
| Output | `briefs/YYYY-MM-DD-daily-brief.md`; structured JSON rendered to the Binky one-screen format |
| Repository mutation | Stages only the new brief and creates one local commit; no push in this executor |
| Completion | Best-effort State Hub `binky_daily_brief`; `binky_rhythm_status` uses it as the daily due bit |
| Failure/retry | Generation/commit failure reopens; an existing daily path succeeds idempotently |
| Current rollback material | Disable/pause the definition. Binky host rhythm timers remain in the tenant repo as an older executor path; current live timer state must be checked before treating them as rollback |
The source definition still says tasks land in issue-core and require an
executor, although the current primary claim authority is `ops_run`. That stale
description is a T05 documentation/conformance input.
### Binky weekly founder-review preparation
| Field | Current contract |
|---|---|
| Definition authority | `activity-core/activity-definitions/binky-weekly-review-prep.md`; owner `custodian-agent`, governance `custodian` |
| File-state cadence | Enabled/active; Fridays 16:43 Europe/Berlin; skip misfires |
| Current selection | Labels `binky`, `weekly-review`, `automated` select `brief-weekly` |
| Inputs | `SuccessMilestones.md`, `DecisionQueue.md`, `RiskRegister.md`, `WORK-RECORDS.md`, current-week daily briefs, prior weekly review, and git history |
| Deterministic tenant policy | Computes milestone movement and Binky `RISK-005` state (`clear`, `watch`, `escalate`, `quiet`) in runtime code |
| Model/credential lane | HTTP `LLM_CONNECT_URL`; `BRIEF_WEEKLY_MODEL` falling back to `BRIEF_DAILY_MODEL` |
| Output | `briefs/YYYY-MM-DD-weekly-founder-review.md` |
| Repository mutation | Stages only the review and creates one local commit; no push |
| Completion | Best-effort State Hub `binky_weekly_review`; used as the weekly due bit |
| Failure/retry | Signal derivation, generation, or commit failure reopens; an existing dated path succeeds idempotently |
| Current rollback material | Disable/pause the definition; tenant-owned host review timer exists but must be verified before use |
The milestone/RISK-005 calculation is business logic. It belongs in a
tenant-owned blueprint or typed capability, not in the shared rein selector.
### Binky weekly mailbox intake
| Field | Current contract |
|---|---|
| Definition authority | `activity-core/activity-definitions/binky-weekly-mail-intake.md`; owner `custodian-agent`, governance `custodian` |
| File-state cadence | Enabled/active; Mondays 09:37 Europe/Berlin; skip misfires |
| Current selection | Labels `binky`, `mail-intake`, `automated` select `mail-scan+triage` |
| Scan inputs | Hard-coded OpenBao KV path `tenants/binky/company-email/imap`, AppRole files under `EXECUTOR_APPROLE_DIR` or ambient Bao token, tenant config `integrations/mailbox-binky-company.yml`, and mutable sibling source default `~/email-connect/src` |
| Scan output | A new `mailmeta/reports/*.csv` metadata report from email-connect |
| Triage inputs | Newest report, eight allowlisted metadata columns capped to 40 rows, and tail of `mailmeta/mail-log.md` |
| Model/credential lane | Scan injects IMAP username/password only into the email-connect child environment. Triage calls `LLM_CONNECT_URL` with optional `MAIL_TRIAGE_MODEL`; provider credentials stay behind llm-connect |
| Triage output | Deterministic rows inserted into `mailmeta/mail-log.md`; suspicious mail is log-only |
| Repository mutation | Triage stages and commits only `mailmeta/mail-log.md`; the generated CSV is not included in that commit and can leave the checkout dirty |
| Completion | Scan success immediately posts `binky_mail_intake`; triage separately posts `binky_mail_triage`. The schedule resolver clears its due bit from the scan event even if later triage fails |
| Failure/retry | Scan or triage failure reopens the ops run; scan can already have written a report and cleared the intake due bit before that failure |
| Current rollback material | Disable/pause the definition; tenant-owned host mail timer exists, but it is the same two-phase implementation and is not an independent code rollback |
Migration must explicitly decide whether the scheduled unit is “mailbox scan”
or “scan plus successful triage.” The completion event cannot keep both
meanings. The report retention/commit policy and credential revocation or expiry
evidence also need named owners.
## Direct and issue-core compatibility
The issue-core path maps Binky definition/label substrings through
`_DEFINITION_HINTS` in `intake.py`. Unknown issues default to agent `coach` and
generic `executor_run`. The `agent-session` approach repeats that inference for
profile-absent ops runs, converts the row to `TaskSpec`, and calls the older
host-checkout runner. Its assertion that the resolved targets agree is
effectively disabled by `or True`.
Direct task-file examples in binky-control name agent instances and completion
events, but those files are attended development/onboarding inputs, not the
Activity Core scheduling authority. Their descriptions promise “Never push”;
that policy is enforced only by the selected legacy runner/tool profile, not by
a repository transaction or remote-ref check.
## Cross-cutting gaps to preserve as migration gates
1. **No exact selector:** all four scheduled definitions route from labels and
substrings. The global Activity Core profile requirement cannot be enabled
while they remain profile-absent.
2. **Tenant code in the shared runtime:** prompts, output schemas, file paths,
event types, FI publication, Binky risk logic, mailbox paths, and
credential lanes require edits to rein-aharness.
3. **No shared repository transaction:** dirty baselines, partial writes,
unexpected commits/paths, lease loss, and retries after mutation are not
bounded. T02/T03 remain prerequisites for any retained direct executor.
4. **Required evidence is best-effort:** Hub delivery failure does not fail or
reconcile a run even though the due resolvers depend on those events.
5. **Completion meanings diverge:** mailbox scan and triage have different
events, while the Activity definition describes one intake task.
6. **Publication is implicit in FI:** default push plus swallowed failure cannot
meet an explicit grant/evidence contract.
7. **Mutable sibling/runtime dependencies:** mail scan defaults to a sibling
email-connect checkout, and model selection depends on process environment
rather than a versioned execution declaration.
8. **Rollback documentation is stale:** tenant host timers remain in source and
some installers enable them, while newer docs call them disabled,
interim, or break-glass.
## Candidate migration sequence
This sequence is preparatory and does not choose a profile or capability owner
before ADR-002 acknowledgement.
1. Land T02/T03 repository transaction, lease-loss, acceptance, and evidence
reconciliation for any compatibility executor that remains callable.
2. For each scheduled definition, obtain an owner-approved declaration of the
exact input schema, allowed paths, model route, credential route, completion
event, commit policy, publication policy, and rollback.
3. Put agentic work behind a versioned Glas profile. Put deterministic
tenant-specific transformations in a tenant-owned blueprint or separately
owned typed capability; do not force every deterministic adapter into a rein
merely to remove it from this repository.
4. Add the explicit selector to one disabled/canary definition, prove the new
and compatibility outputs against controlled inputs, and retain a dated
rollback pin.
5. Enable the replacement, verify the due resolver and durable evidence, then
remove that definition from substring routing.
6. After all four definitions migrate, enable
`ACTIVITY_CORE_REQUIRE_HARNESS_PROFILE=true` for governed execution, delete
`_DEFINITION_HINTS` and tenant approach rules, and reconcile or retire the
tenant host timers.

11
workplans/HARNESS-WP-0003-governed-runtime-integrity.md
View file

@ -109,6 +109,9 @@ and T02–T06 can cite stable decisions rather than infer ownership from code.
(`7fd35fd4-b0e1-42f0-bb56-a983a3e25c78`), and llm-connect
(`c5d1dc62-3dca-4ac8-b3b5-d570d723ceda`). T01 remains `progress` and
downstream tasks remain `wait` until those reviews are reconciled.
- Glas approved the proposed boundary without edits in message
`006fa46f-9419-4f61-90ff-0c3b6bc294c1`. Activity Core, sand-boxer, and
llm-connect acknowledgements remain pending.
## Make each repository run a lease-bound transaction
@ -207,6 +210,14 @@ production runs through generic selectors; tenant modules and hard-coded event,
path, and prompt conventions are removed or moved to their owning packages;
and the compatibility flag is disabled before deletion.
### Preparation — 2026-08-23
`docs/legacy-runtime-inventory.md` records the four profile-absent scheduled
definitions and the direct/issue-core compatibility surfaces from current code
and owner files. It identifies inputs, outputs, credentials, completion events,
commit/push behavior, retry posture, rollback material, and migration gates.
This is read-only preparation; T04 remains `wait` until T01 accepts ADR-002.
## Align deployment, recovery, and conformance with the supported runtime
```task