docs(auth): clarify staged PR workflow

docs/21-unified-identity-federation-design.md

@@ -380,8 +380,9 @@ Registry 和 capability；同时使用 C 处理长尾和高运维成本协议。
 决定如下：
 
 1. 第一个核心架构阶段（在 P0 安全热修之后）只引入统一身份核心并迁移现有
-   OAuth/OIDC，不增加新协议。所有阶段统一在 #628 和本设计 PR 中跟踪，不再拆出
-   子 issue 或并行 PR。
+   OAuth/OIDC，不增加新协议。总范围统一由父 issue #628 跟踪，#630 只作为设计 PR；
+   后续实现按阶段逐个创建 PR、逐个验证并合入 `main`，不再拆出子 issue，也不提前批量
+   打开多个并行实现 PR。
 2. Provider Adapter 按 Browser、Credential、Passive 等交互类型分别集成，不建立万能
    `authenticate(Object credentials)`。
 3. 第一阶段是构建时可信模块，不提供运行时第三方 JAR。
@@ -2180,13 +2181,22 @@ GitHub/GitLab/OIDC：
 6. 检查日志、审计、指标和数据库迁移。
 7. 人工验证对应登录 UI、错误页和账号设置。
 8. 记录镜像、commit、测试命令和结果。
-9. 全部通过后再由维护者决定是否把主 PR 更新到可进入 `main` 的状态。
+9. 全部通过后再由维护者决定是否把当前阶段 PR 更新到可进入 `main` 的状态。
 
 ## 20. 分阶段实施计划
 
-本工作统一在父 issue #628 和主设计/实现 PR #630 中跟踪。为降低认证边界风险，主 PR
-内部仍按阶段提交和验收；每个阶段必须聚焦，不把协议、核心、数据库大迁移和 UI 重构混在
-一起。原先拆出的子 issue/PR 关闭后，其范围、验收和证据回收到本节。
+本工作统一在父 issue #628 中跟踪，#630 只负责设计、阶段计划和验收标准。为降低认证
+边界风险，后续实现按阶段逐个创建 PR、逐个处理、逐个合入 `main`；不要一次性打开多个
+阶段 PR。每个阶段必须聚焦，不把协议、核心、数据库大迁移和 UI 重构混在一起。原先拆出
+的子 issue/PR 关闭后，其范围、验收和证据回收到本节。
+
+阶段 PR 协作规则：
+
+- 只保留一个父 issue #628，不再为阶段拆子 issue。
+- #630 合并后作为后续实现的设计依据，不承载所有实现提交。
+- 每次只创建并推进当前阶段 PR；当前阶段合并或明确暂停后，再创建下一阶段 PR。
+- 每个阶段 PR 在正文中引用 #628，并标明对应阶段、范围、非范围、验收命令和回滚风险。
+- 阶段完成状态回写到 #628，避免用多个 open PR 承载任务状态。
 
 依赖关系：
 
@@ -2490,6 +2500,9 @@ LDAP 和 DingTalk 不要求必须由维护者亲自编码。更准确的规则
 
 ### 21.3 当前 PR 的协作方式
 
+#630 是设计 PR，不承载后续所有实现。实现阶段按第 20 节逐个创建 PR，并在合入 `main`
+后再推进下一个阶段，除非维护者明确批准并行。
+
 #437、#467 暂时保持开放：
 
 1. 告知作者统一身份核心正在冻结。
@@ -2498,7 +2511,7 @@ LDAP 和 DingTalk 不要求必须由维护者亲自编码。更准确的规则
    - 自己迁移到新 Adapter；
    - 同意维护者提取协议客户端和测试；
    - 由其他社区贡献者接手。
-4. 主 PR 中的替代实现真正进入 `main` 后再决定是否以 superseded 关闭。
+4. 对应阶段 PR 中的替代实现真正进入 `main` 后再决定是否以 superseded 关闭。
 5. 关闭或替代时保留需求来源、设计探索和原作者贡献说明。
 
 ## 22. 待决问题