rein-aharness/docs/legacy-runtime-inventory.md

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