8 月 30 日，Inkwell Engine 平台的扩展模块目录里同时多了五个新名字：日程日历、任务待办、加班调休、会议管理、公告通知。五个模块都已完成发布（状态：已发布），可以直接在平台里使用。
这篇讲三件事：上新了什么、每个模块解决的具体问题是什么、以及它们为什么能被放在同一篇里讲。
五个模块，各管一件事
| 模块 | 管什么 | 关键能力 |
|---|---|---|
| 日程日历 | 员工个人与协同日程 | 起止时间、全天标记、地点、参与人、提前提醒；参与人时间冲突校验 |
| 任务待办 | 日常任务的分派与跟进 | 指派负责人、优先级、截止时间；开始 / 完成两个动作端点 |
| 加班调休 | 加班申请与调休额度 | 审批流转；通过后按时长累计调休额度，按员工统计已用与剩余 |
| 会议管理 | 会议室预定与会议纪要 | 会议室字典、时间冲突校验、预定状态流转、纪要正文 |
| 公告通知 | 全员公告的发布与下架 | 置顶、类型 / 优先级 / 状态字典、发布与下架动作端点 |
日程日历：先把"什么时候有空"这件事解决
日程日历记录的不只是一条时间安排：主题、开始与结束时间、是否全天、地点、参与人、提前多少分钟提醒，以及一条备注。
两个细节值得单独说。一是参与人时间冲突校验——同一批参与人在重叠时段里已经被别的日程占用时，系统会在保存环节就把冲突挑出来，而不是等到当天才发现两个人约到了同一个小时。二是参与人以姓名快照的形式留在日程上（存的是引用关系，显示的是当时的人名），人事变动之后回看历史日程，参与人名单不会变成一串认不出来的编号。
查找方式也按日常习惯来：按主题关键字搜、按人筛、按开始日期的区间过滤。周视图、月视图的翻页，本质上就是这几个条件的组合。
任务待办：状态不是填出来的，是走出来的
任务待办的字段很朴素：标题、描述、负责人、优先级、截止时间、完成时间、备注。
不朴素的是它的状态管理。除了常规的增删改查接口，这个模块额外提供两个动作端点（可以理解为"系统里预设好的两个按钮"）：开始与完成。任务从"待办"走到"进行中"再走到"已完成"，是通过这两个动作发生的，而不是让人在表单里直接改一个状态字段。
差别在数据上看得见：谁在什么时候把任务推到了哪一步，都有确定的入口和确定的记录，不会出现"状态写着已完成、完成时间却是空的"这种对不上的情况。列表侧支持按标题搜索、按负责人 / 优先级 / 状态筛选、按截止时间区间过滤——这也是 OA 首页做待办聚合时最需要的几个维度。## 加班调休：把"欠多少假"变成一条能查的账
加班调休是这五个模块里业务链条最长的一条。员工提交加班申请，写清加班类型、起止时间、时长和事由；申请进入审批，留下审批人、审批时间和审批意见；审批通过后，加班时长才折算成调休额度。
额度不是算完就散落在单据里。这个模块带一个统计接口，按员工维度把三件事摆在一起：累计拿到了多少调休额度、已经用掉多少、还剩多少可休。人事不用再拿 Excel 手工加总，员工也不必凭记忆追问"我上次那八小时还算不算数"。
这里有个刻意的保守设计：只有审批通过的加班才进额度。未通过、已撤销的申请留在台账里可查，但不会污染统计结果。
会议管理：预定和纪要在一条记录上
会议管理把"订会议室"和"会后写了什么"合并成一条记录：会议主题、会议室、预定人、参与人、起止时间，以及会后补上的纪要正文。
会议室是一份数据字典（即由管理员集中维护的可选值清单），不是自由文本。这样"三号会议室""3 号会议室""小会议室"不会被录成三个不同的房间，冲突校验才有意义——同一房间、同一时段只能有一次有效预定，时间重叠会在提交时被拦下。
预定本身带状态流转，从申请到确认到结束，每一步的状态都记在同一条记录上。纪要作为字段挂在会议记录里，会后总结不用另开一个模块、也不用担心和对应的会议对不上。
公告通知：发出去就不能再改
公告通知支持标题、正文、公告类型、优先级、是否置顶，以及发布人、发布时间和状态。管理员可以按标题或发布人搜，也可以按发布时间区间过滤。
它最值得讲的是内容不可回改：公告一旦发布或已经下架，正文就不能再编辑。想改，就重新发一条。同时提供发布、下架、置顶三个动作端点——状态变化只能通过这三个动作发生。
这条限制听起来不友好，但全员公告的性质决定了它更接近"对外发出的文件"：员工看到过的内容如果会在背后被悄悄改掉，公告就失去了作为依据的资格。留一条不可篡改的记录，比方便管理员改错字更重要。## 为什么这五个可以放在一篇里讲
单个模块的功能说明看多了会发现，真正决定系统好不好用的不是字段多少，而是约定是否统一。这五个模块共用三套底座约定：
一是同一个"人"。 五个模块的负责人、预定人、发布人、申请人，引用的都是平台上已发布的员工档案模块。员工档案本身支持按部门、岗位、在职状态和入职日期筛选，工号在创建时自动生成。日程上写的是"哪个人"，不是"某个人名"——人换了岗位、改了姓名，历史记录指向的还是同一个对象。
二是同一份数据字典。 任务优先级、加班类型、会议室、公告类型这些可选值，全部来自平台的数据字典模块集中维护，由管理员增删，业务模块只负责引用。想加一种加班类型，不需要改代码，也不需要重新上线模块。
三是同一种状态流转方式。 任务用"开始 / 完成"，公告用"发布 / 下架 / 置顶"，加班和会议用带审批的状态字段。状态变化一律走动作端点，不给"直接改字段"留后门。这条约定是这五个模块的数据能对上的根本原因。
它们是怎么被建出来的
这五个模块和平台上的其他扩展模块走同一条路：在 AI 构建器里由需求描述生成，进入沙箱环境验证，通过发布前预检之后才进入模块目录标记为已发布。
每个模块交付时自带一整套东西：数据模型定义、服务层与接口层代码、以及一份模块接口说明文档（列出这个模块对外提供哪些接口、哪些字段必填、哪些字段只能筛选不能修改）。也就是说，页面和接口出自同一次生成，不会出现"页面上有这个字段、接口不认"的错位。
现在能用到什么程度，接下来是什么
已经可用的：本次发布的五个模块，加上此前已发布的员工档案、打卡考勤、文档知识库。请假休假和通用审批中心目前在测试验证阶段，尚未正式发布，这里不做功能承诺。
正在补的方向很清楚：把已经能各自独立工作的模块串成流程。加班调休的额度接进请假核减、会议预定接上审批中心、公告和待办联动到 OA 首页——这些都需要先在测试环境里跑通，跑通了才会写进下一篇文章。
和本站其他内容一样，这篇里的每一句功能描述都对应平台上真实存在的能力，你可以在演示环境里逐个点开验证。