员工修改密码需求与验收

• 需求版本：v0.3-MVP（Owner冻结）
• 产品原则：先落地基本需求，再分段迭代完善；首版只解决员工不能自行修改本人密码的问题，以可用闭环和交付效率优先，避免小题大做
• 当前状态：v0.3-MVP Gate N/R/C、本机部署、前后端Gate D、隔离与真实浏览器Gate A及本地范围Gate P均已PASS；当前仅在生成数据回环实例下本地可用，正式线上仍禁止

目标

员工登录系统后，可以自行修改本人的登录密码，不再每次都依赖主管代为修改。

首版只建立“进入修改密码页面 → 验证当前密码 → 设置新密码 → 重新登录”的最小可用闭环，不在同一版本中完成整套账号安全体系重构。

交付与迭代原则

• 第一阶段只交付最小可用闭环，不因未来安全、架构或体验规划扩大本期范围。
• 需求和技术边界清楚且Gate N/R已通过后，直接进入实现；除非范围、安全边界或唯一接口发生实质变化，不再追加重复方案评审。
• 后续发现的增强项进入第二、三阶段清单，不阻塞首版基本功能落地。
• 文档以“足够实现、足够验收、能够追溯”为准，不追求与当前小需求不相称的材料规模。
• 首版执行路线压缩为：前后端最小实现 → 开发自测 → 一次独立代码审核 → 隔离测试环境验收。
• 提高效率不能突破三条底线：只能修改本人密码、当前密码必须正确、密码不得泄露或在后端离线时假成功。

本机部署与真实浏览器验收追加授权

• 只允许部署到当前Windows本机并绑定127.0.0.1，不得监听局域网或公网地址，不得创建开机自启或生产服务。
• 只使用运行时生成的虚构员工、主管和停用账号；不得读取、复制或修改data/现有运行数据，不得使用真实凭据或客户数据。
• 部署对象必须保持COLLAB-147审核通过的前后端精确源码不变；如需修改业务代码，立即停止并返回实现与Gate C。
• 运维必须记录脱敏运行ID、本地URL、进程标识、启动/健康结果和停止入口；不得把密码、Token、完整请求响应或原始日志写入协作记录。
• Gate D由前后端开发分别确认目标运行版本、页面资源和API链路；不得由运维或产品代签。
• 真实浏览器Gate A至少覆盖：登录、改密入口、三字段、错误当前密码不成功、正确改密后退出、旧密码登录失败、新密码登录成功、页面无假成功，以及360px布局检查。
• 浏览器验收通过后本地服务继续保持回环运行，直到Owner要求停止；如无法安全保持运行，应回传BLOCKED并关闭进程。
• 正式生产部署仍不在授权范围，BLOCK-001至BLOCK-003和生产No-Go继续有效。

MVP用户故事

1. 作为已登录员工，我能找到“修改密码”入口。
2. 我输入当前密码、新密码和确认密码后，可以修改本人的密码。
3. 当前密码错误、两次新密码不一致或新密码不符合基本规则时，系统明确提示并且不修改密码。
4. 修改成功后，我退出当前登录，并使用新密码重新登录。
5. 主管现有的员工密码重置能力继续保留，不因为增加员工自主改密而失效。

第一阶段：MVP范围

前端

• 所有启用账号登录后都能看到“修改密码”入口，建议放在当前账号信息或退出按钮附近。
• 修改密码表单只包含：当前密码、新密码、确认新密码、确认修改、取消。
• 密码输入框使用密码类型，不在页面上回显实际密码。
• 提交期间禁止重复点击。
• 至少提供以下提示：当前密码错误、两次输入不一致、新密码不符合规则、修改成功、后端不可用。
• 修改成功后清除当前登录状态并返回登录页。

后端

• 增加员工修改本人密码的独立接口。
• 后端根据当前登录身份确定账号，不接受前端指定要修改的其他用户名。
• 后端必须验证当前密码正确后才能写入新密码。
• 后端再次校验新密码规则，不能只依赖前端校验。
• 修改成功后，旧密码不能继续登录，新密码可以正常登录。
• 修改密码接口后端不可用时，前端不得回退到浏览器本地模拟并显示假成功。
• 当前密码和新密码只允许出现在已认证的专用改密接口请求体中；不得进入URL或查询参数、接口响应、普通日志、协作记录或浏览器持久化。非本地隔离环境必须通过HTTPS传输，本任务仍禁止正式生产部署。

MVP密码规则

• 新密码长度为8至64个字符。
• 新密码不得与当前密码相同。
• 新密码与确认密码必须完全一致。
• 首版不强制大小写、数字和符号组合，避免规则过度复杂。
• 不自动删除用户输入两端的空格；前后端必须采用一致处理方式。

主管重置

• 保留当前“主管编辑员工账号并设置新密码”的能力。
• 首版不增加一次性临时密码、有效期或首次登录强制改密。
• 员工忘记密码时，仍由主管重置；员工登录后可再自行修改成自己的密码。
• 员工不能通过自主改密入口修改其他员工的密码、岗位、权限或账号状态。

第一阶段不做项

• 不做短信、邮件找回密码。
• 不做多因素认证、单点登录或第三方身份服务。
• 不做全员上线后强制修改密码。
• 不做主管重置后的首次登录强制改密。
• 不做随机一次性临时密码及安全交付渠道。
• 不做密码历史、常见泄露密码库和定期强制轮换。
• 不做账号锁定、复杂限流、告警中心或完整安全审计平台。
• 不做多设备会话管理页面。
• 不在本任务中清理Git历史或完成全部运行数据治理；这些仍由CRM-20260717-002负责。
• 不为本功能进行前后端整体模块化重构。
• 不部署到当前正式线上环境；第一阶段只允许在隔离的测试环境完成实现验证。

MVP验收标准

1. 启用中的员工登录后能找到“修改密码”入口。
2. 员工输入正确当前密码、合规新密码和一致的确认密码后，修改成功。
3. 当前密码错误时后端拒绝修改，原密码仍可登录。
4. 两次新密码不一致、长度不合规或新旧密码相同时，系统拒绝修改并给出明确提示。
5. 员工只能修改本人密码，构造他人账号参数也不能修改其他账号。
6. 修改成功后当前页面退出登录；旧密码登录失败，新密码登录成功。
7. 主管原有的新建账号和重置员工密码功能继续可用。
8. 停用账号不能登录，因此也不能使用自主改密功能。
9. 后端断开时修改密码不得显示成功，也不得写入浏览器本地模拟数据。
10. 页面、接口响应和普通日志中不出现新旧密码值。

后续阶段

第二、三阶段必须另行冻结范围和验收；不能因为后续内容未实现，就把第一阶段已具备的基本功能描述为不存在。但第一阶段完成也不能被描述为全部账号安全风险已关闭或业务系统已经满足正式上线条件。

角色矩阵

已知风险与边界

• 当前系统的密码保存和登录凭证机制仍属于P0风险。MVP收敛是为了先完成基本功能，不代表接受明文密码作为长期方案。
• 第一阶段可以形成可测试实现，但本需求版本明确禁止部署到当前正式线上环境。未来若申请线上部署，必须另行获得Owner授权并通过当时适用的安全、测试、部署和发布Gate。
• BLOCK-001至BLOCK-003和项目整体No-Go不会因MVP完成自动解除。

Owner决策（已确认）

1. 首版密码长度为8至64个字符，暂不强制大小写、数字和符号组合。
2. 修改成功后直接退出当前登录，员工使用新密码重新登录。
3. 首版继续沿用主管当前的密码重置方式，不做一次性临时密码和首次登录强制改密。
4. 第一阶段只在隔离测试环境验证，暂不部署到当前正式线上环境。
5. 本需求按“小步快跑”推进：先完成基本功能，再分段完善；避免重复评审和过度设计，提高交付效率。

以上五项由Owner于2026-07-17确认。前三项采用产品建议，第四项由Owner明确决定“先不部署到线上”，第五项由Owner在Gate R通过后再次强调。后续若改变任一决策，必须建立新的变更记录并重新判断受影响Gate，不得在实现中自行扩展。