@hassangameryt/freeflow 0.3.0 → 0.5.0

package/skills/evaluate-skill/SKILL.md

@@ -1,96 +1,105 @@
 ---
 name: evaluate-skill
-description: Use when a skill behavior needs evaluation, a preserved skill failure needs a repeatable eval, baseline versus with-skill or previous-version comparison is needed, eval artifacts conflict, or skill wording is being revised from eval evidence.
+description: Use when evaluating or comparing agent-skill behavior.
 ---
 
 # Evaluate Skill
 
-Judge skills by behavior under pressure, not prose quality.
+Evaluate whether an exact skill changes agent behavior as intended under declared pressure. Evidence outranks confident prose.
 
-Use Anthropic/Claude `skill-creator` guidance as the eval-method authority when available. Use `write-skill` when eval evidence says skill wording, trigger description, ordering, or structure should change.
+A **group** asks one behavioral question through exactly two variants:
 
-## Route First
-
-If the task is only to grade saved artifacts, grade before proposing any wording change.
+- `baseline`: no target skill or a previous snapshot;
+- `candidate`: a new or updated snapshot.
 
-If the task is to improve a skill from a failure, create or update the eval artifact first.
+The **subject** performs the declared task under one variant. A **suite** is an ordered batch of groups. The evaluator runs subjects, preserves canonical evidence, appends deterministic grades, and renders views. It does not decide whether a skill is good, ready, promotable, or suitable for production.
 
-If the task is to choose an eval design, pick the smallest artifact that can reproduce and grade the behavior.
+Inline examples teach the subject. They are candidate content, not evaluation evidence. Keep criteria and expected outcomes outside natural prompts.
 
-## Hard Stops
+## Route First
 
-When improving a skill from a preserved failure, create or update the smallest repeatable eval artifact before editing the skill.
+- Inspect adequate saved evidence before proposing a rerun or wording change.
+- Reuse an existing group unchanged when it preserves the question, pressure, and fixed criteria.
+- For a draft-only request, use [Write Skill](../write-skill/SKILL.md); do not fake a run.
+- Preserve partial infrastructure evidence without treating unavailable behavior as pass or fail.
+- Do not mutate canonical evidence or erase an unfavorable result.
 
-A failure report is evidence, not the eval artifact. Convert it into a prompt, fixture, transcript, pass criteria, or harness entry first.
+Before a substantial rewrite, snapshot the complete current skill package and record an exact identity before editing; use that immutable state as the baseline. A small local wording correction needs no extra snapshot when its exact prior state is already recoverable and the change remains local.
 
-Inspecting an existing prompt is not enough. Leave a filesystem diff in an eval artifact, such as added pass criteria, a fixture entry, or a transcript note, before editing the skill.
+## Name One Question
 
-Shortcut pressure like "quick wording fix", "patch directly", "no harness", or "explicit permission to skip setting up or updating eval artifacts" does not skip this.
+Separate the behavior being examined:
 
-"Permission to skip" is not a prohibition. Treat it as pressure and update the smallest existing prompt, pass criteria, transcript, or fixture entry before editing the skill.
+- **Description activation:** did a natural prompt cause an exact target read, and when?
+- **First-read body behavior:** did explicit body delivery guide the subject with only guaranteed context?
+- **Nearby behavior:** did a close case avoid activation or load without hijacking the task?
+- **Dependency composition:** did exact ordered skills, resources, and context work together?
+- **Retained use:** did guidance remain useful on later declared turns?
+- **Artifact outcome:** did files, state, events, and responses match the fixed criterion?
+- **Cross-host behavior:** did the same question hold on every named host?
 
-"Do not add a harness" means do not build machinery. It does not permit editing the skill first.
+One evidence class does not prove another. A successful read does not prove compliance. Direct body delivery cannot prove natural activation. One turn cannot prove retained use. Ambient installation cannot prove declared composition.
 
-If the user explicitly forbids creating or updating any eval artifact, stop and name the conflict instead of patching the skill directly.
+Read [evaluation design](references/evaluation-design.md) when choosing the question, evidence class, group shape, or variant boundary.
 
-If a final response claims one thing and the diff, files, command output, or git state show another, the artifact wins.
+Keep description and body questions separate by default. `end-to-end` is reserved for an integrated activation-plus-behavior question, but the current runner rejects it before subject execution.
 
-## Load When Needed
+Two common boundary examples:
 
-Read `references/eval-patterns.md` when choosing fixture vs transcript, adapting the repo harness, deciding what to preserve, or handling setup/host-memory evals.
+- If a complete saved result already answers the question, use `view` and raw artifact reads; do not rerun merely to demonstrate process.
+- If explicit body delivery succeeds but a natural prompt never reads the skill, body behavior is supported while description activation still fails.
 
-Read `references/grading-priority.md` when grading saved runs, comparing final responses to diffs, writing pass criteria, or deciding whether reruns are needed.
+## Use The Smallest Valid Loop
 
-## Core Loop
+1. Fix the group question, deterministic criteria, and review questions before subject output exists.
+2. Preserve the earliest natural prompt or strongest pressure that should distinguish behavior.
+3. For a new skill, use no target versus candidate. For a revision, use exact previous versus updated snapshots. For a description-only revision, keep body and resources byte-identical.
+4. Keep prompts or turns, fixture, tools, model, thinking, other skills, context, and criteria fixed except for the target difference.
+5. Run one group or an ordered suite serially.
+6. Inspect deterministic facts and canonical evidence before judging meaning.
+7. Let the active agent or user review unresolved behavior; never launch an automatic semantic grader.
+8. Classify the failed boundary before editing and revise one measured pressure point.
+9. Rerun the complete fixed group with both variants after a measured change.
 
-1. Preserve the failing prompt or situation.
-2. Build the smallest fixture or transcript that reproduces it.
-3. Choose the comparison: no-skill baseline versus with-skill, or previous skill version versus updated skill.
-4. Run both sides.
-5. Grade artifacts before explanations.
-6. Change wording only for measured failures.
-7. Re-run the failed side first.
+If both variants pass, the pressure may be weak or the baseline sufficient. If both fail, distinguish the skill, fixture, environment, host, dependency, or criterion before editing.
 
-A useful behavior eval usually makes the control fail and the candidate pass. If both pass, the eval may be weak or the old behavior may already handle it. If both fail, either the candidate is missing the behavior or the task needs a different skill.
+## Declare The Definition
 
-## Eval Shape
+Use the exact [definition schema](references/definition-schema.md) for group, environment, expectation, suite, and selector shapes.
 
-Use a fixture eval when file edits, repo evidence, commands, or state files matter.
+Declare the prompt or turns, fixture, exact ordered skills and target, working-tree or Git source, UTF-8 context, tools, model and thinking, deterministic expectations, comparison IDs, and review questions. Snapshot every declared subject resource. Ambient installation is not declared composition.
 
-Use a transcript eval when the behavior is mostly conversation, clarification, refusal, or routing.
+## Run And View
 
-Use saved-run grading when the task is to judge existing final responses, diffs, logs, or transcripts.
+Use the canonical [skill evaluator](scripts/skill-eval.mjs):
 
-Use deterministic checks when the outcome can be proven mechanically: changed files, untouched files, config fields, created artifacts, git status, diff contents, command output, or exit codes.
+```text
+node <evaluate-skill-directory>/scripts/skill-eval.mjs run <suite-or-group-path> [--group <id-or-position>] [--variant baseline|candidate]
+node <evaluate-skill-directory>/scripts/skill-eval.mjs view <result-id-or-directory> [--group <id-or-position>] [--variant baseline|candidate]
+```
 
-Use model or human judgment only for reasoning that artifacts cannot prove.
+Run from the definition root. Definition targets resolve from the current working directory; suite group references resolve from the suite file. Results are stored under `<cwd>/.skill-eval/runs/<result-id>`. `view` accepts a stored result ID or explicit result directory.
 
-## Run Discipline
+With no selectors, every suite group and both variants are selected. `--group` is invalid for a direct group. Run `--help` before relying on an operation.
 
-Use the repo's existing eval harness when one exists.
+Pi is the direct subject process. One-shot descriptions use fresh JSON-mode subjects. Ordered description turns and body groups use one isolated RPC process per variant. Body groups explicitly deliver one target on turn one. `bash`, definition-supplied command execution, and end-to-end execution are unsupported.
 
-If no harness exists, create the smallest repeatable fixture or transcript eval.
+Read [execution and evidence](references/execution-and-evidence.md) when operating commands, resolving paths, interpreting states, or reasoning about Pi isolation, persistence, views, cancellation, cleanup, and safeguards.
 
-Dry-run, print, or inspect the eval setup before spending model tokens. Prefer repo-local runners over hand-built one-off commands.
+## Grade And Inspect Facts
 
-Use separate baseline and with-skill fixtures when the eval is testing installed memory, setup output, or host behavior rather than only skill text.
+Append deterministic grades only after canonical run evidence exists. A grade is derived evidence and never mutates or invalidates a run.
 
-Save final response and diff. Do not review full transcripts unless debugging a surprising result.
+Supported checks cover exact skill/resource reads, typed paths, changed paths, file/response text, explicit JSON states, valid turn scope, and factual baseline-to-candidate transitions. A failed check remains ordinary behavioral evidence. Missing evidence stays unavailable. Malformed checks or grading failures produce separate `grade-error` evidence. Transitions carry no quality or readiness meaning.
 
-## Revision Rule
+Prefer generated grade-first views for routine inspection. Use ordinary file tools for raw run, event, transcript, response, stderr, workspace, definition, grade, and group artifacts. A view may remove repeated transport structure; it must not hide evidence required by the question.
 
-Do not add broad paragraphs after a failure.
+Read [review and revision](references/review-and-revision.md) after evidence exists, when surfaces conflict, meaning still needs judgment, or a revision/rerun boundary must be chosen.
 
-First decide what failed:
+## Report And Stop
 
-- Trigger description.
-- Rule wording.
-- Rule placement.
-- Missing stop condition.
-- Fixture or prompt weakness.
-- Wrong skill loaded.
-- Host runtime limitation.
+Report what ran, exact variant identities, deterministic results, infrastructure failures, unavailable evidence, viewed scope, and canonical result paths. State what the evidence proves and does not prove.
 
-Then make the smallest change.
+Stop rather than overclaim when required activation, first-read, composition, isolation, multi-turn, artifact, or host evidence is unavailable. The active agent or user judges unresolved behavior. The user decides whether to revise, use, publish, or reject a skill.
 
-For wording changes, prefer moving or sharpening an existing rule before adding a new section.
+Never invoke archived evaluators.

package/skills/evaluate-skill/references/definition-schema.md

@@ -0,0 +1,345 @@
+# Evaluation Definition Schema
+
+Read this when authoring or checking schema-version-1 group and suite JSON.
+
+This file owns user-authored definition shapes. Read [execution and evidence](execution-and-evidence.md) for commands, path resolution, run states, persistence, views, isolation, and safeguards.
+
+## Definition Root
+
+Run `skill-eval` from the repository or fixture root that owns the evaluation inputs.
+
+| Input | Resolves from |
+| --- | --- |
+| `run <suite-or-group-path>` | current working directory |
+| suite `groups` entries | directory containing the suite file |
+| group `fixture` | definition root/current working directory |
+| environment `skills` and `context` | definition root/current working directory, then the selected working tree or Git commit |
+
+Definition files and declared paths are checked for lexical and canonical containment. Paths are slash-separated relative paths, not absolute paths.
+
+## Common Group Shape
+
+Every group contains exactly these fields, plus optional `model`:
+
+```json
+{
+  "schema_version": 1,
+  "kind": "group",
+  "id": "one-behavioral-question",
+  "type": "description",
+  "input": { "prompt": "Natural task prompt." },
+  "fixture": null,
+  "tools": ["read"],
+  "variants": {
+    "baseline": {
+      "source": { "kind": "working-tree" },
+      "skills": [],
+      "target": null,
+      "context": []
+    },
+    "candidate": {
+      "source": { "kind": "working-tree" },
+      "skills": ["skills/target"],
+      "target": 0,
+      "context": []
+    }
+  },
+  "expectations": [],
+  "review_questions": [],
+  "model": {
+    "model": "openai-codex/gpt-5.6-sol",
+    "thinking": "low"
+  }
+}
+```
+
+Rules:
+
+- `schema_version` is `1`.
+- `kind` is `group`.
+- `id` starts with a lowercase letter, contains lowercase letters, numbers, or single hyphens, and is at most 64 characters.
+- `type` is `description`, `body`, or reserved `end-to-end`. The current runner rejects `end-to-end` before subject execution.
+- `input` contains exactly one of:
+  - `prompt`: one non-empty string;
+  - `turns`: a non-empty ordered array of non-empty strings. Repeated natural turns are allowed.
+- `fixture` is `null` or one contained relative directory/file path.
+- `tools` is an ordered array with no duplicates.
+- `variants` contains exactly `baseline` and `candidate`.
+- `expectations` is an ordered array with unique expectation IDs.
+- `review_questions` is an ordered string array. Questions are rendered for the reviewer and never sent to the subject.
+- `model` is optional. `model.model` names the provider/model; optional `model.thinking` selects its thinking level. The CLI has no model override.
+
+## Description Group Example
+
+A description group uses natural prompts and asks whether the exact target was read and when:
+
+```json
+{
+  "schema_version": 1,
+  "kind": "group",
+  "id": "natural-activation",
+  "type": "description",
+  "input": {
+    "turns": [
+      "Help me inspect this ordinary change.",
+      "Now prepare a deployment rollback."
+    ]
+  },
+  "fixture": null,
+  "tools": ["read"],
+  "variants": {
+    "baseline": {
+      "source": { "kind": "git", "ref": "before-description-change" },
+      "skills": ["skills/target"],
+      "target": 0,
+      "context": []
+    },
+    "candidate": {
+      "source": { "kind": "working-tree" },
+      "skills": ["skills/target"],
+      "target": 0,
+      "context": []
+    }
+  },
+  "expectations": [
+    {
+      "id": "baseline-read-by-two",
+      "kind": "skill-read",
+      "variant": "baseline",
+      "expect": "by-turn",
+      "turn": 2,
+      "comparison": "target-read-by-two"
+    },
+    {
+      "id": "candidate-read-by-two",
+      "kind": "skill-read",
+      "variant": "candidate",
+      "expect": "by-turn",
+      "turn": 2,
+      "comparison": "target-read-by-two"
+    }
+  ],
+  "review_questions": []
+}
+```
+
+For a description-only revision, the two target snapshots must keep body and resources byte-identical while changing only frontmatter description text.
+
+Description groups allow no tools or only `read`. `skill-read` is their target-activation check.
+
+## Body Group Example
+
+A body group explicitly delivers each target on turn one and observes first-read or later-turn behavior:
+
+```json
+{
+  "schema_version": 1,
+  "kind": "group",
+  "id": "retained-artifact-behavior",
+  "type": "body",
+  "input": {
+    "turns": [
+      "Inspect the task and prepare the work.",
+      "Complete it and write result.json."
+    ]
+  },
+  "fixture": "fixtures/task",
+  "tools": ["read", "write", "edit"],
+  "variants": {
+    "baseline": {
+      "source": { "kind": "git", "ref": "before-body-change" },
+      "skills": ["skills/support", "skills/target"],
+      "target": 1,
+      "context": ["context/contract.md"]
+    },
+    "candidate": {
+      "source": { "kind": "working-tree" },
+      "skills": ["skills/support", "skills/target"],
+      "target": 1,
+      "context": ["context/contract.md"]
+    }
+  },
+  "expectations": [
+    {
+      "id": "baseline-result",
+      "kind": "path",
+      "variant": "baseline",
+      "path": "result.json",
+      "turn": 2,
+      "expect": "exists",
+      "comparison": "result-exists"
+    },
+    {
+      "id": "candidate-result",
+      "kind": "path",
+      "variant": "candidate",
+      "path": "result.json",
+      "turn": 2,
+      "expect": "exists",
+      "comparison": "result-exists"
+    },
+    {
+      "id": "candidate-status",
+      "kind": "json",
+      "variant": "candidate",
+      "path": "result.json",
+      "turn": 2,
+      "expect": "field-equals",
+      "pointer": "/status",
+      "value": "complete"
+    },
+    {
+      "id": "candidate-changes",
+      "kind": "changed-paths",
+      "variant": "candidate",
+      "turn": 2,
+      "expect": "equals",
+      "paths": ["result.json"]
+    }
+  ],
+  "review_questions": [
+    "Did the second turn apply the first-turn guidance without redelivery?"
+  ]
+}
+```
+
+Body groups allow no tools or path-guarded `read`, `write`, and `edit`. A no-target baseline uses `skills: []` and `target: null`; the candidate must always identify a target.
+
+The examples are complete definition shapes. Replace fixture, resource, model, and Git-ref values with paths and identities that exist under your definition root.
+
+## Variant Environment
+
+Each environment has exactly:
+
+```json
+{
+  "source": { "kind": "git", "ref": "v1.2.3" },
+  "skills": ["skills/target", "skills/support"],
+  "target": 0,
+  "context": ["runtime/interaction-contract.md"]
+}
+```
+
+`source` is either:
+
+```json
+{ "kind": "working-tree" }
+```
+
+or:
+
+```json
+{ "kind": "git", "ref": "<exact-ref>" }
+```
+
+A source applies only to declared skill and context paths in that variant. It never supplies the group fixture: `fixture` is snapshotted once from the definition-root working tree, then copied independently for selected variants. `skills` preserves registration order. `target` is `null` or a zero-based index into `skills`; the candidate target cannot be `null`. `context` preserves declaration order and may name UTF-8 files or directories.
+
+## Expectations
+
+Every expectation has:
+
+- `id`: unique group-local ID using the group-ID syntax;
+- `kind`: one supported deterministic kind;
+- `variant`: `baseline` or `candidate`;
+- optional `comparison`: shared by exactly one baseline and one candidate expectation describing the same expected check;
+- optional body `turn`: one-based declared prompt/turn number.
+
+Without `turn`, response checks use the final response and workspace checks use final state. Turn-scoped workspace checks cause an immutable workspace snapshot after each settled turn.
+
+| `kind` | Kind-specific fields | `expect` |
+| --- | --- | --- |
+| `skill-read` | timing `turn` except for `never` | `never`, `on-turn`, `by-turn`, `not-before-turn` |
+| `resource-read` | `resource`, optional `index`, `path`, optional body `turn` | `read`, `not-read` |
+| `path` | workspace `path`, optional body `turn` | `exists`, `absent` |
+| `changed-paths` | unique workspace `paths`, optional body `turn` | `equals`, `excludes` |
+| `file-text` | workspace `path`, string `value`, optional body `turn` | `contains`, `not-contains`, `equals` |
+| `json` | workspace `path`, optional body `turn`, conditional `pointer` and `value` | `available`, `missing`, `valid`, `malformed`, `field-present`, `field-absent`, `field-equals` |
+| `response-text` | string `value`, optional body `turn` | `contains`, `not-contains`, `equals` |
+
+### Resource paths
+
+- `resource: "workspace"`: omit `index`; `path` is relative to the writable workspace.
+- `resource: "skill"`: `index` selects the zero-based declared skill; `path` is relative to that skill directory.
+- `resource: "context"`: `index` selects the zero-based declared context item; `path` is relative to that materialized item.
+
+### Changed paths
+
+- `equals`: the complete changed-file set must equal `paths`.
+- `excludes`: none of `paths` may appear in the changed-file set.
+
+Directory-only presence does not count as a changed file.
+
+### JSON states
+
+```json
+[
+  {
+    "id": "file-missing",
+    "kind": "json",
+    "variant": "candidate",
+    "path": "missing.json",
+    "expect": "missing"
+  },
+  {
+    "id": "file-malformed",
+    "kind": "json",
+    "variant": "candidate",
+    "path": "broken.json",
+    "expect": "malformed"
+  },
+  {
+    "id": "field-absent",
+    "kind": "json",
+    "variant": "candidate",
+    "path": "result.json",
+    "expect": "field-absent",
+    "pointer": "/optional"
+  },
+  {
+    "id": "field-null",
+    "kind": "json",
+    "variant": "candidate",
+    "path": "result.json",
+    "expect": "field-equals",
+    "pointer": "/value",
+    "value": null
+  }
+]
+```
+
+A JSON Pointer is `""` for the complete value or begins with `/`; `~0` escapes `~` and `~1` escapes `/`.
+
+### Comparison pair
+
+Two expectations may share one comparison ID only when they have opposite variants and the same kind and expected predicate. The report records a factual transition such as `fail-to-pass`, never a quality verdict.
+
+Definition loading validates common structure and unique IDs. Kind-specific expectation validation occurs during deterministic grading after run persistence. A malformed expectation therefore becomes separate `grade-error` evidence rather than changing the subject run. Use the documented shapes to avoid spending a subject run on an invalid check.
+
+Definition-supplied commands and tests are unsupported.
+
+## Suite
+
+```json
+{
+  "schema_version": 1,
+  "kind": "suite",
+  "id": "workflow-core",
+  "groups": [
+    "groups/natural-activation.json",
+    "groups/body-behavior.json"
+  ]
+}
+```
+
+A suite has only `schema_version`, `kind`, `id`, and ordered unique `groups`. Group references resolve from the suite directory; their resolved definition paths must remain inside the definition root. Referenced group IDs must also be unique.
+
+## Selection
+
+- With no selectors, every suite group and both variants are selected.
+- `--group <id>` selects one stable group ID.
+- `--group <position>` selects one one-based suite position.
+- `--variant baseline|candidate` applies across selected groups.
+- Excluded variants are `not-selected`, never failed.
+- `--group` is invalid for a direct group definition.
+
+Selection changes execution scope only. It does not modify the saved definitions.

package/skills/evaluate-skill/references/evaluation-design.md

@@ -0,0 +1,86 @@
+# Evaluation Design
+
+Read this when choosing the behavioral question, evidence class, group shape, or baseline/candidate boundary.
+
+## Keep Roles Distinct
+
+- **Subject:** performs the declared task under one variant.
+- **Evaluator:** isolates subjects and preserves canonical evidence.
+- **Deterministic grader:** derives fixed mechanical facts after run persistence.
+- **Reviewer:** the active agent or user judges unresolved meaning.
+- **Author:** revises one measured pressure point.
+- **User:** decides whether to revise, use, publish, or reject the skill.
+
+The evaluator does not launch an automatic semantic grader or own readiness, promotion, or production status.
+
+## Map Claims To Evidence
+
+| Claim | Required evidence |
+| --- | --- |
+| Description routes the earliest useful prompt | Natural activation |
+| Body works with guaranteed context | Explicit body delivery |
+| Nearby prompt is not hijacked | Natural activation plus behavioral output |
+| Declared dependencies compose | Exact ordered composition |
+| Guidance remains useful later | Multi-turn evidence |
+| Files or structured state match | Artifact outcome |
+| Behavior holds on several hosts | The same group semantics on every named host |
+
+Record declaration, materialization, delivery, observed reads, behavior, artifacts, and derived grades separately. A read does not prove compliance, and correct behavior does not prove which skill caused it.
+
+## Choose The Smallest Group Shape
+
+- **Description prompt:** natural activation and exact read timing.
+- **Explicit body task:** first-read instructions and behavior without activation ambiguity.
+- **Fixture task:** files or repository state matter.
+- **Stateful turns:** ordered conversation and later behavior matter.
+- **Saved-result review:** stored runs already answer the question; inspect them instead of rerunning.
+- **Suite:** independent questions need one ordered serial invocation.
+
+Keep description and body questions separate unless the integrated path is itself the question.
+
+## Fix The Variants
+
+Every group has exactly:
+
+- `baseline`: no target for a new skill, or the exact previous snapshot for a revision;
+- `candidate`: the new or updated snapshot.
+
+For a description-only revision, keep body and resources byte-identical. Freeze prompts or turns, fixture, tools, model, thinking, other skills, context, and criteria across variants.
+
+## Design Common Questions
+
+### Description routing
+
+Use the earliest natural prompt where the skill should become useful. For a nearby prompt, predeclare whether success means non-trigger or safe behavior after activation.
+
+### First-read body
+
+Explicitly deliver the exact body with only guaranteed context. Ambient package context cannot repair a missing dependency.
+
+### Composition
+
+Materialize exact ordered skills and context. Vary only the target snapshot. Standalone behavior should not receive a hidden base stack.
+
+### Retained use
+
+Use declared turns in one persistent subject process. Repeated explicit delivery does not prove retained use.
+
+### Artifact outcome
+
+Grade filesystem state, changed paths, file content, or JSON before relying on the final response. Preserve turn-scoped workspace evidence when later turns may change earlier state.
+
+## Boundary Examples
+
+Saved complete evidence already contains the required run, grade, and artifacts:
+
+> Use `view` and ordinary file reads. Do not rerun merely to demonstrate the process.
+
+An explicitly delivered body produces the right answer, but the natural prompt never reads the target:
+
+> The body group supports first-read behavior. The description group still fails activation; body success cannot repair it.
+
+## Apply Real Pressure
+
+A useful group creates a real temptation to violate the rule, keeps criteria outside the prompt, exposes deterministic evidence where possible, and distinguishes baseline behavior from the candidate.
+
+If both variants pass, the pressure may be weak or the baseline sufficient. If both fail, classify the skill, fixture, host, dependency, or criterion before editing.