docs: simplify ERP requirements design skill

skills/erp-requirements-design/references/business-checklist.md

@@ -1,104 +1,68 @@
 # 业务访谈与产品检查清单
 
-按业务选择使用；这是分析辅助，不是一次性发给用户的问卷。流程已清楚时直接写稿，未知项放回受影响的需求处。
+本文件用于内部查漏，不是文档目录、必写清单或一次发给用户的问卷。先用已有资料贯通主流程，只对影响范围、权责或完成标准的缺口提问；已明确的内容直接写稿。
 
-## 从一句话提炼可讨论的业务
+## 所有业务先检查
 
-优先明确业务背景、目标、使用角色、触发条件、完成标准和本期边界。用户提供流程时沿着“输入 → 处理 → 输出 → 下一位处理人”补齐断点，不先讨论技术。
+| 关注点 | 需要明确的业务结论 |
+|---|---|
+| 目标与范围 | 解决什么问题，本期做到哪一步，哪些事项未纳入 |
+| 角色与入口 | 谁申请、审批、办理和管理，各从哪里进入 |
+| 必要信息 | 办理必须填写什么、哪些可从已有资料带出 |
+| 完成标准 | 审批、实际办理和登记分别何时完成 |
+| 权限与变更 | 谁能查看及处理，修改或取消如何影响已办理事项 |
+| 验收与未决 | 核心结果如何检查，哪些问题确需业务确认 |
 
-例：“销售填单，采购处理，仓库收发货。”先区分现货销售与销售带动采购，问是否需要独立备货。不要直接假设每张销售单必然生成一张采购单。
+检查不等于全部展开。一个明确的短句可以承载结论，无需将每项再拆成字段、状态、权限和异常表。
 
-每个重要缺口按业务名称记录：`确认事项 / 业务影响 / 可选方案或建议 / 决策角色 / 相关功能或章节 / 是否影响定稿`。建议不是默认批准；用户不回答时保留待确认。确认后同步正文、菜单、图示、权限、验收及版本表，不继续在待决表中保留该项。
+## 页面与基础资料
 
-## 角色与权限
+确认菜单所属中心、模块和实际页面；共同父级路径集中写一次，跨模块入口单独补充。不同入口处理同一事项时，说明共用单据。菜单归属不能直接套用其他模块。
 
-- 业务操作者、审核人、管理人、只读查看人分别是谁；组织/岗位变化后如何交接未完成事项。
-- 能否看本人、本部门、负责范围或全部记录；能否查看金额、成本、利润、附件、导出结果。
-- 可见不等于可编辑，可编辑不等于可审批。本人能否审批本人单据、离职人员待办怎么处理，按需要确认。
-- 产品写可验证的权限结果，如“销售不能通过列表、详情、导出或直接访问查看其他销售的订单”；具体实现由开发设计。
+基础档案通常只需维护入口、维护人、建档方式及业务必要字段。用户已确定字段清单时按清单执行，不从通用检查项自动补入平台、系统标识、账号绑定、用途或凭据管理。
 
-## 流程与状态
-
-- 起点、提交条件、接手角色、完成标准和最后一个业务动作。
-- 草稿、待处理、进行中、部分完成、完成、关闭等状态按实际需要采用，不强套统一名称。
-- 审批中允许改哪些内容；退回、驳回、撤回是否不同；修改后是否重审，原记录如何查看。
-- 一单多明细时，部分完成、部分退回、部分关闭如何显示总单状态和剩余工作。
-- 作废、删除、关闭、归档各自代表什么；发生后能否恢复、谁能看历史、关联单据怎么处理。
-- 超时、无人接单、人员停用、处理中断后的责任人和下一步入口。
-- 保存草稿、提交申请、提交业务单据、完成实际办理各自意味着什么；哪些字段允许草稿暂缺、提交前必须补全，用户从哪里继续未完成事项。
-
-## 页面与字段
-
-- 写清一级菜单、二级模块及实际需要的三级页面，区分导航菜单、详情页和申请类型；明确新增、复用或调整。不能仅写“独立入口”。
-- 未确定菜单时依据业务职责和现有导航提出具体建议，标明待确认。确认后给出完整路径；不因内部群管理属于行政中心而将其他模块一律归入行政中心。
-- 申请、审批、办理、查询和基础资料维护分别从哪里进入；多个入口如何关联同一单据、版本和状态；PC 与移动端分别覆盖哪些任务。
-- 父级菜单可见性不应扩大该中心其他功能的权限，子菜单、记录、字段及附件范围分别控制。
-- 基础档案的维护入口、维护角色、建档方式、标识来源、负责人及系统账号关联是否明确；变更、停用、交接与历史记录如何处理。外部角色登记不自动授予平台资格。
-- 接入已有页面时分别记录当前入口、页面标题和拟使用的产品名称。旧菜单规划与实站不一致、标签疑似复制错误时先列差异，不直接照搬。
-- 列表默认视图、筛选、排序、分页、关键列、进度、待办提示；筛选清空后应恢复什么。
-- 新建、编辑、详情、审批、处理、历史记录页之间的关系。
-- 字段含义、来源、选项、单位、是否必填、条件必填、带出/填写、编辑时点、合法范围及错误文案。
-- 查询无结果、无权限、加载失败、处理中、成功、结果不明分别怎么显示；重复点击后的业务结果。
-- 导入、导出、打印、附件只在本期需要时展开。说明导入预览、错误行、重复判断、部分成功是否允许和结果反馈，不设计文件服务实现。
-- 多组明细：每组对应什么对象，允许多少组，逐组必填与整单必填的区别，增删明细如何影响合计、附件和审批条件。
-- 条件附件：何种单价/总额/类型触发，等于门槛如何处理，每组还是整单上传，文件数量和大小、缺失提示、金额修改后是否重新判断。现有行政采购页面的门槛只是该流程的观察值，不自动套给采销。
-- 星号、限额提示、空列表和演示数据分别标注观察层级；没有实际操作验证时，不写成校验已通过或业务已完成。
+列表保留业务需要的查询、进度及操作，通用排序、分页、加载提示和每个错误文案不用逐项写。只有用户提出专项交互要求，或这些行为直接影响办理判断时再展开。
 
 ## 审批与通知
 
-- 哪些单据需要审批、触发条件、节点顺序、审批人来源、多人如何算通过、抄送与通知区别。
-- 无可用审批人时如何提示和处理；人员名单变更对在途单据是否生效。
-- 申请表预览的审批节点、通过方式和抄送信息如何展示；业务要求优先使用岗位/组的职责表述，当前测试账号姓名不作为长期审批规则。
-- 申请人在哪看进度，审批人在哪接待办，办理人从哪里接后续工作；“我发起的、我的待办、我的已办、抄送我的”和全局管理视角按业务分别说明，不仅列一个总菜单。
-- 审批通过后是否生成待办/业务单据，谁继续办理；审批通过不等于业务执行完毕。
-- 相同审批结果被重复处理时，业务单据和待办不应重复；联动失败时显示待处理/异常、由谁核对并恢复。这里只定义用户可观察的结果。
-- 通知渠道、触发事件、接收角色、简要内容、跳转目标、重复或失败时是否重发；不能把“已提交”写成“已通知到所有人”。
+涉及审批时检查申请人、有效审批人、通过后的接手人和完成标志；退回、撤回及批准后修改按实际流程简述。审批层级、金额门槛和多人通过规则未确认时保留待定，不从示例推断。
 
-## 跨模块接入
+涉及通知时写明何时提醒、提醒谁、通过什么渠道、进入何处办理。提醒成功和业务完成分开表达；失败处理合并为业务原则，不扩写发送机制与重试时序。
 
-每项联动写六件事：来源模块和单据、触发业务动作、带入的业务信息、目标单据或待办、双方可追溯入口、失败时的状态和责任人。
+## 按业务条件追加检查
 
-确定已有数据从哪里来、谁维护、修改是否影响历史记录；需要保留成交时名称/价格等历史信息时，用业务语义说明，不指定数据存储结构。
+以下只检查本期实际涉及的部分。结果写回对应功能，不新建一套“完整性附录”。
 
-分清“计划生成入库单”“仓库确认收货”“库存已增加”三个结果。若上游可修改或取消，说明下游尚未办理、部分办理、全部办理三种情况下怎么办。
+| 业务条件 | 必须保留的判断 |
+|---|---|
+| 多明细或部分办理 | 明细粒度、整单进度、剩余工作；部分完成不能显示全部完成 |
+| 已执行后变更或取消 | 保留已发生事实，明确未办理部分及后续补充、重审方式 |
+| 外部执行结果未知 | 先核实再处理，不把未知当失败而直接重复执行；明确跟进人 |
+| 跨部门或组织权限 | 查看和办理范围、敏感字段的必要隔离，不能只靠菜单名称表达 |
+| 跨模块联动 | 来源、触发动作、目标结果及可追溯关系；失败由谁核对，避免重复业务单据 |
+| 金额和数量 | 单位、币种、精度、合计及上下界；关键口径和舍入规则不得为简洁而省略 |
+| 条件附件或门槛 | 触发条件、等于门槛如何处理及修改后的影响；未知上限待确认 |
+| 存量或在途记录 | 历史与新流程如何衔接，避免覆盖事实或重复办理 |
 
-来源单号、目标单号、经办人、审批完成/建单/办理时间分别代表哪个阶段；关联信息为空时显示什么、是否仍允许继续、谁核对补齐。看见已完成状态但关联单号为空，只能记为该记录现象，不能推断关联不需要或功能必然异常。
-
-## 数量与金额
-
-只对涉及它们的业务展开：
-
-- 数量单位、可否小数、最小/最大值、换算、是否允许超量、数量分配到单据或明细的口径。
-- 币种、含税/未税、折扣、运费、税额、金额汇总与舍入位置；客户和供应商价格是否分别管理。
-- 已执行、已退、剩余、可用、占用等名称逐一定义，不能把净数量当累计履约数量。
-- 规则未确认时以具名待确认事项保留；不要把其他系统的税率、审批金额门槛、精度或负库存策略带入本项目。
-- 有示例时标注虚构测试数据，并使用明确公式复核结果；公式和示例必须同一口径。
+金额、人数、容量和时限没有依据时不虚构数值。缺少页面或操作证据时标为未核实，不把标签、星号、空列表当作行为验证。
 
 ## 采销业务追加检查
 
-先确认业务模式：现货销售、以销定采、独立备货、代采中的哪些属于本期。
+先确认现货销售、以销定采、独立备货、代采中的哪些属于本期，不因系统名为 ERP 自动加入合同、收付款、发票和财务。
 
-再按已选范围检查：
+涉及分批履约、退货或库存时，再核对：
 
-- 销售与采购是否一对一、多对多；拆单、合单、分仓、分批及未分配数量。
-- 云库分类/品牌/系列/SKU、行政资产分类与实物唯一码分别是什么；新业务选择现有 SKU 还是允许自由填写，历史商品信息如何保留。
-- 有唯一码的商品是否逐件登记，码与数量怎样对应，重复、缺码、错码、换货怎么处理，退货如何核对原件；无唯一码商品按数量还是批次管理。页面有“是否有唯一码”并不证明这些环节已实现。
-- 库存出库现有“销售、寄出、借出”是否与本期场景相关；不同用途是否需要返回、结算或不同责任人，不把所有出库都当销售完成。
-- 库存是否预留、何时预留/释放；无货、可用量不足、多个订单同时申请同一批货时的用户结果。
-- 订单审核、收发货计划、实际收发货各自时点；入出库单生成是否需要人工确认。
-- 部分到货、少货、多货、错货、不良品、剩余取消；历史手工入出库单是否与新单关联，防止重复处理。
-- 客户退货与供应商退货分别关联哪笔原收发货，数量上限和质检/可用状态，是否补发补采。
-- 退货对库存、订单进度和结算的影响分别说明；不要默认退货自动恢复订单未交数量。
-- 合同、付款、收款、发票、物流和财务是否在本期；不因系统叫 ERP 自动纳入全部范围。
+- 销售、采购与收发货的关联关系，分批数量、已执行与剩余口径。
+- 商品来源、单位及有无实物唯一码；实际收发货时点和库存变动时点。
+- 部分到货、剩余取消、客户或供应商退货的责任及数量边界。
+- 退货对库存、进度和结算的影响，是否补发或补采，不默认恢复原单未交数量。
+
+需要例子时参考 [采销需求片段](procurement-example.md)，不把示例规则或数字直接套为本项目要求。
 
 ## 验收与评审
 
-用“验收场景 / 前置条件与操作 / 预期结果”组织验收，按业务名称或章节关联功能，不默认使用技术式编号，不用“正常”“准确”“友好”代替具体结果。
+默认按核心业务合并为“验收场景｜预期结果”，用具体结果代替“正常、准确、友好”。需要前置条件才能判断结果时再补条件；用户要求测试用例时另行展开边界组合。
 
-按风险覆盖主流程、权限拒绝、字段边界、退回修改、取消、部分完成、重复处理、关联失败和存量衔接；不适用的项说明原因即可。
+只记录影响业务定稿的未决事项及责任人，不把被用户删去的字段或通用技术参数重新列为待确认。已确认内容写回正文并移出待定表。
 
-若产品采纳条件附件、多组明细或唯一码规则，对应增加门槛下/等于/超过、明细增删后重新判断、缺失/重复唯一码等验收场景。测试数据来自已确认规则，不能靠测试样例暗定未知规则。
-
-性能、容量、文件上限等指标来源必须可追溯。业务未提出数值时，问可接受的等待时间或使用规模，或列为待确认；不自行写 2 秒、50 并发等数字。
-
-交付前核对：业务词汇一致、角色与动作相容、关键规则有验收场景，图与正文同义；待确认项未被写成定论，已确认内容不再被列为待定。产品评审通过与实际开发测试通过分开记录。
+交付前核对主流程、关键权限、已发生事实和进度口径仍然完整，Word、Markdown、图示同步；需求稿的验收要求不表示系统已验收通过。

skills/erp-requirements-design/references/delivery.md

@@ -9,7 +9,7 @@
 3. 持续编辑同一评审稿时保留维护入口。局部措辞、格式和删节一般更新当前版本并保留可恢复备份，不每次小改动都复制一套竞争版本。明确发布新基线、重要业务版本变化或用户要求留新版本时，按版本规则新建并指明最新文件。
 4. 同一版本更新该行修订摘要，不把每次对话视为新版本或生成多行同名版本；未确认决策保持待评审。
 5. Markdown 为维护源稿，Word 为排版版本。定点修改 Word 后同步源稿，核对章节、字段、权限、状态、图示和验收，避免两套内容分歧。
-6. 删除或改写须在两种格式及相关引用中生效。后续生成基于最新源稿，不恢复已删除的资料说明、旧标题或元数据。
+6. 删除或改写须在两种格式及相关引用中生效。后续生成基于最新源稿，不恢复用户已删的字段、句子、资料说明、旧标题或元数据，也不将其移到其他章节、图示、验收或待确认表中。
 
 ## Word 与图表制作
 
@@ -30,10 +30,11 @@
 - 已确认菜单是否仍在待确认表内，图中是否存在旧路径。
 - 删除技术式编号后，功能和验收覆盖是否仍然保留。
 - 文首是否仍有重复副标题或版本日期状态行，版本表是否一版本一行。
-- 已删除资料说明或旧标题是否被旧脚本、模板及副本恢复。
+- 用户已删的字段、句子及旧标题是否被模板、脚本、图示或副本恢复。
+- 同一规则是否重复展开，字段和验收是否可合并；必要的业务约束及完成标志是否仍然明确。
 - 业务完成、人工登记及系统回执是否区分，虚构示例是否被误作证据。
 
-版面核对需生成渲染页，检查字体、表格、图片、跨页表头、标题衔接、页码、空白与溢出。新文档及整体重排逐页检查；局部修改检查受影响页。文件能打开不等于版面已核验。
+版面核对需生成渲染页，检查字体、表格、图片、跨页表头、标题衔接、页码、空白与溢出。新文档及整体重排逐页检查；局部修改检查受影响页。文件能打开不等于版面已核验。精简优先合并内容和图示、优化分页，不靠缩小字号挤成固定页数。
 
 ## 预览与保存内容不一致
 

skills/erp-requirements-design/references/prd-style.md

@@ -1,76 +1,62 @@
 # PRD 结构与表达规范
 
-本规范适用于本技能生成的中文业务评审稿。用户提供模板或提出其他明确格式要求时优先；局部修订不自动扩大为整篇改版。
+默认交付简洁的业务评审稿。用户指定的结构、字段和详细程度优先；局部修改不触发全文扩写。
 
-## 文档结构
+## 简版结构
 
-从“主标题、版本记录表、业务正文”开始。版本记录位于最前，不在标题下重复副标题及版本、日期、状态说明行。版本表为“版本、修订日期、修订内容”，每个版本一行，版本及日期取真实记录。
+文首为“主标题 → 版本记录表”，表头为“版本、修订日期、修订内容”，每个版本一行。正文按下列结构裁剪，无内容的章节直接省略。
 
-| 章节 | 核心内容 | 适合的表达方式 |
+| 章节 | 保留内容 | 建议表达 |
 |---|---|---|
-| 背景与目标 | 背景、目标、本期边界及完成标准 | 简洁段落，必要时列范围表 |
-| 现状及预期效果 | 业务环节的变化与预期改善 | 环节对照表、功能建设清单 |
-| 整体流程 | 角色衔接及关键分支 | 泳道图或流程图及文字说明 |
-| 详细需求 | 页面、字段、操作及异常 | 按页面展开，结合示意、字段及操作表 |
-| 权限与状态规则 | 角色范围、状态及关键规则 | 权限矩阵、状态图或必要的状态表 |
-| 验收与上线要求 | 完成标准、异常及切换验证 | 场景、前置条件与操作、预期结果 |
-| 评审确认事项 | 未决事项、责任与影响 | 事项名称、建议方案、确认责任及影响 |
+| 背景与目标 | 解决什么问题、本期做什么 | 一至两段，不重复拆背景、目标、范围 |
+| 整体流程 | 角色、顺序、完成标志 | 一条文字流程或一张紧凑主流程图 |
+| 功能需求 | 入口、必要字段、主要操作和结果 | 按实际页面分节，配必要的短表 |
+| 权限与办理规则 | 查看及办理范围、变更、异常与进度 | 短段落或合并规则，不穷举组合 |
+| 验收与上线 | 核心场景、预期结果、准备工作 | 两列表格及简短上线说明 |
+| 评审确认事项 | 影响定稿的真实未决问题及责任人 | 短表或列表，已确认事项移出 |
 
-现状尚未核实时采用“已明确的管理诉求”对照，不为填表编造现行流程。新增功能标明“本期新增”，未复核的既有能力写“拟复用，适配范围待核实”。
+现状对比、功能建设清单、统计口径、详细状态表、页面示意均按需要加入，不是必填章节。不为填表编造现状。篇幅随业务复杂度确定，不把某次四页文档或六项验收当作固定指标。
 
-## 标题与正文
+## 内容粒度
 
-业务章节采用 `1`、`1.1`、`1.1.1`，不与中文序号混排，不为凑三级标题机械拆分。Word 使用对应标题样式和提纲级别，不只加粗普通段落。
+每个功能回答“在哪里、谁使用、做什么、结果是什么”。影响操作的条件在对应句子或字段旁说明；不要为每个功能再建一套前置条件、权限、异常、日志及验收子章节。
 
-| 口语表述 | 正式表述示例 |
-|---|---|
-| 为什么要做 | 业务背景、建设目标 |
-| 这个功能要解决什么问题 | 项目概述、背景与目标 |
-| 谁来审批 | 审批人员与节点配置 |
-| 怎么填写、从哪里申请 | 表单字段与校验、申请入口与提交规则 |
-| 出问题怎么办 | 异常处理、失败恢复 |
-| 需要谁拍板 | 待确认事项、确认责任 |
-| 看看有没有办完 | 办理状态、完成标准、验收要求 |
+| 内容 | 简版写法 | 需要展开的条件 |
+|---|---|---|
+| 菜单 | 共同父级路径写一次，列页面与用途；跨模块入口补完整路径 | 菜单归属或不同角色入口存在实际分歧 |
+| 基础资料 | 维护人、建档方式及必要字段；少量字段直接一句列出 | 导入、同步、资源变更等属于本期明确需求 |
+| 表单 | “信息｜填写要求”，相关字段合并为一组 | 字段单位、金额门槛、条件附件会改变业务结果 |
+| 权限 | 按角色说明可见及可办理范围 | 涉及跨组织数据、金额或敏感对象的差异权限 |
+| 异常 | 合并说明取消、核实、补登记等业务处理原则 | 部分履约、冲销、退款等存在不同后果 |
+| 验收 | “验收场景｜预期结果”，同类操作合并 | 用户要求测试方案，或前置条件会改变预期结果 |
 
-正文及表格也使用正式而具体的表述，例如“审批通过后生成待办，由有权限的管理员领取；登记实际办理结果后记为已完成”。不要只替换标题而保留口语，也不要用空泛术语代替业务动作。
+详细规格按用户指定的章节展开；数量、金额、库存、审批和权限等关键约束按实际业务补齐。不要由一个复杂环节带动所有章节扩写。
 
-功能用业务名称，如“供应商准入申请”；验收用场景名称，如“审批人员失效”“取消与办理并发”。交叉定位使用名称或章节号，默认不引入技术式标识及编号追踪矩阵。
+## 字段与语言示例
 
-## 页面需求的写法
+采用业务人员熟悉的词，能说“人员范围”就不写“受众”。字段来源、只读状态、字符数、系统标识及账号绑定只在影响业务办理时写，不为普通资料维护自动补齐这些说明。
 
-按“建设方式、入口与角色、页面内容、操作与结果、异常与权限”展开。例：
+例如用户已确认渠道档案字段时，可直接写：
 
-**4.3 资格核对**
+> 业务管理员在“通知渠道”人工建档。群聊记录群名称、人员范围和群主；公共邮箱记录邮箱名称、发件地址和发送负责人。
 
-建设方式：本期新增，审批结果拟复用审批中心。入口：采购中心下的业务模块，具体层级须根据该业务确认。使用角色：获授权的资格核对人员。
+这段说明用于示范字段取舍，不代表所有通知业务都用同一字段集。用户指定“只保留”的清单按其原意执行，不自动补回平台、群 ID、用途、账号关联或凭据管理等细节，也不移到验收或待确认事项中。
 
-审批通过后形成核对待办。核对人员查看批准版本及允许访问的附件，登记核对结果；核对通过并执行启用后，供应商状态变为已启用。审批通过本身不构成启用完成。处理结果不明时先核实原记录，不重复创建供应商。
+正文采用正式、直接的业务表达，如“审批通过后生成待办，由负责人办理并登记结果”。标题使用“背景与目标、申请、审批、发送与回执”等具体名称，通常保留两级标题；不机械拆成三级。
 
-此例仅说明描述粒度，不是其他模块的默认菜单或确认规则。实际文档应将已确认入口写成完整路径，并补齐字段和异常要求。
+功能、规则和验收用业务名称定位，默认不引入技术式编号。重要规则集中说明，验收只写结果，不再复述完整规则。
 
-## 图表与示例
+## 图示与示例
 
-- 跨角色主流程使用泳道图，判断节点标明条件和结果，动作与对应角色一致。
-- 新建页面用低保真示意展示信息分区、关键字段和按钮，标注“拟建页面／非现有界面”。正文保留字段和操作条件。
-- 现有截图注明环境、日期和观察范围；只参考表达风格时，不移用其中的业务规则、数据、人员或链接。
-- 状态或异常图承担必要解释，不重复制作同义图。保留文字流程，便于图片无法显示时理解。
-- 对比、字段、状态和验收等重复结构使用表格；长段规则使用正文，避免挤入窄列。设置合理列宽和跨页表头。
-- 示例注明虚构，覆盖关键判断；时间、金额、数量与正文一致，不以示例暗定限制。
+- 图用于解释角色衔接或不易理解的页面；一张主流程图已能说明时，不重复增加同义图或逐步骤示例表。
+- 页面示意标注“拟建页面／非现有界面”；实站截图注明环境和观察日期，不能把图上的字段、数量或状态当作行为验证。
+- 虚构例子明确标注，不通过样例设定未知限额；金额和时间计算用确定性方法核对。
+- 表格适合菜单、字段、角色和验收的并列信息；长说明用正文。删节靠减少重复和合并内容，不靠缩小字号或挤压行距。
 
-## 评审稿与工作记录
+## 修改和交付前核对
 
-交付稿围绕业务背景、目标、规则及待决事项，不默认附带“参考了哪些资料”、工具过程或“本轮未访问哪些页面”等编制过程章节。资料路径、读取时间和观察证据留在工作记录，按需可追溯。
+先读当前维护稿及用户最新修改，保留已确认的范围和删节决定。将同类细节从模板提示中移除后再生成，避免 Word、Markdown 或图示把它们恢复。
 
-仍须准确表达业务事实：拟建图标为示意，未确认权限和审批层级保留待定，未验证能力不写成已支持，验收条件不写成已通过。用户要求来源说明时另行添加，不能为精简隐瞒影响业务判断的限制。
+业务事实和证据边界保留在相关句子旁：建议不写成定论、拟建不写成已实现、待验收不写成已通过。正文不额外添加工具过程、资料清单或泛化安全说明。
 
-## 菜单与档案检查
-
-成稿前应能明确回答：
-
-1. 一级菜单、二级模块和三级页面分别是什么；哪些属于详情页或申请类型而非导航菜单。
-2. 申请、审批、办理和资料维护各从哪个完整路径进入；不同入口是否对应同一单据。
-3. 父级和子菜单可见性如何授予，是否会扩大其他功能或数据权限。
-4. 基础档案由谁建立、从哪里维护，人工录入、导入或同步的方式是否已确认。
-5. 识别信息、负责人和系统账号如何关联，变更、停用及历史记录如何处理。
-
-内部群管理归属行政中心是该模块的已确认决策，不是其他业务的默认归属。未决菜单需给出有依据的建议及影响；确认后同步所有引用，移除相应的“归属待确认”表述。
+最后通读：主流程能否贯通，字段是否必要，同一规则是否写了多次，常见异常是否可合并，关键约束和真正未决问题是否仍然清楚。