用途：在涉及 Interactivity API、@wordpress/interactivity、data-wp-interactive、data-wp-on--、data-wp-bind--、data-wp-context、区块 viewScriptModule 或水合异常（指令不触发）时使用。需提供仓库根目录与 wp-project-triage 结果、受影响的区块/主题/插件面，以及 WordPress 版本与构建是否支持模块等约束。
主要能力与流程：先搜索 data-wp-interactive、@wordpress/interactivity、viewScriptModule，判断是区块、主题还是插件侧增强；新交互区块建议用 @wordpress/create-block-interactive-template。随后定位 store 定义，确认 state 结构、actions 与 data-wp-on--* 回调。服务端渲染为推荐做法：区块在 block.json 中加 supports.interactivity；主题/插件用 wp_interactivity_process_directives()；用 wp_interactivity_state() 初始化全局状态、wp_interactivity_data_wp_context() 设本地上下文，派生状态需在 PHP 复刻逻辑，如 hasItems 用闭包返回 count 判断。修改指令时保持最小范围并确保服务端标记与客户端水合一致。
WordPress 6.9 变化：data-wp-ignore 已弃用并将在后续移除；同一元素可用 --- 分隔符存放多个同类指令；新增 AsyncAction 与 TypeYield 类型。
验证与限制：改后应确认 triage 显示 usesInteractivityApi: true，做手动冒烟测试，条件允许时用 Playwright 覆盖交互路径。常见故障包括指令存在但不生效（脚本未加载、入口错误、缺 data-wp-interactive、命名空间不匹配）、水合闪烁、PHP 未定义派生状态、布局偏移、交互根范围过大导致性能下降，以及 6.9 中 getServerState()/getServerContext() 在页面切换时重置。构建约束不清时先确认使用 @wordpress/scripts 还是自定义打包器。更详细示例见服务端渲染、指令速查与调试参考文档。