# 全员登录可用性 ## Goal 确保每个 active OA 账户至少有一条实际可验收的登录路径，并为企业微信成员预先建立 userid/企业邮箱到 OA 账户的唯一映射；员工第一次从企微工作台进入即直接登录，不把输入 OA 用户名和密码作为首次绑定步骤。 ## Scope - 当前生产 4 个 active 账户的密码回退与企业微信工作台免登基线。 - 管理员本人优先通过已批准的受控 break-glass 恢复密码，再绑定企微并真机验收；其余 3 个已有 binding 的账户先验证企微免登，再按需完善密码回退。 - 邮件失败时使用现有管理员一次性密码接口作为另行批准的兜底。 - 更新现有账号启用/入职操作门禁，防止后续 active 账户再次只有未知随机密码或未经本人验证的 binding。 - 改造企微登录缺失 binding 时的唯一企业邮箱自动匹配、事务绑定、审计和失败关闭逻辑；同步修正未绑定页面指引。 ## What I Already Know - 管理员本人从企业微信工作台进入时收到“当前企业微信账号尚未绑定”，且没有已知可用密码。 - 当前登录页的未绑定流程要求先使用账号密码登录，再到个人设置完成企业微信绑定；这对不知道随机初始密码的导入账户会形成死锁。 - 现有管理员手册已经规定：全员应能账号密码登录，已绑定员工还应能从企业微信工作台进入。 - OA 已有管理员重置普通账户密码接口：生成一次性密码、强制首次改密、清空锁定、撤销旧会话并写审计。 - OA 也支持企业邮箱验证码登录，但真实邮件投递和边缘 challenge 端点是否当前可用必须现场核对，不能假定为可用兜底。 - 企业微信普通登录只按回调 userid 查询唯一 binding；找不到 active 绑定就进入 `wecom=unbound`，不会按姓名、邮箱或手机号自动猜测账户。 - 生产只读基线为：active 账户 4 个，全部有企业邮箱和密码哈希，3 个有手机号，当前密码/邮箱验证码均无锁定。 - 4 个 active 账户中 3 个处于 `must_change_password=true`，但没有实际交付随机初始密码的证据；仅 1 个账户有历史成功密码登录，邮箱验证码成功登录和企微成功登录均为 0。 - 3 个 active 账户已有企微 binding；唯一 active 管理员正是缺 binding 的账户，且该管理员已有历史密码成功登录、当前无需强制改密但本人已不知道密码。 - 企业微信通讯录本身拥有管理员 userid，但生产只读核对显示 OA 侧没有该管理员的目录同步 userid、成功 HR 主数据映射或 identity binding；当前 OAuth 回调只能拿到 userid，无法仅凭它反推出唯一 OA 账户。 - 现有企微 HR 主数据同步已经能够按 binding、userid/员工编号、手机号或企业邮箱解析员工并在 apply 时写入 binding，但当前普通 `mode=login` 回调只查 binding；binding 缺失时不会利用企微通讯录企业邮箱匹配既有 OA 账户。 - 公网认证能力当前报告企业邮箱验证码登录和忘记密码均已启用。 - `/forgot-password -> /reset-password` 是完整的验证码重设密码路径；正确验证码会设置新密码并清除 `must_change_password`，不是死路。 - 本次实际失败发生在 `/reset-password` 成功之前：第二次签发使第一次验证码失效，用户收到并使用旧验证码后被后端拒绝；未发现“重置成功后被前端缓存再次送回改密页”的现场证据。 - `/email-login/code -> /email-login/verify` 是另一条邮箱验证码登录路径；现有前端在验证成功后仍遵守 `must_change_password` 跳转，而修改密码页强制要求旧密码，因此它对未知随机初始密码账户可能形成死路，但与本次失败无关。 ## Requirements (Evolving) - 登录基线固定为双路径：每个 active 账户都必须具备可实际交付并完成首次改密的账号密码回退；属于当前企业微信通讯录的 active 员工还必须具备唯一 binding 和工作台免登。 - 先以只读方式核对所有 active 账户的状态、可登录标识、密码是否为强制首次改密状态、登录锁定、企业微信 binding、最近成功登录类型和企业邮箱验证码能力；只输出计数和脱敏状态。 - 把“数据库里存在密码哈希”与“员工实际掌握可用凭据”区分开，后者必须由一次真实登录或受控的一次性密码交付证明。 - 管理员本人先通过已批准的受控 break-glass 恢复一条安全登录路径，再完成企业微信绑定和工作台真机登录，不通过聊天、命令参数、环境变量、Trellis、日志或仓库传递密码。 - 其余 3 个已有 binding 的 active 账户先直接验证企业微信工作台免登；只有免登不通或需要独立回退时，才进入密码找回或管理员一次性密码流程。 - 企微成员首次工作台登录不得依赖 OA 密码：已有 userid binding 直接登录；binding 缺失时，仅允许使用企微接口返回的企业邮箱精确匹配唯一 active OA 账户，事务内创建 binding、写审计并继续登录。 - 企业邮箱缺失、无 active OA 匹配、目标账户已绑定另一 userid、userid 已绑定另一账户或企微资料接口失败时必须失败关闭；姓名只用于人工核对，不得作为自动绑定键。 - 自动匹配只允许绑定既有 active OA 账户，不得在普通登录中自动创建员工、修改角色、更新通讯录或覆盖冲突 binding。 - 通讯录/HR 主数据同步应在账号启用前建立 binding；登录时自动补绑定仅作为确定性兜底，不替代入职门禁。 - 对每个 active 账户建立可验收的账号密码回退；属于当前企业微信通讯录的 active 员工还应具备唯一 binding 和工作台免登。 - 当前 4 个 active 账户逐人验收后，把“密码回退已完成 + 企微成员免登已完成”写入新账号启用/入职门禁，避免后续导入账户再次只有未知随机密码。 - 密码重置必须使用现有审计接口或经单独批准的受控 break-glass 路径；生成的一次性密码仅在受控现场显示一次，首次登录立即改密。 - 任何 binding 修正必须先证明目标 OA 员工和企微 userid 唯一对应；不得按姓名模糊匹配，不得修改企业微信通讯录成员。 - 生产 binding、密码、账户状态或认证配置写入前另行给出精确变更清单并取得批准。 - 最终业务职责以用户最新确认口径为准：`majianyong` 是 `ceo`，`wangshunli` 仅承担系统开发和系统管理，不是业务审批人；当前唯一 active `manager` 的 OA 直属主管应为 `majianyong`。 - `majianyong` 本人报销不配置直属主管、不允许自审，目标由 active 非本人 `finance` 审批；当前实现只支持 `finance_mgr` 且生产无持有人，本轮保持失败关闭并记录后续最小权限修正，不修改任何角色、邮箱、密码、binding、审批规则或企微通讯录。 ## Decision: Credential Recovery **Context**：管理员缺企微 binding 且未知密码，忘记密码现场又出现第二封验证码未送达；其余 3 个 active 账户已有企微 binding，但尚无真实企微登录记录。让管理员接触所有员工密码会扩大敏感信息处理面。 **Decision**：管理员先执行已批准的受控 break-glass，随后绑定企微并验证免登；其余 3 人先直接验证企微免登。只有免登不通或需要建立独立密码回退时，员工才使用忘记密码；邮件确实无法送达时，再由管理员使用审计能力生成一次性密码并线下当面交付。 **Consequences**：先验证系统预期主入口，避免让 3 名员工重复经历尚未稳定的邮件找回流程；最终双路径基线不变。任何一次性密码都不得经聊天、任务、邮件正文、命令参数、环境变量或普通日志转发。 ## Decision (ADR-lite) **Context**：仅保证一种登录方式会在企微 binding 漂移或未知随机初始密码时再次形成登录死锁。 **Decision**：采用“双路径基线”。账号密码是每个 active 账户的独立回退；企业微信成员在此基础上必须完成工作台免登。 **Consequences**：需要逐人安全交付一次性密码并完成首次改密，也需要逐人企微真机验收；实施工作略多，但能避免任何单一入口故障把员工锁在 OA 外。 ## Acceptance Criteria (Evolving) - [x] 管理员本人能使用一次性凭据完成首次改密，且凭据未进入聊天、任务材料、日志或仓库。 - [x] 管理员本人能从企业微信工作台直接进入 OA，不再出现未绑定提示。 - [x] 一个“无 binding、企微企业邮箱唯一匹配 active OA 账户”的合成场景能在不输入 OA 密码的情况下自动建立 binding、写审计并直接登录。 - [x] 企业邮箱缺失、无匹配、inactive、userid/binding 冲突等负向场景全部失败关闭，且不创建账户、不改角色、不按姓名绑定。 - [ ] 所有 active 账户均有一次实际账号密码登录验收或等价的安全凭据交付与首次改密证据。 - [ ] 所有属于当前企业微信通讯录的 active 账户均有唯一 binding，并完成本人企微真机登录验收。 - [ ] 不存在 active 账户同时缺少可交付密码回退和可用企微 binding。 - [ ] 所有重置、绑定、解锁、会话撤销均有 OA 审计且未扩角色、未修改企业微信通讯录。 - [x] 当前唯一 active `manager` 的直属主管唯一解析为 active `majianyong`，不存在自环或主管链环路，并有脱敏审计；`wangshunli` 不进入业务审批链。 - [x] `majianyong` 保持 `ceo` 且无直属主管；其本人报销目标为 active 非本人 `finance`，当前 `finance_mgr` 配置缺口未修复前保持阻断且不发生自审。 - [ ] 自动化、Trellis、敏感扫描、生产 `/ready` 和关联认证 smoke 通过后才通知员工测试。 ## Definition of Done - 只读基线、写入前后差异、逐人登录验收和剩余阻断均以脱敏计数记录。 - 相关后端测试、前端 typecheck/build、认证 smoke、Trellis 治理和敏感扫描通过。 - 生产变更具备最小回滚：binding 修正可恢复原映射，密码重置通过 token version 和会话撤销确保旧凭据失效。 - 现有管理员手册和试运行事实源与最终登录基线一致。 ## Test Plan - 生产前后只读聚合：active 总数、必须改密数、锁定数、binding 数和各成功登录类型覆盖数。 - 管理员本人及其余 active 员工分别完成真实密码登录与企业微信工作台免登；人工证据只记录 PASS/BLOCKED 和稳定原因。 - 若发生管理员一次性密码兜底，核对强制改密、旧会话撤销、token version 和审计增量，不记录密码正文。 - 运行认证聚焦后端测试、前端 typecheck/build、生产 `/ready` 与认证 capabilities、公网只读 smoke。 - 运行 Trellis task/governance、敏感扫描、文档审计、流程合同和 `git diff --check`。 ## Out of Scope - 不在 OA 中创建或修改企业微信成员。 - 不把真实密码、完整账号、手机号、邮箱、企微 userid 或认证原始 payload 写入任务证据。 - 不启用自助 OAuth onboarding，不重构认证架构，不放宽登录、绑定或账户管理权限。 - 本轮不修改“邮箱验证码登录后首次改密仍要求旧密码”的认证流程。 - 不启用会自动创建 OA 员工的通用企微 OAuth self-provisioning；本轮普通登录只允许匹配并绑定既有 active OA 账户。 - 不顺带导入剩余通讯录成员、修改角色或业务审批规则；主管字段仅包含用户最终批准的单条 `manager -> majianyong` OA 关系。 ## Technical Notes - 企微登录入口与 binding：`server/src/routes/wecomAuth.js`。 - 账号密码和邮箱验证码：`server/src/routes/auth.js`；普通密码登录不再消费 pending bind 建立企微映射。 - 管理员一次性密码重置：`server/src/routes/users.js`。 - 当前产品事实源：`docs/管理员手册.md` 第 10、12 节。 - 安全边界：`.trellis/spec/hyb-oa/security-privacy.md`、`.trellis/spec/hyb-oa/wecom-boundary.md`。