hyb-oa/.trellis/tasks/07-16-system-multidimensional-audit/design.md

多维系统审查设计

Safety Boundary

• 本任务是只读审查任务。默认允许读取代码、文档、Git 历史和本地测试输出，以及运行无凭据的本地构建、单测、静态门禁和 mock E2E。
• 禁止修改业务代码、数据库、schema、迁移、权限、页面、生产配置或历史证据；发现问题只登记 finding。
• 禁止访问带凭据公网环境、执行真实业务写入、企业微信写入、真实付款或数据库重置。
• 生成截图或测试报告时，固定本轮输出目录并在结束前清理；既有历史证据目录保持不动。
• 普通任务材料中的安全 finding 只保留代码位置、风险类别、业务影响、控制目标和无害验证结论；攻击步骤、载荷、绕过方式、概率推演、可组合接口细节和真实环境信息不进入 task、spec 或聊天摘要。

Audit Model

审查采用三层证据模型：

1. 合同层：当前 Trellis task、项目 spec、业务事实源和现行手册定义“应该是什么”。
2. 实现层：路由、页面、API、service、schema、权限和状态机定义“代码实际是什么”。
3. 行为层：单测、构建、E2E、截图和 QA runner 证明“当前本地行为是什么”。

只有三层一致时才可判为通过；缺一层时记录证据缺口或外部准入，不用历史结论补证。

Execution Order

1. 冻结基线与资产清单

• 记录 HEAD、工作树、Node/npm/Prisma/浏览器版本和本地运行边界。
• 建立功能域、路由、页面、API、schema、测试和事实源清单。
• 标记 feature flag、冻结能力、历史兼容入口和只允许外部验证的能力。

2. 功能与业务闭环审查

• 按普通员工、审批人、财务/出纳、管理员等代表角色抽查核心业务链。
• 从入口追踪到 API、service、storage、状态变化、附件/证据、通知和审计。
• 对异常、重复提交、撤回、归档、无权限和外部依赖失败进行负路径审查。

3. 权限、状态机、数据与安全审查

• 对照导航/路由、前端动作和后端权限，定位“能看不能做”“前端隐藏但后端未拦”“后端拦截但前端误导”等不一致。
• 追踪关键枚举、字段、金额/日期、附件归属和审计信息跨层传递。
• 聚焦认证、导出、上传/下载、日志、错误响应、Secret/env 和外部集成边界。

4. 页面与设计审查

• 先审全局 shell、导航、搜索、通知、错误/空/加载/403/404，再审核心列表、详情和编辑流程。
• PC 以 1440/1024 为主，移动以 375 为主并抽查 320/390/430；涉及企微时只做 UA/布局证据，真机结论保持外部准入。
• 复核标题动作、筛选/表格、表单反馈、弹窗/危险操作、键盘/焦点、对比度、触控目标和横向滚动。

5. 测试、性能、可靠性与运维审查

• 先运行基础门禁，再按矩阵选择最小充分的 Playwright 集合；不以测试数量代替覆盖质量。
• 检查前端没有 unit spec 是否造成关键纯逻辑/组件合同缺口；检查 E2E 是否陈旧、重复、依赖选择器或环境脆弱。
• 通过静态证据、构建报告和必要的浏览器测量识别性能风险；不做无数据的泛化优化建议。
• 核对 readiness、来源追溯、迁移、回滚、备份恢复准入、巡检、文档和培训口径。

6. Finding 收敛与交叉复核

• 每个 finding 先与现有任务、历史证据和其他维度去重。
• P0/P1 finding 至少做一次独立只读复核；权限、状态机、迁移和审批规则 finding 必须跨层复核。
• 将共因问题归并为根因，例如权限显隐合同缺失、页面模板未约束、测试与当前交互漂移。
• 输出建议修复波次：P0 立即隔离、P1 核心闭环、P2 体验/维护、外部准入。

Evidence Layout

• research/baseline.md：commit、环境和门禁结果。
• research/inventory.md：功能/路由/页面/API/schema/test 资产矩阵。
• research/findings.md：唯一 finding 台账。
• research/page-review.md：页面、视觉、交互、响应式和可访问性证据。
• research/business-flow-review.md：核心业务链和负路径证据。
• research/engineering-review.md：权限、数据、安全、测试、性能和运维证据。

如现有文件可承载则复用，不为每个小问题新建文档。

Finding Schema

ID | Dimension | Discovery Severity | Confidence | Discovery Status |
Remediation Status | Deployment Status | External Verification |
Evidence Ref | Business Impact | Control Objective | Safe Verification |
Follow-up Work Package

状态分层规则：

• Discovery Status 只描述发现时证据：CONFIRMED、LIKELY、EXTERNAL_GATED、DUPLICATE 或 NOT_AN_ISSUE。
• Remediation Status 只描述当前本地修复，不因部署或公网未知而回退；常用值为 OPEN、ACTIVE_TASK_OPEN、LOCAL_FIX_VERIFIED、FOLLOW_UP_RECOMMENDED。ACTIVE_TASK_OPEN 只用于已有活动 task 承载但本轮不重复建账的 finding。
• Deployment Status 独立使用 DEPLOYMENT_PENDING、NO_FIX_TO_DEPLOY 或 NOT_APPLICABLE。只有存在本地修复产物时才可写 DEPLOYMENT_PENDING。
• External Verification 独立使用 EXTERNAL_BEHAVIOR_PENDING、EXTERNAL_GATED 或 NOT_REQUIRED。
• Safe Verification 只写防御性断言、测试结论和浏览器尺寸结果，不写可操作的攻击复现过程。

Exit Conditions

• P0/P1/P2 和 EXTERNAL_GATED 均有清晰定义与证据。
• 所有计划内维度完成覆盖或明确说明为什么未覆盖。
• 不存在因审查产生的业务代码、配置、数据或未清理生成物改动。
• 最终报告能直接支持用户决定“立即修、分波修、接受、外部补证或暂缓”。
• 原基线与当前 HEAD delta 均被保留；本地修复、部署和外部行为状态不互相替代。

Rollback

• 审查正文和 task 记录可通过本任务提交回退。
• 本任务不产生业务实现、schema、数据库或生产配置回滚。
• 浏览器和测试生成物仅删除本轮明确生成的路径。