nocobase-notification-manage

目标

端到端指导 NocoBase 通知管理工作：检查通知插件和渠道，配置站内消息或邮件渠道，连接工作流通知节点，测试投递，并诊断发送日志。

范围

• 处理：通知管理器的使用，包括 notificationChannels 中的渠道和 notificationSendLogs 中的发送日志。
• 处理：站内消息渠道（notificationType: in-app-message）及其工作流消息字段。
• 处理：使用 SMTP 传输的邮件渠道（notificationType: email）。
• 处理：节点类型为 notification 的工作流通知节点指南。
• 处理：使用发送日志、工作流任务结果和渠道配置回读进行投递诊断。

非目标

• 不要直接安装、启用或禁用插件。插件状态变更请使用 nocobase-plugin-manage。
• 不要从头设计完整工作流。触发器和节点链的编写请使用 nocobase-workflow-manage。
• 不要创建新的通知渠道类型。自定义提供程序请参考插件开发指南。
• 未明确确认收件人前，不要发送真实的外部邮件测试。
• 不要泄露或回显 SMTP 密码、应用密码或其他渠道密钥。

输入约定

输入	必填	默认值	验证	澄清问题
action	是	inspect	必须为 inspect/configure-channel/test-channel/configure-workflow/diagnose 之一	“要运行哪个操作：inspect、configure-channel、test-channel、configure-workflow，还是 diagnose？”
channel	configure/test 时：是	无	现有渠道名称，或 in-app-message/email 之一	“要使用哪个渠道名称或渠道类型？”
env	否	当前 CLI 环境	已配置的 nb 环境名称	“要使用哪个 NocoBase CLI 环境？”
workflow	configure-workflow/diagnose 时：有时需要	无	可唯一解析的工作流 ID、键或标题	“要检查哪个工作流或通知节点？”
recipients	test-channel 时：是	无	明确的用户 ID 或电子邮件地址	“哪些安全的测试收件人应该接收通知？”
mode	否	safe	必须为 safe/fast 之一	“使用带回读的安全模式，还是快速模式？”

规则：

• 如果缺少任何必填输入，停止变更并请求澄清。
• 如果用户说“由你决定”，使用文档中说明的默认值。
• 从 notificationChannels 中解析渠道名称；不要猜测生成的 s_ 名称。
• 在任何工作流节点或发送操作使用通知渠道之前，该渠道必须已存在于 notificationChannels 中。绝不要臆造或填入不存在的 channelName；应先创建渠道，再回读并使用真实的 name。
• 所有配置和测试工作都优先使用安全模式。

必须通过的澄清关卡

• 最多澄清轮数：2
• 每轮最多提问数：3
• 变更前提条件：
• 已确认 action。
• 已确认应用操作所需的 nb CLI 可访问且已通过身份验证。
• 对于渠道写入，已知渠道类型和必填提供程序字段。
• 对于测试，收件人明确且已获批准。
• 对于工作流编辑，已明确具体工作流或节点的归属。
• 如果未满足前提条件，停止并报告缺少的输入或能力。

工作流

1. 确认 nb CLI 可连接且插件状态正常；如果需要启用插件，请转交给 nocobase-plugin-manage。
2. 在更改任何内容之前，检查 notificationChannels 和已注册的渠道类型。
3. 选择正确的路径：

• inspect：列出渠道和近期的 notificationSendLogs。
• configure-channel：仅创建或更新所请求类型的渠道。
• test-channel：向明确指定的安全收件人发送消息，然后读取日志。
• configure-workflow：指导或委托类型为 notification 的工作流节点编辑。
• diagnose：关联检查渠道配置、发送日志、工作流任务和服务器日志。

4. 提供字段级指导前，先阅读相关参考文件。
5. 执行变更时，每次只进行一项写入，然后读取 notificationChannels 以确认结果。
6. 测试发送情况时，检查 notificationSendLogs.status、reason、message、triggerFrom 和 channelName。
7. 对于工作流通知节点，只使用从 notificationChannels.name 回读的值；如果没有合适的渠道，请先创建或配置渠道，否则停止操作并报告缺少渠道。
8. 报告最终状态、证据和任何剩余风险。

参考文件加载指南

使用本节避免笼统地引用参考文件。每项都应准确说明何时阅读。

参考文件	使用时机	备注
渠道配置	创建、更新或检查站内消息和邮件渠道时。	包含渠道类型、字段和密钥处理说明。
工作流通知	添加或检查工作流通知节点时。	包含节点类型和各渠道的消息字段。
诊断	调查通知发送失败或缺失时。	包含集合、状态字段和常见失败原因。

参考文件规则：

• 本地文件使用相对 Markdown 链接。
• 链接中使用 / 作为路径分隔符。
• 尽可能让参考文件与 SKILL.md 之间只隔一级。
• 如果参考文件超过 100 行，请在该文件中添加目录。

安全门槛

• 执行高风险操作前，必须获得二次确认。
• 高风险操作包括：
• 向外部收件人发送真实邮件
• 更改 SMTP 主机、账号、密码或发件人值
• 删除通知渠道或发送日志
• 更改已启用或曾执行过的工作流中的通知节点
• 启用或禁用与通知相关的插件

二次确认模板：

• “确认执行：对通知渠道 {{channel}} 执行 {{action}}。预期影响：{{impact}}。输入 confirm 继续。”

回滚指南：

• 如果回读结果与请求的渠道或工作流配置不符，则触发回滚。
• 回滚步骤：
• 恢复先前的 notificationChannels 记录值
• 通过 nocobase-workflow-manage 恢复先前的工作流版本或节点配置
• 通过回读确认结果，并在适当时进行安全测试发送

验证清单

• 目标渠道或工作流节点存在且已唯一确定。
• nb 身份验证状态有效。
• 必需的通知插件已启用，或已完成转交。
• 输入值符合验证规则。
• 每次写入后都立即回读验证。
• 渠道的 notificationType 与预期的服务提供方一致。
• 邮件渠道已配置 SMTP host、port、secure、account、password 和 from，且未打印密钥。
• 站内消息渠道具有显示标题，且可供工作流通知选择。
• 工作流通知节点使用类型 notification 和真实的 channelName。
• 工作流站内消息的 receivers 常量使用整数用户 ID，而非 "1" 这样的字符串值。
• 发送日志显示预期的 status、triggerFrom、channelName；失败时还应显示 reason。
• 分别报告错误和部分成功。
• 最终输出包含所用的 CLI 环境变量和应用上下文。

最小测试场景

1. 仅检查：列出通知渠道和最近的发送日志。
2. 配置站内消息渠道，并验证其显示在 notificationChannels 中。
3. 配置电子邮件 SMTP 渠道，在输出中隐藏机密信息，并验证回读结果。
4. 使用明确的收件人测试渠道，并验证 notificationSendLogs。
5. 实际测试时未提供收件人，则阻止发送。
6. 修改已执行工作流中的节点时，遵循 nocobase-workflow-manage 的修订规则进行处理。

输出约定

最终回复必须包含：

• 请求内容。
• 已执行的操作。
• 已验证的内容。
• 失败之处或尚不明确的内容。
• 应用的默认值／假设。
• 通知渠道名称／类型和所用的 CLI 环境变量。
• 如果遇到阻碍，用户接下来需要采取的确切操作。

参考资料

• 渠道配置：用于了解通知渠道配置字段和提供方规则。
• 工作流通知：用于了解工作流通知节点的行为和消息字段。
• 诊断：用于查看日志、失败原因和故障排查顺序。