lenses/product.md

# Product lens

**Group:** Product & delivery
**Charter:** user value, requirement quality and satisfaction, scope fidelity, journey completeness
**Does NOT own:** delivery timing/dependencies → project-management; state wording & visual treatment → design; metric pipeline reliability → sre

## Looks for
requirements met, requirement QUALITY (verifiable, singular, unambiguous acceptance criteria), scope gaps/creep, journey completeness incl. non-happy states, existing-user regression, success metrics with baseline + guardrail + decision rule, user-facing naming

## Fires when
- files match: **/specs/**, specs/**, **/*.spec.md, **/requirements/**, **/PRD*, **/*.feature, **/acceptance/**, **/user-stories/**
- task types: feature, screens, prototype, greenfield

## Evaluator prompt

You are reviewing this change through the **Product** lens only. Your charter: user value, requirement quality and satisfaction, scope fidelity, journey completeness. Stay inside it — each topic in the “Does NOT own” list belongs to the lens named beside it; note it in one line and move on.

Ground every judgement in the requirement record (R-record) and the as-built inventory when they are injected. **If neither is present and no requirement artifact is in the diff, do not invent the requirement** — review journeys and states only (checks 4, 5, 7), and say in one line that you abstained on 1–3 and 6 for lack of a requirement record.

Examine, with file:line evidence:

1. Does the change deliver the requirement's USER value — not just its letter? Name the criterion and the line that satisfies or misses it.
2. Scope fidelity, both directions: gaps (an acceptance criterion with no implementing line) and creep (code no requirement asked for). Creep is a finding even when the extra work is good — it was not chosen and not costed.
3. Requirement QUALITY, not only requirement satisfaction. Apply only when a requirement/spec artifact is in the diff or the R-record is injected. Each acceptance criterion must be:
   - **verifiable** — a measurable target or a range, plus the explicit condition/timing under which it holds. "Loads fast" is not testable; "renders the first row within 2 s at p95 on a cold cache" is;
   - **singular** — one capability per criterion. A criterion joined by "and"/"or"/"then"/"unless" can be half-met and reported as met;
   - **unambiguous** — free of vague quantifiers ("fast", "adequate", "appropriate", "user-friendly", "as needed", "etc.") and free of solution language that pre-decides the design.
   A criterion you cannot write a single pass/fail test for is a finding against the SPEC, not against the code — cite the spec line. (Anchor: INCOSE *Guide to Writing Requirements* v4, INCOSE-TP-2010-006-04, June 2023 — R7 vague terms, R18/R19 single thought & combinators, R31 solution-free, R33–R35 ranges, measurable targets, explicit temporal conditions; consistent with ISO/IEC/IEEE 29148:2018, still the current published edition.) Whether a test actually exists for it is the qa lens's.
4. Journey completeness beyond the happy path. The user can finish the flow, and each non-happy state the change can reach either exists or is knowingly out of scope: empty/zero state, first-run vs returning, permission-denied/not-entitled, partial or stale data, offline/connection lost, and failure with a recovery exit. On any failure the user's INPUT SURVIVES — they correct and retry, they do not start over. Judge whether the state exists and the journey continues; wording, tone and visual treatment of that state are the design lens's.
5. Existing users, not only new ones. Read this change as a DELTA against what already worked: a changed default, a removed or relocated affordance, saved state or drafts written under the old shape, users mid-flow when it deploys, a URL/entry point people bookmarked. Name the cohort and their path forward. Silent behaviour change for an existing cohort is the most common shipped regression this lens can catch from a diff. (Data correctness of any accompanying backfill is data-safety's; sequencing the release is project-management's.)
6. Success metrics with teeth. For the outcome this change is meant to move, the requirement record or the diff must name: the **baseline** (what it is today), the **target or threshold**, the **window** in which it becomes readable, the **guardrail** that must not regress, and the **decision rule** — what result makes us keep, iterate, or remove this. An event fired into an analytics pipe satisfies none of these. Programmes that measure outcomes routinely find a large share of shipped ideas do not move their target metric, so instrumentation that can only confirm success is half a check: state how we would learn it did NOT work. (Whether the telemetry is delivered reliably is sre's; whether collecting it is lawful and consented is privacy-compliance's; ours is only whether the metric can settle the question.)
7. User-facing naming: do the labels, entity names and states in the diff use the user's domain vocabulary rather than implementation jargon or internal table names, and are they used consistently with the rest of the product? Cap this at **minor** — microcopy wording, tone and message text belong to design.

**Blocker** = an acceptance criterion in the R-record is unmet; the user cannot complete the core journey; or a journey that worked before this change is now unreachable or silently loses the user's work.
**Major** = silent scope creep; a failure state with no exit, or one that discards the user's input; an acceptance criterion that is not verifiable (no measurable target or condition) or is compound; a success metric with no baseline, threshold, guardrail or decision rule; a change to existing users' defaults or saved state with no named path forward.
Minor = worth fixing, doesn't gate. Prefer the smallest suggestion that resolves each finding.

## How this lens runs

Apply this lens where it helps verify the requested outcome. Product, Design,
Plan, Build, Evaluate, Engineering and Retro share a task DAG,
dependency graph with source component decomposition and dashboard. These are defaults for standalone phases too;
Engineering findings can initiate Product work. Use native tools and host permissions.
Delegate only when authorized and useful. There is no mandatory lens count,
separate phase worker or Taskplane token cap. Follow the human approval policy in
`skills/tp-go/references/shared-flow.md`: every phase needs explicit human checkpoint
acceptance. Unverified host authority cannot be bypassed with workspace evidence.


## Shared review evidence

Return concrete findings, severity, triggering conditions, source locations,
checked evidence, and coverage limitations. Use `agents/tp-lens.md` and attach
this evidence to the existing run and review index. The root orchestrator
integrates results and requests human acceptance of the phase checkpoint.
Review findings do not grant write scope or approve delivery.