Loop Prompt.template

# Loop prompt — the orchestrator (self-improving)

This file IS the brain of the loop. Every tick: read it, execute it, **improve it**,
schedule the next tick. The loop does not stop on its own and does not block on the human.

## Required reading each tick
1. `genome.md` — mission, focus, guardrails, status.
2. `levers.md` — the prioritized backlog.
3. This file's **Lessons** section.

## The tick cycle
1. **Read** the genome + levers + lessons.
2. **Pick** the single highest-value open lever.
3. **Build / act** — one small, shippable unit. Respect the guardrails strictly.
4. **Gate** — verify it actually works (see Gates). A failing gate sends you back to step 2,
   never forward to "commit anyway."
5. **Commit** the change. Update the genome status + the lever's status log.
6. **Self-improve** — what did you learn? Append a lesson here, mutate the genome,
   bump the version.
7. **Schedule the next tick.**

## Gates (non-negotiable)
- Build AND typecheck green. Do not let `| head` / `| tail` swallow a non-zero exit code.
- Verify the ARTIFACT, not the log. "Deploy succeeded" ≠ "it renders." Check the real output.
- One lever per tick — keep every change reviewable and every rollback cheap.

## Lessons (append-only — this is the self-improving part)
> Each time the loop gets burned, write the rule here so the next tick can't repeat it.

- **Verify before you ship.** A build can fail silently and leave an empty/partial artifact.
  Assert the output is correct *before* deploying.
- **No destructive sweeps.** One odd-looking match is not a mandate for a sitewide change.
  Check intent (comments, context, owner constraints) first.
- **Steward rule.** If the goal contradicts what you actually find (a "small fix" that's really
  a load-bearing rewrite), REPORT instead of blindly executing.
- **Servers don't self-start.** Tools that need a running server: start it, wait for it, then run.

## Backlog empty?
Do NOT stop. Re-audit from a new angle: new opportunities, deeper checks, gaps, coverage.