Harness Loop

Ordinary work stays with one owner using the tracker, direct implementation and checks. This skill does not require a loop or a new refinement pass. For user-requested observer repair, work outside the controller and report any authorized hook bypasses honestly.

Read loop state only when starting, advancing or recovering work explicitly managed by basicly loop:

basicly loop status <issue>

The tracker is authoritative. Continue the existing task and worktree; do not restart completed steps or create another owner merely because the session changed.

Boundaries

• For loop-managed work, commit code on its branch before advancing; the engine commits loop tracker state. Direct observer work commits its own tracker evidence.
• The build-to-verify transition performs landing and records verification. Do not record that gate early; it can skip the landing. Confirm landing from the [merged] output.
• Keep the base checkout read-only while another pass runs. Never clear another session's files to unblock landing.
• Reuse verification only when the engine establishes equivalent trusted inputs. Changed inputs or failed checks require the affected checks again.
• Observe a recorded pending process before launching another. A polling timeout does not prove it stopped.

Read only the procedure needed now

• When using loop transitions to start a leaf, classify/decompose, land, validate, ship or recover a refusal, read operations. It includes exact commands, phase inputs, ledger handling and escalation rules.
• Before deciding which checks to run or rerun, read verification.
• Before waiting on a long-running command or CI, read bounded waiting.
• Before running parallel lanes, read the Many lanes section of operations. For lane limits and spending observations, also read many-lanes.
• For ordinary implementation inside an existing lane, use the task facts and relevant implementation skills. Load the operational reference when a transition or failure requires it.