Feature Risk Router

Feature Risk Router

Use this lightweight router before or during product delivery when the required rigor is unclear. It classifies risk and names the gates that must run; it does not replace product-rd-workflow, testing-strategy, product-ui-ux-design, stack-specific development skills, review skills, or release workflows.

Objective high-risk change-shapes force classification even when the change feels trivial — a low-risk intuition is not a substitute for running the tags. The "when rigor is unclear" entry is not a licence to skip the router because you judged a change low-risk: the tags below classify well once you are here; the failure mode is never arriving because you felt sure. So regardless of that intuition, if the change deletes / backfills / migrates data or is otherwise irreversible, touches authentication / authorization / roles / tenant isolation, handles secrets / credentials / tokens, moves money or billing / quota, alters an external-facing or service-client API contract, changes a trust boundary or an untrusted-input sink, drives a production rollout / flag, or changes a shared deterministic gate / validator / CI harness / merge-readiness or completion-status rule (which can look docs/scripts-only yet decide future merge and completion semantics), run the classification FIRST and only then conclude low-risk if the relevant tags (write-finality, data-migration, permission-access, security-review, api-contract, money-quota, release-ops, shared-gate, ai-action) actually clear. Self-de-escalating one of those change-shapes to "not needed" without running its tag is the miss this prevents.

• Tone and diff size are not classification inputs: a reporter's urgent tone or executive pressure must never escalate a change's tags, and a small diff must never de-escalate them — tags run on the change's objective shape (production impact, frequency, money/data finality, workaround availability, rollback difficulty, verification sufficiency). (The always-on routing layer and product-rd-workflow owner-dispatch are the backstops for the case where the router is never invoked at all — this clause governs the case where you are deciding whether it applies.)

Output Contract

Return a compact routing decision:

• risk tags: the relevant tags below.
• required gates: skills, checks, or evidence that must run before completion.
• skippable gates: checks that can be skipped and why.
• stop reasons: decisions or blockers that require user/product/architecture/security confirmation.
• verification evidence: concrete commands, screenshots, browser/app/device checks, review artifacts, or docs that should prove completion.

Risk Tags And Gates

• visible-ui: Any visible UI change, including layout, copy, state, interaction, navigation, user-facing error/empty/loading feedback, or operation entry. Require product-ui-ux-design, the relevant client skill, and rendered inspection evidence.
• client-plumbing: Client request headers, telemetry, storage, API adapters, generated clients, or non-rendered behavior. If no visible surface changes, record visible surface: no; require focused tests or contract checks for the changed boundary.
• api-contract: Backend route, request/response schema, status code, error envelope, auth/session, or service-client contract changes. Require architecture or development skill for the owning stack plus integration/contract verification.
• permission-access: Authentication, authorization, roles, admin/internal access, tenant/user isolation, or data visibility. Require architecture review, negative tests, and explicit stop if identity/product boundary is unclear.
• money-quota: Billing, points, quota, payment, entitlement, refund, metering, or financial finality. Require high-risk resilience gates, idempotency/replay checks, auditability, and product confirmation for user-facing semantics.
• write-finality: Mutations, async jobs, repeated submission, irreversible actions, imports, deletes, or bulk operations. Require duplicate-submit/idempotency checks, pending/final state coverage, retry semantics, and recovery evidence. Verify the authoritative postcondition, not the call's success/ok status (a 2xx/ok ≠ the effect landed), via a finite ladder — direct read → operation receipt / status / version / ETag / audit-event or effect id (each counts as authoritative only if it actually proves the declared postcondition, not merely "accepted") → bounded eventual-consistency retry (cap attempts/window) → if no authoritative read exists (fire-and-forget / write-only / encrypted), report accepted-not-applied / unverifiable, never done and never loop unbounded; testing-strategy owns the side-effect-finality test mechanics.
• ai-output: LLM, RAG, model routing, generated content, prompt/eval, high-impact answer, or automation decision. Require llm-inference-integration, eval/replay or scenario checks, degradation/refusal behavior, and traceability.
• ai-action: An LLM / agent that does not just produce an answer but takes side-effecting actions — calls tools that mutate state, send or trigger external effects, access privileged data, or make authorization-sensitive decisions; moves money; changes permissions; or drives irreversible effects from model output (industry framing: OWASP Top 10 for LLM Applications 2025 — LLM06 Excessive Agency and LLM01 Prompt Injection).
  • Read-only retrieval used only to form an answer stays ai-output unless it can expose privileged data or drive a downstream action.
  • Require llm-inference-integration for tool-execution validation, fail-closed authorization, human confirmation on destructive / external / financial / permission-changing / irreversible actions, and prompt-injection defense whenever untrusted content (user input, retrieved documents, web pages, tool results) can reach a model able to act or surface privileged data.
  • (This is the product/runtime agent surface; multi-agent-delegation is a different axis — it applies only when the delivery work itself is delegated to subagents, not to a shipped agent feature.) Also apply write-finality, money-quota, or permission-access when the action actually crosses that boundary — durable-state mutation, money/quota movement, or access change — but do not stack those tags for read-only, reversible, or sandboxed actions whose downstream effect stays in bounds.
  • Where a gate does apply, the action being model-decided does not lower the bar; it raises it, because the model must never infer permission from untrusted content.
• genai-compliance: A surface that publishes or distributes generated / synthetic content to end users (synthetic image / audio / video / voice / avatar, user-shareable AI media), or operates a generative-AI service in a covered jurisdiction.
  • This tag only flags that legal/compliance review may be needed — it does NOT determine the obligations or satisfy them, and it is distinct from ai-output (answer quality).
  • Ordinary ephemeral assistant answers are ai-output, not this.
  • Mark it launch-blocking only when legal/compliance ownership is unknown, a target jurisdiction has a covered regime, or the surface distributes synthetic media; route the obligation through product-rd-workflow's compliance/legal stop point and the legal/compliance owner (the Stop Rules below already require stopping for legal/compliance boundaries).
  • Obligations vary by jurisdiction — transparency, labeling, provenance, content filing, safety assessment, or others — and must NOT be inferred from this router.
  • Example: mainland China has AI-generated/synthetic-content labeling rules (explicit user-visible + implicit metadata label concepts, effective 2025-09-01 with a companion mandatory national standard); verify the current requirement for each jurisdiction and content type with legal/compliance.
• data-migration: Schema, storage ownership, migration, backfill, indexing, or irreversible data movement. Require architecture review, migration rehearsal or rollback plan, and live-data boundary confirmation.
• external-integration: Third-party API, webhook, browser/device, deployment platform, queue, object storage, or credential-dependent path. Require mocked fast tests plus explicit live/integration verification or recorded unavailable evidence.
• release-ops: CI, deploy, observability, rollback, feature flags, canary, or platform control-plane changes. Require release/readiness checks and post-change status evidence.
• shared-gate: A shared deterministic gate, verifier, conformance script, CI/harness check, status-source validator, agent-contract checker, or review/merge readiness rule that future agents or repositories rely on. This can look like docs/scripts-only work, but the changed artifact decides whether later work is allowed to merge or be called complete. Require the owning workflow skill (usually product-rd-workflow for product/spec normalization or skill-extraction-workflow for shared-skill gates), testing-strategy when the gate has executable or mutation-test behavior, and an explicit independent review/challenge decision before shared branch push or MR merge. Local passing gate output is required evidence, but it does not replace review of the gate's scope, false-positive/false-negative behavior, and completion semantics.
• security-review: An explicit security audit / threat-model / OWASP / pentest-review request (over an existing or proposed system/design), OR a change that introduces or materially alters a trust boundary, an untrusted-input surface, a sensitive sink, authentication/authorization semantics, secret/credential handling, or data visibility, or is itself a hardening / vulnerability-fix change. Require a security-review gate before completion; conduct, gate statuses, and safety boundary are in references/security-review-gate.md.
  • It co-applies with permission-access, external-integration, release-ops, and ai-action and never de-escalates another tag or a Stop Rule. An explicit security-audit / threat-model / pentest request always sets at least pending-dedicated-review and is never not-applicable. Only the change-triggered arm may be not-applicable, and only after recording security posture unchanged and ruling out every posture-change blocker (trust boundary, untrusted-input surface, sensitive sink, auth/authorization semantics, data visibility, secret handling, hardening, vulnerability-fix intent).
  • This router owns the gate's status and safety boundary, not a security-audit method. With no dedicated security-audit skill/owner available, the most you may run is a read-only first-pass triage (security-first-pass-only, never a passed gate; never "secure" / "audit passed" / a standalone "no findings" as completeness) — a real audit needs a dedicated security owner or professional firm. Normalize findings per the shared review-finding standard.
• verification-scope-unclear: The required test or runtime verification layers are unclear.
  • Must-route only when at least two signals are present: the change spans at least two runtime domains such as browser UI, server process, live infrastructure dependency, or external API; the user mentions complete tests, integration, E2E, live dependency, browser verification, Docker, or equivalent; implementation is underway or complete and the user asks whether a test layer is missing; or the plan/spec does not assign unit, integration, E2E, live dependency, or browser-rendered coverage.
  • Require testing-strategy to produce a lightweight test-layer matrix only: each layer applies yes/no, reason, and owner skill.
• docs-only: Documentation/status-only change. Require consistency scan; skip code tests unless the doc changes executable instructions, product status, or release readiness claims.

Stop Rules

Stop and ask before proceeding when a change affects product direction, monetization, legal/compliance boundaries, identity model, public launch scope, security/privacy assumptions, destructive data actions, or external permissions that cannot be exercised locally.

Do not stop for low-risk implied follow-through such as running focused tests, checking diffs, syncing status docs after a merged slice, or recording visible surface: no for pure plumbing changes.

De-Escalation

Keep the route as small as the risk allows:

• If a change is docs-only, do not require runtime tests.
• If a docs/scripts-only change is tagged shared-gate, do not de-escalate to ordinary docs-only; keep the review/challenge decision and executable verification required unless the owning workflow explicitly classifies the gate as non-blocking and local-only.
• If a client change has no visible surface, do not require a design checkpoint.
• If a backend change is internal and contract-preserving, prefer focused unit/integration tests over full E2E.
• If verification-scope-unclear has only one signal, treat it as a hint, not a must-route. Single-file pure refactors, copy-only changes, tiny style tweaks, and docs-only updates do not need test-layer routing unless another risk tag applies.
• If live infrastructure is unavailable after normal remediation, record the blocked gate with command evidence, residual risk, and next unblock action instead of pretending it passed.