docs(sdlc): name the QA and design skills the lifecycle already runs

[matgren]

🎯 Goal

• SDLC.md names a skill for every lifecycle stage, including QA and design — so the document describes the collection that actually ships rather than a subset of it.

🔍 Problem

The ticket lifecycle table drives every stage with a named skill except one. The QA row's Driven by column reads QA reviewer (manual), and grepping the whole document for om-auto-qa-pr, om-prepare-test-env, om-integration-tests, or any om-ux-* name returns nothing.

Those skills are not aspirational. om-prepare-test-env, om-auto-qa-pr, and om-integration-tests ship in skills/, and docs/roles/qa.md is a five-row page built entirely around them. The same holds for design: om-ux-shape and om-ux-review-pr ship and have a role page, and neither appears in SDLC.md.

The gap matters because of what SDLC.md is for. It is the process document a human reads and an agent loads before acting, and om-setup-agent-pipeline generates it into every repository that installs the pipeline. A reader who has only this file concludes that QA is the one stage the collection offers no help with, and that design is not part of the process at all. Anyone deriving a role-to-skill map from it reproduces that conclusion faithfully — the document is the source, so the error propagates rather than being caught.

The QA gate itself was never wrong: qa-approved is human-owned, and that is deliberate. What went missing is the difference between a person decides and a person works unaided. The old phrasing, "manually exercises user-facing changes," collapsed the two.

What Changed

• SDLC.md and skills/om-setup-agent-pipeline/references/sdlc-template.md, edited in lockstep as the Amending this process section requires:
  • QA row — names om-prepare-test-env (boot the app once), om-auto-qa-pr (walk it in a browser; screenshots and a pass/fail report, no labels touched by default), and om-integration-tests (keep the flow as coverage). Done when now reads "qa-approved applied by a person", making the human ownership explicit rather than implied by the absence of a skill.
  • New Design row between Claim and Implement — om-ux-shape or a human designer, scoped to user-facing changes and explicitly skipped by tickets that touch no UI. Done when is the flow and its states being decided, not an artifact, so a ticket cannot be blocked on a deliverable nobody asked for.
  • Review loop row — adds the om-ux-review-pr design pass, stated as advisory: it informs the review, it does not hold the merge. That is the behavior the skill already had; the row now says so.
  • Roles — a Designer bullet, and a QA reviewer bullet rewritten to distinguish deciding from working unaided.
  • Amending this process — om-ux-setup named next to om-setup-agent-pipeline as one-time setup, because a design contract is repository configuration, not a per-ticket stage.
• UPGRADE_NOTES.md — an entry with the copy-by-hand migration, since a generated SDLC.md is never regenerated for an existing install.

Only skills present on main are referenced, so the lint name-reference gate holds. om-mockup-prototype (#106) and om-ux-style (#107) are deliberately left out until they land.

🧪 Tests

• bash scripts/lint.sh — Lint OK, including the name-reference gate and the discovery-contract check that renders the template and verifies its tables
• node scripts/test-browser-providers.mjs, test-tracker-providers.mjs, test-classify-runs.mjs, test-close-keywords.mjs, test-discovery-contracts.mjs — 5/5 PASS
• Trial merge against feat: pre-intake skills, Definition of Ready, and QA gate hardening #107 — SDLC.md and sdlc-template.md auto-merge cleanly; the only conflict is the adjacent-insert in UPGRADE_NOTES.md, where both branches add an entry at the top. Whichever merges second resolves it by keeping both entries.

💥 Breaking Changes

• None. No skill behavior, label, or gate changes. A repository that skips the migration keeps working exactly as before.

📋 Decisions touched

• None superseded. The QA gate is untouched: qa-approved remains human-owned, and this PR does not restate the self-QA exception — feat: pre-intake skills, Definition of Ready, and QA gate hardening #107 rewrites that section, and duplicating it here would conflict.