@soleur/opencode 0.0.0-stage → 1.0.0

package/skills/plan/references/plan-signoff-lifecycle.md

@@ -0,0 +1,12 @@
+# Sign-off lifecycle staging — who participates at which phase
+
+Moved verbatim from `plan/SKILL.md` section 2.6 (byte-ceiling extraction; see `skill-body-budget.json`).
+
+The set of mandatory leaders changes by lifecycle phase, and that is by design — different leaders weigh in at different decision points:
+
+- **Brainstorm phase (framing time):** CPO + CLO + CTO are spawned in parallel when `USER_BRAND_CRITICAL=true`. Rationale: the approach has not been chosen yet, so all three lenses (product blast-radius framing, legal/compliance, architectural blast-radius) need to land before the plan exists. See `plugins/soleur/skills/brainstorm/references/brainstorm-domain-config.md` `## User-Brand-Critical Tag Processing`.
+- **Plan phase (this gate):** CPO sign-off only. Rationale: the plan implements the approach already framed by all three brainstorm leaders; the plan-time sign-off is the single product-owner ack on the technical approach. CLO and CTO concerns from brainstorm should be reflected in the plan body (Risks section, Sharp Edges, Domain Review carry-forward) — they do not re-sign here.
+- **Review phase (PR time):** CPO is not re-invoked; instead the `soleur:engineering:review:user-impact-reviewer` agent enumerates failure modes against the diff. Rationale: review-time concerns are diff-shaped, not approach-shaped.
+- **Ship phase (preflight Check 6):** No human sign-off; mechanical gate that the section exists and the threshold is valid.
+
+This tiered model is intentional — re-asking CPO/CLO/CTO at every phase would dilute the framing into ceremony. The framing question is asked once (brainstorm), the answer is locked in (plan), the diff is checked against the answer (review), the gate verifies the answer was given (ship).

package/skills/plan/references/webapp-cwv-observability.md

@@ -0,0 +1,143 @@
+# Webapp Core Web Vitals Observability
+
+Trigger: the plan's Files-to-Edit touch a browser-rendered webapp
+(`apps/*/app/`, `pages/`, a client `Sentry.init`, a `next.config.*`), or
+the feature description mentions `FCP`, `LCP`, `CLS`, `INP`, `TTFB`,
+`Core Web Vitals`, `web vitals`, `field RUM`, `real-user monitoring`,
+`first paint`, `page speed` (case-insensitive).
+
+When triggered, the plan MUST wire **field** (real-user) Core Web Vitals
+into the `## Observability` section — a synthetic lab probe is not a
+substitute: it measures one machine on one network. The recipe below is
+the default; a plan that deviates must say why in Alternatives.
+
+## Why this exists
+
+Synthetic probes cannot see the field distribution. #9178 / #8985: the
+dashboard's only perf evidence was the lab `perf-probe` (one headless
+shell, `x-perf-probe`-armed) while `sentry.client.config.ts` set
+`tracesSampleRate: 0` — every real session's LCP/INP/CLS/FCP/TTFB was
+dark, so the warm-FCP regression was measured on a machine that is not
+the user population. The mechanism details below are verified against
+the installed SDK source (`@sentry/browser` 10.59.0,
+`build/npm/esm/dev/integrations/webVitals.js` + `types/integrations/
+webVitals.d.ts`), not docs — re-verify against the installed version
+before reusing them.
+
+## Recipe 1 — Sentry installed (`@sentry/nextjs` or `@sentry/browser`)
+
+Prefer this when the repo already vendors Sentry (our edge: ADR-031,
+org `jikigai-eu` on the DE ingest cluster).
+
+1. **Add `Sentry.browserTracingIntegration()` to `integrations`** in the
+   client config. It auto-registers `webVitalsIntegration`; vitals are
+   attached to the **pageload/navigation transaction** as measurements
+   (LCP, CLS, INP, FCP, TTFB) via the SDK's `afterStartPageLoadSpan` /
+   `spanEnd` hooks — which only fire because tracing creates a pageload
+   span.
+2. **Use `tracesSampler`, not `tracesSampleRate`** — the sampler lets a
+   perf probe fully sample its own runs while real sessions stay cheap:
+
+   ```ts
+   tracesSampler: () => {
+     // Storage getters can throw where cookies are disabled — the
+     // floor (0.1) must be the failure mode, never an exception.
+     try {
+       return sessionStorage.getItem("soleur.perf-probe") === "1"
+         ? 1.0
+         : 0.1;
+     } catch {
+       return 0.1;
+     }
+   },
+   ```
+
+   The probe marker MUST be client-side state (`sessionStorage` —
+   tab-scoped so it never outlives the probe session), armed via
+   `page.addInitScript` **before** navigation. A header marker does
+   not work: `tracesSampler` receives no request headers in the browser.
+3. **Extend the scrub boundary to the new event classes.** Transaction
+   and span payloads bypass `beforeSend`. Reuse the same scrub helpers
+   (`scrubJwtFromEvent` / `stripUserContextFromEvent` / `stripPiiFromRecord`
+   or their local equivalents) in `beforeSendTransaction` and
+   `beforeSendSpan` — both hooks exist on the installed SDK
+   (`options.d.ts`). `sendDefaultPii` stays unset. Add a test asserting a
+   captured transaction/vital payload carries no `user` id, email, or IP
+   after the scrub chain.
+   Tracing also makes `request.url`/`request.query_string`/transaction
+   names live — a substring scrub alone is insufficient: pageload URLs
+   carry bearer-token tails (`/invite/<token>`, `/shared/<token>`) that
+   are not JWT- or email-shaped. Port or share the server-side URL
+   sanitizer (`lib/sentry-url-sanitize.ts` here: strip query/hash, reduce
+   token-path prefixes, delete `query_string`, reduce transaction names)
+   and wire `beforeBreadcrumb` — navigation `from`/`to` data attaches to
+   every envelope. (This gap was the #9180 review P1.)
+
+### The standalone-`webVitalsIntegration` caveat
+
+`webVitalsIntegration()` on its own emits **standalone spans only for
+CLS, LCP, INP** — the `WebVitalName` union is `'cls' | 'inp' | 'lcp'`,
+and even those require `traceLifecycle: 'stream'` or the
+`_experiments.enableStandaloneClsSpans` /
+`enableStandaloneLcpSpans` flags. **FCP and TTFB have no standalone path
+at all** — they exist only as measurements on a pageload transaction.
+If the metric the plan exists to measure is FCP or TTFB, the pageload-
+transaction arm (`browserTracingIntegration`) is not optional. Revisit
+the streaming path only if sampled transactions prove quota-expensive —
+it is an `_experiments` surface.
+
+## Recipe 2 — non-Sentry stacks (beacon endpoint fallback)
+
+When no Sentry SDK is installed, wire the `web-vitals` npm package to a
+first-party beacon endpoint:
+
+- **Client:** `onFCP/onLCP/onINP/onCLS/onTTFB` → `navigator.sendBeacon`
+  to `/api/vitals` (beacon survives page unload; `fetch` does not).
+- **Payload contract — PII fail-closed:** metric name, value, rating,
+  navigation type, page path (template, not URL with params), device
+  class, connection effectiveType. **Never** send user id, email, IP
+  (the endpoint must not log client IPs), session id, or any free-text
+  field. Honor `navigator.doNotTrack === "1"` and GPC by not sending.
+- **Sampled:** client-side dice roll (e.g. 10%) before registering the
+  observers; the probe arm overrides to 100% the same way as Recipe 1.
+- **Storage:** the endpoint writes to the project's existing telemetry
+  store; standing up a new persistent store for vitals is a GDPR/Art. 30
+  surface and needs its own ADR — prefer emitting to the incumbent
+  telemetry vendor over a new datastore.
+
+## Sampling and quota
+
+- Real sessions at `0.1` (10%) is the default posture — enough volume for
+  p50/p75 vitals dashboards, bounded ingest spend. State the expected
+  transaction volume against the project's Sentry quota in the plan's
+  `## Observability` block; quota headroom is a plan-time check, not a
+  post-deploy surprise.
+- Probe-armed runs sample at `1.0` so the lab measurement is
+  unconditionally captured — the marker costs nothing at probe volume.
+- Lower the real-session rate before raising quota; the two levers are
+  `tracesSampler`'s fallthrough rate and a per-route sampler (sample
+  `/dashboard` pageloads at a higher rate than static pages if the plan
+  is about one route).
+
+## Verification
+
+- **Plan-time:** a unit test asserting (a) `browserTracingIntegration`
+  is in `integrations`, (b) the sampler returns `1.0` under the probe
+  marker and the low rate otherwise, (c) a transaction payload survives
+  the scrub chain with no PII keys.
+- **Post-deploy:** the Sentry Web Vitals dashboard (Performance →
+  Web Vitals) shows LCP/INP/CLS/FCP/TTFB for the route within 24 h; the
+  plan enrolls a follow-through script that reads Sentry for
+  vital-bearing pageload transactions rather than eyeballing the
+  dashboard (`hr-no-dashboard-eyeball-pull-data-yourself`).
+- **Alerting:** vitals regressions are dashboard-grade, not page-grade —
+  do not wire a paging alert on a single session's LCP; an aggregate
+  p75 regression alert belongs in the project's alert IaC if the plan
+  adds one.
+
+## References
+
+- Decision record: `knowledge-base/engineering/architecture/decisions/ADR-259-field-rum-cwv-via-sentry-webvitals.md`
+- Installed-SDK source of truth: `apps/web-platform/node_modules/@sentry/browser/build/npm/esm/dev/integrations/webVitals.js` (`setup()`)
+- Client config this recipe was extracted from: `apps/web-platform/sentry.client.config.ts`
+- Mount-path defect class it pairs with: `apps/web-platform/test/dashboard-mount-fetch-dedup.test.tsx` (census guard; ADR-067 amendment 2026-09-28)

package/skills/plan-review/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: plan-review
+description: "This skill should be used when having multiple specialized agents review a plan in parallel. It spawns DHH, Kieran, and code simplicity reviewers to provide diverse feedback on implementation plans."
+---
+
+<!-- soleur-cloud-mode:start -->
+**Cloud Mode (Devin):** before pipeline work run `bash "${CLAUDE_PLUGIN_ROOT}/scripts/cloud-detect.sh"`. If `CLAUDE_PLUGIN_ROOT` is unset (cloud exec shells do not export it), resolve the root by IDENTITY, never by script basename: for `d` in `"$HOME/.local/share/devin/cli/plugins/cache"` and `/opt/.devin/plugins`, skip unless `[ -d "$d" ]`, then `MANIFEST="$(find "$d" -path '*/.claude-plugin/plugin.json' -exec grep -l '"name"[[:space:]]*:[[:space:]]*"soleur"' {} + 2>/dev/null | head -1)"`, `ROOT="${MANIFEST%/.claude-plugin/plugin.json}"` — one resolution, two consumers: `$ROOT/scripts/cloud-detect.sh` and `$ROOT/scripts/precommit-guard.sh`. (Shape check, not authentication: a planted `{"name":"soleur"}` dir passes — ADR-179 A11.) `local` or `not-local:no-devin-env` proceeds normally; any other `not-local:<reason>` applies `<plugin-root>/devin/INSTRUCTIONS.md` §Cloud Mode: emit the `--banner`, fan out sequentially with `Reviewed-Coverage: sequential-fallback` disclosure (never claim an independent review ran), `message_user` ack before any secrets read or production mutation, and run `precommit-guard.sh` before any `git commit` — hooks do not fire in cloud.
+<!-- soleur-cloud-mode:end -->
+
+<!-- grok-harness-invoke:start -->
+**Grok Build (`plugins/soleur/lib/harness.ts` `invokeSkill()`):** Read this SKILL.md in this process and run it to completion. A one-segment `soleur:<name>` in this document names a SKILL — on Grok Build, Read `plugins/soleur/skills/<name>/SKILL.md` in this process; it is not a nested tool_use. A multi-segment id such as `soleur:<domain>:<name>` names an AGENT: spawn it, never Read it, and on Grok Build spawn_subagent takes the id with its colons replaced by hyphens (`agentIdToGrokSubagentType`). **Claude Code:** Skill tool for a skill (`soleur:<name>`), Task tool with `subagent_type` for an agent. Forbidden is executing a subset, not the Read.
+<!-- grok-harness-invoke:end -->
+
+> **Dynamic-workflow alternative (opt-in).** A [`Workflow`-tool](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code) port of this skill lives at [`workflows/plan-review.workflow.js`](./workflows/plan-review.workflow.js) — deterministic fan-out, journaled resume, schema-validated output. Run it with `Workflow({ scriptPath: "plugins/soleur/skills/plan-review/workflows/plan-review.workflow.js", args: ... })`. The prose skill below stays the default; the two coexist during calibration. **Known divergence:** the port's consolidation prompt still carries the older "is this over-architected? what should be cut?" panel framing. (The `code-simplicity` lens string was aligned in #9398 — it now names the per-mechanism requirement question against `## Scope Check`.) See [`knowledge-base/project/specs/archive/20261013-032858-feat-review-workflow-prototype/spec.md`](../../../../knowledge-base/project/specs/archive/20261013-032858-feat-review-workflow-prototype/spec.md).
+
+# Plan Review
+
+Have soleur:engineering:review:dhh-rails-reviewer soleur:engineering:review:kieran-rails-reviewer soleur:engineering:review:code-simplicity-reviewer review this plan in parallel.
+
+**Prompt `soleur:engineering:review:code-simplicity-reviewer` per mechanism, not per plan.** Its question is *"which requirement does this mechanism satisfy, and does a simpler mechanism already satisfy it?"* — never "is this plan good?". A reviewer asked to assess quality optimizes the design it was handed; asked to justify each mechanism against a requirement, it can recommend deleting one. Feed it the **Property List** and **Cut List** from the plan's `## Research Insights` section so "which requirement" has something to check against; if the plan carries neither, report that absence as the first finding rather than inferring a requirement. Also feed it the `## Scope Check` section — `### Ask Mapping` and `### Plan-Item Provenance` give it the verbatim ask list, so an `inferred` item or a mechanism answering no ask is a named finding rather than a re-derivation. (`soleur:engineering:review:code-simplicity-reviewer` renders `### Goal Verification` per its own `plan-review` carve-out — without that carve-out this instruction is silently no-opped.) **Why:** #7418 / ADR-176 — a six-agent plan-review panel returned eight P0s and every one of them made the proposed cursor *better*, with `soleur:engineering:review:code-simplicity-reviewer` in that panel; the same agent class, asked post-implementation whether the design was necessary at all, said delete it — at roughly ten times the cost to act on.
+
+When the plan declares `Brand-survival threshold: single-user incident` in its `## User-Brand Impact` section, also include soleur:engineering:review:architecture-strategist and soleur:product:spec-flow-analyzer in the parallel batch — the 3-agent baseline catches overengineering and convention drift; the 5-agent panel catches blast-radius and flow gaps.
+
+When consolidating a 5-agent panel's findings, treat the simplification panel (DHH + code-simplicity) and the correctness panel (Kieran + soleur:engineering:review:architecture-strategist + spec-flow) as orthogonal axes. **When BOTH panels fire on the same scope, prefer delete over fix** — a feature that simultaneously triggers "too complex, remove" and "has 4 specific bugs" is over-architected; cutting it dissolves the bugs. Many "paper-resolution" findings (FRs added without implementation) vanish when the cuts land. **Why:** 2026-05-11 #2720 plan v1→v2 — 953→829 lines, 4 P0 issues dissolved when the matrix-split cut landed; see `knowledge-base/project/learnings/2026-05-11-five-agent-plan-review-panel-and-architectural-false-trails.md`.
+
+## Named CEO/design/devex panel (relevance-gated)
+
+The eng panel above reviews for engineering quality (simplicity, convention, correctness, blast-radius, flow). A plan can be engineering-immaculate and still be a **product / market / design / developer-experience** mistake. Alongside (never replacing) the eng panel, include a **named panel** of the existing domain leaders — spawned only when the plan is *relevant* to their lens:
+
+| Panel axis | Agent(s) | Lens (reviews the finished plan for) |
+|---|---|---|
+| **CEO / business** | `soleur:product:cpo` + `soleur:marketing:cmo` | soleur:product:cpo: product strategy, positioning, scope-vs-roadmap fit. soleur:marketing:cmo: market/GTM implications, brand-voice, messaging risk. |
+| **design** | `soleur:product:design:ux-design-lead` | user-flow completeness, UX decay, design-taste risk in user-facing surfaces. |
+| **devex / eng-strategy** | `soleur:engineering:cto` | developer/operator experience, maintenance/DX cost, build-vs-buy, ongoing engineering strategy — **distinct** from `soleur:engineering:review:architecture-strategist`'s blast-radius/structural lens. Give `soleur:engineering:cto` a devex lens string, not a structural one, so the two do not duplicate. |
+
+**Relevance gate — INDEPENDENT of the plan's own `## Domain Review` verdict.** The named panel exists to catch what plan Phase 2.5 got wrong, so it MUST NOT trust that phase's verdict as its trigger (a UI plan mis-judged `Product: NONE` would inherit the exact miss). Compute activation from an **independent** read of the plan's actual content; use the `## Domain Review` + Product/UX Gate tier only as a *hint*, never as the sole gate:
+
+1. **Mechanical UI-surface scan (independent):** scan the plan's `## Files to Create` + `## Files to Edit` against the UI-surface glob superset (`components/**/*.tsx`, `app/**/page.tsx`, `app/**/layout.tsx`, plus the shared UI-term list). Any hit → force `soleur:product:design:ux-design-lead` + `soleur:product:cpo` active regardless of the Domain Review verdict.
+2. **Fresh relevance read (independent):** judge relevance from the plan *body* (Overview, Files, User-Brand Impact), not by parsing a "Domains relevant: none" line — product/scope language → `soleur:product:cpo`; market/GTM/brand/user-copy language → `soleur:marketing:cmo`; user-facing/flow/visual language → `soleur:product:design:ux-design-lead`; code/infra/tooling Files-to-Edit → `soleur:engineering:cto`.
+3. **Threshold bias:** when the plan declares `Brand-survival threshold: single-user incident`, bias toward activating (stakes are high — the eng panel already escalated).
+4. If **none** activate (trivial non-engineering docs plan), only the eng panel runs — today's behavior is preserved.
+
+**Every named-panel reviewer is prompted for structured advisory only — NO `AskUserQuestion`.** soleur:product:cpo/cmo default to orchestrator mode and will otherwise emit `AskUserQuestion`, which hangs a headless `one-shot` (a Task subagent cannot answer it, and the agent `.md` body does not reach anonymous Task spawns). The prohibition MUST live in the prompt text, mirroring the plan Phase 2.5 Product/UX gate's "Output a structured advisory — do not use AskUserQuestion."
+
+## Standing panel checks (every review, no relevance gate)
+
+> **Rule `cq-ac-must-not-depend-on-concurrent-sessions` — migrated out of `AGENTS.rules.md` on 2026-09-10 (PR #8034).**
+> Domain-scoped per `cq-agents-md-tier-gate`: the violation it prevents can only
+> occur in this phase, which already enforces it, so it no longer costs every
+> session's always-loaded budget. This is now its canonical home.
+>
+> An acceptance criterion whose truth depends on unrelated concurrent processes — a sibling worktree, another session, ambient machine state — is not a property of the code and MUST be re-expressed as a deterministic test [id: cq-ac-must-not-depend-on-concurrent-sessions] [skill-enforced: plan-review Standing panel checks]. Litmus: could a process the plan never mentions flip it with no line of the diff changing? Then it measures the machine. **Why:** 2026-08-11 — "fires no contention banner" cost a second ~45-min re-run that verified an environment, not code.
+
+Run these against the plan regardless of change class. They are cheap, textual, and each has
+exactly one right answer, so all findings here classify **Mechanical** and auto-apply.
+
+1. **Acceptance criteria must not depend on unrelated concurrent processes**
+   (`cq-ac-must-not-depend-on-concurrent-sessions`). Read every entry under `## Acceptance
+   Criteria` and ask: *could a process this plan never mentions — a sibling worktree, another
+   agent session, ambient machine state, whatever else happens to be running — flip this from
+   true to false without a single line of the diff changing?* If yes, the criterion measures the
+   machine rather than the change, and it must be rewritten as a deterministic test over a
+   synthetic fixture.
+
+   The tell is an AC that asserts the ABSENCE of an ambient signal: "the run fires no contention
+   banner", "no sibling process is detected", "`/tmp` has N MB free", "the suite completes in
+   under N minutes". Each is unfalsifiable when it passes (you learn only that nothing else ran)
+   and uninformative when it fails.
+
+   Rewrite by moving the property into a fixture the plan controls. "Fires no contention banner"
+   becomes "with a synthetic procfs containing zero sibling runs, `tc_preamble` emits no
+   `SIBLING_RUN_DETECTED`" — which is a claim about the code, runs in milliseconds, and cannot be
+   invalidated by a colleague starting a build.
+
+   **Why this is worth a standing check:** on 2026-08-11 an AC of exactly this shape ("the
+   sanctioned full-gate run fires neither banner") cost a second ~45-minute full-gate re-run
+   after a sibling worktree started a suite one second after the clearance check. The re-run
+   verified an environmental condition, not the code, and the substantive property was already
+   proven deterministically by a synthetic-procfs unit test. Catching it at plan review costs one
+   sentence; catching it at verification costs the whole run.
+
+## Classifier routing (taste findings are surfaced, never silently applied)
+
+Consolidation tags **each** consolidated decision with `decisionClass ∈ {mechanical, taste, user-challenge}` per **[decision-principles.md](../brainstorm-techniques/references/decision-principles.md)** (ADR-084), routing through that doc's **four never-Mechanical classes** (dropping operator-requested scope; a new sub-processor/paid dep; a new recurring cost; an irreversible data op) — not a fresh classification path. A technical ruling is not a taste item: it goes to the CTO, not the operator ([technical-ruling-delegation.md](${CLAUDE_PLUGIN_ROOT}/skills/brainstorm-techniques/references/technical-ruling-delegation.md)). The taxonomy applies to the rest:
+
+- **Eng-panel** correctness/simplification findings (bug, convention-drift, flow-gap, blast-radius) → **Mechanical** (one right answer / purely-technical), **auto-appliable**. Exception: a `simplify-cut` of **operator-requested scope** is never-Mechanical → Taste / User-Challenge.
+- **Named-panel findings default to Taste** (fail-safe): a CPO/CMO/UX/CTO finding touching **user-visible / money / scope** is Taste unless it is *clearly* Mechanical (a factual/typo/broken-link fix). Product/market/design findings are almost never Mechanical — bias them to **surface**, never silently auto-apply. This is the single safety point of the panel; on ambiguity it fails toward surfacing.
+- Any finding arguing the operator's **stated scope/direction** should change (drop/merge/split/add) → **User-Challenge** — never auto-decide.
+- **Security/feasibility regression** → the ADR-084 sanctioned exception: attached → urgent `AskUserQuestion`; headless → terminal halt before merge + an `action-required`+`security` issue.
+
+**Single-signal context.** `plan-review` is NOT one of ADR-084's two "both-signals" consult gates (`plan` Step 4.5, `ship` Phase 5.5); it classifies with a **single** signal (the consolidator's judgment). Per decision-principles.md, ambiguity biases to the more-surfaced class (unsure Taste-vs-User-Challenge → treat as User-Challenge). Do NOT add a per-review strong-model consult here (cost/latency creep — the both-signals adjudication stays owned by `plan` Step 4.5, which writes the *same* `decision-challenges.md` artifact). **The consumer applies the routing** (`plan` "Plan Review (Always Runs)"): Mechanical → auto-apply; Taste / User-Challenge → attached present at the "Apply these changes?" gate (5-line frame for User-Challenge), headless persist to `knowledge-base/project/specs/<branch>/decision-challenges.md` (append; `ship` Phase 6 renders it + files the `action-required` issue). `plan-review` only classifies + appends — it never authors the PR body.

package/skills/plan-review/lib/named-panel.mjs

@@ -0,0 +1,58 @@
+// ---------------------------------------------------------------------------
+// Named CEO/design/devex panel composition (ADR-084 / #5985).
+//
+// PURE decision function: maps the detect step's INDEPENDENT relevance signals
+// to the set of named-panel lenses to spawn. Kept in an importable module so it
+// is testable WITHOUT spawning live agents (AC11/AC12) — the Workflow runtime
+// cannot import (no filesystem/import access), so `plan-review.workflow.js`
+// carries a LOGIC-IDENTICAL duplicate of `computeNamedPanel` per the
+// self-contained-workflow convention. The drift guard in
+// `plugins/soleur/test/plan-review-named-panel.test.ts` normalizes away
+// comments/export/whitespace and asserts the two function bodies match, so a
+// logic edit to either copy fails CI. (Step 3 of the plan's relevance gate —
+// threshold bias — is applied upstream at the detect prompt, not here, so this
+// stays a pure signals→lenses mapping.)
+//
+// CPO Condition 1 (correlated-failure fix): activation is driven by an
+// INDEPENDENT content scan, never by trusting the plan's own `## Domain Review`
+// verdict — a UI plan mis-judged `Product: NONE` still activates ux+cpo via the
+// mechanical UI-surface hit.
+// ---------------------------------------------------------------------------
+
+// The four named lenses, in stable output order.
+export const NAMED_LENSES = ['cpo', 'cmo', 'cto', 'ux-design-lead']
+
+/**
+ * Compute the named panel from INDEPENDENT relevance signals.
+ *
+ * @param {object} signals
+ * @param {boolean} signals.uiSurfaceHit  - mechanical: `## Files to Create/Edit`
+ *   contains a UI-surface glob (components/**\/*.tsx, app/**\/page.tsx,
+ *   app/**\/layout.tsx, or a shared UI-term path). Overrides the Domain Review
+ *   verdict — this is the correlated-failure fix.
+ * @param {boolean} signals.productSignal - fresh read: product/scope language.
+ * @param {boolean} signals.marketingSignal - fresh read: market/GTM/brand/user-copy language.
+ * @param {boolean} signals.uxSignal - fresh read: user-facing/flow/visual language.
+ * @param {boolean} signals.devexSignal - fresh read: code/infra/tooling Files-to-Edit.
+ * @returns {string[]} activated lens keys, subset of NAMED_LENSES, stable order.
+ */
+export function computeNamedPanel(signals) {
+  const s = signals || {}
+  const active = new Set()
+
+  // Step 1 — mechanical UI-surface scan (independent). A UI-surface hit forces
+  // ux-design-lead + cpo regardless of the Domain Review verdict.
+  if (s.uiSurfaceHit) {
+    active.add('ux-design-lead')
+    active.add('cpo')
+  }
+
+  // Step 2 — fresh independent relevance read (NOT the verdict line).
+  if (s.productSignal) active.add('cpo')
+  if (s.marketingSignal) active.add('cmo')
+  if (s.uxSignal) active.add('ux-design-lead')
+  if (s.devexSignal) active.add('cto')
+
+  // Step 4 — if none activate, the named panel is empty (eng panel still runs).
+  return NAMED_LENSES.filter((k) => active.has(k))
+}