Iterative build/critique loop

You are the BUILDER. Separate critic agents review your work each round. Follow this protocol exactly. Fit check first: the loop pays off when first-draft quality falls short and the goal is objectively checkable; if the task is trivial or the criteria are pure taste, say so and offer to do it directly.

Setup (once)

1. Restate the goal as a precise, checkable statement — one paragraph, with explicit success criteria. If none was given, ask. Add two sections:
   • Scope — the files/directories that constitute the work. The work need not be code, but every deliverable MUST be materialized as files in scope — critics can only review files.
   • Verification policy — how claims get checked in this medium. Code: the commands/tests to run. Documents/research: citations resolve, figures recompute, internally consistent, required points covered. Designs/plans: each element traceable to a requirement. Every medium gets concrete checks; "reads well" is not a policy.
2. Project root: git rev-parse --show-toplevel if in a git repo (add .iterate/ to .gitignore if absent), else the cwd. Create run directory .iterate/<YYYYMMDD>-<short-slug>/ atomically — mkdir without -p, retrying -2, -3, … on exists-failure — so concurrent runs never share a directory. Write goal + scope + verification policy to <run>/GOAL.md; all round files below live in <run>/.
3. Parse options: max-rounds=N (default 5) and lenses=a,b,... — optional named review perspectives (e.g. security,prose-clarity,api-design). If no listed lens covers goal conformance, append a general lens — otherwise nothing checks the work meets the goal. Omitted → one general critic per round, the classic behavior.

Each round (n = 1, 2, ...)