759 行
82 KiB
Markdown
759 行
82 KiB
Markdown
# hyb-oa 管理员手册（10 人以下团队版）
|
||
|
||
**当前状态（2026-05-20 / WOPS1/WROAD2-CLOSEOUT/WROAD2-BIZ1/WAPPR1/WRULE1/WREAL1-PREP 后）**：R7E、PRELAUNCH、财务闭环、ATTV1、HR-WECOM-DIRECTORY-V1、WAPI、WOUA-FIX、WRV1/WRA1、WMSG1、WAPC1/WAPC2、WPROC1/WPROC2、WAPC2F dry-run、WAPC2FLIVE、WCBK1、WEGOV1、WACP3/WACP3R、WREAD1/WREAD1F、WADM1、WARCH1 和 WARCH2 均已收口到当前开发阶段；WROAD2+OPS 已完成测试账号受控上线 Day 0 巡检，报告 `/app/artifacts/qa-flow/wroad2-ops-20260520-041941/summary.json` 为 `PASS_WITH_FINDINGS`；SYSTEM-COMPLETE-GATE 结论为 `GO_TO_USE`。WAPI 后固定企微 API 能力目录和 Secret 矩阵：通讯录使用 `WECOM_CONTACT_SECRET`，人事助手/打卡/消息/OAuth/审批读取使用 `WECOM_AGENT_SECRET`，运行时代码不得靠多个 Secret 试错。WAPC2FLIVE 已创建 OA-POC 请假/补卡测试模板和低风险测试审批单，报告 `/app/artifacts/qa-flow/wecom-approval-fixtures-20260519T053400Z/summary.json` 为 `PASS_FIXTURE_CREATED`，自动复跑 WAPC2 为 `PASS_APPROVAL_POC`；测试模板和审批记录保留审计，不自动删除。WCBK1 已部署只读回调端点和 runner，远端完成回调 URL 验证并收到一条由 `SMOKE101` 同意现有 OA-POC 补卡测试单触发的真实审批状态事件，报告 `/app/artifacts/qa-flow/wecom-approval-callback-poc-20260519T092648Z/summary.json` 为 `PASS_CALLBACK_EVENT_CONFIRMED`。WACP3R 已新增自动发现模板 ID 路径并公网只读复跑，报告 `/app/artifacts/qa-flow/wecom-approval-compensation-poc-20260519T115944Z/summary.json` 为 `PASS_WITH_FINDINGS`；WREAD1F 新样例后，用户确认请假/补卡在企业微信消息卡片、列表和详情页均可看清，远端报告 `/app/artifacts/qa-flow/wecom-approval-readability-gate-20260519T133628Z/summary.json` 为 `PASS_READABLE`。WARCH1 已新增并部署请假/补卡最小审批历史留存：回调事件默认入 OA DB，补偿拉取可在 `--persist-to-db` + `WECOM_ARCHIVE_WRITE=1` 双开关下写 OA 留存，离线 runner 可不调用企微 API 读取已保存历史摘要；公网报告 `/app/artifacts/qa-flow/wecom-approval-compensation-poc-20260519T160306Z/summary.json` 和 `/app/artifacts/qa-flow/wecom-approval-archive-20260519T160330Z/summary.json` 均为 `PASS_WITH_FINDINGS`，2 条请假/补卡历史可离线读取，finding 是旧回调未入库历史 gap。WARCH2 已新增只读历史查询 API 和 PC/移动历史页：页面入口为“企微审批历史”，文案固定“企业微信主办，OA 自建留存”和“仅已归档记录”，只读 OA DB，不调用企微 API，不提供审批动作；权限按本人相关、直属下属和 HR/admin/* 分层，申请人未映射或 callback-only 记录仅 HR/admin/* 可见。WARCH3 已新增 07:30 systemd timer 巡检和脱敏企微告警；WOPS1 将默认告警收件员工号修正为 `HYD000006`，也就是管理员 `wangshunli` 的员工号，并把策略改为只在阻断、脚本失败、新增 finding 或状态恶化时发送，已知 observation 不重复告警。WCHECK1 已新增打卡规范化明细、日/月摘要和规则快照留存；WEXT1 已支持外出/加班 dry-run，但未 live 创建模板或审批单。WROAD2-BIZ1 固定三天内补充测试账号人工业务冒烟：`SMOKE002` 打卡、请假、补卡，`SMOKE101` 先看详情再审批，`HYD000006` 查看 OA 归档历史和打卡摘要；WAPPR1 固定审批规则门禁，申请人不得任意选择审批人，正式模板必须自动带出审批人，缺审批人或自审时阻断。WRULE1 新增只读审批链校验器：OA 按员工直属主管、指定审批角色和管理员兜底计算理论审批人，再与 OA 已归档的企微实际审批链对比；它不读取企微后台规则、不写企业微信、不替代 WAPPR1 人工 A/B/C/D 门禁。巡检只允许补偿归档和打卡摘要写 OA 留存库，不写企业微信、不扩大真实员工。WREAL1-PREP 只准备真实小范围试用清单，当前不启用真实员工；三天巡检、业务冒烟和审批规则门禁后先问答是否进入 WEXT1-FORMAL 正式模板外出/加班测试，四类测试号证据和 WAPPR1/WRULE1 通过后才问是否启动真实小范围试用。同意单击即通过风险已进入归档审计事实，后续正式历史页和操作规程继续突出动作来源与补偿一致性。采购、费用、合同、项目、报销、付款、AP、代账交接和高敏附件继续 OA 主办，企业微信只做脱敏提醒和 OA deeplink。公网 `payment_batch_v1=force_on`，`erp_sync=force_off`。公司当前无 ERP/独立财务系统，且 ERP 未来不接入 OA；财务闭环以 OA 内审批、台账、付款批次、银行对公付款回单和月度代账交接为准。
|
||
|
||
**WROUTE2/WREMOTE1 后续路线锁定**：继续先收口测试账号全域证据，不提前启用真实员工。WAPPR1 四类模板必须达到 A（审批人自动带出，申请人不能任意选择）后，下一步不再自动创建外出/加班 OA-POC 模板，而是先远端执行 WTCLOSE2 和 WFULLSMOKE2，再问答是否由 `SMOKE002` 在正式模板提交外出+加班测试单、`SMOKE101` 先看详情再审批。请假、补卡、外出、加班四类测试号证据通过后，WREAL1 首批固定为 1 名真实员工 + 1 名审批人/管理员观察；WREAL1 通过后优先规划 `wecom_attendance_approval_mirror_v1` 最小完整镜像，应急接管、恢复回写和 RuleOps 均后置。
|
||
**WTCLOSE1 小团队规则**：公司不到 10 人时，HR/考勤审批先按一层直属主管或指定审批角色自动带出审批人，申请人不能任意改人；主管链缺失、审批人不可见/停用/未绑定或命中自审时，管理员兜底或阻断。当前目标是请假、补卡、外出、加班四类模板均达到 A；本轮自动工作只到 WAUTO1/WFULLSMOKE1 汇总、WEXT1LD dry-run 和 WREMOTE1 远端收口，不创建企微样件。
|
||
**WAPPR1 2026-05-21 真机结论**：测试员工直属上级已设置为测试主管；请假、补卡、外出、加班提交页均自动带出测试主管，且申请人不能删除、改人或新增审批人，四类模板均按 A 记录。该结论仍需结合提交后的 WRULE1 实际审批链校验和三天业务冒烟证据，不单独放行真实员工试用。
|
||
**WRULE1 审批链校验**：管理员后台规则和真机提交页仍由 WAPPR1 人工确认；系统只能用已归档审批详情校验实际审批链。校验命令为 `npm run check:wecom-approval-rule-validator -- --template=<类型> --manual-gate=<类型>:A`，缺人工门禁时结论为 `PAUSED_MANUAL_CONFIRMATION`；自审、实际审批人不符或申请人可手选审批人均阻断 WEXT1-FORMAL、WREAL1 和最小镜像。
|
||
**WTCLOSE2/WTCLOSE2F 测试号最终收口**：企业微信 API 已限制只能由部署服务器可信 IP 访问，因此命令必须使用 `bash scripts/qa/run-wecom-test-account-final-closeout.sh --remote`。本地直接执行脚本会拒绝跑企微链路，只能用于 `bash -n`、合同和文档静态门禁；不得把本地缺 env/DB 的结果当作业务阻断。远端脚本复跑 WAUTO1、WFULLSMOKE1、外出/加班 dry-run 和 WRULE1，并汇总 WROAD2/WARCH3 既有报告；WFULLSMOKE1 在该脚本中关闭公网业务写流程，不新增 OA 测试业务数据；如子 runner 触发既有归档写库，只能走 WARCH3/WCHECK1 已批准的 OA 自建留存路径；脚本不写企业微信、不创建审批样件、不启用真实员工。
|
||
**WEXT1F 正式模板外出/加班证据脚本**：管理员或 QA 只在人工测试完成后执行 `WEXT1F_MANUAL_CONFIRMATION=SMOKE002_SUBMITTED_SMOKE101_REVIEWED bash scripts/qa/run-wecom-formal-outing-overtime-evidence.sh --remote`。人工步骤固定为：`SMOKE002` 在企业微信正式外出模板提交低风险测试单，确认审批人自动带出测试主管且不能改人；再在正式加班模板提交低风险测试单并做同样确认；`SMOKE101` 必须先打开详情页再同意或驳回，不能直接点快捷同意。缺少该人工确认标记时脚本只输出 `PAUSED_MANUAL_CONFIRMATION`，不跑企微 API。脚本从部署服务器可信 IP 读取企微审批 API，不创建模板、不自动提交审批、不写企业微信；补偿拉取必须同时按 `template_id` 和 `creator=SMOKE002` 过滤，避免读取同一正式模板下其他员工单据；仅在既有 `WECOM_ARCHIVE_WRITE=1` + `--persist-to-db` 双开关下把拉到的外出/加班详情写入 OA 自建留存，然后做离线归档读取和 WRULE1 审批链校验。
|
||
**OAOPS1 小团队真实使用稳定化**：企微打卡、补卡、外出、请假先冻结在当前完成态，日常继续由企业微信主办，OA 做留存、审计和后续兜底。当前主线回到 OA 主办域，按 7 天小团队全员真实使用稳定化执行；允许公网 OA 录入真实报销、采购/费用、合同台账、项目、付款批次和银行回单等业务数据，数据按审计保留不自动清理。新增 `scripts/qa/run-oa-real-use-daily.sh` 作为每日只读巡检；真实业务写入只由人工在公网 OA 内完成。图片 OCR、复杂 BPM、预算、ERP、银行流水导入、真实支付直连、企微 HR 深镜像、应急接管、恢复回写和 RuleOps 继续冻结。
|
||
**OSMOKE1 OA-only smoke 账号治理**：企业微信账号数量有限时，不再为了 OA 报销、资产、财务、AP、合同或权限回归额外申请企业微信账号。企微测试账号只服务 HR/考勤链路；公网 OA 自动化使用 OA-only smoke 账号，允许不绑定企微，但必须在 OA 内保持 active、角色正确且可登录。企微/OA 一致性审计会把私有 env 中列出、显式员工号 allowlist 命中，或符合 `SMOKE*`/`smoke-*`/`oa-smoke-*`/测试命名的 OA-only smoke 账号归为 `oaOnlySmokeExempted`，不再当作“缺企微账号”归档；真实员工不得用该命名绕过一致性治理。恢复账号必须先 dry-run，真实修复必须 `--apply` 且设置 `OA_ONLY_SMOKE_REPAIR_APPLY=1`，不得重置密码、不得打印凭据、不得影响真实员工。
|
||
**OALAUNCH1 最终启用门禁**：ASSET1D 已完成资产台账公网部署、最小 UI 试录和 3 条脱敏 `EA-DOC` 受控导入；OAOPS1 自动巡检已具备公网只读证据，但正式启用前仍必须补齐真实业务闭环、权限矩阵、备份恢复演练、数据治理培训和 Day 7 Go/No-Go。新增 `scripts/qa/run-oa-final-launch-readiness.sh` 只聚合证据并输出 `PASS_OA_LAUNCH_READY`、`PASS_WITH_FINDINGS`、`PAUSED_MANUAL_CONFIRMATION` 或 `SKIP/BLOCKED_BY_EXTERNAL_CONFIG`；脚本不创建业务数据、不执行付款、不写企业微信、不做数据库恢复。未达到 `PASS_OA_LAUNCH_READY` 前，只能视为小团队稳定化收口中，不能宣布最终正式启用完成。
|
||
**OPOLICY1 制度与 OA 对齐口径**：公司制度包已裁剪为“小团队 V1”执行口径，原则是先做到能执行、能留痕、能追责。制度参数、资料留存、用印台账、审批异常 SOP、制度签收和 P2 冻结边界进入 OALAUNCH1 数据治理门禁；预算硬控、复杂招采、电子签章、完整电子档案系统、ERP/银行深集成和 AI 自动改规则不作为正式启用前置条件。
|
||
**OAFLOW1 负责人本人报销兜底审批**：当前业务负责人是 `majianyong`（`ceo`），不配置直属主管且不允许自审；`wangshunli` 仅承担系统开发和系统管理，不是业务审批人。`07-28-ceo-finance-fallback` 已部署并原子回填生产 3 条启用规则：三档负责人本人 fallback 均为 `finance`，CEO 三档只读解析均为唯一 active 非本人 `finance`；普通员工链保持小/中额 `manager -> finance`、大额 `manager -> ceo -> finance`。不得用 `admin` 代批，也不得把系统管理员配置成假直属主管。
|
||
|
||
## 1. 适用范围
|
||
- 适用于 `small_team_internal` 工作区模式。
|
||
- 适用于单公司、少部门、全员账号密码登录的小团队。
|
||
- 目标是把财务、报销、采购、合同、项目、审计、镜像和接管能力收口到 `hyb-oa`；企业微信优先承担通讯录、人事助手、打卡、HR/考勤员工日常审批和移动入口。
|
||
|
||
## 2. 管理员每周固定动作
|
||
- 周一：查看 `审批待办`、报销/OCR 异常、企微 HR/考勤审批镜像、项目风险和本周关键付款/归档事项。
|
||
- 周中：处理报销退回、重复发票例外、企业微信绑定异常、人员权限和审批规则缺口。
|
||
- 周五：复核未完成审批、未付款报销、待归档合同/附件、采购/费用申请和下周请假安排。
|
||
|
||
## 3. 首次上线最小配置
|
||
1. 进入 `工作区设置`，确认产品模式为 `small_team_internal`。
|
||
2. 首批主路径优先保留：`Portal`、`审批待办`、`报销`、`票据/OCR`、`项目`、`采购/费用`、`合同/附件`、企微 HR/考勤镜像和 OA 应急接管状态。请假、补卡、外出、加班的正常提交入口后续迁往企业微信。
|
||
3. `团队状态`、`周报`、`待办`、`公告`、`人员`、`资产` 可按真实试运行需要开启；`付款` 和 `应付账款` 已作为财务闭环正式能力面向出纳、财务和管理员开放，普通员工不显示该入口；`预算`、`AI`、完整差旅能力仍作为备用或历史能力，ERP 不再规划接入。
|
||
4. 在 `用户管理` 中按推荐预设配置：老板 / 管理员 / 主管 / 员工。
|
||
- 正式审批组织口径：`majianyong` 配置为公司负责人 `ceo` 且不配置直属主管；`wangshunli` 仅配置系统开发/系统管理职责，不配置 `manager`、`ceo`、`finance` 或 `finance_mgr` 业务角色。
|
||
- 普通员工配置有效直属主管；当前唯一 active `manager` 的直属主管配置为 `majianyong`。不得把 `wangshunli` 放入正常业务汇报或审批链。
|
||
- `admin` 只代表系统管理权限，不代表业务审批权；需要业务审批时必须配置 `manager`、`ceo`、`finance`、`hr` 等正式业务角色。
|
||
- 缺直属主管、主管停用、主管链断裂或审批节点解析到申请人本人时，应先修正组织或审批规则，不要用管理员账号代批。CEO 本人报销只允许通过当前已部署的审批规则进入 active 非本人 `finance` 审批；无可用持有人或命中自审时继续阻断。
|
||
5. 检查功能开关：
|
||
- 建议开启：`portal_home_v1`、企业微信入口相关开关、报销/OCR、审批待办、请假、项目基础能力和 `payment_batch_v1`。
|
||
- 按需开启：`announcements_v1`、`presence_board_v1`、`weekly_report_v1`、`employee_lifecycle_v1`、`hr_wecom_directory_sync_v1`、`todo_board_v1`、`global_search_v1`。
|
||
- 已实现并部署验证：`wecom_hr_master_sync_v1`，默认和最终 `force_off`；启用和生产 apply 需单独确认。
|
||
- QA-only 运行门禁：`npm run check:wecom-runtime-ready -- --live --format=json`；默认不发送真实消息，低风险消息验证必须额外设置 `WECOM_RUNTIME_TEST_SEND=1` 并传 `--send-test-message`。
|
||
- 后续按独立合同评估：`wecom_attendance_approval_mirror_v1`（承接旧口径 `wecom_native_approval_mirror_v1`）、`oa_hr_emergency_mode_v1`、`wecom_recovery_writeback_v1`、`wecom_ruleops_v1`。
|
||
- 建议保留备用：`cutover_console_v1`、预算、AI 和完整差旅相关开关；`erp_sync` 保持关闭且不再作为后续接入目标。
|
||
|
||
### 3.1 ORG8 组织账号与角色边界
|
||
|
||
WFOC 后，企微/人事助手是员工主数据源，OA 是员工镜像、账号权限、财务业务、接管状态和审计事实源。管理员维护组织账号时，先确认企微通讯录、人事助手和员工绑定状态，再检查 OA 员工镜像、角色、账号状态和应急接管配置。
|
||
|
||
最小必填主数据：
|
||
|
||
| 字段 | 用途 | 缺失影响 |
|
||
| --- | --- | --- |
|
||
| 员工账号和姓名 | 登录、单据归属、审批历史 | 无法稳定追踪责任人 |
|
||
| 部门和职位 | 列表筛选、组织展示、权限判断辅助 | 财务和负责人扫读困难 |
|
||
| 直属主管 | 请假、报销、采购等默认审批链 | 审批人缺失或错误回退 |
|
||
| 账号状态 | 登录、入口、通知和禁用拦截 | 离职或停用人员可能继续进入 |
|
||
| 业务角色 | 审批、财务、HR、系统管理入口 | 权限过大或无法处理待办 |
|
||
| 企业微信通讯录/绑定状态 | 手机入口、免登、通知 deeplink、打卡采集身份 | 企业微信入口无法直达、误绑定或离职后未禁用 |
|
||
|
||
角色边界：
|
||
|
||
| 角色 | 允许能力 | 禁止或高风险边界 |
|
||
| --- | --- | --- |
|
||
| 员工 | 提交本人报销、请假、采购，查看本人单据和通知 | 不得查看他人财务、审批待办或管理员入口 |
|
||
| 直属主管 / 审批人 | 处理分配给自己的审批待办，查看必要的单据摘要和历史 | 不得处理未分配给自己或超出角色范围的待办 |
|
||
| 财务 | 复核报销、处理付款标记、导出授权范围内财务数据 | 不默认拥有系统管理权限，不处理非财务系统配置 |
|
||
| 管理员 / HR | 维护员工、部门、角色、主管链、入口配置和绑定异常 | `admin` 不等于业务审批人，不应用管理员账号代批 |
|
||
| 系统管理员 | 维护部署、备份、配置、日志和企业微信应用密钥 | 不处理业务审批，不查看无关财务明细 |
|
||
| 老板 / 负责人 | 处理高风险或大额审批，查看授权管理摘要 | 不替代员工直属主管的日常组织配置 |
|
||
|
||
不兼容或需确认的组合：
|
||
|
||
- `admin-only` 账号不得作为报销、请假或采购的业务审批人。
|
||
- 财务和系统管理员混授属于高风险组合，必须有人工确认、审计记录和可回退路径。
|
||
- 直属主管、审批人或财务账号停用后，不得继续接收新待办；历史审批记录保留只读。
|
||
- 新员工账号创建必须同时确认直属主管、初始角色、账号状态、企业微信通讯录同步状态和绑定路径。
|
||
- 离职或停用账号必须阻断登录、企业微信入口和新业务处理；离职完成后默认禁用企业微信成员，不删除成员，不删除历史单据和审批记录。
|
||
|
||
只读审计口径：
|
||
|
||
所有 ORG8 主数据审计只允许使用只读账号执行 `SELECT`，输出仅保留工号、姓名、状态、角色摘要、业务类型和数量；不得导出手机号、邮箱、银行卡、身份证号、密码哈希、token 或企业微信真实标识。发现问题后只记录摘要和责任归属，不在审计 SQL 中修数据。
|
||
|
||
直属主管缺失：
|
||
|
||
```sql
|
||
WITH role_summary AS (
|
||
SELECT employee_id, string_agg(role_code::text, ',' ORDER BY role_code::text) AS roles
|
||
FROM employee_roles
|
||
GROUP BY employee_id
|
||
)
|
||
SELECT e.employee_no, e.name, e.status, COALESCE(r.roles, '') AS roles
|
||
FROM employees e
|
||
LEFT JOIN role_summary r ON r.employee_id = e.id
|
||
WHERE e.status = 'active'
|
||
AND e.direct_manager_id IS NULL
|
||
AND COALESCE(r.roles, '') !~ '(^|,)(ceo|admin)(,|$)'
|
||
ORDER BY e.employee_no;
|
||
```
|
||
|
||
主管停用或主管链断裂：
|
||
|
||
```sql
|
||
SELECT e.employee_no, e.name, m.employee_no AS manager_no, m.name AS manager_name, m.status AS manager_status
|
||
FROM employees e
|
||
LEFT JOIN employees m ON m.id = e.direct_manager_id
|
||
WHERE e.status = 'active'
|
||
AND e.direct_manager_id IS NOT NULL
|
||
AND (m.id IS NULL OR m.status <> 'active' OR m.archived_at IS NOT NULL)
|
||
ORDER BY e.employee_no;
|
||
```
|
||
|
||
待办分配给停用审批人或无有效角色持有人：
|
||
|
||
```sql
|
||
SELECT t.id AS task_id, wi.entity_type, a.employee_no AS assignee_no, a.name AS assignee_name, a.status AS assignee_status
|
||
FROM workflow_tasks t
|
||
JOIN workflow_instances wi ON wi.id = t.instance_id
|
||
LEFT JOIN employees a ON a.id = t.assignee_id
|
||
WHERE t.status = 'pending'
|
||
AND t.assignee_id IS NOT NULL
|
||
AND (a.id IS NULL OR a.status <> 'active' OR a.archived_at IS NOT NULL)
|
||
ORDER BY t.created_at;
|
||
|
||
SELECT t.assignee_role, count(*) AS pending_count
|
||
FROM workflow_tasks t
|
||
WHERE t.status = 'pending'
|
||
AND t.assignee_role IS NOT NULL
|
||
AND NOT EXISTS (
|
||
SELECT 1
|
||
FROM employee_roles er
|
||
JOIN employees e ON e.id = er.employee_id
|
||
WHERE er.role_code = t.assignee_role
|
||
AND e.status = 'active'
|
||
AND e.archived_at IS NULL
|
||
)
|
||
GROUP BY t.assignee_role
|
||
ORDER BY t.assignee_role;
|
||
```
|
||
|
||
`admin-only` 误用为业务审批：
|
||
|
||
```sql
|
||
WITH role_summary AS (
|
||
SELECT employee_id, string_agg(role_code::text, ',' ORDER BY role_code::text) AS roles
|
||
FROM employee_roles
|
||
GROUP BY employee_id
|
||
)
|
||
SELECT t.id AS task_id, wi.entity_type, e.employee_no, e.name, r.roles
|
||
FROM workflow_tasks t
|
||
JOIN workflow_instances wi ON wi.id = t.instance_id
|
||
JOIN employees e ON e.id = t.assignee_id
|
||
JOIN role_summary r ON r.employee_id = e.id
|
||
WHERE t.status = 'pending'
|
||
AND r.roles ~ '(^|,)admin(,|$)'
|
||
AND r.roles !~ '(^|,)(manager|ceo|finance|finance_mgr|hr)(,|$)'
|
||
ORDER BY t.created_at;
|
||
|
||
SELECT id, name, level1_role, level2_role, level3_role, owner_self_fallback_role
|
||
FROM approval_rules
|
||
WHERE enabled = true
|
||
AND 'admin' IN (
|
||
level1_role::text,
|
||
COALESCE(level2_role::text, ''),
|
||
COALESCE(level3_role::text, ''),
|
||
COALESCE(owner_self_fallback_role::text, '')
|
||
)
|
||
ORDER BY priority;
|
||
```
|
||
|
||
负责人本人报销兜底检查：
|
||
|
||
```sql
|
||
SELECT name, level1_role, level2_role, level3_role, owner_self_fallback_role
|
||
FROM approval_rules
|
||
WHERE enabled = true
|
||
ORDER BY priority;
|
||
```
|
||
|
||
管理要求：
|
||
|
||
1. 当前代码允许 `owner_self_fallback_role = 'finance' | 'finance_mgr'` 或置空，新建规则默认 `finance`；生产 3 条启用规则已统一为 `finance` 收口。
|
||
2. 当前生产链为小/中额 `manager -> finance`、大额 `manager -> ceo -> finance`，三档 fallback 均为 `finance`；后续变更仍必须原子执行，任一生产前置漂移则零写入停止。
|
||
3. 不得为省事把 `admin` 当业务审批角色，也不得仅为绕过阻断给财务人员附加超出实际职责的权限；优先按最小权限调整支持角色和规则。
|
||
4. 提交后系统保存审批快照；之后修改规则只影响新单，不回写历史流程。
|
||
5. 生产回填先在部署后的 server 容器内执行 `npm run apply:ceo-finance-fallback -- --dry-run --format=json`；只有结果为 `DRY_RUN_PASS`，才设置一次性写入确认开关并执行同一命令的 `--apply`。脚本只输出状态和计数，任一规则、角色、binding 或受保护计数漂移都会回滚。
|
||
|
||
财务和系统管理员混授：
|
||
|
||
```sql
|
||
WITH role_summary AS (
|
||
SELECT employee_id, string_agg(role_code::text, ',' ORDER BY role_code::text) AS roles
|
||
FROM employee_roles
|
||
GROUP BY employee_id
|
||
)
|
||
SELECT e.employee_no, e.name, e.status, r.roles
|
||
FROM employees e
|
||
JOIN role_summary r ON r.employee_id = e.id
|
||
WHERE e.status = 'active'
|
||
AND r.roles ~ '(^|,)admin(,|$)'
|
||
AND r.roles ~ '(^|,)(finance|finance_mgr)(,|$)'
|
||
ORDER BY e.employee_no;
|
||
```
|
||
|
||
### 3.2 WFOC 企微优先与 OA 接管
|
||
|
||
正常运行时：
|
||
|
||
1. HR 先在企业微信通讯录或人事助手维护员工、部门、主管、职位、手机号、邮箱和在职状态。
|
||
2. OA 后续通过 `wecom_hr_master_sync_v1` 同步员工镜像，自动生成或更新 OA 员工档案、账号、角色、企业微信绑定和审计记录。
|
||
3. 员工请假、补卡、外出、加班优先在企业微信原生审批中提交和处理。
|
||
4. OA 后续先通过 WARCH1 保存企微审批、打卡和人事关键历史，再通过 `wecom_attendance_approval_mirror_v1` 增强审批详情、审批历史、附件、状态回调、打卡规则、排班、记录、日报、月报和异常摘要查询；该命名承接旧口径 `wecom_native_approval_mirror_v1`。
|
||
5. 报销、PDF OCR、付款批次、银行回单、AP 台账和代账交接仍在 OA 内完成，不迁移到企业微信。
|
||
6. 采购、费用、合同、项目、报销、付款、AP、代账交接和高敏附件继续 OA 主办；采购单附件、合同正文、报价、供应商资料、发票、银行回单和代账资料不进入企业微信原生审批或企业微信附件。
|
||
7. OA 主办审批仍可向企业微信个人应用发送脱敏消息；消息点击后通过免登录或账号绑定回到 OA 目标审批页，审批动作仍在 OA 完成。
|
||
|
||
WARCH1 后的管理员关注点：
|
||
|
||
1. WARCH1 已实现最小历史留存：先保存请假/补卡审批历史、回调事件、补偿拉取记录和必要员工映射，保证企微 API 不可用时仍可查看已保存历史摘要。
|
||
2. 回调 Token、EncodingAESKey、Secret 和 access token 只配置在部署环境，不写入文档、Issue、聊天或报告。
|
||
3. OA 数据库可保存完整 `sp_no`、`template_id` 和企微 userid 以便补偿和审计；对外报告、日志和导出默认脱敏。
|
||
4. 同意单击即通过是企业微信端交互特性，管理员应通过操作规程要求审批人先看详情再同意；OA 后续通过历史留存、审批轨迹和补偿对账提供追溯。
|
||
|
||
企微不可用时：
|
||
|
||
1. 管理员人工判断故障后开启 `oa_hr_emergency_mode_v1`，不得因短时 API 异常完全自动切换。
|
||
2. 开启时必须填写原因、影响范围、预计结束时间和责任人。
|
||
3. OA 临时开放请假、补卡、外出、加班提交和审批，所有单据带 `EMERGENCY` 标记。
|
||
4. 故障结束后关闭应急入口，执行恢复对账。
|
||
5. `wecom_recovery_writeback_v1` 先 dry-run，再对无冲突应急数据自动回写企微；冲突、权限不足、API 不支持或风险过高时进入人工确认。
|
||
|
||
RuleOps：
|
||
|
||
- `wecom_ruleops_v1` 允许 AI 草拟企微审批模板、打卡规则、排班、假期余额和人事字段配置建议。
|
||
- 正式写入前必须人工确认；每次写入保存前后快照、确认人、API `errcode`、失败原因、回滚建议和审计记录。
|
||
- 不得在报告、日志或截图中暴露 Secret、access token、完整位置、人脸数据、身份证号、完整手机号或原始密钥材料。
|
||
|
||
WCP1/WCPC/WHMS 后续推进：
|
||
|
||
1. 继续先读取 [企微优先开发路线图](./企微优先开发路线图.md) 和 WCP1 报告，再判断能否进入下一阶段。
|
||
2. WCP1 历史结论为 `PAUSE_FOR_CONFIG`；WCPC 已用既有在职测试号完成远端只读复跑，报告 `/tmp/wecom-capability-poc-wcpc-smoke002/summary.json`，结论 `GO_TO_HR_MASTER_SYNC`。
|
||
3. WCPC 已证明 HR 主数据镜像准入项可用：通讯录成员读取、人事助手花名册读取、打卡短窗口记录/规则读取和假期余额读取均达到可复用状态；审批模板、审批实例和回调配置仍是后续考勤/审批镜像前置项。
|
||
4. WHMS 已实现并部署验证 `wecom_hr_master_sync_v1`，包括同步批次、逐员工结果、dry-run/apply、People 管理入口和 QA-only runner；公网验证后最终保持 `force_off`。
|
||
5. 正式开发仍按 `wecom_hr_master_sync_v1` -> `runtime_first_wecom_enablement` -> `WOUA-FIX / WECOM-RUNTIME-READY-V1` -> `WAPC1 审批配置准备` -> `WAPC2 请假/补卡只读 POC` -> `WAPC2F 自动生成 POC 样件` -> `WAPC2FLIVE live 创建与 WAPC2 自动复跑` -> `WCBK1 回调只读 POC` -> `WEGOV1 企微主办治理与自建留存路线修正` -> `WACP3/WACP3R 补偿拉取 POC` -> `WREAD1 审批可读性与误审批防护门禁` -> `WADM1 自建留存/镜像数据模型设计` -> `WARCH1 最小自建历史留存实现` -> `WARCH2 正式只读历史查询` -> `WROAD2+OPS 受控上线与每日巡检` -> `WARCH3 归档稳定化自动巡检` -> `WCHECK1 打卡摘要留存` -> `WEXT1 外出/加班 dry-run` -> `WOPS1 巡检告警降噪` -> `WROAD2-CLOSEOUT 三天验收` -> `WROAD2-BIZ1 三天业务冒烟` -> `WAPPR1 审批规则规范化` -> `WRULE1 审批链校验器 POC` -> `WAUTO1 自动证据汇总` -> `WEXT1LD 外出/加班 live 前 dry-run` -> `WFULLSMOKE1 三天全域最终目标测试` -> `WROUTE2 测试号收口到最小镜像路线锁定` -> `WTCLOSE2 测试号最终收口与证据复核` -> `WTCLOSE2F 远端可信 IP 执行口径修正` -> `WREMOTE1/WFULLSMOKE2 远端收口` -> `WEXT1-FORMAL 正式模板外出/加班测试` -> `四类测试号证据和审批规则门禁通过后问答 WREAL1 小范围真实试用` -> `wecom_attendance_approval_mirror_v1` -> `oa_hr_emergency_mode_v1` -> `wecom_recovery_writeback_v1` -> `wecom_ruleops_v1` 分合同实施；WOUA-FIX 已收口测试账号差异和处理决策，WRV1/WRA1/WMSG1 已验证运行入口、OAuth/绑定、脱敏消息、Deeplink、通讯录、人事助手和打卡读取主链路。WAPC2FLIVE 已生成请假/补卡低风险样例，WCBK1 已证明真实审批回调 URL、验签/解密和事件脱敏留证，WACP3R 已证明请假/补卡补偿拉取和详情读取可用，WREAD1 已确认请假/补卡可读性，WADM1 已明确自建留存模型，WARCH1 已实现最小请假/补卡历史留存，WARCH2 已实现正式只读查询；后续仍不得跳过 WROAD2-CLOSEOUT、WROAD2-BIZ1、WAPPR1、WRULE1、WAUTO1/WEXT1LD/WFULLSMOKE1、WTCLOSE2/WREMOTE1、WEXT1-FORMAL、WREAL1 问答或明确批准，直接进入深度考勤/审批镜像。
|
||
- WROUTE2/WTCLOSE2/WREMOTE1 后尾部顺序修正为：`WFULLSMOKE1` -> `WROUTE2` -> `WTCLOSE2` -> `WTCLOSE2F` -> `WREMOTE1/WFULLSMOKE2` -> `WEXT1-FORMAL` -> `WREAL1（首批 1 名真实员工 + 1 名审批人/管理员观察）` -> `wecom_attendance_approval_mirror_v1 最小完整镜像`；应急接管、恢复回写和 RuleOps 仍排在最小镜像稳定之后。
|
||
6. 任何生产写接口、企微规则写入、应急模式开启或恢复回写都必须有单独批准、dry-run 或可审计记录。
|
||
|
||
WCPC 配置复跑清单：
|
||
|
||
1. 已完成：自动查找并指定已有在职测试号 `SMOKE002/测试员工`；未使用已离职/禁用的 `HRWDTEST-20260517214548` 作为主测试成员。
|
||
2. 已完成：服务器复跑采用临时环境变量和既有容器配置，不持久写入 `.env`，不重启服务；报告落到远端 `/tmp/wecom-capability-poc-wcpc-smoke002/summary.json`。
|
||
3. 已完成：复跑结论 `GO_TO_HR_MASTER_SYNC`，该准入已由 WHMS 承接并完成本地实现。
|
||
4. 后续考勤/审批镜像前仍需补齐：外出/加班样例、批量补偿拉取、镜像数据模型和 HR 写接口单独 POC；请假/补卡 OA-POC 回调真实事件已由 WCBK1 验证。
|
||
5. WAPC1 已固定首批审批配置准备范围：请假、补卡、外出、加班；每个模板需记录模板 ID、适用范围、字段项、审批人规则、可见范围和所属自建应用权限。
|
||
6. 测试审批单不得上传采购、合同、报销、发票、银行回单或其他敏感附件；Secret、Token、EncodingAESKey 不在聊天中明文发送。
|
||
|
||
WHMS 管理操作口径：
|
||
|
||
1. 当前 `wecom_hr_master_sync_v1` 已部署并完成受控公网验证，但最终默认保持 `force_off`；正式批量同步真实员工前必须另行批准。
|
||
2. 在 `人员管理` 的“企微 HR 主数据镜像”卡片先执行 `同步预检`；预检只生成差异和同步记录，不写员工主数据。
|
||
3. 确认差异后再执行 `确认写入`；生产真实员工批量 apply 必须另有批准，不在日常巡检中自动触发。
|
||
4. 缺姓名、手机号、邮箱或部门时系统跳过并记录 `missing_required_field`，管理员应先回企微/人事助手补齐，不在 OA 造占位数据。
|
||
5. 企微不在职或禁用状态只记录 `needs_offboarding_confirmation`，管理员按 OA 离职 checklist 处理，不由同步任务静默禁用账号。
|
||
6. 同步报告、日志和审计只看脱敏摘要；不得导出完整手机号、邮箱、userid、Secret、access token 或企微原始 payload。
|
||
7. `WHMSLIVE` 验证证据：`SMOKE002/测试员工`（脱敏 `oa_smoke***`）dry-run 和显式 userids apply 已在公网执行；因企微侧缺手机号、邮箱和部门按 `missing_required_field` 跳过，未写 OA 主数据；普通员工访问同步 API 返回 403。
|
||
|
||
WRV1 运行优先检查口径：
|
||
|
||
1. 管理员或 QA 在服务器容器内执行 `npm run check:wecom-runtime-ready -- --live --format=json`，报告写入 `artifacts/qa-flow/wecom-runtime-ready-<timestamp>/summary.json`。
|
||
2. 报告结论为 `PASS_RUNTIME_READY` 时，入口、OAuth、绑定、消息 dry-run、通讯录/人事助手/打卡只读链路和后续配置均可用。
|
||
3. 报告结论为 `PASS_WITH_CONFIG_GAPS` 时，运行优先主链路可用，但审批模板、测试 `sp_no`、回调、补偿拉取或镜像模型等后续项仍可能缺配置；这不允许直接开发考勤/审批镜像。
|
||
4. 报告结论为 `SKIP/BLOCKED_BY_EXTERNAL_CONFIG` 时，先检查对应 Secret、可信 IP、应用可见范围、授权、企微 API 权限或数据库只读能力，不能把 SKIP 记录为成功。WRA1 后，`WECOM_CHECKIN_SYNC_ENABLED` 仅控制正式考勤同步批次，不作为 QA-only 打卡只读探测的硬阻断。
|
||
5. 默认不发送真实企微消息；如需低风险消息验证，必须同时设置 `WECOM_RUNTIME_TEST_SEND=1` 并传 `--send-test-message`，消息内容仅含标题、类型、编号、状态和 OA deeplink。
|
||
|
||
WAPC1 审批配置准备清单：
|
||
|
||
1. 首批模板只准备 HR/考勤员工日常审批：请假、补卡、外出、加班。
|
||
2. 每个模板准备模板 ID、适用范围、字段项、审批人规则、可见范围和所属自建应用权限；暂不创建 OA 镜像表或真实回调接收端。
|
||
3. 测试审批单 `sp_no` 必须为低风险样例，不包含采购、合同、报销、发票、银行回单、高敏附件或真实敏感业务资料。
|
||
4. 回调配置只在部署环境保存真实值；文档、Issue 和聊天只写配置项名称，如 `WECOM_APPROVAL_CALLBACK_URL`、`WECOM_CALLBACK_TOKEN`、`WECOM_CALLBACK_ENCODING_AES_KEY`。
|
||
5. 后续进入 POC 前必须确认：模板详情读取、审批详情读取、回调 URL 验证、事件验签、解密、幂等键、重试语义和补偿拉取方案。
|
||
6. 批量获取审批单号只作为补偿拉取候选，先标记 `NEEDS_API_POC`。
|
||
|
||
WCBK1 回调只读 POC：
|
||
|
||
1. 当前公网 Callback URL 应配置为 `https://oa.hyinda.com/api/wecom/approval/callback`。
|
||
2. 部署环境变量只写名称，不在文档或聊天保存真实值：`WECOM_APPROVAL_CALLBACK_URL`、`WECOM_CALLBACK_TOKEN`、`WECOM_CALLBACK_ENCODING_AES_KEY`。
|
||
3. `npm run check:wecom-approval-callback-poc -- --live` 已在远端达到 `PASS_CALLBACK_URL_VERIFIED`，随后由 `SMOKE101` 在企业微信处理一条现有 OA-POC 补卡测试审批单，复跑达到 `PASS_CALLBACK_EVENT_CONFIRMED`。
|
||
4. 后续如更换回调 URL、Token 或 EncodingAESKey，必须先同步部署环境并重启 server，再在企微后台保存；不得把真实密钥写入仓库、文档或聊天。
|
||
5. 报告只保存事件类型、审批类型、状态摘要、脱敏 `sp_no`/模板前缀和幂等键摘要；不得截图、转存或粘贴 Token、EncodingAESKey、原始 XML、密文、完整 `sp_no`、完整 userid、表单值、附件或评论。
|
||
|
||
WEGOV1 自动化与人工边界：
|
||
|
||
1. 我可以自动完成：Trellis task、文档回写、runner、synthetic 测试、API 只读探测、回调验签/解密测试、补偿拉取测试、脱敏报告、受控部署、`/ready`、公网 runner 复跑、状态回填和中文提交。
|
||
2. 管理员或用户必须人工处理：企微后台无法 API 化配置、Secret/Token/EncodingAESKey 填入部署环境、可信 IP/可见范围调整、正式写入批准、真机收到消息/点击/审批可读性确认、是否启用正式批量同步或应急模式的风险拍板。
|
||
3. 企业微信自建应用没有完整隔离 sandbox 假设；后续测试默认使用真实企业内受控测试域：`SMOKE002 -> SMOKE101`、`OA-POC` 模板、低风险审批单和脱敏报告。
|
||
4. OA 后续保存企微关键历史和完整外部关联键；V1 目标是企微不可用时能查看历史，不是完整替代企微继续办理。
|
||
|
||
WAPC2 请假/补卡只读 POC 操作口径：
|
||
|
||
1. 优先用 WAPC2F runner 自动生成 OA-POC 请假/补卡测试模板和低风险测试审批单；当前 dry-run 已通过，真实创建模板/审批单前仍需管理员批准单次 live 创建。
|
||
2. WAPC2F 默认申请人为 `SMOKE002`，审批人为 `SMOKE101`；两者必须 active、已绑定企微、可见、不是同一 OA 员工、不是同一企微 userid。`SMOKE101` 不可用时不自动换人，先问答确认。
|
||
3. WAPC2F live 创建只能在单次命令同时包含 `--live --create-templates --submit-test-approvals` 且设置 `WECOM_APPROVAL_FIXTURE_WRITE=1` 时执行；默认 dry-run 不获取写入 token、不在企微后台留下 OA-POC 记录。WAPC2FLIVE 已执行一次批准的 live 创建，后续不得重复创建样件，除非另建 Trellis task 并再次批准。
|
||
4. 测试单 `sp_no` 不得包含采购、合同、报销、发票、银行回单、高敏附件或真实敏感业务资料。
|
||
5. QA 在服务器容器内执行 `npm run check:wecom-approval-poc -- --live --format=json`，并通过 CLI 或临时 env 传入请假/补卡模板 ID 和 `sp_no`。
|
||
6. 报告结论 `PASS_APPROVAL_POC` 只代表模板详情和审批详情只读链路可用；`PARTIAL_APPROVAL_POC_NEEDS_CONFIG` 代表缺模板 ID 或 `sp_no`；`SKIP/BLOCKED_BY_EXTERNAL_CONFIG` 代表 Secret、权限、可信 IP、可见范围或企微 API 阻断。
|
||
7. 报告只看脱敏模板 ID/`sp_no` 前缀、字段类型计数、审批节点计数和错误分类；不得截图或转存完整 `sp_no`、表单值、附件、评论、Secret、token 或原始 payload。
|
||
|
||
### 3.3 正式财务闭环与代账交接
|
||
|
||
公司当前没有 ERP 或独立财务系统，OA 不生成 ERP 实时凭证，也不接真实支付接口。正式财务闭环如下：
|
||
|
||
1. 员工在 OA 提交报销，发票/OCR 正式入口保持 PDF-only，图片只作为普通附件。
|
||
2. 直属主管、财务或负责人按审批规则在 OA 内完成审批。
|
||
3. `wangzhiling` 作为出纳，在付款批次中创建待付款批次，按批次准备对公银行付款。
|
||
4. 付款批次由非创建人且具备 `payment.batch.review` 与明确 `manager`/`ceo` 业务角色的人员复核；当前公司负责人为 `majianyong(ceo)`。`wangshunli` 的系统管理员身份不产生付款复核权。
|
||
5. 出纳在 OA 外通过网银或银行渠道付款，然后在付款批次详情上传银行回单附件，补齐凭证号、付款日期和付款渠道。
|
||
6. 出纳执行 OA 已付款标记；系统将报销单置为 `paid`，票据归档为 `archived`，AP 台账变为已付款状态。
|
||
|
||
银行渠道付款必须至少有一份银行回单附件后才能在 OA 内执行付款标记。回单附件支持 PDF、JPG、PNG、WEBP，作为批次级付款证据保存；导出和报告中不复制回单原件内容。
|
||
|
||
月度代账交接按以下清单执行：
|
||
|
||
| 资料 | 来源 | 负责人 | 说明 |
|
||
| --- | --- | --- | --- |
|
||
| 应付账款导出 | OA `应付账款` 的 `导出` | 出纳/财务 | 用于核对已付款、待付款和异常项；应付台账不是银行流水 |
|
||
| 报销导出 | OA 报销导出 | 出纳/财务 | 按月导出，必要时筛选已通过或已付款状态 |
|
||
| 票据中心导出 | OA 票据/OCR | 出纳/财务 | 用于核对 PDF 发票识别、绑定和归档状态 |
|
||
| 付款批次清单 | OA `付款` | 出纳/财务 | 记录批次、复核、执行和对应报销单 |
|
||
| 银行回单附件清单 | OA 付款批次详情 | 出纳 | 只交接清单和必要回单原件，不把真实回单提交到代码仓库 |
|
||
| 审计日志导出 | OA 审计日志 | 管理员 | 覆盖导出、付款批次创建、复核、回单上传和执行动作 |
|
||
| 银行流水和回单原件 | 网银或银行渠道 | 出纳 | 由出纳从银行侧导出，交给代账人工核对；不导入 OA |
|
||
|
||
交接建议：
|
||
|
||
- 每月固定一个交接目录或压缩包，由出纳线下维护，命名建议为 `YYYY-MM-海音达-代账交接`。
|
||
- OA 导出文件、银行流水、银行回单原件和异常说明分目录保存；仓库只记录流程和脱敏证据，不保存正式财务资料。
|
||
- 代账如发现金额、收款方、日期或票据状态不一致，先回查 OA 报销单、付款批次、银行回单和审计日志，再决定是否由出纳补充说明。
|
||
- 若代账方后续要求一键交接包，再另建开发合同，明确包内文件、权限、脱敏、审计和下载回滚规则。
|
||
|
||
### 3.4 首周正式使用运营
|
||
|
||
首周支持分工：
|
||
|
||
| 职责 | 负责人 | 处理范围 |
|
||
| --- | --- | --- |
|
||
| 上线拍板和回滚决策 | `wangshunli` | 判断继续、暂停、回滚或另建修复合同 |
|
||
| 系统管理 | `wangshunli` | 账号、配置、部署、权限配置和审计核查；不处理付款批次或正常业务审批 |
|
||
| 业务复核 | `majianyong` | 以 `ceo` 身份处理分配给本人的业务审批和付款批次复核；不得自审或复核本人创建的批次 |
|
||
| 出纳/付款执行 | `wangzhiling` | 银行对公付款、回单上传、付款标记和代账资料准备 |
|
||
| 问题登记 | `wangshunli` | 汇总问题、分级、每日收口和结论回写 |
|
||
|
||
首周每日巡检：
|
||
|
||
1. 访问 `https://oa.hyinda.com/ready`，确认公网健康。
|
||
2. 用管理员和普通员工各登录一次，确认 PC 和移动入口可达。
|
||
3. 抽查审批待办、报销/PDF OCR、请假、采购、通知和企业微信入口。
|
||
4. 抽查 `payment_batch_v1` 仍为开启、`erp_sync` 仍为关闭。
|
||
5. 出纳查看待付款、付款批次、银行回单附件和 AP 台账导出。
|
||
6. 管理员查看审计日志中是否有异常导出、权限拒绝或付款动作。
|
||
7. 记录当天新增问题、影响等级、处理人、结论和是否需要暂停。
|
||
|
||
自动异机备份运维口径：
|
||
|
||
1. 自动备份以 OA 仓库 runbook 首部“紧急恢复卡”为唯一短入口；公司当前只有一名系统管理员，由该管理员维护恢复卡，不另设知识库副本或虚构替补操作人。
|
||
2. 每日 02:30 生成数据库、附件、manifest 同批恢复点并推送 ARM；07:10 检查最近 24 小时异机成功状态，ARM 另以 26 小时 dead-man 独立检查归档。生产保留 7 个自动日批次，ARM 保留 7 个日批次和 4 个周检查点。
|
||
3. ARM 专用身份只能写 inbox 和请求 finalize，不能登录 shell、读取或删除 archive。任何人不得为了省事改用普通 ARM 登录账号或关闭 known-hosts 固定校验。
|
||
4. 自动备份使用独立企微运维群机器人，不依赖 OA server 或个人员工号。Webhook 只由用户写入两台主机的 root-only 文件，不进仓库、普通 `.env`、日志或聊天。企微只收脱敏异常、finding 和恢复通知；同一失败降噪。季度提醒只要求人工在 ARM 隔离目标恢复，不会自动恢复生产。
|
||
5. 群机器人、ARM dead-man、更新后的两端脚本、首次有效真实批次、全部 timer enable 和真实源端停止告警均已按阶段授权完成并回填当前 Trellis task；后续安装或配置变更仍为 **EXTERNAL_GATED**。真实验收必须停止一次源端 timer 或故意让一次传输失败，不能只测试机器人发送。
|
||
6. 每季度由唯一系统管理员按恢复卡在 ARM 隔离目标执行一次影子恢复，核对归档类别、三条恢复入口、`/ready` 和关键计数；未实际执行时，本季度恢复门禁不通过。
|
||
7. 卸载 timer 或 receiver 时保留历史 archive 和源端完整批次；账号、密钥、备份数据的删除必须另行批准。
|
||
8. 改动每日备份时刻后，人工确认次日 UTC 分桶和 26 小时窗口，避免把调整日的预期空窗误当成长期故障。
|
||
|
||
WROAD2/WARCH3 企微受控上线每日巡检：
|
||
|
||
1. 试用范围固定为测试账号 `SMOKE002 -> SMOKE101`，管理员观察和告警收件人为 `HYD000006`；`HYD000006` 是 `wangshunli` 的员工号，`wangshunli` 只作为姓名/账号别名记录。试用周期 3 天；WARCH3 可通过 `hyb-oa-warch3-ops.timer` 每天 07:30 自动触发。
|
||
2. 手动执行命令：`bash scripts/qa/run-warch3-ops-daily.sh`；原始 WROAD2 编排仍可用 `bash scripts/qa/run-wroad2-ops-daily.sh`。
|
||
3. systemd 安装/卸载：`bash deploy/trialrun/install-warch3-ops-timer.sh`；卸载用 `bash deploy/trialrun/install-warch3-ops-timer.sh uninstall`。
|
||
4. 巡检会复用公网 `/ready`、live smoke、feature flag、企微 runtime、审批补偿拉取和 OA 归档离线读取；默认不写企业微信。
|
||
5. 唯一允许写入的是审批补偿归档步骤：进程级 `WECOM_ARCHIVE_WRITE=1` 加 runner `--persist-to-db`，仅写 OA 自建留存库，用于补齐历史和对账证据。
|
||
6. 每日报告位于 `artifacts/qa-flow/warch3-ops-<timestamp>/summary.json` 或 `artifacts/qa-flow/wroad2-ops-<timestamp>/summary.json`；出现 Secret、权限、可信 IP、可见范围或外部配置问题时，先记录真实阻断，不扩大范围。
|
||
7. 告警命令为 `cd server && npm run send:wecom-ops-alert -- --summary-file=<summary.json> --send`，真实发送还需 `WARCH3_OPS_ALERT_SEND=1`；默认收件员工号为 `HYD000006`，消息只包含阶段、状态、finding 数、报告路径和下一步建议。
|
||
8. WOPS1 后告警使用状态文件 `artifacts/qa-flow/warch3-ops-alert-state.json` 记忆上次状态和 finding 摘要；已知 `PASS_WITH_FINDINGS` 或 observation 不重复发消息，只有 `SKIP/BLOCKED_BY_EXTERNAL_CONFIG`、脚本失败、新增 finding、状态恶化或人工 `--force` 才发送。
|
||
9. WCHECK1 打卡摘要命令：`cd server && npm run check:wecom-checkin-summary-archive -- --offline --format=json`；如要写 OA 留存，必须 `WECOM_CHECKIN_ARCHIVE_WRITE=1` 且带 `--live --persist-to-db`。
|
||
10. WEXT1 外出/加班 dry-run：`cd server && npm run check:wecom-approval-fixtures -- --format=json --target=outing --target=overtime`；WREMOTE1 后下一步不再自动 live 创建外出/加班 OA-POC 样件，而是另走 `WEXT1-FORMAL` 问答，由 `SMOKE002` 真机提交正式模板测试单，系统只读补偿、归档和审批链。
|
||
11. WROAD2-BIZ1 三天人工业务冒烟：`SMOKE002` 每天按企微规则尝试上/下班打卡，提交低风险请假和补卡；`SMOKE101` 每条审批必须先打开详情再同意或驳回；`HYD000006` 每天查看 OA 企微审批归档历史和打卡摘要。无法打卡、无法审批或仍需手动选择审批人时，按 finding 记录，不伪造成通过。
|
||
12. WAPPR1 审批规则规范化：测试模板固定 `SMOKE002 -> SMOKE101`；正式请假、补卡、外出、加班模板必须按一层直属主管或指定审批角色自动带出审批人。申请人不得任意选择审批人；审批人缺失、停用、未绑定、不可见、主管链断裂或自审时，必须由管理员兜底或阻断，不能直接进入真实试用。
|
||
13. WAPPR1 管理员后台检查位置：进入企业微信管理后台的审批应用或自建应用审批接口模板配置，打开请假、补卡、外出、加班对应模板的编辑页，检查“审批流程/规则”是否存在“申请人自选”节点，是否按直属主管、部门负责人或指定审批角色自动带出审批人，以及主管链缺失、自审、审批人停用或不可见时是否阻断或进入管理员兜底。
|
||
14. WAPPR1 真机确认方式：用 `SMOKE002` 进入对应模板提交页，不提交敏感内容，只观察审批人是否自动带出、是否可以任意改人；提交低风险样例后，由系统用 `getapprovaldetail` 校验实际审批链是否为 `SMOKE101` 且无自审。企业微信官方 API 不能只读读取后台审批规则本身，管理员手动设置后系统只能检查提交后的实际结果。
|
||
15. WAUTO1 自动证据汇总：`bash scripts/qa/collect-wecom-controlled-trial-evidence.sh`。该脚本只读汇总 `/ready`、WARCH3 summary、审批补偿只读、审批归档离线、打卡摘要 offline、外出/加班 dry-run 和隐私扫描；不会设置 `WECOM_ARCHIVE_WRITE=1`、`WECOM_CHECKIN_ARCHIVE_WRITE=1` 或 `WECOM_APPROVAL_FIXTURE_WRITE=1`，不写 OA DB、不写企业微信。
|
||
16. WFULLSMOKE2 全域最终目标测试：`WFULLSMOKE_ALLOW_PUBLIC_WRITES=1 bash scripts/qa/run-three-day-full-goal-smoke.sh --remote`。该脚本必须在部署服务器可信 IP 上执行，聚合企微 HR/考勤、OA 报销、采购、合同/项目、付款批次、移动/企微入口和运维巡检；若只想做只读汇总，可设置 `WFULLSMOKE_ALLOW_PUBLIC_WRITES=0`。默认只允许带 `TEST-SMOKE-WFULL` 标记的 OA 测试业务数据；不写企业微信、不创建外出/加班样件、不启用真实员工、不真实付款、不接真实支付、不写 ERP、不导入银行流水。
|
||
17. WAPPR1 人工确认清单按请假、补卡、外出、加班逐模板填写：模板入口、适用范围、审批人规则、是否允许申请人手选、是否可能自审、主管链缺失时表现、审批人不可见或停用时表现。每个模板只选一个结论：A 审批人自动带出且申请人不能任意选择；B 默认带出但申请人仍可改人；C 必须申请人手选审批人；D 当前看不到或模板未配置。B/C/D 均不得直接进入真实员工试用。
|
||
18. WEXT1LD live 前 dry-run：远端只执行 `npm run check:wecom-approval-fixtures -- --format=json --target=outing --target=overtime`；不要设置 `WECOM_APPROVAL_FIXTURE_WRITE=1`，不要带 `--live`、`--create-templates` 或 `--submit-test-approvals`。WREMOTE1 后续路线已改为 WEXT1-FORMAL：只在问答批准后，由 `SMOKE002` 真机提交正式模板外出/加班测试单，系统只读校验；不再自动创建外出/加班 OA-POC 样件。
|
||
19. WEXT1-FORMAL 已锁定为使用现有正式外出+加班模板人工提交，不自动创建 OA-POC 测试模板，不自动提交审批单。操作方式为 `SMOKE002` 真机提交正式模板外出/加班测试单，`SMOKE101` 先看详情再审批；系统随后在部署服务器只读复跑补偿拉取、OA 归档读取和 WRULE1，确认实际审批链与 OA 理论审批人一致。
|
||
20. Day 0 公网报告为 `/app/artifacts/qa-flow/wroad2-ops-20260520-041941/summary.json`，结论 `PASS_WITH_FINDINGS`：企微 runtime、补偿归档、离线归档读取和隐私扫描通过；finding 为缺 live smoke 登录凭据/pending OCR 子检查异常以及历史 callback gap，不阻断测试账号受控试用。
|
||
21. WROAD2-CLOSEOUT/WROAD2-BIZ1/WAPPR1/WRULE1/WAUTO1/WEXT1LD/WFULLSMOKE1/WTCLOSE2 结束后再做人工问答：进入 WEXT1-FORMAL 正式模板人工提交测试、先处理指定 finding、或暂停；未确认前不启用真实员工，不自动创建外出/加班样件。
|
||
22. WTCLOSE2 作为 WEXT1-FORMAL 前的最后自动收口：复跑命令必须是 `bash scripts/qa/run-wecom-test-account-final-closeout.sh --remote`，因为企微 API 只允许部署服务器可信 IP 访问；结论为 `PASS_TEST_ACCOUNT_CLOSEOUT_READY`、`PASS_WITH_FINDINGS`、`PAUSED_MANUAL_CONFIRMATION` 或 `SKIP/BLOCKED_BY_EXTERNAL_CONFIG`；它只进入问答，不自动提交审批。本地直接执行脚本只用于静态门禁，不得作为企微业务证据。
|
||
23. WREAL1-PREP/WROUTE2 当前只准备和锁定路线，不要求提供真实员工；后续真实试用必须等请假、补卡、外出、加班四类测试号证据、WAPPR1/WRULE1 审批规则门禁、WREMOTE1/WFULLSMOKE2 和 WEXT1-FORMAL 可解释通过后再问，首批固定为 1 名真实员工 + 1 名审批人/管理员观察。真实员工和审批人只通过 `/tmp/hyb-oa-wreal1.env` 临时文件提供，不写入仓库或聊天。
|
||
24. `wecom_attendance_approval_mirror_v1` 最小完整镜像必须等 WREAL1 通过后优先规划；应急接管、恢复写回、RuleOps、图片 OCR、复杂 BPM、预算、ERP 和银行流水导入继续冻结。
|
||
|
||
问题登记最小字段：
|
||
|
||
| 字段 | 说明 |
|
||
| --- | --- |
|
||
| 时间 | 发现时间，精确到日内即可 |
|
||
| 角色/账号 | 员工、审批人、财务、管理员或企业微信入口 |
|
||
| 页面/入口 | PC、移动、企业微信、付款批次、报销、审批等 |
|
||
| 复现步骤 | 只写必要步骤，不记录密码、token、银行回单原件或完整票面 |
|
||
| 影响等级 | 阻断、高、中、低 |
|
||
| 处理结论 | 已解释、已修复、待修复、暂停、另建 Issue |
|
||
|
||
暂停条件：
|
||
|
||
- 无法登录、无法进入企业微信工作台或公网 `/ready` 异常。
|
||
- 无法提交或审批报销、请假、采购任一主流程。
|
||
- 付款批次状态错误、回单附件丢失、AP 导出异常或审计缺失。
|
||
- 员工、审批人、出纳、管理员出现越权访问。
|
||
- `payment_batch_v1` 意外关闭，或 `erp_sync`、图片 OCR、真实支付、银行流水导入被误开启。
|
||
- 同一天出现多个高优先级问题且无法解释清楚。
|
||
|
||
首周不主动新增可选功能。UX8 只接真实反馈或自动化确定性失败；移动采购创建、通知扩展、合同/供应商/资产、图片 OCR、真实支付、银行流水导入、复杂 BPM、审批设计器和重预算都必须另建独立合同；ERP 不再作为后续合同候选。
|
||
|
||
### 3.5 OAOPS1 七天真实使用稳定化
|
||
|
||
OAOPS1 是当前 OA 主办域稳定化主线，周期 7 天，目标是让小团队把真实业务在 OA 中跑起来，而不是继续用测试单替代日常流程。
|
||
|
||
每日只读巡检：
|
||
|
||
```bash
|
||
bash scripts/qa/run-oa-real-use-daily.sh
|
||
```
|
||
|
||
巡检默认只读，输出 `artifacts/qa-flow/oa-real-use-daily-<timestamp>/summary.json`，覆盖公网健康、live smoke、功能开关、报销/PDF OCR、审批待办、采购/费用、合同台账、项目、付款批次、AP 台账、移动/企微入口和隐私扫描。若缺少 live smoke 凭据，按 finding 或 SKIP 记录，不伪造成通过。
|
||
|
||
每日人工业务动作：
|
||
|
||
| 角色 | 动作 | 注意事项 |
|
||
| --- | --- | --- |
|
||
| 员工 | 提交真实报销、PDF 发票、采购/费用申请，必要时关联项目或合同 | 图片发票仍作为普通附件；不要上传密码、密钥、完整银行流水或未脱敏敏感材料 |
|
||
| 审批人 | 从 OA 待办打开详情后审批 | 退回时写清补充材料，不用口头说明替代系统记录 |
|
||
| 出纳/财务 | 创建付款批次、线下银行付款、上传银行回单、标记已付款、导出 AP/报销/票据资料 | OA 只记录付款闭环和证据；不接真实支付接口，不写 ERP |
|
||
| 管理员 | 检查权限、审计日志、合同台账、项目关联和每日巡检报告 | 阻断当天建修复合同或暂停对应流程；非阻断体验问题进入反馈池 |
|
||
|
||
合同台账纳入首批真实使用：合同负责人可录入合同编号、合同名称、主体、金额、负责人、项目、状态和线下归档位置；非涉密盖章页、验收单、归档证明等可按权限上传并留下下载审计。涉密合同正文、敏感报价、成本细节、客户敏感资料不进入公网 OA；只记录线下归档位置或外部归档编号。
|
||
|
||
### 3.6 ASSET1 统一资产台账
|
||
|
||
ASSET1 后，资产模块统一承载固定资产和电子资产索引，不再另建两套资产系统。编号族如下：
|
||
|
||
| 编号 | 用途 |
|
||
| --- | --- |
|
||
| `FA-YYYY-NNNNNN` | 公司固定资产，例如电脑、设备、办公物品、备份硬盘实物 |
|
||
| `EA-DOC-YYYY-NNNNNN` | 电子资料资产，例如合同、发票、回单、证照、软著、项目资料索引 |
|
||
| `EA-SYS-YYYY-NNNNNN` | 电子系统资产，例如 OA、企业微信后台、服务器、数据库、域名、证书、云服务 |
|
||
| `EA-REPO-YYYY-NNNNNN` | 代码仓库资产，只登记仓库元数据，不托管源码 |
|
||
| `EA-BKP-YYYY-NNNNNN` | 备份介质或备份集合，例如移动硬盘、NAS、快照、数据库备份目录 |
|
||
| `VER-NNNNN` | 历史验证编号，只用于旧资料映射和查找 |
|
||
|
||
管理员登记资产时按以下规则处理：
|
||
|
||
1. 固定资产继续走领用、归还、调拨、盘点和移动扫码。
|
||
2. 电子资料只登记名称、类型、hash、敏感级别、负责人、归档位置摘要和关联项目/合同/付款摘要；涉密正文、真实完整路径、敏感报价、银行账户、身份证件、账号凭据不上传公网 OA。
|
||
3. 电子系统记录负责人、入口、到期日期、备份策略和权限回收要求；密码、token、Secret、证书私钥和完整配置不进 OA。
|
||
4. 代码仓库继续由 Git 管理源码和提交历史；OA 只登记仓库名称、用途、负责人、托管平台、可见级别、关联项目/系统、归档状态和备份策略。
|
||
5. 备份资产记录保管人、备份范围、加密状态和最近恢复验证日期；真实恢复演练仍需另建批准合同。
|
||
|
||
账号资产 `EA-ACC` V1 暂缓。离职交接时检查“此人是否持有关键系统权限”，不在 OA 维护每个普通账号资产卡，也不保存任何密码或密钥。
|
||
|
||
历史资料导入只允许从管理员指定的公司资料脱敏索引目录读取，默认 dry-run。公网写入需要 `ASSET_INDEX_IMPORT_WRITE=1` 和单独确认；报告不得输出 S3/S4 原文、完整路径、Secret、token、银行流水原件或未脱敏票面。
|
||
|
||
公司电子资料和 OA 协作按以下口径执行：
|
||
|
||
| 资料形态 | 主事实源 | OA 中允许 | OA 中禁止 |
|
||
| --- | --- | --- | --- |
|
||
| 全量原件库 | 负责人受控资料区、离线电脑或受控 NAS | 只登记资料编号、类别、敏感级别、hash/校验摘要、责任人和归档位置摘要 | 镜像全量目录、完整本地路径、历史资料包、员工自由浏览目录 |
|
||
| 授权业务原文附件 | OA 具体业务流程 | 合同审批稿、盖章扫描件、发票、银行回单、报价、验收、交付证明等必要原文 | 脱离业务对象的自由上传、跨业务搜索下载、企业微信原生附件承载高敏资料 |
|
||
| 脱敏协作副本 | OA 任务、项目或待办 | 台账整理、正式文件格式初审、外发复核、员工交付物 | 可反推出客户、报价、账号、证件、合同敏感条款的副本 |
|
||
| 禁止入库资料 | 专用密钥/档案/源码/银行渠道 | 只记录“需线下受控处理”的状态或负责人 | 密码、token、Secret、私钥、源码包、完整配置、完整银行流水、身份证银行卡和工资社保原件 |
|
||
|
||
员工资料整理、制度建设和业务指导优先用现有 OA 能力承接：
|
||
|
||
1. 制度发布用公告签收记录版本、适用范围、签收声明和签收时间。
|
||
2. 资料目录和历史包只做 `EA-DOC` 索引，先不导入全量原文。
|
||
3. 外发材料必须先在项目任务、合同或待办中记录用途、脱敏检查和负责人复核。
|
||
4. 合同、报销、采购、付款、项目和制度资料附件必须依附具体业务对象，跟随状态、权限、复核、归档和审计。
|
||
5. 敏感附件下载默认需要用途说明；付款回单、财务证明和其他 `confidential/restricted` 附件必须写下载审计。
|
||
6. 企业微信只发送脱敏标题、编号、状态和 OA 链接，不发送附件原文。
|
||
|
||
文件存储阶段性决策：当前不新建通用文件管理服务器，不自研网盘。V0 继续使用部署服务器本地存储承载授权业务附件；部署服务器空间不足时优先选“只保存索引 + 负责人线下调取原件”，后续再评估腾讯云 COS 或受控 NAS/MinIO。家用群晖适合作为冷归档、二级备份或低风险 MinIO 试点，不直接作为正式公网 OA 主附件库。
|
||
|
||
阻断判定：
|
||
|
||
- 无法登录、无法提交或审批报销/采购/合同相关事项。
|
||
- PDF 发票 OCR、查重、绑定或状态长期卡住且无法解释。
|
||
- 付款批次、银行回单、已付款标记、AP 导出或审计日志异常。
|
||
- 普通员工越权查看财务、合同附件、他人审批或管理入口。
|
||
- `payment_batch_v1` 意外关闭，或 `erp_sync`、图片 OCR、预算、银行流水导入、真实支付直连被误开启。
|
||
|
||
7 天结束后按自动报告和人工问题登记选择：接受 `PASS_OA_REAL_USE_READY` 进入体验/效率优化；接受 `PASS_WITH_FINDINGS` 但先处理指定 finding；或暂停真实使用扩展先整改。
|
||
|
||
### 3.7 OALAUNCH1 最终启用 Go/No-Go
|
||
|
||
OALAUNCH1 是 OAOPS1 和 ASSET1D 之后的最终启用门禁层。它不替代真实业务操作，也不替代备份恢复演练；它只把自动报告、人工验收和 Go/No-Go 结论汇总成一份脱敏证据。
|
||
|
||
默认汇总命令：
|
||
|
||
```bash
|
||
bash scripts/qa/run-oa-final-launch-readiness.sh
|
||
```
|
||
|
||
如需同步复跑 OAOPS1 每日只读巡检，再执行：
|
||
|
||
```bash
|
||
OALAUNCH_RUN_OAOPS1_DAILY=1 LIVE_SMOKE_BASE_URL=https://oa.hyinda.com bash scripts/qa/run-oa-final-launch-readiness.sh
|
||
```
|
||
|
||
7 天稳定化必须指定起始日期，避免脚本误用历史报告凑数：
|
||
|
||
```bash
|
||
OALAUNCH_STABILIZATION_START_DATE=2026-05-23 bash scripts/qa/run-oa-final-launch-readiness.sh
|
||
```
|
||
|
||
正式启用前必须逐项确认：
|
||
|
||
| 门禁 | 通过标准 | 未通过处理 |
|
||
| --- | --- | --- |
|
||
| OAOPS1 真实业务闭环 | 报销/PDF OCR/审批/付款/AP、采购/费用/项目或合同、合同台账/归档/权限均有真实样本 | 当天建修复合同，或暂停对应流程 |
|
||
| 7 天稳定化 | 每日巡检无不可解释 blocker，非阻断 finding 有 owner 和日期 | 延长稳定化或先修指定 finding |
|
||
| 权限矩阵 | 普通员工不能越权；主管、财务、HR、CEO、管理员入口和 API 权限符合角色 | 权限相关修复后必须只读 reviewer 复核 |
|
||
| 备份恢复 | 备份存在、可访问，影子库或受控恢复演练通过，记录 RTO/RPO 和负责人 | 不得直接启用；修复后重跑演练 |
|
||
| 数据治理和培训 | 员工、审批人、财务、管理员知道可上传/不可上传边界和问题上报方式 | 补培训或补手册后再 Go/No-Go |
|
||
| Day 7 Go/No-Go | 人工选择 A/B/C 并记录理由 | 缺结论时保持 `PAUSED_MANUAL_CONFIRMATION` |
|
||
|
||
Day 7 选项固定：
|
||
|
||
- A：接受 `PASS_OA_LAUNCH_READY`，进入小团队正式启用。
|
||
- B：接受 `PASS_WITH_FINDINGS`，但必须指定 owner、处理日期和接受理由。
|
||
- C：暂停启用，先整改。
|
||
|
||
备份恢复演练必须在不影响公网生产库的前提下完成。可以使用影子库、临时恢复库或受控恢复验证；不得为了演练重置公网数据库。证据路径可通过 `OALAUNCH_BACKUP_EVIDENCE` 传给汇总脚本。权限矩阵和真实业务闭环证据也可分别通过 `OALAUNCH_PERMISSION_EVIDENCE`、`OALAUNCH_BUSINESS_EVIDENCE` 指定脱敏证据文件。
|
||
|
||
制度对齐证据默认读取 OPOLICY1 历史合同或后续 Trellis task；如需指定外部制度验收摘要或脱敏评审证据，可通过 `OALAUNCH_POLICY_EVIDENCE` 指定路径。缺 OPOLICY1 收口时，最终启用汇总必须继续保持 `PAUSED_MANUAL_CONFIRMATION`。
|
||
|
||
### 3.8 OPOLICY1 制度对齐与人工门禁
|
||
|
||
OPOLICY1 是正式启用前的制度收口层。它不新增一套业务流程，也不把制度全文复制进 OA；它把制度包裁剪成小团队 V1 可执行清单，并要求管理员在 OALAUNCH1 前确认以下事项。
|
||
|
||
| 门禁 | V1 处理方式 | 未确认处理 |
|
||
| --- | --- | --- |
|
||
| 制度参数 | 金额阈值、报销期限、借款核销、采购比价、法务触发和用印责任先由管理层确认，不在代码中硬编码虚构金额 | 保持人工逐单审批或暂停对应真实启用 |
|
||
| 资料留存 | OA 只放可控摘要、hash、归档位置摘要、非涉密证明和审计线索；涉密正文、敏感报价、成本细节、银行流水原件和凭据继续线下或专用工具保管 | 资料不清楚时不上传，只登记待归档 |
|
||
| 用印台账 | V1 先通过合同台账的摘要、归档位置、离线档案号和附件审计承载用印记录；至少记录事项、文件版本、份数、审批状态、日期、责任人和归档位置 | 现有字段无法说明时，先用人工台账补充，后续再立项做专用字段 |
|
||
| 审批异常 SOP | 无审批人、自审、越权可见、付款/AP 卡住、合同或资料敏感信息误上传均视为阻断 | 当天建修复合同、人工绕行留风险，或暂停对应流程 |
|
||
| 制度签收 | OA 公告管理可创建“制度签收”公告，员工必须勾选声明并点击签收；系统保存本人签收时间、声明快照和审计记录 | 缺签收或缺外部签收证据时不进入最终 Go/No-Go |
|
||
| P2 冻结 | 复杂预算、复杂招采、电子签章、完整档案系统、ERP、银行流水导入、真实支付直连和 AI 写规则继续冻结 | 真实使用证明必要后另建 Trellis task |
|
||
|
||
制度参数人工问答建议：
|
||
|
||
- A：先采用小团队默认参数试运行，并在 Day 7 Go/No-Go 前由管理层确认。
|
||
- B：暂不填固定金额阈值，所有预算外、合同、用印和高风险事项逐单管理层审批。
|
||
- C：暂停财务、合同或采购真实启用，先把制度参数定稿。
|
||
|
||
当前 OA 对齐判断：合同台账已有敏感级别、归档位置和离线档案号，资产台账已有 `FA/EA-DOC/EA-SYS/EA-REPO/EA-BKP` 元数据能力，公告模块已支持轻量制度签收回执。用印台账专用字段仍不作为正式启用前置；如果真实使用证明该字段是阻断，再另建功能合同并进入 reviewer。
|
||
|
||
## 4. 人员生命周期管理
|
||
### 4.1 入职
|
||
1. 在 `人员管理` 创建员工账号。
|
||
2. 打开员工详情页，补齐部门、职位、直属上级、试用期结束日、工作地点、紧急联系人。
|
||
3. 若已开启 `hr_wecom_directory_sync_v1` 且企业微信通讯录配置完整，创建或发起入职时系统会尝试创建企业微信成员；HCLT 已验证公网真实写入闭环，缺 Secret、缺默认部门或无通讯录权限时记录 `SKIP/BLOCKED_BY_EXTERNAL_CONFIG`，OA 入职不回滚。
|
||
4. 发起 `入职`，系统会自动生成 checklist：账号初始化、资产发放、制度确认。
|
||
5. checklist 全部完成后，员工状态自动从 `onboarding` 进入 `probation`。
|
||
6. 人员列表或员工详情中的“企业微信通讯录”状态若为同步失败或配置缺失，管理员可在配置修复后执行“重试同步”。
|
||
|
||
### 4.2 转正 / 调岗
|
||
- `转正`：记录事件并将员工状态改为 `active`。
|
||
- `调岗`：当前记录部门、直属上级、职位调整，同时生成调岗交接 checklist；WFOC 后目标是从企微/人事助手同步到 OA，OA 管理员修复需写原因和审计。
|
||
- 这两个动作只做管理留痕，不引入复杂审批流。
|
||
|
||
### 4.3 离职
|
||
1. 发起 `离职` 后，系统自动生成离职 checklist：资产归还、权限回收、费用与审批清理、交接说明。
|
||
2. 若员工仍有名下资产或待处理审批任务，系统不会自动完成离职。
|
||
3. checklist 完成且阻塞清零后，OA 账号会被停用并吊销现有会话，主业务入口对该账号不可再用。
|
||
4. 当前离职完成后系统默认尝试禁用企业微信成员，不删除企业微信成员；WFOC 后目标是企微离职/禁用状态同步到 OA，OA 禁用账号并吊销会话。
|
||
|
||
## 5. 团队状态与考勤口径
|
||
- 员工每天可在 `Portal` 或 `团队` 页更新状态：在岗 / 居家 / 外出 / 出差。
|
||
- 已批准请假会自动覆盖当天状态为 `请假`。
|
||
- 企业微信打卡作为原始采集和规则执行工具；定位、人脸、Wi-Fi、设备和排班规则不在 OA 内重造。
|
||
- 当前 OA 已完成请假审批、补卡/外出/加班修正审批和月度考勤解释；WFOC 后这些能力默认作为历史查询和应急接管基础。
|
||
- 历史 `attendance_v1` 是 OA 极简打卡和管理员补卡能力，不等同于企业微信打卡风控；该入口已关闭，旧写接口返回可解释 409，历史表保留。
|
||
- OA 后续同步企业微信打卡规则、排班、记录、日报、月报和 HR/考勤审批镜像，形成正式考勤口径；缺企微打卡 Secret 或 API 权限时，同步批次按 `SKIP` 记录。
|
||
- 请假、补卡、外出、加班正常在企业微信内完成；OA 仅在管理员开启应急模式时接管，恢复后 dry-run 并自动回写企微。
|
||
|
||
## 6. 周报与待办
|
||
- 周报固定三段：本周完成 / 当前阻塞 / 下周计划。
|
||
- 建议每周五下班前提交，周一老板看团队汇总。
|
||
- 需要跟进的事项可从周报沉淀为待办。
|
||
- 高优先级待办建议由老板或管理员统一看板跟进。
|
||
|
||
## 7. 公告与 Portal 使用建议
|
||
- 公告只发公司级通知、制度更新、假期提醒，不做复杂 CMS。
|
||
- 涉及员工利益、费用、保密、资产、权限或档案的制度，优先在 `系统设置 -> 公告管理` 创建“制度签收”公告，填写签收声明和截止日；已有人签收后如制度内容变化，应新建公告版本，不直接改旧公告标题、摘要或声明。
|
||
- 管理员可在公告管理页查看全员 active 员工的已签、待签、逾期统计和最小必要未签名单；不得把手机号、邮箱、企业微信 userid 或敏感资料导出到公告签收证据里。
|
||
- `Portal` 首屏建议重点看：
|
||
- 今日团队状态
|
||
- 未提交周报人数
|
||
- 需协助员工
|
||
- 入/离职待办
|
||
- 资产待归还
|
||
- 审批待办
|
||
|
||
## 8. 备用模块治理
|
||
- 采购/费用、合同/附件和项目轻管理属于 P1 轻量能力，可在 P0 报销/OCR、财务闭环、企微 HR/考勤镜像和企业微信入口稳定后逐步开放。
|
||
- 付款和应付账款已作为正式财务闭环开放给出纳、财务和管理员；普通员工仍不显示财务运营入口。
|
||
- 预算、AI、完整差旅等保留代码和历史数据，但不作为当前 MVP 首批主路径；资产管理按 ASSET1 统一台账 V1 小范围启用；ERP 保持关闭，不再规划接入。
|
||
- 若短期完全不用，保持管理员可见即可，不必删除。
|
||
- 只有出现真实场景时，再恢复到主导航或单独扩展。
|
||
|
||
## 9. 推荐上线顺序
|
||
1. 先完成账号、角色、部门、企业微信自建应用入口和账号密码回退路径。
|
||
2. 再启用 `OA 统一审批中心 + 报销/发票/OCR/附件`，跑通提交、审批、退回、查重、付款和导出闭环。
|
||
3. 同步启用付款批次、AP 台账和银行回单附件，付款动作仍由出纳在 OA 外通过银行渠道完成。
|
||
4. 先以企业微信作为请假、补卡、外出、加班和打卡主操作端；OA 侧按后续合同逐步启用 HR 主数据镜像、企微审批/考勤镜像、人工接管和恢复回写。
|
||
5. 在 P0 稳定后开放 P1：`采购/费用审批`、`合同/附件归档`、`项目轻管理`。
|
||
6. 最后按真实需要评估周报、团队状态、公告、资产台账、预算、AI 和完整差旅；ERP 不进入评估队列。
|
||
|
||
## 10. 试点验收口径
|
||
- 全员都能账号密码登录；已绑定员工能从企业微信 `海音达工作台` 进入移动工作台。
|
||
- 至少 1 笔报销完成：上传发票或附件 -> OCR/查重 -> 提交 -> OA 审批 -> 财务复核/付款标记 -> 导出。
|
||
- 至少 1 个付款批次完成：出纳创建 -> 管理员复核 -> 出纳上传银行回单 -> 执行 OA 已付款标记 -> AP 台账和审计可查。
|
||
- 后续 WFOC POC 至少 1 条企微请假和 1 条企微考勤修正完成：员工在企微提交 -> 企微审批 -> OA 镜像可查；应急模式另以测试窗口验证，不默认常开。
|
||
- 至少 1 个审批待办从企业微信提醒 deeplink 回到 OA 页面处理。
|
||
- P1 试点时，至少 1 条采购/费用申请、1 条合同台账、1 个项目关联事项可创建、审批或归档。
|
||
- 正式使用前至少完成一次备份可用性核对；真实恢复演练必须另建批准合同，并记录恢复后的 `/ready` 结果。
|
||
- 普通员工主导航不出现预算、AP、AI、完整差旅等当前首批不开放的备用模块；ERP 入口保持关闭。
|
||
|
||
## 11. 4 周观测操作法
|
||
1. 每周一进入 `Portal`、`审批待办` 和 `考勤` 查看近 7 天登录覆盖率、审批积压、报销/OCR 异常、请假/考勤修正审批和企业微信入口错误；企微打卡同步缺已授权应用 Secret 或 API 权限时记录为 `SKIP`。
|
||
2. 每周五记录本周结论、关键阻塞、是否需要调整审批规则、报销规则、企业微信入口或导航。
|
||
3. 若某周出现员工未登录、报销长期停留、发票重复处理不清、审批积压或企业微信绑定异常，优先修正规则和入口，不额外维护表格作为正式记录。
|
||
4. 连续 4 周都达到预期后，再扩大到 P1 采购/费用、合同归档和项目轻管理试点。
|
||
|
||
## 12. 企业微信入口与登录策略
|
||
- 企业微信定位为 `入口 + 免登 + 通知 + 打卡原始采集 + HR/考勤员工日常审批`，不承载 OA 主办的采购、合同、项目、报销或财务审批。
|
||
- 公司只维护一个企业微信自建应用，建议命名为 `海音达工作台`。
|
||
- 默认工作台入口在企业微信手机端落到 `/mobile`；桌面浏览器和账号密码登录仍进入 `/portal`。OA 主办业务的真正操作仍在 `hyb-oa` 内完成。
|
||
- 已上线的报销、采购、费用、合同、项目和财务类 OA 主办审批都在 OA 内提交和审批；企业微信消息只负责脱敏提醒并 deeplink 回 OA。请假、补卡、外出、加班后续按 WFOC/DBWFOC 迁往企业微信原生审批，OA 同步镜像并保留应急入口。
|
||
- 企微免登要求在账号启用时通过 userid 或唯一企业邮箱完成映射；员工第一次从工作台进入不需要先输入 OA 密码。账号密码只作为企微不可用时的独立回退。
|
||
- 若 OA 部署到公网，生产建议同时满足：`HTTPS`、`COOKIE_SECURE=true`、登录失败锁定、限流、审计开启。
|
||
|
||
### 正式接入最小步骤
|
||
1. 在企业微信管理后台创建或编辑唯一自建应用：`海音达工作台`。
|
||
2. 将工作台入口配置为：`https://oa.hyinda.com/api/auth/wecom/login?returnTo=%2Fmobile`。
|
||
3. 将 OAuth 回调地址配置为：`https://oa.hyinda.com/api/auth/wecom/callback`。
|
||
4. 在 `deploy/trialrun/.env` 中补齐并开启：
|
||
- `WECOM_ENABLED=true`
|
||
- `WECOM_ENTRY_ENABLED=true`
|
||
- `WECOM_PC_WEB_LOGIN_ENABLED=false`（普通 PC 浏览器扫码默认关闭）
|
||
- `WECOM_OAUTH_ENABLED=true`
|
||
- `WECOM_CORP_ID=...`
|
||
- `WECOM_AGENT_ID=...`
|
||
- `WECOM_AGENT_SECRET=...`
|
||
- `WECOM_REDIRECT_URI=https://oa.hyinda.com/api/auth/wecom/callback`
|
||
- `WECOM_ALLOWED_RETURN_HOSTS=oa.hyinda.com`
|
||
5. 如需普通 PC 浏览器企业微信扫码登录，先在自建应用开启“企业微信授权登录”，并确认 OA 域名已配置为 OAuth 可信域名或 Web 网页授权回调域名，再单独设置 `WECOM_PC_WEB_LOGIN_ENABLED=true`。该入口跳转企微托管登录页，不在 OA 密码页加载企微脚本；关闭该开关即可独立回滚。
|
||
6. 先 dry-run 核对通讯录 userid/企业邮箱与 OA active 账户的唯一映射，再 apply 建立 binding；无 binding 时，首次企微登录会用 userid 或企微企业邮箱精确匹配既有 active OA 账户并自动补绑定。员工不需要先输入 OA 密码。
|
||
7. 若启用 OA 同步企业微信打卡数据，在企业微信打卡 API「可调用接口的应用」中授权 `海音达工作台`。OA 默认可复用 `WECOM_AGENT_SECRET`；只有单独创建考勤同步应用时才额外配置 `WECOM_CHECKIN_SECRET`。
|
||
8. HR/考勤员工日常审批后续配置企业微信原生审批模板作为主流程；WAPC2FLIVE 已自动生成请假/补卡 OA-POC 低风险样件并复跑只读 POC，WCBK1 已完成真实回调事件确认，WACP3R 已完成补偿拉取，WREAD1 已确认请假/补卡在企微中可读，WADM1 已完成自建留存/镜像模型设计，WARCH1 已完成最小请假/补卡历史留存，WARCH2 已完成正式只读历史查询。WARCH3/WCHECK1/WEXT1 后先做自动巡检、打卡摘要留存和外出/加班 dry-run；WOPS1 后告警默认发给 `HYD000006`（`wangshunli` 的员工号）且只报新增异常。同意单击即通过需继续纳入操作提示和审计设计。外出/加班正式模板人工测试仍需后续单独批准。报销、财务、采购、合同和项目类 OA 主办审批仍使用企业微信消息提醒并回到 OA 页面完成。
|
||
|
||
### 员工会看到的典型状态
|
||
- 映射唯一：首次从工作台进入即可自动补 binding 并直接登录，无需 OA 密码。
|
||
- 映射缺失或冲突：登录页提示联系管理员核对通讯录同步；系统不按姓名猜测、不创建账户、不覆盖冲突 binding。
|
||
- 已绑定：从企业微信工作台进入后直接落到 `/mobile`，桌面或普通浏览器场景仍可进入 `Portal`。
|
||
- 入口未开放：个人设置仍可绑定，但登录页不会把企业微信作为正式入口展示。
|
||
- 配置不完整：个人设置会明确提示缺少 `CorpID / AgentID / 回调地址` 等原因。
|
||
- 收到审批提醒：点击后进入 OA 审批页，在 OA 中同意、驳回、退回或转审。
|
||
|
||
## 13. 轻项目管理使用建议
|
||
- 项目主档只做轻量管理：成员、里程碑、任务、风险、交付记录、合同台账与资料引用。
|
||
- 不要把 `hyb-oa` 推成完整项目组合平台；甘特图、资源排产、CRM 仍不在本主线。
|
||
- 员工日常动作建议统一挂项目：
|
||
- 差旅申请挂项目
|
||
- 报销单挂项目
|
||
- 周报按项目拆分进展
|
||
- 待办可直接挂项目
|
||
- 管理层每周主要查看 `项目` 页中的逾期里程碑、高优任务、风险与费用/出差汇总，而不是再维护第二套项目台账。
|
||
|
||
## 14. 涉密边界
|
||
- `hyb-oa` 只记录涉密合同或资料的元数据：编号、责任人、密级、归档位置、离线档案号。
|
||
- 涉密正文、涉密附件、详细报价/成本/毛利、敏感客户资料不进入公网 OA。
|
||
- 企业微信通知不得发送涉密正文，只保留最小必要信息和 deeplink。
|
||
- 企业微信审批不作为涉密或财务审批载体，正式审批记录以 OA 审批历史和审计日志为准。
|
||
- 采购单附件、合同正文、报价、供应商资料、发票、银行回单和代账资料不上传到企业微信原生审批或企业微信附件；企业微信只保留脱敏标题、编号、状态和 OA 链接。
|
||
- 如项目被标记为涉密，管理员应要求正文继续保存在内网文件盘、NAS 或离线档案中。
|
||
|
||
## 15. 初始化与导入建议
|
||
1. 首次上线先完成系统初始化：数据库迁移、配置种子、管理员种子。
|
||
2. 不要直接把开发库、测试库或旧 OA 整库导入到生产。
|
||
3. 如需导入，只导最小必要主数据：
|
||
- 部门
|
||
- 员工
|
||
- 角色
|
||
- 在用固定资产和必要电子资产索引
|
||
- 活跃项目
|
||
- 合同元数据
|
||
4. 不导入这些内容：
|
||
- 历史审批单
|
||
- 通知历史
|
||
- 审计日志
|
||
- 聊天记录
|
||
- 涉密正文与附件
|
||
5. 建议顺序：初始化系统 -> 管理员登录验证 -> 最小主数据导入 -> 小范围试点 -> 全员启用。
|
||
|
||
## 16. 公网部署最低建议
|
||
1. 为 OA 配置独立 HTTPS 域名，例如 `https://oa.example.com`。
|
||
2. 在 `deploy/trialrun/.env` 中设置：
|
||
- `APP_ORIGIN=https://oa.example.com`
|
||
- `COOKIE_SECURE=true`
|
||
- `PUBLIC_SECURITY_HARDENING_ENABLED=true`
|
||
3. 若启用企业微信入口，补齐：`WECOM_*` 与 `WECOM_ALLOWED_RETURN_HOSTS`。若启用 OA 驱动企业微信通讯录同步，还需补齐 `WECOM_CONTACT_SYNC_ENABLED=true`、`WECOM_CONTACT_SECRET`、`WECOM_CONTACT_DEFAULT_DEPARTMENT_ID`，并确认该 Secret 具备通讯录写权限。若启用企微打卡同步，确认 `海音达工作台` 已被授权调用打卡 API；`WECOM_CHECKIN_SECRET` 留空时复用 `WECOM_AGENT_SECRET`，单独考勤同步应用才需要填写独立 Secret。若启用企微 HR 主数据镜像，按 WAPI 口径确认通讯录读取使用 `WECOM_CONTACT_SECRET`、人事助手/花名册读取使用 `WECOM_AGENT_SECRET`；正式批量 apply 仍由 `wecom_hr_master_sync_v1` feature flag 和单独批准控制。
|
||
4. 将 `OPENAPI_DOCS_ENABLED` 保持为 `false`，不要在公网生产暴露文档入口。
|
||
5. 定期检查审计日志中的登录失败、Refresh 来源不匹配与涉密资料查看记录。
|
||
6. 准备独立 smoke 账号，不使用老板、管理员或真实员工日常账号跑自动化；smoke 账号的角色和直属上级应按正式审批链配置。
|
||
7. 每次正式发布前记录备份文件名、恢复负责人和上个可回滚 tag。
|
||
|
||
## 17. 网页自动化门禁（R28/R30）
|
||
- 推荐发布时直接执行：`bash scripts/qa/run-release-gate.sh all`。
|
||
- 发布前至少执行一次：`bash scripts/qa/run-web-gates.sh smoke-local`。
|
||
- 发版前或主分支合并前建议执行：`bash scripts/qa/run-web-gates.sh full-local`。
|
||
- 发布到 `https://oa.hyinda.com` 后，使用独立 smoke 账号执行：`bash scripts/qa/run-web-gates.sh smoke-live`。
|
||
- live smoke 只做只读检查，不允许提交审批、付款、导入或任何真实业务写操作。
|
||
- 如果本机已配置 `LIVE_SMOKE_*`，`bash deploy/trialrun/deploy.sh` 完成远端部署后会自动补跑 live smoke。
|
||
- 首次接入企微、SMTP 或证书变更可人工复核；日常发布不再要求手点页面验收。
|
||
|
||
## 18. R23 试点收口纪律
|
||
- 客户沟通如果影响项目计划、交付、报价、风险或下一步动作，必须在 `24h` 内回填到 `项目 -> 客户沟通`。
|
||
- 回填只写结果摘要、下一步动作和下次跟进日期，不粘贴完整聊天记录，不上传私人微信截图。
|
||
- 项目经理每周至少检查一次 `项目 -> 项目收口` 面板，确认红黄灯来源是否已经处理。
|
||
- 若某项收口任务选择 `已豁免`，必须填写理由；豁免不代表永久忽略，只代表本周软约束放行。
|
||
- 试点期每周五复盘一次“仍靠聊天/表格补流程”的案例，并决定是补回填纪律还是补最小功能。
|
||
|
||
|
||
## 19. R29 设计与工作台治理口径
|
||
- 首页不再做“模块超市”，而是先告诉员工今天该做什么。
|
||
- 管理员不要把备用模块重新平铺到主导航，避免系统再次变成模块拼盘。
|
||
- 员工入口默认认知应保持为：`企业微信进入 -> OA 移动工作台 -> 进入审批/报销/请假等模块处理`；PC 用户可直接登录 OA。
|
||
- 如果未来新增页面，请优先复用统一骨架：
|
||
- 首页：`WorkbenchHero + MetricCard + SectionPanel`
|
||
- 列表页：`PageHeader + FilterBar + 主列表`
|
||
- 详情页：`概览 -> 执行 -> 留痕 -> 归档/合规`
|
||
- 若某页面出现两个以上竞争级主按钮，应视为设计回退并在上线前修正。
|
||
## 20. 企业银行账户与收款信息
|
||
|
||
- 部署本能力后，先由管理员在“管理 → 企业银行账户”配置法人主体的建设银行付款账户，再由 HR/管理员在员工档案“收款信息”中选择建设银行并录入工资卡账号；不要通过聊天、工单或仓库传递完整账号。
|
||
- 同一法人主体只保留一条当前启用账户。换卡使用“替换”，系统归档旧记录；不再使用时选择“停用”，不要覆盖历史记录。
|
||
- 默认页面只显示脱敏尾号。查看公司或员工完整账号必须填写业务原因，系统记录查看审计；查看完成后及时关闭或隐藏。
|
||
- 新建银行付款批次会冻结付款方和收款方账号。旧批次没有冻结密文，永久不支持制单，仍按人工转账、上传回单、登记付款完成的路径处理。
|
||
- 银行制单仅支持建设银行本行，生成真实 BIFF8 `.xls`。重新下载不会作废旧文件；若旧文件已导入网银，不得重复提交。
|
||
- 制单下载不是付款证据。企业网银付款完成后仍须上传银行回单，才能登记付款完成。
|
||
- 下一笔新快照批次首次验证时，先把“验证制单”和“使用制单付款”分开：先导出文件，用 Excel 打开并由固定版本 `xlrd` 独立读回；只有建设银行网银明确提供“仅校验、不提交”步骤时，才进入网银做格式校验。若没有该步骤，不把文件导入网银，实际付款仍走人工转账、上传回单和登记完成。
|