Drupal Rules 是一套面向 Drupal 开发的整合规则，资料说明其应被用于每一次实现任务。以下是按用途整理的主要内容。
一、规则定位与强制干预 这是一套整合的 Drupal 开发规则，覆盖代码质量、安全、服务与测试验证。资料特别指出，当 hook 输出中出现 AUTOPILOT [type]: 消息时，必须停止当前操作并遵循该指令；这些不是建议，而是会话自动策略的强制执行，干预中包含在继续编辑前必须执行的具体工具调用。忽略 AUTOPILOT 干预等同于忽略测试失败。
二、服务与依赖注入 必须使用服务加依赖注入，绝不要在类中使用 \Drupal::* 静态调用。所有 CRUD 操作必须使用 Entity API，绝不使用原始 SQL 查询。新模块需要包含 .info.yml、.module、/src（PSR-4）和 .services.yml；配置默认值应放在 config/install/ 中，而不是 hook_install() 中；前端资源使用库系统，不要内联 JS/CSS。服务设计上，所有服务在 <module>.services.yml 中注册并使用接口类型提示，使用构造函数属性提升做依赖注入，声明类为 final（除非明确设计为可扩展），所有自定义 PHP 文件使用 declare(strict_types=1)，可见性最小化（private > protected > public）。服务变更后，需确认服务注入正确、数据库表和列名存在、Twig 过滤器在项目中确实存在。不要猜测服务名，应直接读取模块的 *.services.yml；可用 Drupal::hasService("module_name.service_name") 快速检查；注意模块前缀可能为单数（如 group_permission），即使文档或模块名暗示复数。服务名失败时应检查 YAML，而不是反复猜测。
三、安全 所有用户输入用 Xss::filter() 或渲染数组净化，所有表单提交用 Form API 验证，使用参数化查询或 Entity API，绝不把用户输入拼接到 SQL。输出依赖 Twig 自动转义；Twig 之外的原始 HTML 输出使用 Html::escape()；绝不输出未转义的用户输入。所有自定义路由和实体操作都要定义访问控制；状态变更操作通过 Form API 令牌做 CSRF 保护；文件上传需校验类型、大小和扩展名。路由可以叠加多个访问检查器，必须全部通过才授予访问；$entity->access('update') 返回 ALLOWED 并不代表路由授予访问，其他检查器（归档状态、自定义 gate）仍可能拒绝；调试 403 时读取路由的 requirements YAML 并逐个追踪每个 __access 检查器类。源代码中不得硬编码凭据或 API 密钥，使用环境变量或 Drupal 的 key 模块管理密钥，绝不提交 .env、settings.local.php 或凭据文件。
四、代码质量 跨文件修改函数、常量或变量后，用 grep 搜索代码库中残留引用，避免运行时错误。在硬编码值之前先搜索已有配置常量（例如用 * 8 表示小时、* 5 表示工作日），改用系统配置值。移除或禁用某物时，从所有位置移除（控制器、模板、Twig、JS、配置）并用 grep 确认无遗漏。实现偏好：用 guard 子句降低圈复杂度，尽早返回；优先使用 array_filter()、array_map()、array_reduce() 而非带嵌套 if/break/continue 的 foreach；用数据对象替代数组，尽快把数组转成对象；PHP 8.4+ 可用 property hooks 实现 get/set；例外是 Drupal 渲染/表单 API 可以使用数组。实体查询始终使用 accessCheck(TRUE)，绝不省略；渲染数组始终添加 #cache 元数据（tags、contexts、max-age）；面向用户的字符串始终用 ->t() 或 Twig 中的 |t 包裹为 TranslatableMarkup。JSON 使用 \GuzzleHttp\Utils::jsonDecode/jsonEncode（而非 PHP 的 json_*）；日志使用 LoggerInterface 方法（debug/info/warning/error），不要自定义调试标志；避免 "Service" 命名空间（Drupal\my_module\Service），使用逻辑分组。变量命名：局部变量和函数参数用 $snake_case，类属性/特性用 $lowerCamelCase。注释中完整句子以句号结尾；例外是 Behat 注解（@Then、@Given、@When）不加句号。
五、测试与验证 宣称完成前必须运行测试、读取输出、确认其证明你的说法，然后才宣称完成；没有测试输出时，不要声称"应该可以"、"看起来正确"或"我已实现 X"。首选验证方法按优先级：一是 curl 冒烟测试（最可靠），示例命令包括：
ddev exec curl -s -o /dev/null -w "%{http_code} %{size_download}" -b <COOKIE> "http://localhost/<PATH>" ddev exec curl -s -b <COOKIE> "http://localhost/<PATH>" > /tmp/page-output.html ddev drush uli --uid=1 --no-browser 2>/dev/null
二是 Drush Eval（次要），转义规则：单引号内用 Drupal:: 而非 \Drupal::，用 Exception 而非 \Exception，不要 use 语句，PHP 保持单行，示例：
ddev drush eval 'print json_encode(["exists" => Drupal::hasService("my.service")]);' 2>/dev/null
三是测试脚本（复杂场景），存放在 scripts/tests/，创建脚本时更新 scripts/tests/index.md。危险信号："应该可以了"、"看起来正确"、"这会修好它"，以及响应中没有测试输出却宣称完成。
DDEV Shell 规则：绝不通过 ddev exec 传复杂 shell 结构（管道、变量、嵌套引号），应写脚本文件再执行；drush uli 与 curl 必须在同一脚本、同一 shell 中，并带 --uri=http://localhost 使 cookie 域匹配；在 curl 输出中检查表单元素可见性时，搜索 Drupal HTML ID（edit-features、edit-moderation-state-0）而非通用机器名。脚本存放：始终放在 scripts/tests/ 目录并带索引，执行 chmod +x scripts/tests/*.sh，命名约定包括 verify-{feature}.sh（功能验证）、debug-{feature}-{aspect}.php（调查）、check-{aspect}.sh（快速检查）、list-{entities}.php（数据列表）、fix-{issue}.php（一次性修复）。
适用场景：编写或审查 Drupal 模块、服务、路由、表单、实体操作和前端资源，以及在提交前验证实现。限制：资料未说明价格、收费方式或具体支持的 Drupal 版本范围，暂未提供。