fix(explore-feature): harden Phase 1 and local-run gate from pilot findings

Piloted the skill on two real PRs (a multi-surface fix needing an unusual seed
shape, and a perf change with no UX delta). Five gaps found and closed:
- Phase 1: fix PRs must gate the repro condition, not the easy path that also
  passes against pre-fix code (vacuous gate).
- Phase 1: N equivalent surfaces -> gate the most representative, list the rest
  under Not covered.
- Phase 1: seed-feasibility check before authoring -> if the repro shape isn't
  seedable via bridge/SDK/fixtures, the deliverable is a bridge/fixture addition
  or QA hand-off, not a gate.
- Phase 3: probe backend health (:8080/is-alive/ver), not just the FE; a half-up
  stack was passing the gate.
- Skip-check: perf/internals changes with no behavior delta -> labelled generic
  regression or skip-with-note, not a fake PR-specific happy path.
- Template: add a required "Repro condition" field for fix PRs.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: AndreiCautisanu

.agents/skills/explore-feature/SKILL.md

@@ -64,18 +64,41 @@ Produce the **ScopeSpec**:
 - `happyPath` — the one end-to-end flow to gate. Multi-PR → the **combined assembled-feature
   flow, as one test** (earlier PRs don't each get a gate).
 
+Three things to resolve while shaping the happy path — each caught a false or unbuildable gate in piloting:
+
+- **Fix PRs — gate the repro, not the easy path.** For a `fix:`, the happy path must exercise the
+  exact condition the bug needed. If the state can be reached two ways and only one triggered the
+  bug (e.g. a trace shows the bug only when `source=sdk` via manual reference-linking, not via
+  `evaluate()`), seeding the easy way makes the test pass against the *pre-fix* code too — a
+  vacuous gate. Identify the repro condition from the PR's root-cause description and seed that shape.
+- **N equivalent surfaces — gate the most representative one.** If the change fixes the same
+  behavior in several places (e.g. experiment "Go to logs", a shared sidebar, and a Playground
+  cell link), don't try to cover them all — pick the single most representative entry point for
+  the gate and list the rest under the plan's "Not covered" for QA. Keeps it cheap.
+- **Seed-feasibility check (do this before authoring).** Can the suite actually seed the state the
+  happy path needs — via the bridge (`services/opik-sdk-driver`), the SDK clients, or an existing
+  fixture? Check now, not at Phase 4. If the repro shape isn't seedable (e.g. the bridge only
+  exposes `evaluate()` but the bug needs manual reference-linking), the deliverable for this PR is
+  a **bridge/fixture addition first** (or a hand-off to QA), *not* a gate test. Say so and stop —
+  don't march to authoring on a state you can't create.
+
 **Two gates here, before expensive authoring:**
 
-1. **Scope gate** — state the resolved happy path + target path + stamp back to the dev and get a
-   yes. Multi-PR especially: "One combined test `<lead>.spec.ts` covering X→Y→Z, stamped
-   `<version>`. OK?"
+1. **Scope gate** — state the resolved happy path + repro seed shape + target path + stamp back to
+   the dev and get a yes. Multi-PR especially: "One combined test `<lead>.spec.ts` covering X→Y→Z,
+   stamped `<version>`. OK?"
 2. **Skip check** — if the change is pure refactor / infra / docs with no user-facing behavior,
    say so, point at the skip label, and stop. This is the escape hatch for the "every user-facing
    PR" policy. Note two cases that *are* user-facing even though they look like config: a
    capability-map / constants change that adds a user-visible option (e.g. a new model in a
    dropdown → happy path: "open the page, the option is selectable"), and a backend-dominant
    change whose only visible effect is subtle (e.g. a trace that should *not* appear in a default
-   list) — find the user-observable effect and gate that, don't skip.
+   list) — find the user-observable effect and gate that, don't skip. The opposite case also
+   happens: a perf / internals change with **no behavior delta by design** (e.g. swapping a slow
+   probe for a fast one, same rendered result). There's no PR-specific happy path to gate — so
+   either gate a *generic* regression on the affected page and label it as such in the plan, or
+   skip-with-a-note if QA's regression suite already covers that page. Don't dress a generic
+   regression up as a PR-specific gate.
 
 ### Version stamp
 
@@ -107,7 +130,10 @@ git show origin/main:version.txt   # the stamp
 
 Before authoring can be verified, confirm the dev has a local stack **with their changes**:
 
-1. Probe for a running stack (`http://localhost:5173`, and `:5174` for FE-from-source).
+1. Probe for a running stack — the **frontend** (`http://localhost:5173`, and `:5174` for
+   FE-from-source) **and the backend** (`http://localhost:8080/is-alive/ver`). A FE answering with
+   the BE down is a half-up stack: every seeded test fails on the first API call for env reasons,
+   not the feature. Require the backend up, not just "something answers on 5173."
 2. **Gate the dev:** confirm the running stack actually contains their changes. A stale prebuilt
    `opik.sh` stack won't show new `data-testid`s — if the feature adds testids, the dev must be on
    FE-from-source `:5174` (`dev-runner --restart`).

.agents/skills/explore-feature/test-plan-template.md

@@ -20,8 +20,11 @@ drive spec generation. **Never committed to the repo.**
 ## Preconditions / seed
 - <state the test seeds via the SDK/bridge before the browser opens>
 
+## Repro condition (fix PRs only)
+- <the exact state that triggered the bug — the shape the seed MUST create. Omit for feat PRs.>
+
 ## Not covered (out of scope for the gate)
-- <edge cases, error paths, perf — flagged for QA's deeper pass>
+- <edge cases, error paths, perf, and any equivalent surfaces not gated — flagged for QA's deeper pass>
 
 ## Open questions for QA
 - <anything the skill was unsure about — the explicit feedback prompt>
@@ -33,6 +36,9 @@ drive spec generation. **Never committed to the repo.**
   not edge cases — those go under "Not covered" for QA.
 - **Observable results.** Each step names what the *user sees* (a row appears, a badge turns
   green), not an internal state change — this is what the spec will assert.
+- **For fix PRs, "Repro condition" is mandatory.** Name the exact state that triggered the bug,
+  and make the seed create that shape — not a similar one the pre-fix code already handled. A gate
+  that passes against the pre-fix behavior gates nothing.
 - **"Not covered" and "Open questions" are mandatory sections**, even if short. They are the
   dev↔QA boundary and the feedback surface that improves this skill. An empty "Open questions"
   means "I'm confident"; say that rather than deleting the section.