FSWP QA 工程师 是做什么的？
验证已构建的文件夹，在门控过程中不要修复。先报告，然后在路由器的修复循环中修复。
1. 机械门控
bash scripts/setup_toolchain.sh # 每个环境运行一次（仅限 apt + GitHub，无 Composer）
bash scripts/run_gate.sh <dir> [min-php] [--fix]
run_gate.sh 检测主题（包含“Theme Name”头部的 style.css）并运行 scripts/theme_check.py；否则运行 scripts/qa_check.py。两者仅使用 Python 标准库，始终有效。然后，如果 PHP 和相应工具存在，会依次执行：php -l、PHPCS WordPress-Extra（错误视为失败，警告仅列出）、针对最低 PHP 版本的兼容性检查、以及包含 WordPress 存根的 PHPStan 级别 5。
--fix会首先运行phpcbf（WordPress 标准）。在脚手架搭建后或大量编辑后使用；请审查差异。- 插件检查 需要 WordPress 安装和命令行工具（
wp plugin check <slug>）；在其他环境中标记为 NOT RUN。告诉用户在提交 WordPress.org 插件之前运行它。对于主题，等效检查是 Theme Check 插件或目录的自动审查。 theme_check.py <dir> [--directory]：不加标志时，真实缺陷标记为 FAIL，目录专用规则标记为 WARN；加上--directory时，WordPress.org 主题目录的要求（缺少头部、截图尺寸和比例、禁止的文件、插件领域代码、必需的主题经典函数调用）标记为 FAIL。qa_check.py还检查插件头部和 readme 规则（来自手册：描述长度、唯一的 Plugin URI、最多 5 个标签、无Stable tag: trunk、数字格式的Tested up to、简短描述长度）并输出警告。qa_check.py对插件强制执行以下检查：ABSPATH 防护、版本匹配（头部、常量、readme 的 Stable tag）、无 example.com 或 CDN 或托管字体、每个路由上必须有permission_callback（注释的__return_true除外）、数据库升级检查、在回调内部进行入队、禁止的函数、卸载防护、仅 rem 单位、JS 翻译、源代码随编译输出一起提供、字体许可证。theme_check.py检查头部、许可证、入口模板、theme.json有效性、禁止的函数、未转义的 echo 启发式检查、远程资源、文本域、截图和 readme。
报告规则： 每个检查项输出 PASS、FAIL 或 NOT RUN，并附上使用的工具版本。NOT RUN 绝不能视为通过，也不能被概括为“干净”。如果缺少 PHP 或某个工具，需明确说明并指出应该运行哪个命令。
1a. 范围检查
将差异或文件列表与已批准的概要进行比较。计划中未要求的文件、钩子、选项或依赖项报告为范围蔓延（参见 fswp-developer/references/lean-coding.md）。统计新增行数与删除行数，若比例悬殊则给出注释。
2. 手动检查清单
references/checklist.md：仅包含脚本无法判断的项目。在机械门控全部通过后运行。
3. 场景测试
PRD（由 fswp-architect 提供）中的每个编号场景都获得 PASS、FAIL 或 NOT RUN 状态并附上证据。始终包含：
- 全新安装（无先前的选项或表）：无通知或无致命错误。
- 停用后重新激活：无重复的调度任务或选项。
- 从先前版本的存储数据升级，而不重新激活：在加载时迁移模式和选项。
- 卸载：仅移除插件拥有的数据。
- 迁移模式：导出差异，并对
baseline/进行视觉回归门控（由fswp-architect提供）。
根据工作类型，添加：
- 主题： PRD 列出的每种模板类型均使用真实内容和空内容渲染；编辑器与前端一致；仅键盘导航正常；主题切换到其他再切换回来不会导致致命错误。
- 更新： 变更概要中每一项都重新检查并标记；从先前版本存储数据升级正常；概要之外无任何变更（读取差异）。
- 附加组件： 主机处于活跃状态且在支持的范围内（正常工作）；主机停用（附加组件保持静默，显示通知，无致命错误）；主机低于支持的版本（干净地拒绝）。
- 核心补丁： 工单的复现步骤在修复前失败，修复后通过；相关的 PHPUnit 测试组通过；更改的行通过 PHPCS 检查；参见
fswp-core-contributor。
在可以运行 PHP 的地方，使用一个小型 PHP 脚本执行激活和迁移逻辑；否则通过阅读代码进行追踪，并标记为“已追踪，未运行”。
4. 发布检查
在上述所有步骤通过后：references/release-check.md。
输出
一张表格：检查项 | PASS/FAIL/NOT RUN | 详细信息。然后是失败列表（包含文件与行号），以及用户必须自己运行的内容。对于多会话构建，将表格复制到 HANDOFF.md 中。