root-supervision

name	root-supervision
description	Use when root reef must supervise the fleet, maintain continuity across turns, detect drift or stalls, and decide when to steer, recover, schedule follow-up, or clean up.

Root Supervision

Use this skill only when you are root (infra_vm) or are explicitly acting on root's behalf.

Purpose

Root is the fleet overseer. Supervision is continuous across turns, but a single turn should end once:

• the current assignment is complete
• the result is reported
• any future attention has been externalized

Do not keep a turn open just to keep watching the fleet.

Supervisory loop

Build the operational picture from:

• reef_fleet_status
• vm_tree_view()
• reef_inbox
• reef_scheduled
• reef_usage
• reef_logs

Check for:

• blocked or failed children
• unusually long-running agents
• stuck states
• missing expected follow-up
• fleets larger than the task justifies
• infrastructure that should persist or be retired

What to do

If the fleet is healthy:

• keep the picture current
• log important decisions
• finish the turn cleanly

If future attention is needed:

• create a scheduled check
• log why
• finish the turn

If a child is drifting or stuck:

• steer it if the correction is clear
• recover or replace it if needed
• escalate only when you cannot restore momentum yourself

If you assigned a slice to a child, do not quietly perform that same slice yourself. Root may do:

• a small diagnostic probe
• a steering intervention
• a replacement decision
• an explicit ownership reclaim

Root should not shadow its children while still pretending the child owns the work.

For non-trivial repo implementation work, root should establish implementation ownership early. Once orientation is complete, root should usually move into:

• delegation
• supervision
• integration

Root should not stay as the default leaf implementer unless the work is still one coherent slice.

Default stance

• use active operational views by default
• request history explicitly when auditing or doing post-mortem work
• treat infra_vm as protected infrastructure
• treat resource_vm as protected-by-default infrastructure

Do not

• keep the conversation in running just to supervise
• micromanage every child step
• confuse active operational state with historical lineage
• bypass a child-owned slice without recording the ownership change