你现在是资深全栈工程师，请在现有仓库中直接开发一个“监测提醒”子模块。请先通读项目代码、Prisma schema、现有任务管理相关页面/API/权限方式/目录结构，然后在尽量不破坏现有系统的前提下完成开发。 【项目背景】 这是一个已经存在的任务管理系统，要新增一个“监测提醒”子模块，用于专项工作的周期监测、到期催办、完成确认、短信提醒、日志审计,该项目最终是使用docker部署在内网(无互联网ubuntu22系统中) 典型场景： - 例如“预防未成年人违法犯罪工作” - 某专项工作下会有多个具体事项 - 某事项可能要求每周、每月、每季度、或一次性完成 - 用户需要在系统中手动点击“完成” - 若未完成，则在到期前 X 天开始提醒 - 提醒方式包括： 1）系统内提醒 2）短信提醒（通过向 Oracle 11g 的短信表插入数据实现） - 需要保留提醒日志和操作审计 - 需要支持历史追踪、防重复提醒、失败补偿 【开发目标】 请你直接完成以下内容： 1. 设计并落地数据库结构（Prisma schema + migration） 2. 实现后端接口（Next.js Route Handlers / Server Actions / 项目当前使用的后端模式） 3. 实现前端页面 4. 实现周期实例生成逻辑 5. 实现提醒规则计算逻辑 6. 实现短信发送对接预留接口或实际逻辑 7. 实现操作审计与提醒日志 8. 确保代码风格、目录结构、UI 风格、权限风格与现有仓库一致 9. 输出完整改动，不要只给设计稿 -------------------------------------------------- 一、请先做的事情 -------------------------------------------------- 1. 先扫描仓库并识别： - 当前技术栈 - 目录结构 - 是否使用 App Router - Prisma schema 位置 - 数据库类型 - 现有用户表/部门表/任务表 - 现有权限控制方式 - 现有 API 风格 - 现有 UI 组件封装方式 - 现有表单、表格、弹窗、分页、状态枚举写法 2. 在现有风格下开发，不要凭空另起一套体系 3. 尽量复用： - 用户表 - 部门表 - 登录鉴权 - 页面布局 - 通用表格/弹窗/表单组件 4. 如果仓库中已经存在 task、task_item、task_log、user、department 等模型，请结合已有模型命名习惯适配；不要生硬造轮子 -------------------------------------------------- 二、业务设计要求 -------------------------------------------------- 这个子模块的核心概念分 5 层： 第 1 层：专项工作（plan） 表示一个大的专项任务。 例如： - 预防未成年人违法犯罪工作 - 某专项整治行动 - 某阶段报送任务 第 2 层：事项定义（item） 一个专项工作下有多个具体事项。 例如： - 每月向政法委报送汇报 - 每周上报 XX 数据 - 每季度提交专项分析 - 一次性提交总结材料 第 3 层：责任人/提醒对象 一个事项可以有： - 责任人 OWNER - 提醒接收人 REMIND - 抄送人 CC 需要支持一对多、多对多关系。 第 4 层：提醒规则（rule） 提醒规则必须可配置，不能写死： - 到期前 X 天开始提醒 - 到期当天提醒 - 逾期后继续提醒 - 每天提醒一次 - 工作日每天提醒 - 每 N 小时提醒 - 完成后停止提醒 第 5 层：事项实例（instance） 事项定义是模板，真正执行的是每一期实例。 例如： - “每月报送”在 2026-03 会生成一个实例 - “每周报送”在 2026-W10 会生成一个实例 - 用户点击完成的是实例，不是模板 -------------------------------------------------- 三、数据库设计要求 -------------------------------------------------- 请直接在现有 Prisma schema 中新增以下模型，并生成 migration。 1）monitor_plan 用途：专项工作主表 建议字段： - id - planCode：专项编码，唯一 - planName：专项名称 - planType：专项类型，可空 - sourceTaskId：可选，若要关联现有任务主表 - ownerDeptId - ownerDeptName - startDate - endDate - status：DRAFT / ENABLED / PAUSED / FINISHED - remark - createdBy - createdAt - updatedBy - updatedAt - deletedFlag 要求： - planCode 唯一 - 可按状态、结束日期查询 2）monitor_item 用途：事项定义表 建议字段： - id - planId - itemCode - itemName - itemCategory - cycleType：ONCE / WEEKLY / MONTHLY / QUARTERLY / CUSTOM - cycleConf：JSON，存不同周期配置 - dueTime：例如 17:00:00 - completeMode：默认 MANUAL_CLICK - needAttachment：是否要求附件 - needRemark：是否要求备注 - sortNo - isEnabled - remark - createdBy - createdAt - updatedBy - updatedAt 要求： - (planId, itemCode) 唯一 - 支持 JSON 周期配置 - 周期配置示例： - WEEKLY: {"weekday":5} - MONTHLY: {"dayOfMonth":25} - QUARTERLY: {"quarterMonth":3,"dayOfMonth":25} - ONCE: {"fixedDueDate":"2026-12-20"} 3）monitor_item_user 用途：事项责任人/提醒人表 建议字段： - id - itemId - userId - userName - deptId - deptName - mobile - roleType：OWNER / REMIND / CC - isPrimary - isEnabled - createdAt 要求： - 支持 item 对应多个用户 - 建立合理唯一约束，避免重复添加 4）monitor_rule 用途：提醒规则表 建议字段： - id - itemId - ruleName - triggerType：BEFORE_DUE / ON_DUE / AFTER_DUE - offsetDays - offsetHours - repeatType：ONCE / DAILY / WORKDAY_DAILY / EVERY_N_HOURS - repeatInterval - remindTime - maxTimes - channelSms - channelSystem - stopWhenDone - contentTpl - isEnabled - createdAt 要求： - 一个事项可以有多条规则 - 例如： - 提前 7 天，每天 09:00 提醒 - 到期当天 09:00 提醒 - 逾期后每天 09:00 提醒 5）monitor_instance 用途：事项实例表，最关键的执行表 建议字段： - id - planId - itemId - instanceCode - periodKey：例如 2026-W10 / 2026-03 / 2026-Q1 / ONCE - periodLabel - periodStart - periodEnd - dueAt - status：PENDING / COMPLETED / OVERDUE / CANCELLED - completedBy - completedByName - completedAt - completeRemark - attachmentJson - remindCount - firstRemindAt - lastRemindAt - createdAt - updatedAt 要求： - (itemId, periodKey) 唯一，防重复生成 - 用户点完成时更新实例状态 - 所有提醒都基于实例 - 附件可先用 JSON 存引用信息，适配项目现有附件模式 6）monitor_notify_log 用途：提醒发送日志表 建议字段： - id - instanceId - ruleId - receiverUserId - receiverName - receiverMobile - channel：SMS / SYSTEM - title - content - bizDedupeKey：业务幂等键，唯一 - sendStatus：READY / SUCCESS / FAILED / SKIPPED - sendTime - failReason - oracleEid - oraclePushTime - createdAt 要求： - bizDedupeKey 必须唯一 - 用于防止重复短信 - 发送成功/失败均要记录 7）monitor_operate_log 用途：操作审计表 建议字段： - id - planId - itemId - instanceId - actionType：CREATE_PLAN / UPDATE_PLAN / CREATE_ITEM / UPDATE_ITEM / GENERATE_INSTANCE / COMPLETE / REOPEN / SEND_REMIND / RULE_CHANGE 等 - operatorId - operatorName - operatorDeptId - operatorIp - detailJson - createdAt 要求： - 所有关键业务动作都写审计日志 -------------------------------------------------- 四、实例生成逻辑 -------------------------------------------------- 请实现“周期实例生成器”，可做成： - 独立 service - 或 cron handler - 或 command script - 以项目现有习惯为准 规则如下： 1. ONCE - 只生成一条实例 - periodKey = ONCE 或固定日期 - 到期时间来自 fixedDueDate + dueTime 2. WEEKLY - 根据 weekday 生成每周实例 - 例如 weekday=5 表示每周五截止 - periodKey 格式建议：2026-W10 3. MONTHLY - 根据 dayOfMonth 生成每月实例 - periodKey 格式建议：2026-03 4. QUARTERLY - 根据季度规则生成 - periodKey 格式建议：2026-Q1 5. 防重复 - 生成前检查 (itemId, periodKey) 唯一约束 - 已存在则跳过 6. 建议支持： - 每天凌晨跑一次，生成未来一段时间的实例 - 可配置生成窗口，例如未来 30 天 / 60 天 -------------------------------------------------- 五、提醒逻辑 -------------------------------------------------- 请实现提醒扫描逻辑： 1. 扫描条件 - 实例状态为 PENDING 或 OVERDUE - 未完成 - 命中提醒规则 - 未超过 maxTimes - 同一规则同一时间点不要重复提醒 2. 规则解释 - BEFORE_DUE 在 dueAt 前 offsetDays / offsetHours 开始生效 - ON_DUE 到期当天提醒 - AFTER_DUE 逾期后提醒 3. repeatType - ONCE：仅提醒一次 - DAILY：每天一次 - WORKDAY_DAILY：仅工作日每天一次 - EVERY_N_HOURS：每 N 小时提醒一次 4. 完成后停止提醒 - 如果实例已 COMPLETED，则 stopWhenDone=true 的规则不再触发 5. 提醒写日志 - 每次触发先写 monitor_notify_log - 再执行渠道发送 - 再回写 sendStatus -------------------------------------------------- 六、Oracle 短信发送设计(内网docker部署) -------------------------------------------------- 系统中的短信发送不是第三方 HTTP API，而是通过向 Oracle 11g 某短信表插入数据触发。 请这样实现： 1. 在当前模块中抽象一个短信发送 service，例如： - sendSmsByOracleQueue(...) - 内部负责向 Oracle 插入数据 2. 请不要把 Oracle 连接写死在业务代码里： - 使用环境变量 - 单独配置文件 - 单独 service 封装 3. 幂等要求 - oracleEid 建议格式： MI-{instanceId}-R-{ruleId}-U-{mobile} - bizDedupeKey 也要对应唯一 - 避免重复发同一条短信 4. 失败处理 - Oracle 插入失败时记录 failReason - sendStatus = FAILED - 后续扫描时支持补偿重试，但不能无限重复 5. 短信内容模板 - contentTpl 可支持变量替换，例如： {planName} {itemName} {periodLabel} {dueAt} - 若项目里已有模板渲染方式，则复用 注意： 如果当前仓库没有 Oracle 客户端依赖，请补充一个合理的封装，并保证： - 不影响现有项目启动 - 本地开发环境没有 Oracle 时也能正常跳过或 mock - 生产环境可切换为真实发送 -------------------------------------------------- 七、前端页面要求 -------------------------------------------------- 请基于现有 UI 风格新增子模块页面，挂到当前系统菜单结构中，命名尽量贴合现有风格。 至少实现以下页面： 1. 专项工作列表页 功能： - 查询专项工作 - 按状态筛选 - 新建 / 编辑 / 启用 / 暂停 / 结束 - 进入详情页 2. 专项工作详情页 展示： - 基本信息 - 下属事项列表 - 提醒规则配置入口 - 周期实例入口 3. 事项配置页/弹窗 功能： - 新增事项 - 编辑事项 - 配置周期 - 配置截止时间 - 配置是否必须附件、必须备注 - 配置责任人和提醒对象 4. 提醒规则配置页/弹窗 功能： - 配置提前几天提醒 - 配置重复提醒方式 - 配置短信/系统内提醒开关 - 配置提醒模板 5. 实例列表页 功能： - 按专项/事项/状态/周期查询 - 展示是否完成、完成时间、提醒次数、最后提醒时间 - 支持手动点击完成 - 支持填写备注、上传附件 - 支持查看提醒记录 6. 提醒日志页 功能： - 查看发送状态 - 失败原因 - 渠道 - 接收人 - 时间 - 支持筛选 要求： - 尽量复用现有表格、表单、抽屉、弹窗、按钮、状态标签组件 - 保持与现有系统视觉一致 - 不要引入风格突兀的新 UI 框架 - 中文文案自然，适合政务内网系统 -------------------------------------------------- 八、后端接口要求 -------------------------------------------------- 请按照项目当前风格实现接口。 建议至少包括： 1. 专项工作 - 创建专项工作 - 更新专项工作 - 查询专项工作列表 - 查询专项工作详情 - 启用/暂停/结束专项工作 2. 事项 - 创建事项 - 更新事项 - 查询事项列表 - 删除/停用事项 - 配置事项责任人 3. 提醒规则 - 创建规则 - 更新规则 - 查询规则列表 - 启用/停用规则 4. 实例 - 查询实例列表 - 查询实例详情 - 手动完成实例 - 重新打开实例（可选） - 查看实例提醒记录 5. 调度/任务 - 手动触发实例生成 - 手动触发提醒扫描 - 手动补偿失败提醒（可选，仅管理员） 要求： - 鉴权方式复用现有系统 - 参数校验风格复用现有项目 - 错误处理风格统一 - 返回结构与项目现有 API 保持一致 -------------------------------------------------- 九、完成动作要求 -------------------------------------------------- “完成”操作必须具备以下能力： 1. 用户在实例上点击完成 2. 可填写完成备注 3. 若事项要求附件，则必须上传附件 4. 写入： - monitor_instance 状态更新 - completeRemark - completedBy - completedAt - attachmentJson 5. 同时写 monitor_operate_log 6. 完成后所有 stopWhenDone=true 的规则停止触发 -------------------------------------------------- 十、状态流转要求 -------------------------------------------------- 建议实现以下状态流转： 专项工作： - DRAFT -> ENABLED - ENABLED -> PAUSED - ENABLED -> FINISHED - PAUSED -> ENABLED 事项实例： - PENDING -> COMPLETED - PENDING -> OVERDUE（由扫描逻辑自动判定） - OVERDUE -> COMPLETED - COMPLETED -> PENDING（若你认为需要“重新打开”功能，可实现，但要写审计日志） -------------------------------------------------- 十一、调度要求 -------------------------------------------------- 请在仓库中实现可执行的调度入口，方式优先适配现有项目。 建议包含： 1. 每天凌晨生成未来实例 2. 每 10 分钟扫描提醒 3. 每 30 分钟补偿失败短信 如果项目已有 cron 体系，就接入现有体系； 如果没有，则增加一个简单稳妥的 server-side 方案，并给出运行说明。 -------------------------------------------------- 十二、代码质量要求 -------------------------------------------------- 请确保： 1. TypeScript 类型完整 2. Prisma 模型、DTO、前端表单字段一致 3. 尽量少写重复代码 4. service 层拆分清晰 5. 时间处理统一，注意时区 6. 中文命名仅用于显示文案，代码命名使用英文 7. 不要只生成 demo，要生成可落地代码 8. 关键位置写必要注释 9. 对可能失败的地方增加错误处理 10. 不要为了省事把所有逻辑都塞到单个文件里 -------------------------------------------------- 十三、你最终需要输出的内容 -------------------------------------------------- 请直接修改项目并给出完整结果，至少包括： 1. Prisma schema 修改 2. migration 文件 3. 新增/修改的后端代码 4. 新增/修改的前端页面 5. 调度逻辑代码 6. Oracle 短信 service 封装 7. 必要的工具函数 8. 菜单/路由接入 9. README 或开发说明，说明： - 如何配置环境变量 - 如何执行 migration - 如何启动 - 如何手动触发实例生成/提醒扫描 10. 最后给出一份改动说明： - 新增了哪些文件 - 修改了哪些文件 - 每个文件作用是什么 -------------------------------------------------- 十四、实现时的关键约束 -------------------------------------------------- 1. 不破坏现有 task 主流程 2. 新模块应尽量独立，但能复用现有用户/部门/权限/布局 3. 不允许把周期规则、提醒规则硬编码在页面里 4. 所有提醒、完成、状态变更都要可追踪 5. 所有关键表都要有合理索引 6. 所有“防重复”都要有数据库唯一约束，不只靠代码判断 7. 代码必须是可以继续维护的工程代码，不是示例代码 -------------------------------------------------- 十五、建议的默认实现细节 -------------------------------------------------- 若仓库中没有现成实现，可按以下默认值落地： 1. periodKey 规则 - ONCE: ONCE - WEEKLY: 2026-W10 - MONTHLY: 2026-03 - QUARTERLY: 2026-Q1 2. 默认提醒模板 【专项监测提醒】{planName} - {itemName}（{periodLabel}）尚未完成，请于 {dueAt} 前处理。 3. 默认实例状态 - 新生成：PENDING - 到期未完成：OVERDUE 4. 默认提醒规则示例 - 提前 7 天，每天 09:00 - 到期当天 09:00 - 逾期后每天 09:00 5. 附件字段 - 若项目已有文件表，优先关联现有文件表 - 若没有，则 attachmentJson 暂存文件引用信息 -------------------------------------------------- 十六、工作方式要求 -------------------------------------------------- 请不要只给设计方案，请直接： - 扫描仓库 - 识别现有模式 - 修改代码 - 输出完整可运行实现 如果发现仓库实际技术实现与上述假设不一致，请优先以仓库实际情况为准，但必须保证“监测提醒”业务能力完整落地。 开始执行。