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