qa（stardust:qa）是 Adobe stardust 技能集中的只读站点 QA 巡检技能，用于对已部署在 AEM Edge Delivery Services 上的 stardust 站点执行自动化质量检查。它的工作方式是：输入一个线上 URL，输出一份与证据绑定的发现报告。该技能从不编辑任何内容——不修改站点内容、不修改 DA 文档、不修改仓库代码；它唯一的写入是 stardust/qa/ 下的报告产物。如果用户希望修复发现的问题，那属于本技能之外的、单独的显式后续操作。
用途与定位 qa 是 rollout 交付验证的部署后对应环节：rollout 问的是“每个页面是否都已上线？”，qa 问的是“已上线的内容是否真的正确？”。它覆盖一次部署可能静默破坏的三个层面：
- 交付层（delivery）：管线实际提供的内容（.plain.html、完整 HTML、sheets、sitemap）。
- 渲染层（rendered）：浏览器在块装饰后实际显示的内容（以及它的行为：一个只显示海报图的自动播放视频属于渲染缺陷）。
- 回归层（regression）：相对上次已批准状态发生的变化（视觉基线）。 上层为绿并不代表下层正常：发布返回 200 不等于已交付，已交付的 HTML 不等于渲染正确。
主要能力
- 确定性巡检：运行 qa.mjs 脚本，生成 stardust/qa/inventory.json、report.json、report.html，截图保存在 stardust/qa/shots/ 下，首次运行还会在 stardust/qa/baselines/ 下建立视觉基线。退出码 0 表示无活动错误，1 表示存在活动错误，2 表示基础设施故障。
- 检查项：包括路由、内容、模板、元数据、链接等交付层检查，以及 AI 可读性检查和可编辑性检查。AI 可读性检查按页面复现 Adobe 的 AI Content Visibility Checker（已提供词数 ÷ 已渲染词数），并按块归因差距。可编辑性检查是部署后的 Experience Workspace 可编辑性门禁（EW1–EW10）：逐页在已提供文档上重建 da.live 画布的插桩，让线上页面进行装饰，统计哪些作者文本仍带有编辑器索引。editability/dead-text（错误）表示某个块重建了作者文本，作者无法在画布中点击它；editability/duplicated-index（警告）表示一个展示性克隆保留了索引。声明为 @ew-exempt（或列入 --ew-exempt）的块内的死文本记为 info，而非错误。
- 人工分诊：确定性巡检会把两类发现标记为 needs triage，需要读取 report.json 后仅对这两类做判断：content/verbatim-below-threshold（对照 evidence.missingNodes、线上页面和抓取快照，判断文案是真的丢失/损坏，还是可接受的转换）和 visual/visual-diff（并排查看 evidence.baseline 与 evidence.current 两张 PNG，判断是真实的布局/样式回归，还是良性动态变化，如轮播帧、字体加载、实时嵌入）。分诊结论以注释形式写入给用户的总结中，不修改 report.json 的评分，也不做任何修复。
- 允许清单：stardust/qa/allowlist.json（schema 见 schemas/qa-allowlist.schema.json）用于记录已知的非缺陷，避免它们淹没后续每次运行。条目按 check/id/path/messagePattern 匹配，且必须携带原因。被允许的发现仍保留在报告中（置灰），证据不会被删除。只有在用户确认某标记为非缺陷（或项目记录中已记录为非缺陷）时才添加条目；绝不允许为了让运行变绿而添加允许清单。
使用方式 前置设置：如果本次会话尚未完成，先运行主技能的设置（skills/stardust/SKILL.md § Setup）。qa 也可独立运行，只需要一个线上基础 URL。
- 解析基础 URL（*.aem.live 主机或生产域名）。如果用户未提供，可查看 stardust/rollout/rollout.json（site.liveHost）或询问用户。
- 解析清单来源——巡检覆盖哪些页面，合并自：stardust/template-map.json（同时提供用于一致性检查的模板分配；scripts/from-knowledge.mjs 从 spec 写入它，并为源站已有的 404 添加允许清单条目）、一个路径文件，以及线上 sitemap.xml（始终抓取；parity 不匹配会成为发现，因此错误的 sitemap 不会静默缩小覆盖范围）。
- 可选输入以解锁更深检查：--scrape stardust/scrape（对照提取快照做逐字保真度检查）、--expected-blocks <json>（显式的按模板块期望）、--parity <json>（要重放的动态 parity 文件，默认 stardust/dynamics/parity.json；缺失时 dynamics 检查报告 parity-missing）、--auth-header "token …" / --token-env SITE_TOKEN（受保护源站；密钥仅发送到基础源站，否则由 fleet 共识推导）、--blocks-dir <dir>（站点的 blocks/ 检出，使可编辑性检查能遵守 @ew-exempt JSDoc 标签；否则传 --ew-exempt a,b 用于索引驱动的块）。
- 浏览器检查需要项目可解析 playwright（node_modules/playwright）。如果缺失，仅运行交付层检查（--checks routing,content,templates,metadata,links），并告知用户跳过了哪些内容。
- 按 reference/run-status.md（主技能）在巡检开始/结束时向 stardust/status.jsonl 追加一行阶段转换记录。
阶段 1 — 确定性巡检
运行命令：
node <plugin>/skills/qa/scripts/qa.mjs
--base https://main--<site>--<org>.aem.live
--template-map stardust/template-map.json
--scrape stardust/scrape
常用变体：--checks <subset>、--max-pages <n>（冒烟运行）、--fail-on warn（严格门禁）。reference/checks.md 记录了每项检查、其发现 id 和严重性理由。
首次在某个站点运行时：预期会出现一批 visual/baseline-created 的 info 发现——那是在建立基线，不是缺陷。基线是截图，因此是本地文件（stardust/.gitignore 排除了 qa/baselines/ 和 qa/shots/）：同一台机器上的后续运行会与其做差异比较；全新克隆会在首次巡检时重新建立它们。qa/allowlist.json 是被跟踪的判断记录。
阶段 2 — 分诊模糊标记（LLM 判断，仍然只读） 读取 report.json，仅对 needs triage 的两类发现做判断，并在给用户的总结中为每个发现标注结论（缺陷 vs 非缺陷 + 原因）。不要编辑 report.json 的评分，也不要修复任何内容。
阶段 3 — 向用户报告 总结：按严重性统计总数，先列已确认的缺陷（含页面路径和一行证据），再列已分诊排除的标记及其理由，最后列值得注意的警告。指向 stardust/qa/report.html。建议修复方案，但不要应用。
只读契约
- 仅在 stardust/qa/ 下写入（外加 status.jsonl 账本行）。
- 从不调用 deploy/publish API，从不 PUT 到 DA，从不编辑块、样式或内容——即使是对巡检本身发现的“琐碎”修复。
- 如实报告失败：崩溃的检查会以 <check>/check-crashed（错误）出现在报告中，绝不静默丢弃。
调度 / CI 运行器是纯 node，不依赖插件运行时，因此同一命令可用于 GitHub Action 或 cron 做漂移监控；--fail-on 设置门禁。在没有 playwright 的 CI 中，将 --checks 固定为交付层子集。
适用场景与限制 适用于已部署 stardust 站点的部署后质量巡检、内容保真度验证、视觉回归监控、AI 可读性评估和 Experience Workspace 可编辑性门禁。限制：只读，不修复问题；浏览器检查依赖 playwright，缺失时只能运行交付层检查；视觉基线为本地文件，跨机器需重新建立；受保护源站需要认证头或 token 环境变量。