15 KiB
15 KiB
产品口径文档
来源：2026-03-25 产品需求梳理会话 适用版本：R35 之后
平台边界
P0-1 企微优先 + OA 镜像/接管
- WFOC 起，能用企业微信成熟能力的 HR/考勤员工日常审批优先使用企业微信；OA 做按域镜像、人工接管、恢复回写、财务闭环和审计中台。
- DBWFOC 后固定数据边界：企业微信成熟功能可作为流程、字段、交互和规则参考，但不默认成为高敏业务数据托管处。
- 报销、采购、费用、合同、项目、财务付款、AP 台账、代账交接、审计和敏感附件仍由 OA 主办，在 OA 内提交、审批、留痕、归档。
- 请假、补卡、外出、加班等 HR/考勤员工日常审批优先在企业微信原生审批中提交和处理，OA 同步按域镜像；企业微信不可用时由管理员人工开启 OA 应急模式。
- 企业微信作为手机工作台入口、免登/绑定、通讯录身份、消息通知、打卡、人事助手和 HR/考勤员工日常审批主操作端；OA 主办审批通过企业微信个人应用消息发送脱敏提醒并 deeplink 回 OA 处理。
- 采购单附件、合同正文、报价、供应商资料、发票、银行回单和代账资料不上传到企业微信原生审批或企业微信附件。
- 简写口径：采购不进企微原生审批，合同不进企微原生审批，附件不进企微附件；企微只做提醒、入口和免登录回 OA。
- WAPI/WRRA/WOUA-FIX 后固定“运行优先 + 差异收口先行”：近期先用入口、免登/绑定、脱敏消息、deeplink、通讯录 userid 清单、人事助手花名册读取和打卡读取；WOUA-FIX 已清零 OA active 缺企微测试账号差异，但
PASS_WITH_FINDINGS剩余缺字段和归档绑定不直接放行深度镜像。WMSG1 已证明企业微信应用消息和 Deeplink 可用；WAPC1 只固化审批配置准备清单，不代表审批镜像或真实回调已实现。
P0-2 企业微信打卡与 OA 考勤口径
- 企业微信打卡用于原始采集，保留其定位、人脸、Wi-Fi、规则与设备能力。
- OA 后续同步企业微信打卡规则、排班、记录、日报、月报和 HR/考勤审批镜像，形成正式考勤口径。
- 请假、补卡、外出、加班等考勤修正正常在企业微信完成；OA 只在应急模式下接管，并在企微恢复后 dry-run 和自动回写。
wecom_hr_master_sync_v1已本地实现并部署公网完成受控验证；最终保持force_off。WOUA-FIX 已按用户确认软归档 7 个缺企微测试账号，复检 OA active 5、企微 active 5、匹配 5、OA active 缺企微 0；剩余企微缺字段先接受不补，归档绑定保留审计。WCBK1 已完成审批回调 URL 验证和一条真实测试审批事件确认。后续考勤/审批镜像、应急接管、恢复回写或 RuleOps 仍必须先完成 WACP3 和 WADM1，再另建wecom_attendance_approval_mirror_v1（承接旧口径wecom_native_approval_mirror_v1）、oa_hr_emergency_mode_v1、wecom_recovery_writeback_v1或wecom_ruleops_v1合同。
P0-3 按域镜像定义
- 企微主办域镜像到 OA：通讯录/人事助手、打卡、请假、补卡、外出、加班、假期余额和 HR/考勤规则。
- OA 主办域不反向全量镜像到企微：报销、采购、费用、合同、项目、付款批次、AP、代账交接和审计只发送脱敏消息、状态和 OA 链接。
- “无痛接管”长期目标只针对必要业务连续性，不承诺把所有 OA 高敏附件和财务资料复制到企业微信。
P0-4 WFDG 设计门禁
- WFDG 后，后续企微/OA 改造必须先按业务域判定主办方、主事实源、操作端、镜像方向、附件归属和审计责任，再拆实现合同。
- PC 和移动页面需要区分三种状态：
OA 主办、企微镜像、OA 应急接管；不得把企微镜像页面误做成员工日常新建入口。 - 企业微信同步、镜像和回写必须具备幂等、重试、脱敏日志、审计记录和
SKIP/BLOCKED_BY_EXTERNAL_CONFIG状态；缺 Secret、权限、模板或可信 IP 时不得伪造成成功。 - 企微能力不清楚时先读 企微 API 能力目录，输出
CAN_REUSE_NOW、NEEDS_CONFIG、NEEDS_API_POC、KEEP_OA_PRIMARY、NOT_SUPPORTED_BY_API能力矩阵，再进入正式开发。
P0-5 WDRG 开发路线图门禁
- WDRG 后采用“路线图门禁 + 单功能 Issue CSV”：路线图只控制阶段顺序、准入/退出门禁、并行规则和禁止跳阶段，具体功能仍单独方案、单独 Issue CSV、单独验证。
- 当前企微优先 HR/考勤路线顺序固定为：
WECOM-CAPABILITY-POC-V1->wecom_hr_master_sync_v1->runtime_first_wecom_enablement->WOUA-FIX / WECOM-RUNTIME-READY-V1->WAPC1 审批配置准备->WAPC2 请假/补卡只读 POC->WAPC2F 自动生成 POC 样件->WAPC2 自动复跑->WCBK1 回调只读 POC（真实事件已确认）->WACP3 补偿拉取 POC->WADM1 镜像数据模型设计->wecom_attendance_approval_mirror_v1->oa_hr_emergency_mode_v1->wecom_recovery_writeback_v1->wecom_ruleops_v1。 WECOM-CAPABILITY-POC-V1已由 WCPC 收口，WHMS/WHMSLIVE 已完成 HR 主数据镜像实现和受控公网验证，WOUA-FIX 已完成测试账号差异收口；WRV1/WRA1/WMSG1 固定运行入口、OAuth/绑定、脱敏消息、Deeplink、通讯录、人事助手和打卡只读门禁。后续不得跳过 WAPC2F 自动样件、真实回调 POC、补偿拉取 POC 和镜像数据模型设计，直接开发考勤/审批镜像、OA 应急接管、恢复回写或 RuleOps 正式写入。- 线上缺陷、正式使用阻断、真实反馈扫尾和 QA-only 脚本维护可以另开合同并行；采购、合同、报销、付款、AP、代账和高敏附件继续 OA 主办，不混入企微 HR/考勤路线。
- 路线图事实源为 企微优先开发路线图；该路线图不代表任何运行时迁移能力已完成。
- API 和 Secret 事实源为 企微 API 能力目录：通讯录用
WECOM_CONTACT_SECRET；人事助手、打卡、消息和 OAuth 默认用WECOM_AGENT_SECRET；不得在运行时代码里轮询多个 Secret 试错。
P0-6 WCP1 企业微信能力 POC 结论
- WCP1 已完成 QA-only 只读 POC，历史结论为
PAUSE_FOR_CONFIG；该阻断已由 WCPC 复跑收口。 - 已可复用：工作台应用 token、核心配置、HCLT 通讯录 create/update/disable 证据、通讯录部门读取、人事助手字段配置读取；WCPC 又确认既有在职测试号的通讯录成员读取、人事助手花名册读取、打卡短窗口记录/规则读取和假期余额读取可用。
- WCP1 初始缺口已留痕：通讯录测试成员读取
wecom_errcode_48009、人事助手测试员工读取wecom_errcode_60021、打卡同步开关、审批模板 ID、测试审批单号、假期权限wecom_errcode_301062、回调 URL/Token/AESKey。WAPC2FLIVE 已解决请假/补卡 OA-POC 模板和低风险测试审批单样例；WCBK1 已解决请假/补卡范围内的真实回调 URL 与事件确认。当前仍未补齐的是补偿拉取、镜像数据模型、外出/加班样例或处理决策，以及 HR 写接口 POC。 - WCP1 报告继续作为初始配置缺口证据保留，当前 HR 主数据镜像准入以 WCPC 结论为准。
P0-7 WCPC 配置复跑口径
- WCPC 只做企业微信后台配置收口和只读 POC 复跑，不改业务代码、不部署、不持久写服务器
.env。 - 已按用户要求自动查找并使用既有在职低风险测试号
SMOKE002/测试员工复跑；报告和文档只记录脱敏企业微信 userid 前缀oa_smoke***，不得使用已离职/禁用的HRWDTEST-20260517214548作为主测试号。 - 复跑报告为远端
/tmp/wecom-capability-poc-wcpc-smoke002/summary.json，结论GO_TO_HR_MASTER_SYNC，nextStageAllowed=true，blockingCapabilities=[]。 - WCPC 已由 WHMS 承接；请假/补卡审批模板 ID、测试审批单号
sp_no和真实回调已由 WAPC2FLIVE/WCBK1 验证；补偿拉取、镜像数据模型、外出/加班样例和 HR 写接口仍需后续独立合同处理。WAPC1/WAPC2 已固定配置准备和只读 POC，但不得据此直接跳到考勤/审批镜像、OA 应急接管、恢复回写或 RuleOps。
P0-8 WHMS 企微 HR 主数据镜像口径
- WHMS 已本地实现并部署验证
wecom_hr_master_sync_v1，默认和最终均为force_off，未执行生产真实员工批量 apply。 - 企微/人事助手作为 HR 主数据源；OA 同步员工档案、部门、主管、职位、手机号、邮箱、默认角色、企业微信绑定和审计。
- dry-run 只生成差异和同步记录，不写员工主数据；apply 需要管理员确认，生产真实员工批量 apply 需单独批准。
- 缺姓名、手机号、邮箱或部门时记录
missing_required_field并跳过，不生成占位数据；企微不在职状态记录needs_offboarding_confirmation，不自动禁用 OA 账号。 - WHMSLIVE 公网验证中，
SMOKE002/测试员工（脱敏oa_smoke***）因企微侧缺手机号、邮箱和部门按missing_required_field跳过，证明缺字段不会写入占位数据；普通员工访问同步 API 已验证为 403。 - 已有 OA 员工只更新安全主数据字段，不覆盖银行账户、身份证、工资、合同附件或历史审批。
- WAPI 后 WHMS/WOUA 读取策略修正为通讯录
user/list_id+ 可选成员详情 + 人事助手get_staff_info，通讯录用WECOM_CONTACT_SECRET，人事助手用WECOM_AGENT_SECRET，不再靠 fallback 试错。 - WHMS/WOUA-FIX 不代表考勤/审批镜像、OA 应急接管、恢复回写或 RuleOps 已完成；WRA1 后 WRV1 的
PASS_WITH_CONFIG_GAPS只代表运行优先主链路可用且曾有审批/回调配置缺口；WMSG1 只证明消息和 Deeplink 可用；WAPC1 只证明审批配置准备清单已固化；WAPC2 只证明只读 runner 已具备；WAPC2FLIVE 只证明 OA-POC 样件可创建并可读；WCBK1 已证明真实回调 URL 验证、验签/解密和一条现有 OA-POC 测试审批单事件脱敏留证。后续先做 WACP3 补偿拉取 POC 和 WADM1 镜像数据模型设计，不直接另建wecom_attendance_approval_mirror_v1。
请假模块
L-1 团队日历可见性
HR / Admin（具备leave.view_all+leave.manage）：看全员部门经理（具备leave.view_all，仅限本部门）：看本部门- 普通员工：不可见团队日历 Tab
实现要点：前端 canViewAll 判断需区分"HR 全员视图"和"经理部门视图"，查询时经理视图需传 departmentId 过滤。
L-2 草稿与已驳回请假的编辑
draft和rejected状态的请假支持原单编辑后再提交- 不要求"撤回再新建"；直接在已有单据上修改字段后重新 submit
- 实现时需要
leave.edit_own（或直接在现有权限下放开）并在 submit 路由内允许此两种状态
L-3 审批中请假的撤回
- 申请人可主动撤回
reviewing状态的请假，撤回后状态回draft approved后不允许直接撤回，需走销假/更正流程（后续另立需求）- 当前状态：撤回已实现，此条为确认口径，无需改代码
L-4 leave.approve vs leave.manage
leave.approve：仅表示"处理分配给自己的审批任务"，不赋予查看全量的权利leave.manage：HR/行政运营权限，包括查看全量、人工纠偏/取消、余额与规则维护leave.manage不允许静默改写历史申请内容（需留审计痕迹）
审批流 / 工作流
W-1 无直接经理时的阻断规则
- 正式员工必须配置直属主管；缺直属主管属于组织主数据错误。
- 缺直属主管、主管停用、主管链断裂或审批节点解析为申请人本人时，提交必须阻断并提示"未配置可审批人"或"当前审批规则未找到审批人"。
- 只有审批规则显式配置老板/总经理或兜底审批节点，且目标不是申请人本人时，才进入
CEO或其他非本人兜底审批人。 - 不自动通过，不静默跳过，不用无条件升级
CEO掩盖组织配置问题。 - 当前正式运行口径：
majianyong是员工可见直属主管；wangshunli是ceo + admin，不配置为普通manager；admin不代表业务审批权。
W-2 转审适用范围
- 产品目标：转审是通用审批能力，目标覆盖报销、请假、采购、差旅。
- 条件：只能转给具备对应单据审批权限的人，且不得绕过必经老板、财务或 HR/行政节点。
- 当前实现状态：转审路由仍使用
expense.transfer前置权限，approvalTransfer专门留痕仍以报销为主；跨域转审扩展不作为当前 R7 硬门禁。 - 后续若要覆盖请假、采购或差旅，拆
W2Ffollow-up，先评审权限、状态机、转审链路、通知和历史留痕。
W-3 转审次数上限
- 上限保留 3 次，超过后拒绝继续转审
- 超限后不自动转给固定角色；要求当前审批人自行处理或由管理员走代理机制
W-4 并行会签
- 当前阶段不做并行会签
- 大额采购等双签场景，优先做串行多节点（两步顺序审批），不引入并行会签模型
通知渠道
N-1 三渠道联动策略
- 产品目标：审批类高优先级事件可支持站内通知 + 企业微信个人应用消息 + 邮件。
- 当前 R7 验收口径：以站内通知 + 企业微信个人应用消息和 deeplink 为主；邮件通道是否进入验收另拆 Issue。
- 当前不做用户级"关某渠道"配置
- 后续通知量上来后再做订阅偏好管理
Portal 首页
P-1 经理视图判断逻辑
- 当前状态：Portal 经理/角色能力已通过
buildRoleCapabilities类逻辑按角色和权限承载。 - 口径：有任一审批权限（
*.approve）或域管理权限（*.manage非view_all）的用户进入经理视图 - 后续可选择提取
isManagerRole(permissions)共享工具减少重复，但这不是当前 R7 阻断项。
权限模型
R-1 view_all vs manage 语义定义
view_all：对应域全量数据只读可见manage：域内管理与运营动作权限（如人工纠偏、配置维护、取消操作）manage不是approve的别名，也不等于"可任意改历史数据"
R-2 报销/费用金额分层审批
- 需按金额分层，但通过审批规则配置实现（工作流步骤条件），不通过拆
manager/ceo权限组实现 - 权限层面两个角色都保留
expense.approve，具体金额阈值在工作流定义里配置
R-3 资产转移权限
asset.transfer只给administration / 资产管理员finance_mgr有asset.manage但不拥有实物调拨权限，这是有意设计