Harvest: add eval-before-adoption step for behavior-changing candidates

LifeOS/install/skills/Harvest/SKILL.md

@@ -33,6 +33,7 @@ Take one piece of content and ask a single question: **is there anything in here
 
 - **YouTube needs `fabric -y` first.** Never parse the YouTube page HTML — it's nav and JS. `fabric -y <url>` returns the transcript; analyze that.
 - **System adoption is report-only. Never edit the system from inside a harvest.** The mining output is a proposal set. Changing an Algorithm file, a hook, a skill, or doctrine happens only after {{PRINCIPAL_NAME}} approves a specific item. The ONE write a harvest always performs is the Knowledge Archive ingestion (final step).
+- **Behavior-changing candidates need an eval, not just a review.** If adopting a candidate would change how the system behaves (Algorithm mechanics, skill workflow logic, hooks, routing policy), the Recommended action proposes an offline comparison against the current mechanism, with a decision rule written down before results exist — review catches bad designs; only evals catch worse-than-baseline designs. Cosmetic candidates skip with a one-line reason.
 - **Name the surface or drop the finding.** "This is a cool idea" is not a harvest hit. "This maps to a new PostToolUse hook that would catch X" is. Vague usefulness gets cut.
 - **Prior Status prevents re-surfacing solved work.** Before tagging NEW, check whether LifeOS already does it (grep skills/hooks, recall recent ISAs). Re-pitching something already built is the main failure mode.
 - **Be honest about empty content.** A lot of content has nothing to harvest. Say that. Manufacturing three weak findings to look thorough is worse than one true "nothing here."

LifeOS/install/skills/Harvest/Workflows/Harvest.md

@@ -76,7 +76,15 @@ Rules for the report:
 - Recommend, don't do. Adoption of any item is a separate step that needs {{PRINCIPAL_NAME}}'s explicit go-ahead.
 - Keep it tight. A harvest is a filter, not an essay.
 
-## Step 7 — Ingest into the Knowledge Archive (ALWAYS the final step)
+## Step 7 — Eval before adoption (behavior-changing candidates only)
+
+For any candidate whose adoption would change system **behavior** — Algorithm mechanics, a skill's workflow logic, hooks, routing/delegation policy — the Recommended action proposes **eval-first**: an offline comparison against the current mechanism, with a decision rule written down before results exist, and blind judging where feasible. Write eval criteria to the standard of `ALGORITHM/eval-guide.md` (the 3-question test). Past ISA Changelog `conjectured → refuted_by` entries make useful test labels where they exist. Adoption still requires {{PRINCIPAL_NAME}}'s explicit go-ahead after the eval.
+
+Cosmetic or non-measurable candidates (format rules, doc grafts) skip the eval — note the skip in one line. When unsure whether a candidate is behavior-changing, treat it as behavior-changing.
+
+**Why:** review catches bad designs; only evals catch worse-than-baseline designs. A mechanism can survive adversarial review and still lose a blind comparison to the status quo it was meant to replace.
+
+## Step 8 — Ingest into the Knowledge Archive (ALWAYS the final step)
 
 Every harvest ends by preserving the source as a KNOWLEDGE note, regardless of how thin the mining verdict was: