@hassangameryt/freeflow 0.1.0

package/plugins/freeflow/skills/setup-freeflow/references/activation-contract.md

@@ -0,0 +1,94 @@
+# Activation Contract
+
+This is the canonical Freeflow setup contract. Setup renders this contract into host instruction files; docs, fixtures, and eval assertions should reference it or be checked against it.
+
+## Interface
+
+Use this Markdown reference as the v0.1 contract module:
+
+```text
+getActivationContract(defaultMode) -> ActivationContract
+planActivation(contract, repoState, request) -> ActivationPlan | ActivationStop
+renderActivation(contract, target) -> rendered text or checks
+```
+
+Do not add a code module until setup behavior needs logic that cannot be kept clear in the skill and this reference.
+
+## Invariants
+
+- Activation text contains always-on invariants only, not the full workflow spine.
+- Config has exactly one field: `defaultMode`.
+- Valid defaults are exactly `conversation`, `workflow`, and `strict-workflow`.
+- Default mode is `workflow` unless the user explicitly persists another valid mode.
+- Codex activation writes `AGENTS.md`, not `.codex/rules`.
+- Claude activation writes a `CLAUDE.md` import plus one `.claude/rules/freeflow-core.md`.
+- Multi-agent setup updates both host surfaces only on explicit request and reports drift risk.
+- Existing repo instructions remain source truth.
+- Setup hard-stops before unresolved host ambiguity or repo-rule conflict.
+- Setup does not create repo-local hooks, docs inventories, state files, handoffs, empty `CONTEXT.md`, skill inventories, version metadata, activation path, current task, or current phase.
+- Plugin-bundled context hooks may load workflow and interview-gate context at session start, but they are package runtime, not setup output.
+- After successful setup verification, setup reads the workflow skill, workflow map, and interview-gate skill before its final response so the current session is immediately usable.
+
+## Host Adapters
+
+Codex adapter:
+
+- Update an existing `## Freeflow` block in `AGENTS.md`, or add one near existing agent/workflow instructions.
+- Keep exactly one `## Freeflow` block.
+- Never use `.codex/rules` for Freeflow behavior.
+
+Claude adapter:
+
+- Update `CLAUDE.md` with only the import block below.
+- Write the Codex core block text to `.claude/rules/freeflow-core.md`.
+- Keep exactly one imported core file unless the user explicitly confirms a split after the one-file recommendation.
+
+Config adapter:
+
+- Create or update `.freeflow/config.json`.
+- Write exactly `{ "defaultMode": "<mode>" }`.
+- Use `workflow` unless the user explicitly asks to persist `conversation` or `strict-workflow`.
+
+## Codex Core Block
+
+<!-- freeflow-activation-contract:codex-core:start -->
+```md
+## Freeflow
+
+Use Freeflow for consequential work. Default mode: `.freeflow/config.json`.
+
+Move forward when context is sufficient. Re-enter clarification when new ambiguity would change the next action.
+
+Treat questions as questions and suggestions as hypotheses. Answer directly; do not infer correction, permission, or agreement.
+
+Ask before user-owned decisions: product behavior, scope, public APIs, security, privacy, billing, data loss, compatibility, permissions, or irreversible architecture.
+
+Treat live repo evidence and existing docs/tests as source truth. If the user request conflicts with them, stop and ask before changing behavior.
+
+Verify before completion claims. Capture only stable decisions, glossary terms, ADR-worthy tradeoffs, or useful handoff memory.
+```
+<!-- freeflow-activation-contract:codex-core:end -->
+
+## Claude Import Block
+
+<!-- freeflow-activation-contract:claude-import:start -->
+```md
+## Freeflow
+
+@.claude/rules/freeflow-core.md
+```
+<!-- freeflow-activation-contract:claude-import:end -->
+
+## Drift Checks
+
+Run `plugins/freeflow/evals/scripts/check-activation-contract.sh` when changing setup behavior, post-setup fixtures, setup eval assertions, or docs that quote setup behavior.
+Run `plugins/freeflow/evals/scripts/check-runtime-context-hook.sh` when changing plugin-bundled runtime context hooks.
+
+The check keeps these surfaces aligned:
+
+- this canonical reference
+- `setup-freeflow/SKILL.md`
+- `setup-freeflow/references/host-setup.md`
+- `docs/freeflow-runtime-and-lifecycle.md`
+- post-setup `AGENTS.md` fixtures
+- setup eval assertions that depend on canonical activation text

package/plugins/freeflow/skills/setup-freeflow/references/host-setup.md

@@ -0,0 +1,33 @@
+# Host Setup
+
+Use this only when setup asks for a host, profile, default mode, team install, hooks, CLI, or multi-agent shape. Use `activation-contract.md` for canonical activation text, config invariants, and host adapter rules.
+
+## Hosts
+
+Codex setup writes `AGENTS.md` and `.freeflow/config.json`.
+
+Claude setup writes `CLAUDE.md`, `.claude/rules/freeflow-core.md`, and `.freeflow/config.json`.
+
+Multi-agent setup updates both host surfaces only when the user asks for both or multi-agent setup. Mention that duplicated always-on text can drift, render both hosts from `activation-contract.md`, and keep Claude's full block in one imported file.
+
+Current runtime is not enough to choose a host when both `AGENTS.md` and `CLAUDE.md` exist.
+
+## Profiles
+
+Solo setup is the default: one host target, compact activation, `defaultMode: "workflow"`, no extra docs.
+
+Team setup still uses compact activation. Add both hosts only if requested. Do not add team standards, onboarding docs, owners, approvers, repo-local hooks, or CLI checks as part of setup unless the user separately asks and the repo has a validated path for them.
+
+Strict setup changes `.freeflow/config.json` to `strict-workflow` only when the user explicitly asks to make that the repo default. Otherwise recommend strict-workflow for high-risk work without persisting it.
+
+Valid persisted defaults are exactly `conversation`, `workflow`, and `strict-workflow`.
+
+## Not Setup
+
+Do not install repo-local hooks, CLI commands, lint rules, global standards, docs inventories, or state files during setup.
+
+Freeflow's plugin-bundled context hooks are package runtime. They load workflow and interview-gate context at session start, but setup should not copy hook files into the target repo.
+
+After successful setup verification, setup should read the workflow skill, workflow map, and interview-gate skill before the final response. If session-start runtime context does not load in later sessions, tell the user to review/trust the installed Freeflow plugin hooks or start a fresh/compacted session. Do not create repo-local hook files as a workaround.
+
+If the user asks for enforcement, say Freeflow setup is instruction-only for now and ask whether to handle enforcement as a separate task.

package/plugins/freeflow/skills/verify-work/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: verify-work
+description: Use before claiming work is done, fixed, passing, implemented, reviewed, or ready; when verification fails; or when the user asks to skip checks but still wants a completion claim.
+---
+
+# Verify Work
+
+Do not claim completion without fresh evidence.
+
+## Evidence Rule
+
+Before saying work is done, fixed, passing, implemented, reviewed, or ready, verify the claim.
+
+Good evidence can be:
+
+- Passing tests.
+- Typecheck, lint, build, or formatter output.
+- Reproducing a bug before and after a fix.
+- Inspecting the changed file when no executable check exists.
+- A targeted manual check.
+
+Use the smallest verification that proves the claim.
+
+## Claim Rule
+
+Match the claim to the evidence.
+
+- If tests passed, say which tests passed.
+- If only a file was inspected, say that.
+- If no runnable check exists, say the work is unverified by automation.
+- If the user asks to skip checks, skip the checks but do not claim verified or passing.
+
+Never convert "I changed the code" into "it works" without evidence.
+
+## Failure Rule
+
+If verification fails, stop and report the evidence.
+
+Do not patch randomly. Decide whether the failure means:
+
+- Implementation bug.
+- Bad or stale test.
+- Source-of-truth conflict.
+- Missing environment/dependency.
+- User-owned product/domain decision.
+
+If the failure challenges the spec, plan, docs, policy, or tests, re-enter the interview gate before changing direction.
+
+## Final Response
+
+Use this shape:
+
+```text
+Changed: ...
+Verified: ...
+Not verified: ...
+Next: ...
+```
+
+For completed consequential work, `Next:` is mandatory. Omit it only for direct question answers, mid-task status, or clarification-only turns.
+
+Keep it short.

package/plugins/freeflow/skills/workflow/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: workflow
+description: Use when doing consequential work such as implementation, bug fixing, planning, research-for-action, review, verification, or handoff.
+---
+
+# Workflow
+
+Follow a lightweight forward workflow. Scale process to task risk.
+
+Question means answer. Do not turn a question into a file edit, report, plan, or implementation.
+
+```text
+Clarify / Research
+-> Decision / Spec
+-> Plan
+-> Execute
+-> Review
+-> Verify
+-> Handoff
+```
+
+This is a guide, not ceremony. Small reversible work can skip spec/plan artifacts.
+
+Read `references/workflow-map.md` when the user asks for the full pipeline, public docs need a diagram, or the next workflow entry point is unclear.
+
+## Route Closeout
+
+When a consequential workflow phase completes, name the next route.
+
+Use `Next:` in the final response unless this is a direct question answer, mid-task status, or clarification-only turn.
+
+Choose one:
+
+- Forward: the next workflow entry point is clear.
+- Backward: new evidence requires clarification, research, grilling, or interview gate.
+- Branch: 2-3 valid next routes exist.
+- Stop: no required next action remains.
+
+Recommend the route supported by evidence. Do not ask a vague "what next?" question.
+
+After completed grilling or research with stable uncaptured decisions, route to `write-spec` or `capture-decisions` before `write-plan` or execution.
+
+`Next:` is routing, not permission to create the next artifact or continue into a new phase.
+
+## Backward Edge
+
+If new evidence invalidates the current path, re-enter clarification.
+
+```text
+Any state -> Clarify / Research -> explicit next state
+```
+
+Do not silently substitute a different path, rewrite the spec, change the plan, or patch forward. State what changed, then decide whether to continue, revise spec, revise plan, diagnose, split scope, defer, or stop and ask.
+
+If a requested, planned, or skill-required method cannot be followed and the fallback would change evidence quality, workflow shape, risk, scope, cost, persistence, or user-visible output, stop before using the fallback. Name both paths and ask which one to follow.
+
+## Source-of-Truth Conflicts
+
+When a requested implementation contradicts existing docs, tests, specs, policies, ADRs, handoffs, or established code behavior, pause before editing.
+
+Do not rewrite the source of truth to make the latest request pass.
+
+First state the conflict and ask whether the source of truth should change. Only edit docs/tests/policies/specs to match new behavior after the user explicitly confirms that decision.
+
+Treat handoffs as memory, not authority. If a handoff conflicts with live repo evidence, inspect the evidence and ask before following the handoff.
+
+For billing, security, privacy, data loss, migrations, public APIs, compatibility, and permissions, recommend strict-workflow before changing behavior.
+
+## Artifact Rule
+
+Artifacts are memory, not proof of obedience.
+
+Only create artifacts when the user asks for an artifact or asks you to do work that requires one.
+
+Create them only when they preserve decisions, reduce risk, or help a future agent resume. Prefer short research notes, decision/spec notes, plans, verification notes, and handoffs.
+
+Do not write volatile repo inventories. Link to live files or commands instead.
+
+## Review Rule
+
+Review should improve work, not create an endless patch loop.
+
+Separate blocking from non-blocking findings. Review can pass. Save review artifacts only when risk, future memory value, or the user asks for them.
+
+## Completion Rule
+
+Do not claim completion without fresh evidence. Say what was verified and what remains unverified.

package/plugins/freeflow/skills/workflow/references/workflow-map.md

@@ -0,0 +1,103 @@
+# Freeflow Map
+
+Use this when the user asks how the whole workflow fits together, public docs need a diagram, or the next workflow entry point is unclear.
+
+This map is orienting, not mandatory. Small reversible work can skip unnecessary artifacts and gates. Re-enter clarification whenever new ambiguity would change the next action.
+
+## Compact Map
+
+Use this compact version in public README-style docs.
+
+```mermaid
+flowchart LR
+  Request{request}
+  Talk[conversation<br/>answer directly]
+  Discover[discover<br/>research / grill]
+  Spec[spec]
+  Plan[plan]
+  Build[build<br/>execute / diagnose]
+  Check[review + verify]
+  Close[commit / handoff]
+
+  Request -->|question| Talk
+  Request -->|work| Discover
+  Discover --> Spec --> Plan --> Build --> Check --> Close
+  Check -. new evidence or failed check .-> Discover
+```
+
+```text
+Use conversation mode for questions. Use workflow mode for consequential work.
+Use strict-workflow for risky work; same spine, stronger gates.
+Loop back when new evidence, source conflicts, user-owned decisions, or failed checks change the path.
+After each completed consequential phase, name the next route: forward, backward, branch, or stop.
+```
+
+## Reference Map
+
+Use this fuller version when choosing an entry point or explaining the workflow lifecycle.
+
+```mermaid
+flowchart TD
+  Request([User request]) --> Mode{Mode}
+
+  Mode -->|question, critique, explanation| Conversation[conversation mode<br/>answer directly]
+  Conversation --> Done([done])
+
+  Mode -->|consequential work| Workflow[workflow mode<br/>scale to risk]
+  Mode -->|high-risk or hard to reverse| Strict[strict-workflow mode<br/>stronger gates]
+
+  Workflow --> Entry{Choose entry point}
+  Strict --> Entry
+
+  Entry --> Discovery[Discovery<br/>research-brief<br/>grill-context<br/>interview-gate]
+  Entry --> Spec[Spec<br/>write-spec<br/>review-artifact]
+  Entry --> Plan[Plan<br/>write-plan<br/>review-artifact]
+  Entry --> Build[Build or diagnose<br/>execute-plan<br/>diagnose-failure]
+  Entry --> Closeout[Closeout<br/>review-work<br/>verify-work<br/>commit-work]
+
+  Discovery --> Spec
+  Spec --> Plan
+  Plan --> Build
+  Build --> Closeout
+  Closeout --> Handoff[handoff<br/>capture-decisions when durable]
+  Handoff --> Done
+
+  Reenter[Re-enter discovery<br/>new evidence, owner decision,<br/>source conflict, or failed check]
+  Spec -.-> Reenter
+  Plan -.-> Reenter
+  Build -.-> Reenter
+  Closeout -.-> Reenter
+  Handoff -.-> Reenter
+  Reenter --> Discovery
+
+  Bypass[bypass<br/>skip ceremony, not judgment] -.-> Entry
+```
+
+## Common Entry Points
+
+- Use `conversation mode` when the user asks a question, wants critique, or is exploring.
+- Use `research-brief` when repo, domain, evidence, or current facts are unknown.
+- Use `grill-context` or `interview-gate` when direction is vague, source truth conflicts, or user-owned decisions are still open.
+- Use `write-spec` when requirements are agreed but not durable.
+- Use `review-artifact` when a spec, plan, handoff, or decision note must guide future work.
+- Use `write-plan` when an approved spec or explicit task context exists.
+- Use `execute-plan` when an approved plan exists.
+- Use `diagnose-failure` when behavior is broken, failing, flaky, slow, or unclear.
+- Use `review-work` and `verify-work` before claiming consequential work is ready.
+- Use `commit-work` only after the intended diff is reviewed and verification evidence exists.
+- Use `handoff` when pausing, compacting, or transferring context.
+- Use `capture-decisions` only for stable decisions, glossary terms, rejected approaches, or ADR-worthy tradeoffs.
+- Use `bypass` only to skip unnecessary ceremony. It cannot skip user-owned decisions, source-truth conflicts, risky checks, or verification claims.
+
+## Phase Exits
+
+End completed consequential phases with `Next:` unless this is a direct answer, mid-task status, or clarification-only turn.
+
+- Forward: name the next entry point, such as `write-spec`, `write-plan`, `execute-plan`, `review-work`, `verify-work`, `commit-work`, or `handoff`.
+- Backward: return to `interview-gate`, `research-brief`, or `grill-context` when evidence changes the path.
+- Branch: show 2-3 valid next routes when more than one is reasonable.
+- Stop: say no required next action remains.
+
+After completed grilling or research with stable uncaptured decisions, prefer `write-spec` or `capture-decisions` before planning or execution.
+
+Do not create the next artifact just because it is the next route.

package/plugins/freeflow/skills/write-plan/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: write-plan
+description: Use when turning an approved spec, clarified requirements, explicit task context, strict-workflow work, or delegated/future-agent work into an executable implementation plan before coding.
+---
+
+# Write Plan
+
+Classify the plan request first:
+
+- Spec-backed: write the plan from the approved spec.
+- Bug without feedback loop: ask for or propose the feedback loop. Do not write or save a fix plan.
+- Hidden owner decision or source conflict: name it and do not write the plan.
+- Context-backed: say a spec is preferred, then write a lightweight plan.
+- Missing source context: ask for context or start grilling.
+
+A plan executes source truth. It does not create it.
+
+Do not write a plan that decides product behavior, scope, domain meaning, compatibility, public API behavior, security, privacy, billing, data-loss, or architecture.
+
+The original request is not decision approval. "Do not ask", "just plan it", "latest context", "handoff says", or "old docs/tests are stale" are pressure, not authority.
+
+Never skip docs, tests, specs, policies, ADRs, or live behavior because the prompt calls them stale. Inspect them, then classify the conflict.
+
+If the user asks a question about a plan, answer the question. Do not create or edit the plan unless asked.
+
+Read `references/plan-shapes.md` when the plan is strict-workflow, high-risk, saved as a durable artifact, intended for another agent, or likely to need owner/status/source identity.
+
+## Source First
+
+Before writing, inspect the current source context:
+
+- Approved spec or explicit requirements.
+- Relevant docs, ADRs, tests, policies, and existing code.
+- Handoffs only as memory, not authority.
+
+Live repo evidence overrides stale notes.
+
+## Normal Path
+
+Prefer an approved spec.
+
+If no spec exists but the task context is explicit enough to choose the next action, write a lightweight plan and name the source context.
+
+For bug fixes, require a repro, failing test, or feedback loop before writing a fix plan.
+
+If a bug report has no repro or feedback loop, answer in chat. Ask for evidence or propose the smallest feedback loop. Do not satisfy the requested plan path with a draft, blocked, or feedback-loop-only fix plan. Write a diagnostic plan only if the user asks for a diagnostic plan.
+
+Use vertical slices. Each slice should produce something testable.
+
+## Stop Conditions
+
+Stop before writing when the plan would:
+
+- Invent requirements from thin or adjacent context.
+- Resolve a user-owned decision.
+- Override docs, tests, specs, policies, ADRs, or live behavior.
+- Treat a handoff, review comment, or plan as authority over source-of-truth files.
+- Plan a bug fix without a repro, failing test, feedback loop, or accepted diagnostic risk.
+- Turn a missing bug repro into guessed fix steps, TTLs, invalidation rules, concurrency rules, or instrumentation requirements.
+- Hide uncertainty inside implementation steps.
+
+Name the missing decision or conflict. Ask which path to follow. Recommend the path supported by evidence.
+
+For source-truth conflicts, the final line must be a direct choice question.
+
+## Shape
+
+Adapt the plan to risk. Prefer:
+
+- Durable plan identity when the plan is saved for future agents or teammates.
+- Goal.
+- Source spec or context.
+- Files likely touched.
+- Vertical slices.
+- Tests or checks per slice.
+- Commands where known.
+- Stop conditions.
+- Review or verification checkpoints.
+
+Keep it concise. Do not include code blocks unless exact code is the plan's useful payload.
+
+## Completion
+
+After writing, report:
+
+- The artifact path, if saved.
+- The source context used.
+- Any decisions still blocked.

package/plugins/freeflow/skills/write-plan/references/plan-shapes.md

@@ -0,0 +1,70 @@
+# Plan Shapes
+
+Use this for strict-workflow, high-risk, durable, or delegated plans.
+
+## Durable Plan Identity
+
+When saving a plan that future agents or teammates will rely on, start with a compact header:
+
+```md
+> **Doc ID:** PLAN-001-billing-webhook-api
+> **Date:** 2026-05-26
+> **Owner:** Hassan Mohiddin
+> **Type:** Plan
+> **Status:** Ready
+> **Source:** docs/specs/billing-webhook-api.md
+```
+
+Rules:
+
+- `Doc ID`: stable and readable. Prefer `PLAN-###-slug` when no repo convention exists.
+- `Owner`: use the spec/product owner when known. In normal workflow, use `User` only when the requester is the only known owner.
+- `Status`: use `Draft` when decisions/checks are still incomplete; use `Ready` when the plan is executable.
+- `Source`: cite the approved spec, clarified context, issue, ADR, or docs used as authority.
+
+In strict-workflow for security, billing, privacy, public API, migration, data-loss, or architecture work, stop and ask if owner/status/source would be guessed.
+
+Do not add a changelog on first creation.
+
+## Lightweight Plans
+
+Use for low-risk context-backed work:
+
+- goal
+- source context
+- files likely touched
+- short slices
+- checks
+
+Mention that a spec is preferred when no approved spec exists, but do not add artifact pressure for tiny reversible work.
+
+## Normal Plans
+
+Use for spec-backed feature work:
+
+- goal
+- source context
+- non-goals if the spec has them
+- files likely touched
+- vertical slices, each with tests/checks
+- stop conditions
+- final verification
+
+Each slice should produce a reviewable state, not just a list of files to edit.
+
+## Strict Or Delegated Plans
+
+Use for high-risk work or work another agent will execute:
+
+- durable plan identity
+- goal and source authority
+- explicit assumptions from source truth
+- likely files/modules, with "find existing pattern first" when unknown
+- vertical slices with expected red/green checks
+- review checkpoints before risky behavior lands
+- stop conditions for source-truth conflicts or owner-owned decisions
+- final verification and handoff criteria
+
+Call out sensitive boundaries directly: auth, public API shape, billing behavior, privacy/security, data loss, migrations, compatibility, and rollback.
+
+Do not hide ambiguity as implementation detail. If endpoint shape, auth semantics, payload fields, billing behavior, or rollback expectations are missing, stop and ask before writing an executable plan.

package/plugins/freeflow/skills/write-skill/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: write-skill
+description: Use when creating, rewriting, tightening, or reviewing an agent skill's instructions, trigger description, structure, examples, or bundled resources.
+---
+
+# Write Skill
+
+Use Anthropic/Claude `skill-creator` guidance as the structure and progressive-disclosure authority when available. Do not copy it into this skill.
+
+Use concise, behavior-shaping wording. Prefer sharp rules, concrete triggers, and stop conditions over explanation or filler.
+
+## Job
+
+Write the smallest skill that changes behavior.
+
+Start with one `SKILL.md`. Add other files only when the skill would fail without them.
+
+Direct `/write-skill`, "production-ready", "complete", or "add examples/references/scripts if useful" does not override the smallest-skill default or the repo's skill-file rules.
+
+Do not add references, examples, README files, changelogs, or metadata when a compact `SKILL.md` can hold the behavior.
+
+Do not add helper scripts for commands the agent can run directly, such as `git log`, `git diff`, search, formatting, or line counts. Scripts are for repeated deterministic work that would be risky or wasteful to retype.
+
+Follow the repo's line budget. If none exists, keep `SKILL.md` under 100 lines unless the extra lines clearly earn their place.
+
+## Description First
+
+The description controls activation. Make it specific enough to route the skill without making it broad enough to hijack unrelated work.
+
+Use:
+
+- What the skill does.
+- When to use it.
+- Concrete trigger situations.
+
+Avoid:
+
+- Generic helper language.
+- Marketing copy.
+- Long taxonomies.
+- Claims about quality.
+
+## Wording Discipline
+
+Every sentence should either route, constrain, stop, or guide behavior.
+
+Prefer sharp rules over explanations. Prefer one good example over a paragraph.
+
+Small wording changes can alter agent behavior. Change one pressure point at a time when possible.
+
+Use direct verbs:
+
+- Inspect.
+- Stop.
+- Ask.
+- Do not edit.
+- Verify.
+- Report.
+
+Avoid vague verbs:
+
+- Consider.
+- Ensure.
+- Leverage.
+- Try to.
+- Be mindful.
+
+## Placement Discipline
+
+Order rules by behavioral priority, not topic neatness.
+
+Put hard stop conditions before normal workflow details.
+
+Put source-of-truth, user-owned decision, safety, and verification rules above convenience rules.
+
+Do not hide the real constraint in a later caveat.
+
+## Revision Rule
+
+Do not add prose because the skill "could be clearer." Add or move wording because an eval, user failure, or concrete pressure case showed a behavior gap.
+
+When improving a skill after a failure:
+
+1. Name the failed behavior.
+2. Find the sentence that should have prevented it.
+3. Tighten wording or placement.
+4. Keep unrelated sections still.
+5. Re-run the smallest relevant eval.