diff --git a/LifeOS/install/skills/Harvest/SKILL.md b/LifeOS/install/skills/Harvest/SKILL.md index 537dd5c839..f59d35f149 100644 --- a/LifeOS/install/skills/Harvest/SKILL.md +++ b/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 ` 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." diff --git a/LifeOS/install/skills/Harvest/Workflows/Harvest.md b/LifeOS/install/skills/Harvest/Workflows/Harvest.md index 98a3f0734e..41006d9f22 100644 --- a/LifeOS/install/skills/Harvest/Workflows/Harvest.md +++ b/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: