Overview
Fill the gap between "design convergence" and "code review":artifact-level acceptance. It answers neither "does the design look good" (the Critic of taste-driven-designer handles that) nor "is the code correct" (dual-round-review handles that), but rather "does it actually work in a real browser」。
taste-driven-designer D1-D3 → frontend-qa-gate → dual-round-review P4
(品味与方向) (产物断言) (代码正确性)
This skill is therouting layer: it only declares trigger conditions, invariants, and assertion domains; for check details and report contracts see references/。
When to use / when not to use
Use(if any is met):
- The frontend artifact (page/component/flow) needs acceptance before delivery, especially AI-generated or AI-assisted output;
- The user asks "is responsiveness complete / does it work on mobile / is the keyboard path traversable / is accessibility compliant";
- The user asks "are error states, empty states, loading states implemented" "do network disconnection, permission failure, and repeated submission have artifact representations";
- The user asks "are the target browsers covered" "has performance regressed" "what else needs to be verified before launch";
- After delivery at taste-driven-designer D3, or during the goal-loop P3.5 integration verification phase.
Do not use：
- Pure design direction and taste judgment (belongs to the Critic of taste-driven-designer and the human creative director);
- Code-level correctness review (belongs to dual-round-review);
- Security and supply chain (XSS / secrets / dependency poisoning) — belongs to the host CI and permission layer; this skill only marks "outside acceptance scope" in the report;
- Backend/data logic tasks.
Invariants
- Evidence over narrative: any assertion must have reproducible operation steps and artifact evidence (screenshots / logs / measured values / command output). Natural language summaries do not constitute evidence.
- Three-state honesty: each requirement must land in one of the three states "implemented / verified by running / not verified"; unverified items must not be written as passed.
- No scoring criteria: absolute scores, ratings, or pass rates must not be output as acceptance conclusions (taste V1.1 disproofs E1/E2/E3 have falsified scoring-style gates). Conclusions are only PASS / FAIL / BLOCKED.
- Release authority belongs to humans: this skill only outputs evidence, conclusions, and recommendations; it does not replace taste's Gate C human sign-off, nor dual-round-review's final adjudication.
- Artifact-level boundary: only judge based on the running artifact and behavior; code-level criteria are explicitly routed to dual-round-review, and this skill does not review code within its scope of responsibility.
- Capability gating: when the host lacks a certain type of verification capability, the corresponding assertion is recorded as "not verified" and included in the blocking list; it must not be downgraded to passed.
- Independently distributable: cross-skill relative path hard links must not be written (independent installation would break the links); references to other skills are only allowed as named references and pattern numbers.
- Backflow has routing: defects found in acceptance must be triaged according to references/regression-routing.md; silently patching structural defects in place is prohibited.
Assertion Domains (Five Assertion Domains)
| Domain | Question answered | Details |
|---|---|---|
| D-R Responsive Viewports | Whether content and interactions remain continuously usable across viewports, rather than the number of breakpoints | acceptance-matrix.md §2 |
| D-S Interaction States | Whether loading/empty/error/disabled/focus/retry/back-navigation recovery all have artifact manifestations | acceptance-matrix.md §1 |
| D-A Accessibility | Keyboard, focus order, accessible names, screen reader paths, reduced motion | acceptance-matrix.md §3 |
| D-B Browser Coverage | Whether minimum supported versions and critical flows are usable in the target browser matrix | acceptance-matrix.md §4 |
| D-P Performance Budget | Whether build size and critical interactions regress relative to the baseline | acceptance-matrix.md §5 |
Execution Discipline: When any of the five domains has unverified or failed assertions, the report conclusion shall be BLOCKED / FAIL; delivery completion must not be claimed while unverified items exist.
Quick Checklist
Q1 ┌ 确定验收范围：产物入口、目标设备/浏览器、基线（上一版或设计稿）
└ 采集探针环境：URL / 构建号 / commit / 测试数据
Q2 ┌ 按 acceptance-matrix 五域逐项执行断言（能力门控：缺能力即记未验证）
├ 每项断言记录：操作步骤 + 证据路径 + 三态标记
└ 状态矩阵与视口矩阵必须逐格填写（缺失态写「未实现」而非留空）
Q3 ┌ 校验报告结构：bash scripts/check-qa-report.sh <报告文件>
├ 失败缺陷按 regression-routing.md 分流并登记
└ 存在未验证项 → 结论 BLOCKED，交人类裁决
Q4 ┌ 人类签收（放行权在用户）
└ 需要代码级修复时 → 转 dual-round-review；结构类缺陷 → 回 taste D2
Capability Gating
| Host Capability | Available | Unavailable |
|---|---|---|
| Browser driver (screenshot/click/input) | Execute real assertions | Record this domain as "unverified + blocked"; hand off to a human or switch hosts |
| Keyboard emulation | Keyboard paths and focus order measured in practice | Record manual to-dos only; inference of pass is not allowed |
| Screen reader | Screen reader measured in practice for critical flows | Record as unverified; automated scan results must not substitute for screen reader acceptance |
| Performance measurement (size/timing) | Compare with baseline values | Record as unverified; subjective "looks smooth" must not be used as a substitute |
General Principle: If the capability exists, test it; if not, record as unverified;never pretend it has been verified。
Security and Compliance Boundaries
- Do not write any private credentials, tokens, or real user data into the report; use synthetic data for test data;
- Check screenshots and logs for sensitive information before storing them;
- When security issues such as credential leaks, XSS, or dependency poisoning are found: record the phenomenon + mark "outside the scope of this skill" + escalate to the host CI and permission process; do not fix within this skill.
Reference Navigation
- acceptance-matrix.md — Discipline for filling in the five-domain assertion matrix, state matrix, and viewport matrix
- browser-verification-protocol.md — Capability gating, evidence contract, receipt, and blocking semantics
- regression-routing.md — Defect classification feedback routing table and routing record format
- qa-report-template.md — "Frontend Acceptance Report" template (structure validated by script)
- check-qa-report.sh — Mechanical gate for report structure