# 多维系统审查设计

## 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

```text
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、数据库或生产配置回滚。
- 浏览器和测试生成物仅删除本轮明确生成的路径。