docs: 固化 L1 固定工作区收口
This commit is contained in:
@@ -90,8 +90,13 @@ description: >-
|
||||
- 禁止随机端口、临时 URL、命令行覆盖和代码默认值。
|
||||
- L1 验收以 native 服务为准:
|
||||
- lifecycle status 必须证明 API、Worker 和 Web 进程仍在运行且 health ready;
|
||||
- lifecycle status 必须披露运行进程选中的源码 workspace 和 commit,并与本次修改所在的受控 workspace 一致;
|
||||
- 任务 worktree 可以承载短反馈迭代,但不得成为 L1 完成运行面;
|
||||
- 宣称 L1 完成前,已验收语义必须以边界明确的提交合入 owning YAML 选定的固定 L1 workspace;
|
||||
- 合入后必须通过项目 lifecycle CLI 重载受影响进程,并从固定端口重新回归;
|
||||
- lifecycle status 必须披露运行进程选中的源码 workspace 和 commit,并与固定 L1 workspace 一致;
|
||||
- 源码 provenance 缺失或不一致时不得用页面结果判定修复通过,应先修复受控 CLI 可见性或按 owning YAML 重新选择源码;
|
||||
- 仍有已验收语义只存在于任务 worktree、未提交 diff 或临时产物时,L1 必须保持未完成;
|
||||
- 详细收口合同以 `docs/reference/dev-environment.md#l1-固定工作区收口` 为唯一权威;
|
||||
- CLI 必须通过 native `--over-api` 完成真实业务操作;
|
||||
- Web 必须通过 native Web 完成受影响页面和交互;
|
||||
- localhost 或 probe host 只要来自 owning YAML,就可以作为同 host L1 证据。
|
||||
|
||||
@@ -8,6 +8,7 @@
|
||||
- 持久化 `unidesk-dev` 环境;
|
||||
- 公开开发前端端口;
|
||||
- `deploy apply --env dev`;
|
||||
- L1 任务 worktree 向固定 workspace 的收口;
|
||||
- Rust backend-core 构建边界。
|
||||
|
||||
发布线和开发 lane 治理由 `docs/reference/release-governance.md` 与
|
||||
@@ -119,10 +120,38 @@ trans D601:/home/ubuntu/workspace/unidesk-dev git remote -v
|
||||
- L1 任务不进入 CI/CD、Kubernetes 和 public-edge 调查或操作。
|
||||
- L1 源码 provenance 是 lifecycle 状态的一部分:
|
||||
- 聚合 `status` 应同时披露 owning YAML 固定 repo、实际选中的 source workspace、commit 和进程工作目录一致性;
|
||||
- source workspace 可以是固定 workspace,也可以是 owning YAML 受控选择且属于固定 repo 的任务 worktree;
|
||||
- 迭代期间的 source workspace 可以是固定 workspace,也可以是 owning YAML 受控选择且属于固定 repo 的任务 worktree;
|
||||
- L1 完成时的 source workspace 必须回到 owning YAML 选定的固定 workspace,并满足下一节的收口合同;
|
||||
- 浏览器、CLI 或 smoke 命中其他 workspace 的旧代码时,结果只能证明旧运行面,不得作为当前修改的验收证据;
|
||||
- 状态缺少这些字段属于受控 CLI 可见性缺陷,应在当前 L1 任务内修复或登记到既有 source-worktree 改进任务,禁止用裸进程探测固化第二套验收流程。
|
||||
|
||||
## L1 固定工作区收口
|
||||
|
||||
- 任务 worktree 只承载隔离开发和短反馈迭代:
|
||||
- 可以从受控 worktree 启动临时 native 进程或 HMR 预览;
|
||||
- 此类结果只证明迭代版本,不能证明固定 L1 运行面已经更新;
|
||||
- 不得因为页面、CLI 或 smoke 在任务 worktree 中通过,就宣称 L1 完成。
|
||||
- 宣称 L1 完成前必须按顺序完成以下动作:
|
||||
- 把本任务已验收的全部语义整理为边界明确的提交;
|
||||
- 将该提交语义合入 owning YAML 选定的固定 L1 workspace 和其固定跟踪分支;
|
||||
- 保留固定 workspace 中无关的并行改动,禁止用 reset、覆盖式 checkout 或文件复制代替语义合并;
|
||||
- 确认没有已验收语义只留在任务 worktree、未提交 diff 或临时产物中;
|
||||
- 通过项目 lifecycle CLI 从固定 workspace 重载或重启受影响的 API、Worker 和 Web;
|
||||
- 重新读取聚合 `status`,确认 repo、workspace、commit 和进程工作目录都指向固定 L1 workspace;
|
||||
- 从固定端口重新执行受影响的 CLI、API、Workflow 或 Web 回归。
|
||||
- HMR 不改变收口要求:
|
||||
- 固定 workspace 合入后由 HMR 自动更新页面,可以不做无意义的前端进程重启;
|
||||
- API、Worker 或未被 HMR 接管的进程仍须通过 lifecycle CLI 重载;
|
||||
- 最终 provenance 和回归证据必须来自固定 workspace 合入后的版本。
|
||||
- L1 本地合入不等于 L2 发布:
|
||||
- 固定 workspace 收口不依赖 CI/CD、镜像、Kubernetes 或集群 rollout;
|
||||
- 后续进入 L2 时,再按项目 Git 和发布规则推送并交付同一语义。
|
||||
- 固定 workspace 暂时无法完成语义合并时:
|
||||
- 保留任务 worktree 和提交,不得删除或丢弃;
|
||||
- 将 L1 状态保持为未完成并报告具体阻塞;
|
||||
- 不得把仍指向任务 worktree 或旧固定版本的公网地址作为完成入口交付。
|
||||
- 任务 worktree 只有在固定 workspace 已吸收全部语义、固定入口回归通过且不存在未吸收提交后才能清理。
|
||||
|
||||
## L1 受控 CLI 即时修复
|
||||
|
||||
- 执行 L1 开发、诊断或验收时,发现项目受控 CLI 存在问题即可在当前任务内即时修改:
|
||||
|
||||
Reference in New Issue
Block a user