真实内部实例只读基线

边界

核查日期：2026-07-26。
已获得只读核查授权。
未修改远程文件、环境变量、数据库、角色、容器、反向代理或企微配置；未执行备份、恢复、部署和业务写入。
证据只记录布尔值、数量、时间和短构建标识状态，不保存主机名、IP、SSH 别名、Secret、连接串、账号标识或业务正文。

公开入口

检查	结果	判断
HTTPS 首页	`200`	可访问
TLS 证书	存在，截止 2026-10-19	当前有效，需纳入到期提醒
HSTS	存在	通过
CSP	未发现	非本批 P0，但公网继续使用时列入后续安全任务
`/ready`	`data.ok=true`	当前进程与基础依赖可用
`/ready` 构建标识	缺失	无法由公开接口追溯运行 commit

运行来源与迁移

检查	结果	判断
容器	server/db 正在运行，容器内 `/ready=true`	运行中
运行端口	仍使用历史宿主端口基线	与当前 Compose 基线不一致
`BUILD_SHA`	容器未配置	无法证明运行来源
前端 build marker	缺失	无法从静态资源证明运行来源
Prisma migration	远端已应用 58，本地当前 61；最新项不匹配	远端落后，禁止直接宣称当前版本已部署
来源门禁复验	`PASS`，当前提交已发布	已完成普通快进发布，范围 `325a795..7658051`，未使用覆盖参数

角色和付款职责

只读聚合结果：

活跃员工账号：1。
活跃角色只有 admin 和 employee，属于同一账号的组合。
财务处理角色数量：0。
manager/ceo 付款复核候选数量：0。
可形成不同自然人的制单/复核组合：否。
远端旧 schema 尚无当前 system_admin 角色值。

结论：当前真实角色配置不满足付款 maker-checker，也不满足“系统管理员与业务审批职责分开”的当前规约。不得启用真实付款闭环。

备份和恢复

检查	结果	判断
DB dump	7 份	有历史产物
附件 tar	7 份	数量上可配对，但无 manifest 证明批次关系
manifest	0	不符合新成对备份合同
最新产物年龄	约 1316 小时（约 55 天）	明显过期
备份介质	与 DB 数据和附件目录位于同一设备	不构成异机/异盘副本
目录权限	`755`	备份目录可读范围偏宽，后续应按运维账号收紧
真实恢复证据	无	本地 6 秒合成演练不能替代真实格式影子恢复和 `/ready`

结论：当前历史备份不能证明满足 RPO 24 小时、异机副本或可恢复性，不得作为正式启用依据。

Go / No-Go

结论：NO_GO_FOR_FORMAL_INTERNAL_USE。

服务当前可访问不等于运行与恢复底线通过。进入下一步前必须按顺序完成：

已将当前获批代码以普通快进方式发布到 upstream，来源门禁复验为 PASS。
重新从活动 DB 与活动 server 附件挂载源生成 DB + 附件 + manifest，并复制到独立主机；此前批次混用了非活动附件目录，不能作为活动实例的成对恢复证据。
明确至少一名财务处理人和另一名 manager/ceo 付款复核人；系统管理职责单独分配，应急 admin 独立托管。
通过获批部署任务升级代码和 3 项迁移，验证 BUILD_SHA、前端 marker、/ready、权限矩阵和回滚点。
在独立影子目标恢复同一批次 DB/附件，验证应用 /ready 和关键附件引用，记录真实 RPO/RTO。

发布和远程备份已分别获得授权并完成；真实角色写入、部署和影子恢复仍须继续取得明确授权，不能由既有批准推导。

后续获批写入：已降级的异机备份批次

执行日期：2026-07-26。
授权范围：生成真实 DB、附件和 manifest 成对备份，并复制到用户指定的另一台主机。
源机与目标机设备指纹不同；未记录主机名、地址、SSH 名称、账号或完整目录。
批次 hyb-oa-backup-20260726T133923Z-live 的三份产物及传输校验本身完整，但后续拓扑复核证明其来源是“活动 DB + 非活动附件目录”。该批次保留作审计，不再计为活动实例的成对恢复点。
该批次的附件归档含 54 个文件，而活动 server 实际附件挂载为空，活动库附件类记录也均为 0；两端哈希一致只能证明传输一致，不能证明源选择正确。
目标批次目录权限为 700；传输失败产生的单文件残缺副本已精确删除，本机临时暂存数据已安全清理。
运行主机没有宿主 Node.js，因此为成对备份入口增加 Python 3 manifest 等价回退；无 Node 路径已通过完整合成恢复演练，本地参考 RTO 仍为 6 秒。
运行中的 PostgreSQL 容器参数与部署目录环境文件存在漂移；本次只在运行容器参数与活动服务数据库连接相互匹配后执行备份，未修改环境文件。
必须在另行批准后，显式提供经挂载核验的 STORAGE_DIR_HOST 和 Compose 解析出的 DB 容器 ID，重新生成并复制正确批次。本次未执行恢复、部署、迁移、角色修改、企微写入或业务写入；真实格式影子恢复和恢复后 /ready 仍无证据。

后续获批调查：部署拓扑与企微字段可用性

当前 OA 公网路由由宿主反向代理进入 server 容器；后端和前端构建位于同一应用镜像，数据库位于独立容器，附件由宿主目录挂载。
运行容器来源目录与日常运维任务目录不同；两套目录都没有 Git 元数据，源文件相同但 Compose 与环境文件摘要不同。运行代码与本机当前代码不一致，/ready 无构建标识。
核查时仓库部署脚本的固定宿主健康检查端口与现场实际端口不一致；本地现已改为 Compose 动态解析，并移除固定容器名、参数化数据目录，但新项目名和数据路径尚未在获批停机窗口启用，故仍未执行部署、重启、迁移或目录改写。
使用修正后的双 Secret 读取链路做结构化探测：成员详情 6/6 成功、部门 6/6 可读，手机号/邮箱/企业邮箱均 0/6 可读；HR 详情 6/6 返回成功但 staff_info 为 0/6。该结果只证明批量读取链路拿不到敏感字段。
企微官方文档复核：2022-06-20 后新建的自建应用不再通过 /user/get 返回手机、邮箱和企业邮箱；管理员需在应用详情选择敏感字段，成员使用 snsapi_privateinfo 手工授权，/cgi-bin/auth/getuserinfo 才返回 30 分钟有效的 user_ticket，随后 /cgi-bin/auth/getuserdetail 可返回成员同意的手机号、邮箱和企业邮箱。
当前 OA server/src/routes/wecomAuth.js 固定使用 snsapi_base，只调用 getuserinfo 获取 userid，不调用 getuserdetail；因此现状是项目尚未接入官方敏感信息授权链路，而不是企微没有该能力。
两名目标成员的脱敏结果为匹配计数 [1,1]、身份不同、均 active、数据库匹配 [0,0]、计划动作均为 create；两人均缺 phone 与 email，因此没有员工、角色、会话、付款或其他业务写入。

7.2 KiB 原始文件 Blame 文件历史