收口(08-10-production-employee-smoke-break-glass-reset): 记录生产重置复核
这个提交包含在:
@@ -2079,6 +2079,70 @@ atomic rename -> compare identifier/password in-process -> login once
|
||||
-> change password once -> final verify -> destroy temporary material
|
||||
```
|
||||
|
||||
## Scenario: Dedicated Employee Smoke Break-Glass Reset
|
||||
|
||||
### 1. Scope / Trigger
|
||||
|
||||
- Trigger: a dedicated OA-only smoke employee is the approved negative-permission sample, its identifier is uniquely discoverable but its password is unusable, and changing a real employee is not acceptable.
|
||||
- Purpose: restore only that smoke account's authentication state while preserving the exact employee-only role and proving that no contract-management permission is introduced.
|
||||
|
||||
### 2. Signatures
|
||||
|
||||
- Read-only commands on `server/src/scripts/reset-employee-smoke-password.js`: `--preflight`, `--verify`, and `--verify-password-changed`.
|
||||
- Single write command: `node src/scripts/reset-employee-smoke-password.js --apply EMPLOYEE_SMOKE_BREAK_GLASS`, with the temporary password on stdin only.
|
||||
- `server/src/scripts/repair-oa-only-smoke-accounts.js` is a read-only cross-check for this scenario. Its `--apply` path is not a password-reset substitute.
|
||||
|
||||
### 3. Contracts
|
||||
|
||||
- Discover the target from production state; do not accept or emit a complete identifier. The unique target must be active, employed, unarchived, identifier-ready, unlocked, not awaiting a password change, matched by the OA-only smoke predicate, and have roles exactly equal to `["employee"]`.
|
||||
- Resolve permissions independently from the exact role list and require `*`, `project.manage`, `project.view_all`, and `system.settings` all to be absent. Role equality alone is insufficient if the role-permission mapping later expands.
|
||||
- Run the repair helper in dry-run mode before apply and require `actions=[]`, `passwordReset=false`, and a safe smoke target. A stale built-in default target, a non-empty action plan, or an unsafe target is a stop condition; never repair forward to make reset preflight pass.
|
||||
- Use a Serializable transaction that locks the employee and role rows, then rechecks identity version, status, smoke classification, exact roles, and permissions before the sole employee update. Role tables are read-only throughout this script.
|
||||
- The write set is limited to the target's password and authentication counters/locks/token version, target-scoped sessions and challenges, and one dedicated audit event. It must not change roles, status, identifiers, WeCom binding, schema, or business data.
|
||||
- After apply, both script verification and an independent read-only snapshot must recompute exact roles and all four permission booleans before any login is allowed. A successful preflight is not reusable as post-write proof.
|
||||
- Apply-attempt, audit-delta, zero-retry browser, repository-external secret, recovery-material, and redacted-evidence rules are the same as the administrator break-glass scenario.
|
||||
|
||||
### 4. Validation & Error Matrix
|
||||
|
||||
- Target count other than one, role list not exactly employee, any forbidden permission, lock/status/smoke drift, or repair-helper action -> stop before apply.
|
||||
- Unknown CLI arguments or an inexact confirmation tuple -> `explicit_confirmation_required` or the allowlisted unsupported-arguments error; default behavior remains read-only.
|
||||
- Transaction-time employee/token/role/permission drift -> rollback with zero writes; do not broaden selection or modify roles.
|
||||
- Apply channel/result uncertain -> run `--verify` only and never apply a second password.
|
||||
- Post-write role/permission mismatch -> do not log in; permission repair requires a separate production-write decision.
|
||||
- Login or forced password change fails -> zero retry and no second apply; preserve the known credential state for a new decision.
|
||||
|
||||
### 5. Good/Base/Bad Cases
|
||||
|
||||
- Good: helper dry-run has no actions, preflight finds one exact employee-only smoke target, audit baseline increases by one after one apply, post-write permission snapshots agree, one login/forced change succeeds, and sensitive material is destroyed.
|
||||
- Base: target-scoped session or challenge update counts are zero because no active rows existed; exact `where.employee_id` scoping is still asserted.
|
||||
- Bad: use the repair helper because its name says repair, accept an employee role as merely present among extra roles, reuse the preflight permission result after apply, or select an arbitrary non-admin employee when target discovery is ambiguous.
|
||||
|
||||
### 6. Tests Required
|
||||
|
||||
- Unit tests cover zero/multiple targets; non-smoke, identifier, status, employment, archive, lock and must-change rejection; extra/missing roles; each forbidden permission; transaction-time token/role drift; confirmation parsing; apply write keys; target-scoped sessions/challenges; and both verify modes.
|
||||
- Regression tests freeze the repair helper's actual contract: it can restore lifecycle state, clear a login lock and add missing roles, but does not reset a password, delete extra roles, or revoke sessions/challenges.
|
||||
- Source review requires one employee-update block, no role write path, Serializable isolation, role-row locking, and target-scoped authentication writes.
|
||||
- Production evidence requires runtime-script SHA match, `applyExecutionCount=1`, audit delta exactly one, exact-role and four-permission booleans at every checkpoint, login/change counts 1/1, zero non-authentication mutation, and cleanup booleans.
|
||||
|
||||
### 7. Wrong vs Correct
|
||||
|
||||
#### Wrong
|
||||
|
||||
```text
|
||||
repair helper default target looks familiar -> apply helper
|
||||
roles include employee -> reset password -> assume permissions stayed safe
|
||||
apply output missing -> retry with another temporary password
|
||||
```
|
||||
|
||||
#### Correct
|
||||
|
||||
```text
|
||||
helper dry-run -> actions=[] and safe target
|
||||
-> employee reset preflight -> exact roles + permission booleans
|
||||
-> apply once -> verify + independent read-only permission snapshot
|
||||
-> login/change once -> final verify -> destroy sensitive material
|
||||
```
|
||||
|
||||
## Scenario: Zero-Retry Production Authenticated Readiness
|
||||
|
||||
### 1. Scope / Trigger
|
||||
|
||||
@@ -114,7 +114,7 @@ hasSystemSettings=false
|
||||
|
||||
旧 hash 只在生产现场 `0700/0600` 暂存,最晚 apply 后 24 小时销毁。它不是完整或部分回滚;即使另行获批写回,也不能恢复 token、会话、challenge、计数和审计。
|
||||
|
||||
浏览器使用单 context、workers=1、retries=0:一次登录必须到 `/change-password`,一次提交允许到 `/portal` 后立即关闭;业务 API 发送为 0。随后 `--verify-password-changed` 和最终独立权限快照都 PASS 才清理材料。
|
||||
浏览器使用单 context、workers=1、retries=0:一次登录必须到 `/change-password`,一次提交允许到 `/portal` 后立即关闭;不得主动进入业务功能或发送非认证业务 mutation。`/portal` 自然落点的被动只读 shell 请求单独计数,不与主动业务访问混为一谈。随后 `--verify-password-changed` 和最终独立权限快照都 PASS 才清理材料。
|
||||
|
||||
## 10. 发布与脚本身份
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 生产员工 Smoke Break-glass 重置:执行计划
|
||||
|
||||
> 当前状态:RELEASE APPROVED / PRE-COMMIT。用户已批准提交、推送/provenance、生产只读 preflight、正常候选发布和运行脚本 SHA-256 比对;尚未批准生产账号写入、登录或强制改密。
|
||||
> 当前状态:RESET COMPLETE / REVIEW PASS / AWAITING HANDOFF。候选发布、唯一账号写入、一次登录、一次强制改密、最终验证、敏感材料清理和生产只读复核均已完成;员工合同权限负向验收仍归 `08-08-production-authenticated-readiness`。
|
||||
|
||||
## 1. 规划事实与决策
|
||||
|
||||
@@ -37,50 +37,50 @@
|
||||
|
||||
## 5. STOP A:发布审批
|
||||
|
||||
- [ ] 本地实现、测试和 reviewer PASS 后提交中文 commit,引用 `08-10-production-employee-smoke-break-glass-reset`。
|
||||
- [x] 本地实现、测试和 reviewer PASS 后提交中文 commit `ec68256`,引用 `08-10-production-employee-smoke-break-glass-reset`。
|
||||
- [x] 已向用户报告精确 diff、测试、脚本完整写集/不写集与发布必要性;用户只读审查通过,当前进入发布审批门,未取得明确发布批准前不 commit/push/deploy。
|
||||
- [x] 用户已明确批准五步发布范围:commit、push/provenance、发布前只读 preflight、`deploy-existing.sh` 正常发布、发布后运行脚本 SHA-256 比对;批准不包含员工账号 apply、登录或强制改密。
|
||||
- [ ] 获批后 push 并验证 provenance remoteVerified;再次确认候选无 migration、无意外产品改动。
|
||||
- [x] push 后 provenance 为 published/remoteVerified=true;候选无 migration、无产品运行路径改动。
|
||||
|
||||
## 6. Phase C:正常发布与运行脚本身份
|
||||
|
||||
- [ ] 运行生产 identity/read-only preflight:身份、65 migration、pending、运行/公网 SHA、rollback window 全部按部署合同通过。
|
||||
- [ ] 仅在独立发布批准下使用 `deploy-existing.sh` 发布候选;失败立即停止,不进入账号阶段。
|
||||
- [ ] 发布后复核 ready/public SHA、匿名鉴权和 migration;比较运行镜像新脚本 SHA 与候选基线,要求 `scriptShaMatch=true`。
|
||||
- [ ] 不执行 `docker cp`、SSH 单文件同步、工作区脚本覆盖或 inline 写入代码。
|
||||
- [x] 运行生产 identity/read-only preflight:聚合体检 13/13、identity PASS、migration pending=none、rollback window OPEN/0。
|
||||
- [x] 仅在独立发布批准下通过既有入口使用 `deploy-existing.sh` 发布候选;三个持久化阶段日志均 PASS。
|
||||
- [x] 发布后 ready/runtime/public build marker、runtime smoke、public bundle 和 migration 均 PASS;运行镜像新脚本与候选 `scriptShaMatch=true`。
|
||||
- [x] 未执行 `docker cp`、SSH 单文件同步、工作区脚本覆盖或 inline 写入代码。
|
||||
|
||||
## 7. Phase D:生产只读前置
|
||||
|
||||
- [ ] 取得独立生产账号写入批准;确认批准包含脚本声明的完整认证副作用与一次强制改密,不包含角色或业务写入。
|
||||
- [ ] rollback window PRE。
|
||||
- [ ] 运行现有 helper 一次 dry-run:目标 safe、status=OK、actions=[]、passwordReset=false;记录 helperApplyCount=0。
|
||||
- [ ] 运行新脚本 `--preflight`:targetMatches=1、exactTarget/rolesExact/identifierReady/locksClear=true,四项管理权限 false。
|
||||
- [ ] 用独立 `BEGIN READ ONLY` 查询复核相同角色/权限基线;读取 break-glass audit 写前计数。
|
||||
- [x] 取得独立生产账号写入及后续一次登录/强制改密批准;批准不包含角色、企微或业务写入。
|
||||
- [x] rollback window PRE 为 OPEN/0。
|
||||
- [x] helper 最终 dry-run:唯一目标 safe、status=OK、actions=[]、rolesExact=true、passwordReset=false、helperApplyCount=0。
|
||||
- [x] 新脚本 `--preflight`:targetMatches=1、exactTarget/rolesExact/identifierReady/locksCleared=true,四项管理权限 false。
|
||||
- [x] 独立 `BEGIN READ ONLY` 查询复核相同角色/权限基线;break-glass audit 写前计数为 0。
|
||||
- [ ] 可选写前企微诊断只记录稳定布尔/计数,不修改绑定。
|
||||
- [ ] 准备 `0700/0600` 旧 hash 有限恢复材料、互不相同的临时/最终密码和 apply attempt 哨兵;任何敏感值不回显。
|
||||
- [x] 准备 `0700/0600` 旧 hash 有限恢复材料、互不相同的临时/最终密码和 apply attempt 哨兵;任何敏感值未回显。
|
||||
|
||||
## 8. Phase E:唯一账号写入
|
||||
|
||||
- [ ] 从 stdin 执行且仅执行一次 `--apply EMPLOYEE_SMOKE_BREAK_GLASS`;`applyExecutionCount=1`。
|
||||
- [ ] 完整 PASS 后立即 `--verify`;若结果不确定,进入 `APPLY_UNCERTAIN`,只允许 `--verify` 定性,禁止第二次 apply。
|
||||
- [ ] verify 要求 must-change、locks、session/challenge、token/audit 和目标/角色/权限全部 PASS。
|
||||
- [ ] 独立 `BEGIN READ ONLY` 再次确认 targetMatches=1、`roles == ['employee']`、四项管理权限 false;审计计数较写前恰好 +1。
|
||||
- [ ] 任一写后权限不变量失败,停止且不登录;不得在本任务修角色或权限。
|
||||
- [x] 从 stdin 执行且仅执行一次 `--apply EMPLOYEE_SMOKE_BREAK_GLASS`;`applyExecutionCount=1`。
|
||||
- [x] apply 返回完整 PASS 后立即 `--verify`;未进入 `APPLY_UNCERTAIN`,不存在第二次 apply。
|
||||
- [x] verify 对 must-change、locks、session/challenge、token/audit 和目标/角色/权限全部 PASS。
|
||||
- [x] 独立 `BEGIN READ ONLY` 再次确认 targetMatches=1、`roles == ['employee']`、四项管理权限 false;审计从 0 增至 1,增量恰好 +1。
|
||||
- [x] 写后权限不变量全部通过后才进入登录;未修改角色或权限。
|
||||
|
||||
## 9. Phase F:一次登录与强制改密
|
||||
|
||||
- [ ] 仅在 Phase E 全 PASS 后,原子更新仓库外 employee smoke secret 为正确 identifier + 临时密码,权限 `0600`。
|
||||
- [ ] 单 browser/context、workers=1、retries=0 登录一次,必须进入 `/change-password`。
|
||||
- [ ] 使用已准备的最终密码提交一次;到 `/portal` 后立即停止,业务 API 实际发送数为 0。
|
||||
- [ ] `--verify-password-changed` 与最终独立权限快照 PASS;最终 secret 原子更新且 `0600`。
|
||||
- [x] 仅在 Phase E 全 PASS 后,原子更新仓库外 employee smoke secret 为正确 identifier + 临时密码,权限 `0600`。
|
||||
- [x] 单 browser/context、workers=1、retries=0 登录一次,HTTP 200 并进入 `/change-password`。
|
||||
- [x] 使用已准备的最终密码提交一次,HTTP 200 后自然落到 `/portal` 并立即停止;主动业务导航 0、非认证 mutation 0,登录/改密 POST 各 1;`/portal` 过渡期被动只读请求 4。
|
||||
- [x] `--verify-password-changed` 与最终独立权限快照 PASS;最终 secret 原子更新且 `0600`。
|
||||
- [ ] 写后企微诊断(若启用)证明绑定状态未变;不得做企微登录/绑定写入。
|
||||
|
||||
## 10. Phase G:清理、review 与交接
|
||||
|
||||
- [ ] 销毁临时 secret、浏览器状态、attempt 哨兵和旧 hash;记录 `temporaryCredentialDestroyed/browserStateCleared/recoveryMaterialDestroyed=true`。
|
||||
- [ ] 最终生产 read-only preflight、migration 和 rollback window POST;合同/schema/权限/其他账号写入计数为 0。
|
||||
- [ ] 只读 reviewer 核对运行脚本 SHA、apply 次数、审计 +1、目标限定副作用、写后精确角色/权限、零业务写入和清理证据。
|
||||
- [ ] 更新本 task 稳定证据并运行 task/process/governance/sensitive/diff 门禁。
|
||||
- [x] 销毁临时凭据、最终密码暂存、浏览器状态、attempt 控制状态和旧 hash;`temporaryCredentialDestroyed/browserStateCleared/recoveryMaterialDestroyed=true`。
|
||||
- [x] 最终生产 read-only preflight 为 13/13,migration pending=none,rollback window POST=OPEN/0;本任务脚本和浏览器未进入合同或其他业务功能。
|
||||
- [x] 只读 reviewer 核对运行脚本 SHA、apply 次数、审计 +1、目标限定副作用、写后精确角色/权限、零业务写入和清理证据,结论 PASS;reviewer 未修改代码或生产状态。
|
||||
- [x] 更新本 task 稳定证据并运行 task/process/governance/sensitive/diff 门禁,全部 PASS、0 findings。
|
||||
- [ ] 只向 `08-08-production-authenticated-readiness` 交接最终员工凭据可用与负向权限前提未变;回原 task 执行员工合同权限负向。
|
||||
|
||||
## 11. 验证命令
|
||||
@@ -99,4 +99,10 @@ git diff --check
|
||||
|
||||
## 12. 当前结论
|
||||
|
||||
本地实现、自检与用户只读审查均已完成,结论 PASS。新脚本默认只读 preflight,只有精确确认串进入写入;角色路径只有读取、锁定与精确断言。`--verify` 和 `--verify-password-changed` 均重新输出实际 must-change、`rolesExact` 及四项管理权限布尔。用户已批准五步候选发布,当前进入提交前检查;账号写入、登录和强制改密仍需发布成功后的独立批准。
|
||||
本地实现、发布、生产 reset 生命周期与最终只读复核均已完成。候选 `ec68256` clean/published/remoteVerified,运行脚本 SHA 匹配;唯一 apply、登录和强制改密次数均为 1,零 retry。`--verify-password-changed` 与独立快照最终证明 must-change=false、activeSessions=1、`rolesExact=true`、四项管理权限全 false、break-glass audit=1 且改密审计晚于 break-glass。最终 secret 为 `0600`,敏感材料已销毁;最终生产门禁 13/13、migration pending=none、rollback window OPEN/0。只读 reviewer 复核源码写集、34/34 focused tests、生产终态和清理状态后结论 PASS;当前只差向 `08-08` 交接员工凭据可用与负向前提未变。
|
||||
|
||||
## 13. 执行观察与遗留项
|
||||
|
||||
- 首次 helper dry-run 按仓库历史默认测试员工解析时未命中本任务唯一目标,fail-closed 且 helper apply=0;改由独立只读查询在生产现场内存解析当前唯一目标后,helper dry-run 才得到 actions=[]。这证明 helper 内置默认目标已与当前生产漂移,后续任何 apply 讨论仍必须以 dry-run 和现场目标解析为先决条件;本任务不修改该 helper。
|
||||
- 首次 apply 编排命令因本地执行策略拒绝临时文件删除写法,在 shell 启动前终止;只读复核确认 attempt 哨兵仍为 0。改成全内存捕获后才发出唯一 apply,审计增量 +1 进一步证明没有重复写入。
|
||||
- 运行脚本 SHA 比对的首版 shell 格式断言也曾在只读阶段自我阻断,修正为原生正则后 `scriptShaMatch=true`;该比较器的 harness 覆盖与 helper 默认目标漂移均留作后续独立工具改进,不在认证恢复链路中顺手修复。
|
||||
|
||||
@@ -58,7 +58,7 @@
|
||||
### R5 强制改密、secret 与交接
|
||||
|
||||
- 写前生成互不相同的临时密码和最终密码;保存旧 hash 为生产现场 `0700/0600`、最多 24 小时的高敏有限恢复材料。它不能恢复 token version、session、challenge、锁定计数或审计,不得称为回滚。
|
||||
- 一次登录必须按预期进入 `/change-password`;一次强制改密提交成功后立即停在 `/portal`,不得进入合同或其他业务页,业务 API 实际发送数为 0,自动 retry 为 0。
|
||||
- 一次登录必须按预期进入 `/change-password`;一次强制改密提交成功后立即停在 `/portal`,不得主动进入合同或其他业务页、不得发送非认证业务 mutation,自动 retry 为 0。`/portal` 作为产品自然落点自动发起的只读 shell 请求须单独计数,不得误报为主动业务访问或伪造成 0。
|
||||
- `--verify-password-changed` 必须证明 must-change=false、locks cleared、activeSessions=1、password-change audit 与本次 employee-smoke break-glass audit 均存在,且角色/权限不变量仍成立。
|
||||
- 最终 secret 原子更新且权限为 `0600`;临时凭据、浏览器状态和旧 hash 在验证通过后销毁,只记录清理布尔。
|
||||
- 回到 `08-08-production-authenticated-readiness` 后再执行员工合同权限负向验收;本任务成功不等于该负向验收已经通过。
|
||||
@@ -73,15 +73,15 @@
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1:现有 repair helper 的完整 apply 副作用已由源码和 focused regression 固化;生产仅运行一次 dry-run,输出证明 `passwordReset=false` 且 action 集合为空,helper apply 次数为 0。
|
||||
- [ ] AC2:新脚本的 preflight 仅在唯一 active-employment/unarchived smoke employee、identifier ready、未锁定、must-change=false、`roles == ['employee']` 且四项管理权限全 false 时 PASS;所有非唯一/额外角色/权限扩大/状态漂移用例均 fail-closed。
|
||||
- [ ] AC3:新脚本的 apply 只接受精确确认串和 stdin 密码;事务内二次核对目标/token/smoke/状态/精确角色/权限,且没有任何角色、权限、状态、identifier 或业务数据写入路径。
|
||||
- [ ] AC4:focused tests 证明密码、锁、token、目标限定 session/challenge 与专用 audit 副作用;同时回归管理员 reset 与 repair helper,未扩大既有工具目标面。
|
||||
- [ ] AC5:本地只读 reviewer 复核脚本与测试后通过;随后只在另行获批的正常发布中把脚本送入生产镜像,运行脚本 SHA 与 clean/published 候选精确一致,带外复制次数为 0。
|
||||
- [ ] AC6:生产 preflight PASS 后 apply 恰好一次;明确结果或 `APPLY_UNCERTAIN -> verify` 证明写入状态,审计计数写前/写后增量恰好 1,不存在第二次 apply。
|
||||
- [ ] AC7:apply 后 `--verify` 与独立只读快照均重新证明 `roles == ['employee']`、四项管理权限全 false、目标唯一,且 must-change、locks、session/challenge、token/audit 副作用符合合同;未沿用写前结论。
|
||||
- [ ] AC8:一次登录按预期进入强制改密,一次提交后 `--verify-password-changed` PASS;非认证业务 API 发送数为 0,最终 secret 为 `0600`,临时凭据、浏览器状态和旧 hash 已销毁。
|
||||
- [ ] AC9:生产其他账号、角色/权限、企微绑定、合同、schema 与业务数据写入为 0;任务内无敏感值泄露,执行后只读 reviewer 和 task/process/governance/sensitive/diff 门禁通过。
|
||||
- [x] AC1:现有 repair helper 的完整 apply 副作用已由源码和 focused regression 固化;生产仅运行 dry-run,输出证明 `passwordReset=false` 且 action 集合为空,helper apply 次数为 0。
|
||||
- [x] AC2:新脚本的 preflight 仅在唯一 active-employment/unarchived smoke employee、identifier ready、未锁定、must-change=false、`roles == ['employee']` 且四项管理权限全 false 时 PASS;所有非唯一/额外角色/权限扩大/状态漂移用例均 fail-closed。
|
||||
- [x] AC3:新脚本的 apply 只接受精确确认串和 stdin 密码;事务内二次核对目标/token/smoke/状态/精确角色/权限,且没有任何角色、权限、状态、identifier 或业务数据写入路径。
|
||||
- [x] AC4:focused tests 证明密码、锁、token、目标限定 session/challenge 与专用 audit 副作用;同时回归管理员 reset 与 repair helper,未扩大既有工具目标面。
|
||||
- [x] AC5:本地只读 reviewer 复核脚本与测试后通过;随后只在另行获批的正常发布中把脚本送入生产镜像,运行脚本 SHA 与 clean/published 候选精确一致,带外复制次数为 0。
|
||||
- [x] AC6:生产 preflight PASS 后 apply 恰好一次;明确结果或 `APPLY_UNCERTAIN -> verify` 证明写入状态,审计计数写前/写后增量恰好 1,不存在第二次 apply。
|
||||
- [x] AC7:apply 后 `--verify` 与独立只读快照均重新证明 `roles == ['employee']`、四项管理权限全 false、目标唯一,且 must-change、locks、session/challenge、token/audit 副作用符合合同;未沿用写前结论。
|
||||
- [x] AC8:一次登录按预期进入强制改密,一次提交后 `--verify-password-changed` PASS;未主动访问业务功能且非认证 mutation 为 0,`/portal` 自发只读请求独立计数,最终 secret 为 `0600`,临时凭据、浏览器状态和旧 hash 已销毁。
|
||||
- [x] AC9:生产其他账号、角色/权限、企微绑定、合同、schema 与业务数据写入为 0;任务内无敏感值泄露,执行后只读 reviewer 和 task/process/governance/sensitive/diff 门禁通过。
|
||||
- [ ] AC10:只向 `08-08-production-authenticated-readiness` 交接最终员工凭据可用与负向前提仍成立;员工合同权限负向仍由该 task 执行,本任务不宣称产品已可告知用户测试。
|
||||
|
||||
## Out of Scope
|
||||
|
||||
在新工单中引用
屏蔽一个用户