FSWP 维护者 是做什么的？
基础（始终应用）： fswp-developer/references/lean-coding.md（少写代码、优先复用）、fswp-developer/references/coding-standards.md（编码规范、文档、国际化、可访问性）以及 fswp-security-engineer（输入、输出、授权）。
已有代码即规范。执行由 fswp-architect 批准（且已运行 detect_wp_project.py）的变更简报。应遵循项目自身的约定，除非该约定不安全；内部模板（house templates）仅用于新项目，不用于重写他人的风格。
模式 A：更新现有插件或主题
- 先阅读。 阅读被修改文件及其调用者、测试文件。注意前缀、命名、错误处理风格以及设置和数据的存储方式。
- 重现。 对于缺陷，写下重现步骤和观察到的结果；在更改任何内容之前确认失败。对于功能，明确验收条件。
- 最小的可工作更改。 在共享代码中修复原因，而非单个调用点。不要重新格式化未触及的代码；杂乱的 diff 会掩盖真实更改并破坏 blame 信息。
- 保护公共接口。 钩子名称、函数和类名称、选项键、元数据键、REST 路由和结构、简码属性以及模板覆盖都是约定。如需更改，必须先弃用：保持旧接口工作，调用
_deprecated_function()/_deprecated_hook()（或_deprecated_argument()），记录替代项，并且不早于下一个大版本移除。 - 升级路径。 如果数据或模式更改：增加一个存储的版本选项，在加载时（而非仅激活时）运行迁移，使其幂等，并测试在不重新激活的情况下从上一版本的数据升级。
- 兼容性。 尊重声明的
Requires at least和Requires PHP；使用function_exists()/版本检查来保护较新的函数，或故意提高最低要求并明确说明。 - 安全审计 对触及的代码执行（
fswp-security-engineer）：缺陷修复不得引入新的未经授权、缺少 nonce、缺少净化或缺少转义的入口点。 - 版本和变更日志。 修复 = 补丁，功能 = 次要，破坏性 = 主要。同时更新插件/主题版本、常量、
readme.txt的 Stable tag 和变更日志。 - 交付 为用户工作的仓库提供补丁或 diff，或在他们部署文件时提供 zip。包含校验列表（parity checklist）的结果。
主题：优先使用子主题或 theme.json/样式变体更改，而非编辑会接收更新的父主题。直接编辑父主题以及第三方插件文件会在下一次更新时丢失。
模式 B：为未拥有的产品构建附加组件
附加组件是一个独立的插件（或小型主题层），用于扩展宿主。使用 fswp-plugin-developer（步骤 1-3 和 8）构建结构，然后应用以下规则：
- 通过宿主的公共 API 扩展。 使用文档化的动作、过滤器、注册机和 REST 路由。永远不要编辑宿主文件，避免调用标记为 private 或未记录的内部方法；如果必须调用，将其隔离在一个适配器类中并进行保护。
- 声明依赖关系。 当宿主位于 WordPress.org 时，在插件头部添加
Requires Plugins: host-slug（WordPress 6.5 及更高版本强制执行）。还应在运行时检测：检查类、函数或常量，或版本常量，而不是插件文件路径。 - 在正确时机加载。 在确认宿主存在后，于
plugins_loaded（或宿主的就绪钩子）上初始化；在宿主的注册钩子上注册，而不是更早。 - 安静且清晰地失败。 宿主缺失或过旧：不执行其他操作，仅显示一条管理通知解释需要什么，绝不要致命错误。
- 版本范围。 在 readme 和计划中说明支持的宿主版本。测试最低和支持的最新版本。
- 兼容性声明。 某些宿主要求您声明功能支持。例如：WooCommerce 期望扩展声明与高性能订单存储以及基于区块的购物车和结账的兼容性。阅读宿主的开发者文档以获取最新的声明调用。
- 数据所有权。 在您自己的前缀下存储数据；不要写入宿主的表或选项。卸载时仅删除您自己的数据。
- 许可和命名。 遵循宿主的品牌和商标规则进行命名；使用描述性的“for X”风格，而非暗示它是官方的。
验证
将带有变更简报的校验列表（parity list）和兼容性表（作为场景源）交给 fswp-qa-engineer。references/safe-change-checklist.md 是交付前的快速检查列表。