DCL8/REQ8 同步事实源并规划后续门禁

docs/产品口径.md

@@ -57,9 +57,10 @@
 - 当前正式运行口径：`majianyong` 是员工可见直属主管；`wangshunli` 是 `ceo + admin`，不配置为普通 `manager`；`admin` 不代表业务审批权。
 
 ### W-2 转审适用范围
-- 转审是通用审批能力，支持：报销、请假、采购、差旅
-- 条件：只能转给具备对应单据审批权限的人
-- 当前代码仅限报销，需移除 `entity_type !== "reimbursement"` 的硬限制
+- 产品目标：转审是通用审批能力，目标覆盖报销、请假、采购、差旅。
+- 条件：只能转给具备对应单据审批权限的人，且不得绕过必经老板、财务或 HR/行政节点。
+- 当前实现状态：转审路由仍使用 `expense.transfer` 前置权限，`approvalTransfer` 专门留痕仍以报销为主；跨域转审扩展不作为当前 R7 硬门禁。
+- 后续若要覆盖请假、采购或差旅，拆 `W2F` follow-up，先评审权限、状态机、转审链路、通知和历史留痕。
 
 ### W-3 转审次数上限
 - 上限保留 3 次，超过后拒绝继续转审
@@ -74,7 +75,8 @@
 ## 通知渠道
 
 ### N-1 三渠道联动策略
-- 审批类高优先级事件默认三渠道并发：站内通知 + 企微 + 邮件
+- 产品目标：审批类高优先级事件可支持站内通知 + 企业微信个人应用消息 + 邮件。
+- 当前 R7 验收口径：以站内通知 + 企业微信个人应用消息和 deeplink 为主；邮件通道是否进入验收另拆 Issue。
 - 当前不做用户级"关某渠道"配置
 - 后续通知量上来后再做订阅偏好管理
 
@@ -83,9 +85,9 @@
 ## Portal 首页
 
 ### P-1 经理视图判断逻辑
-- 现状：用 `system.users` 或 `report.dashboard.view` 判断，不准确
+- 当前状态：Portal 经理/角色能力已通过 `buildRoleCapabilities` 类逻辑按角色和权限承载。
 - 口径：有任一**审批权限**（`*.approve`）或**域管理权限**（`*.manage` 非 `view_all`）的用户进入经理视图
-- 实现时建议提取 `isManagerRole(permissions)` 工具函数统一判断
+- 后续可选择提取 `isManagerRole(permissions)` 共享工具减少重复，但这不是当前 R7 阻断项。
 
 ---