Harness Loop

---
name: harness-loop
description: Drives tracked work through the basicly loop, intake to ship. Use to start or resume work, or to move an issue past a checkpoint or gate.
---
<!-- Generated by `basicly skills-build` from skill.yaml. Do not edit; edit the source. -->

# 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`:

```sh
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

- The user task request authorizes classification, decomposition and completion within its scope. Do not create a synthetic grant or require a token budget. Honor explicit spending limits.
- Keep verification honest, host permissions and destructive-action confirmations intact. A bypass is not a passing check.
- 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](references/operations.md). It includes exact commands, phase inputs, ledger handling and escalation rules.
- Before deciding which checks to run or rerun, read [verification](references/verification.md).
- Before running parallel lanes, read the **Many lanes** section of operations. For lane limits and spending observations, also read [many-lanes](references/many-lanes.md).
- 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.