Docs: the skill file says what the trainer does now

iris instead of question_lint everywhere; the skill's procedure is
plan, build, score: the opener and the look-around, mails and the
sender, moves for the person, doors only when measured, the lift
through a rebuild, the language and link guards, the descriptions
score over the headings score, and the spread a change has to beat.
README documents --llm-for.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

README.md

@@ -12,7 +12,7 @@ produced is content, and every line of it is held to a verifier.
 
 ```
 portal-trainer build --plan plans/contractor.yaml --out out/nordvik \
-    --lint question_lint --llm "MODEL=nemotron-3.5-lightning:30b-a3b engines/ollama.sh"
+    --lint iris --llm "MODEL=sonnet engines/claude.sh"
 ```
 
 A `plan.yaml` is a needs spec that also says what each form collects
@@ -30,7 +30,10 @@ result by construction; what it still checks is the budget.
 
 The model writes words only, one page at a time, into a JSON object
 whose shape is fixed. Its strings are merged over built-in fallbacks
-key by key, so a bad reply costs wording, never a working site.
+key by key, so a bad reply costs wording, never a working site. `--llm-for <path prefix>` points the model at some pages only
+(`aggregates.yaml` for the mails alone); a reply in the wrong language
+for the plan is refused, and a mail that lost the submitter's link
+gets it back.
 
 ### Onboarding from the plan
 
@@ -195,7 +198,7 @@ against the lint. It is kept for the record of what it measured.
     ▼  phase 1                       frozen after this phase: the generator
  needs.yaml ───────────────────────  may not weaken the spec to pass
     │
-    ▼  phase 2   ◄── question_lint findings, until it exits 0
+    ▼  phase 2   ◄── iris findings, until it exits 0
  aggregates.yaml + questions/** + desks
     │
     ▼  phase 3   ◄── misroutes from a blind visitor model
@@ -208,7 +211,7 @@ against the lint. It is kept for the record of what it measured.
    handles it, the states that count as finished, and the effort the
    visitor will tolerate.
 2. **Structure.** Pages, state machines and desks are generated, then
-   revised against portal's `question_lint` until every need is met:
+   revised against the lint, `iris check`, until every need is met:
    a path within budget, a desk held by the right group, every
    finished state reachable, no record stranding. The page-writing
    model sees the needs and never the personas.
@@ -222,7 +225,7 @@ and `questions/**.yaml` inside the output directory.
 
 ```
 portal-trainer generate --intake intakes/contractor.yaml --out out/nordvik \
-    --lint /srv/app/<inst>/current/question_lint --llm engines/ollama.sh
+    --lint iris --llm engines/ollama.sh
 portal-trainer answer --tasks tasks.jsonl --llm engines/ollama.sh > answers.jsonl
 ```
 
@@ -232,7 +235,7 @@ sees another visitor's situation, a heading's place on the page cannot
 carry the answer, and a rerun on the same site is the same experiment.
 The earlier runs under `runs/` answered all tasks in one prompt.
 
-The verifier is portal's `question_lint`, not code in this repo: it
+The verifier is uhhm/iris, not code in this repo: it
 reads portal's own content types and ships in every portal release, so
 a generated repo's CI keeps enforcing its needs after handover.