# Transferrec Automation Governor

> Thin governor for the Transfer_Recovery mainline automation loop. Use when the task is recurring experiment control, state transition, ledger/docs/memory closeout, or handoff recovery. Do not use for open-ended method ideation or historical batch review.

- Skill: `ocean326/transferrec-automation-governor` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ocean326/transferrec-automation-governor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ocean326/transferrec-automation-governor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: ocean326 (https://skillmd.com/u/ocean326)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ocean326/transferrec-automation-governor

---


# TransferRec Automation Governor

Use this skill when the work is:

- recurring automation on the active Transfer_Recovery mainline
- manual recovery of an interrupted automation loop
- state classification and one-step experiment governance
- ledger, docs, and memory synchronization after a run-state change

Do not use this skill for:

- broad research ideation
- historical rollout review
- prompt polishing unrelated to the active mainline
- expanding parameter matrices without an explicit keep/stop/turn decision

## Primary Goal

Keep the controller focused on one active mainline and one bounded action per round, while keeping `179` evidence, the active run ledger, 0417 docs, and automation memory aligned.

## Evidence Order

Always resolve conflicts in this order:

1. `179` latest JSON / log / process
2. current active run ledger
3. 0417 main docs
4. automation memory
5. current prompt or prior assumptions

Never let stale docs, stale memory, or a stale prompt override live `179` evidence.

## State Machine

Classify the round into exactly one state before broad probing:

- `A = live mainline sync`
- `B = completed harvest`
- `C = next mainline launch`
- `D = incident / handoff`

If the state is unclear, spend the first tool budget resolving the state. Do not start with wide exploration.

## Allowed Actions

For each state, authorize exactly one bounded worker action:

- `A -> live_sync`
  - probe `179`
  - update active ledger
  - minimally sync queue/live docs
  - refresh memory

- `B -> result_harvest`
  - extract final metrics
  - update ledger
  - update 0417 docs
  - make one keep/stop/turn decision

- `C -> launch_prep`
  - write pending ledger with goal, control, single variable, success criteria, stop rule, command, artifact path
  - launch one next run only after the ledger exists

- `D -> incident_probe`
  - record exact time, machine, SSH path, PID, log path, last refresh time, attempted actions, current judgment
  - leave one concrete first command for the next round

## Hard Guardrails

- Maintain exactly one active mainline.
- Do not start a new formal batch in state `A` or `D`.
- Do not treat Lenovo smoke as accepted evidence.
- Do not backfill formal tables before `179` evidence is sufficient.
- Do not reopen an old parameter matrix without an explicit prior decision.
- Do not bring `codex-session-evolution` into the normal hourly loop.

## Skill Routing

- default owner: `delivery-conductor`
- use `research-router` only if state classification is genuinely ambiguous after snapshot
- use `proposal-critique-refine` only when revising the workflow, prompt, or this skill itself
- reserve `codex-session-evolution` for offline governance audits

## Output Contract

Every run should close with:

1. current state summary
2. actions actually taken
3. evidence vs inference
4. files updated
5. next handoff with the first command

If no new results are available, still leave a recoverable handoff.