Merge remote-tracking branch 'origin/master' into feat/2010-hwlab-release-production-lane
This commit is contained in:
Codex
@@ -55,7 +55,7 @@
|
||||
- 分流顺序：
|
||||
|
||||
- 可复用工作流进入 skill `SKILL.md`，例如：
|
||||
- `$dad-dev`、`$unidesk-cicd`、`$unidesk-gh`；
|
||||
- `$unidesk-daddev`、`$unidesk-cicd`、`$unidesk-gh`；
|
||||
- `$unidesk-trans`、`$unidesk-otel`、`$unidesk-webdev`；
|
||||
- `$unidesk-ymalops`。
|
||||
- 稳定项目约束、工作区规则、架构边界和验收标准进入 `docs/reference/*.md`。
|
||||
@@ -132,7 +132,7 @@
|
||||
- CLI 行为与输出：`docs/reference/cli.md`。
|
||||
- YAML-first 配置：`docs/reference/yaml-first-ops.md` 与 `$unidesk-ymalops`。
|
||||
- 平台基础设施：`docs/reference/platform-infra.md`；涉及 Sub2API 时使用 `$unidesk-sub2api`。
|
||||
- 分布式现场修复：`$dad-dev` 与 `docs/reference/devops-hygiene.md`。
|
||||
- 分布式现场修复：`$unidesk-daddev` 与 `docs/reference/devops-hygiene.md`。
|
||||
- CI/CD 与发布：`$unidesk-cicd` 与 `docs/reference/cli.md`。
|
||||
- GitHub issue 与 PR 写入：`$unidesk-gh`。
|
||||
- Trans/远端补丁传输：`$unidesk-trans` 与 `docs/reference/cli.md`。
|
||||
|
||||
@@ -46,26 +46,41 @@ AgentRun 源码仓目标 branch 的任何变更都必须通过 GitHub PR 合并
|
||||
|
||||
## 部署目标
|
||||
|
||||
AgentRun 废弃旧 `dev/prod` 和非 NC01 node 运行口径。固定部署目标是 NC01 k3s 的 AgentRun namespace：
|
||||
AgentRun 固定在 NC01 k3s，按 **namespace 隔离** 拆分 development / production 两条 lane（同集群，非独立物理集群）。身份真相是 `config/agentrun.yaml#controlPlane.lanes`；跟踪见 [UniDesk #2154](https://github.com/pikasTech/unidesk/issues/2154)。
|
||||
|
||||
| 角色 | Lane | Namespace | Source branch | Workspace | 默认 |
|
||||
|------|------|-----------|---------------|-----------|------|
|
||||
| Development | `nc01-v02` | `agentrun-v02` | `v0.2` | `/root/agentrun-v02` | 是（`controlPlane.default.lane`） |
|
||||
| Production | `nc01-release` | `agentrun-release` | `release` | `/root/agentrun-release` | 否，必须显式 `--lane nc01-release` |
|
||||
|
||||
```text
|
||||
NC01:k3s namespace agentrun-v02
|
||||
NC01:k3s namespace agentrun-v02 # development runtime
|
||||
NC01:k3s namespace agentrun-release # production runtime（manager 已上线；内网 ClusterIP）
|
||||
```
|
||||
|
||||
- production 内网入口：`http://agentrun-mgr.agentrun-release.svc.cluster.local:8080`
|
||||
- production DB：host PostgreSQL 独立库 `agentrun_release`（与 `agentrun_v02` 隔离）
|
||||
- production PaC consumer：`agentrun-nc01-release`（YAML 已声明；`nc01-release-gitops` 分支与自动链待 agentrun 仓补齐）
|
||||
- 当前 production manager 可由 YAML 渲染 manifest 做 bootstrap 上线；完整 PR merge → GitOps 自动链仍属 #2154 后续收敛
|
||||
|
||||
所有 k3s 操作必须使用 UniDesk route 语法：
|
||||
|
||||
```bash
|
||||
trans NC01:k3s kubectl get pods -n agentrun-v02
|
||||
trans NC01:k3s kubectl get ns agentrun-release
|
||||
bun scripts/cli.ts agentrun control-plane plan --node NC01 --lane nc01-v02
|
||||
bun scripts/cli.ts agentrun control-plane plan --node NC01 --lane nc01-release
|
||||
```
|
||||
|
||||
不得把临时 NodePort、host port、pod IP、provider-gateway 业务 HTTP proxy 或一次性 port-forward 固化为 AgentRun 部署路径。任何公网入口、UniDesk/HWLAB 集成入口或跨服务访问路径，都必须先通过 AgentRun 仓库内经过审查的变更引入；UniDesk 只在后续记录对应运维入口。
|
||||
|
||||
## 受控 CI/CD 入口
|
||||
|
||||
AgentRun 目标必须从 `config/agentrun.yaml` 解析，不得从 service repo 的 `deploy.json` 或 URL 片段推断。Delivery authority 还必须与 `config/platform-infra/gitea.yaml`、`config/platform-infra/pipelines-as-code.yaml` 的 consumer/repository 组合校验。当前默认 `NC01/nc01-v02` 是 PaC migrated consumer；目标 source branch 的 GitHub PR merge 是唯一正式交付触发。
|
||||
AgentRun 目标必须从 `config/agentrun.yaml` 解析，不得从 service repo 的 `deploy.json` 或 URL 片段推断。Delivery authority 还必须与 `config/platform-infra/gitea.yaml`、`config/platform-infra/pipelines-as-code.yaml` 的 consumer/repository 组合校验。当前默认 `NC01/nc01-v02` 是 PaC migrated consumer；目标 source branch 的 GitHub PR merge 是唯一正式交付触发。`nc01-release` 的独立 PaC consumer 属于 #2154 后续阶段，R1 仅完成 namespace 与 lane 声明。
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts agentrun control-plane status
|
||||
bun scripts/cli.ts agentrun control-plane status --node NC01 --lane nc01-v02
|
||||
bun scripts/cli.ts agentrun control-plane status --node NC01 --lane nc01-release
|
||||
bun scripts/cli.ts platform-infra pipelines-as-code status --target NC01 --consumer agentrun-nc01-v02
|
||||
bun scripts/cli.ts platform-infra pipelines-as-code history --target NC01 --consumer agentrun-nc01-v02 --limit 10
|
||||
bun scripts/cli.ts agentrun control-plane cleanup-runners --node NC01 --lane nc01-v02 --dry-run
|
||||
|
||||
@@ -60,9 +60,31 @@ If a manual repair is needed to unblock the platform, the durable fix must be co
|
||||
|
||||
## 分布式敏捷流程
|
||||
|
||||
“分布式敏捷”是 UniDesk 对 distributed agile field repair 的固定流程名；通用 P1/P2/P3/P4 阶段、禁止行为和证据边界由 `$dad-dev` skill 维护，本参考不再重复展开。UniDesk 项目内只保留下面的特有约束：必须使用结构化 `trans`/UniDesk CLI 进入真实 provider、pod、host bridge 或 service port；运行面热补只能证明方向或临时恢复，不能成为隐藏部署真相；持久化完成必须回到 Git/PR/CI/CD 后原入口复测。
|
||||
“分布式敏捷”是 UniDesk 对 distributed agile field repair 的固定流程名；通用 P1/P2/P3/P4 阶段、禁止行为和证据边界由 `$unidesk-daddev` skill 维护，本参考不再重复展开。UniDesk 项目内只保留下面的特有约束：
|
||||
|
||||
固定主 repo 是 source truth anchor，不是源码/运行面 scratch 区。会产生源码、配置、issue closeout、部署脚本、验收产物或高风险 dad-dev / post-task 交付的工作，执行前必须先从目标 fixed repo 的最新 remote/base 创建任务专属 `.worktree/<task>`，后续编辑、验证、提交、push 和受控 CLI 写操作都在该 worktree 内完成。UniDesk 任务 worktree 必须通过 `bun scripts/cli.ts dev-env worktree add .worktree/<task> --branch <branch> [--from origin/master]` 创建，让 `.worktreecopy` 白名单内的本地配置自动复制到新 worktree；fixed repo 只用于 `git fetch`、`git status`、快进同步、读取规则和这个受控创建入口。其中已有的并行未提交修改默认保持不动，不纳入当前任务，也不要用 reset、checkout 或删除来“清理”。
|
||||
- 必须使用结构化 `trans`/UniDesk CLI 进入真实 provider、pod、host bridge 或 service port；
|
||||
- P2 允许按调试需要实施最小、可逆的运行面 patch 或热补，
|
||||
但它只能证明方向或临时恢复，不能成为隐藏部署真相、第二 authority、
|
||||
GitOps desired、自动交付成功或最终验收证据；
|
||||
- P3 必须把有效变化写回 owning YAML、源码或 renderer，
|
||||
经正常 PR 与自动 CI/CD/GitOps 交付；临时 patch 必须撤销，
|
||||
或由已确认的声明式交付覆盖；
|
||||
- P4 使用用户原入口复测，不能用单次手工成功替代终态。
|
||||
|
||||
固定主 repo 是 source truth anchor，不是源码/运行面 scratch 区。
|
||||
|
||||
- 会产生源码、配置、issue closeout、部署脚本、验收产物，
|
||||
或高风险 unidesk-daddev / post-task 交付的工作，
|
||||
执行前必须从目标 fixed repo 的最新 remote/base
|
||||
创建任务专属 `.worktree/<task>`；
|
||||
- 后续编辑、验证、提交、push 和受控 CLI 写操作都在该 worktree 内完成；
|
||||
- UniDesk 任务 worktree 必须通过
|
||||
`bun scripts/cli.ts dev-env worktree add .worktree/<task> --branch <branch> [--from origin/master]`
|
||||
创建，让 `.worktreecopy` 白名单内的本地配置自动复制到新 worktree；
|
||||
- fixed repo 只用于 `git fetch`、`git status`、快进同步、读取规则
|
||||
和这个受控创建入口；
|
||||
- 其中已有的并行未提交修改默认保持不动，不纳入当前任务；
|
||||
- 禁止用 reset、checkout 或删除来“清理”。
|
||||
|
||||
The root UniDesk checkout at `/root/unidesk` is the fixed main worktree and must stay on `master`. Non-`master` work belongs in a task-specific `.worktree/<task>`. Unexpected local changes are presumed to belong to another concurrent task: preserve them, do not reset, checkout, delete or rewrite them, and scope the current task's commit to its own files.
|
||||
|
||||
@@ -90,7 +112,7 @@ CONSTAR、控之星、71-FILTER、71-FREQ、PLC 项目和 PLC 控制器任务是
|
||||
|
||||
When UniDesk's own CLI, wrapper or controlled toolchain is repaired, merge the durable fix into `master` before relying on it for the original operation. The checkout that actually executes the tool must then contain that merged revision. If a fixed checkout cannot fast-forward because of unrelated changes, preserve it and run the tool from a clean worktree based on current `origin/master`; never reset or overwrite concurrent work to update the executable path.
|
||||
|
||||
在模型 provider、API provider、硬件链路、跨平台 bridge、CLI/trans/tran 或高频工具链问题上，判定外部 blocker 前仍需完成 UniDesk 的防误判核查：确认当前 runtime config / Secret key presence / env / proxy / NO_PROXY / endpoint / args，使用实际目标运行面复现，并尽量与 UniDesk/HWLAB 成熟实现对照。用户反馈或新证据推翻 blocker 判断时，立即切回 `$dad-dev` 的现场修复闭环。
|
||||
在模型 provider、API provider、硬件链路、跨平台 bridge、CLI/trans/tran 或高频工具链问题上，判定外部 blocker 前仍需完成 UniDesk 的防误判核查：确认当前 runtime config / Secret key presence / env / proxy / NO_PROXY / endpoint / args，使用实际目标运行面复现，并尽量与 UniDesk/HWLAB 成熟实现对照。用户反馈或新证据推翻 blocker 判断时，立即切回 `$unidesk-daddev` 的现场修复闭环。
|
||||
|
||||
如果某个现场步骤因为 quoting、route 定位、kubeconfig、输出体积或缺少 helper 而反复痛苦，优先改进 UniDesk passthrough / CLI 并在本文件的 `Distributed Command Passthrough` 或 `docs/reference/cli.md` 中记录稳定入口，不要沉淀一批一次性 shell 菜谱。
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ The shared Prometheus stack may discover application monitors across namespaces
|
||||
|
||||
## GitOps And Control Plane
|
||||
|
||||
Monitoring infrastructure must be declared as Git-backed desired state and applied through a controlled UniDesk or G14 GitOps path. A temporary `kubectl apply` may be used only as a `$dad-dev` P2 experiment; it must be followed by a durable source change and GitOps/CLI validation.
|
||||
Monitoring infrastructure must be declared as Git-backed desired state and applied through a controlled UniDesk or G14 GitOps path. A temporary `kubectl apply` may be used only as a `$unidesk-daddev` P2 experiment; it must be followed by a durable source change and GitOps/CLI validation.
|
||||
|
||||
Current durable control surface:
|
||||
|
||||
@@ -92,7 +92,7 @@ Durable validation after rollout must prove:
|
||||
- No public HWLAB or UniDesk FRP endpoint exposes raw Prometheus, Grafana or application `/metrics`.
|
||||
- CLI or controlled proxy output can answer a bounded query and reports the target namespace/lane/source of the data.
|
||||
|
||||
Metrics are supporting observability evidence. They do not replace `$dad-dev` source-level tests, CI/CD provenance or original-entry validation for HWLAB issues.
|
||||
Metrics are supporting observability evidence. They do not replace `$unidesk-daddev` source-level tests, CI/CD provenance or original-entry validation for HWLAB issues.
|
||||
|
||||
## Application Closeout Contract
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
- HWLAB 固定运行面、工作区、原入口验收与凭据边界：`docs/reference/hwlab.md`。
|
||||
- Gitea source authority、PaC/Tekton、GitOps/Argo 与自动交付边界：`docs/reference/platform-infra.md#gitea-与-pipelines-as-code-边界`。
|
||||
- 跨节点现场调查、持久化和原入口复测：`$dad-dev`。
|
||||
- 跨节点现场调查、持久化和原入口复测：`$unidesk-daddev`。
|
||||
- CI/CD 只读观察、scoped help 与 legacy 判定：`$unidesk-cicd` 及其按需 reference。
|
||||
- 固定开发机、Master 构建限制和任务 worktree：`docs/reference/dev-environment.md`。
|
||||
|
||||
|
||||
+14
-1
@@ -7,7 +7,20 @@
|
||||
- UniDesk 指挥侧 workspace：`/root/unidesk`，固定使用 `master`，开始前执行 `git status` 和 `git pull --ff-only origin master`。
|
||||
- HWLAB 开发、部署和验证固定只使用 NC01。`config/hwlab-node-lanes.yaml` 是 node、lane、workspace、CI/CD repo、namespace、GitOps path、公网入口和 Secret sourceRef 的配置真相，当前默认目标必须是 `NC01/v03`。
|
||||
- HWLAB 固定主 workspace 是 `NC01:/root/hwlab-v03`，固定跟踪 `v0.3`。源码修改、PR 准备、repo 内验证、GitOps render 和 rollout 修复都必须在该固定 workspace 下创建任务级 `.worktree/<task>`；master server 本地 `/root/HWLAB`、一次性 clone、runner clone、pod 内副本或非 NC01 workspace 只能做只读对照，不能承担开发 source truth。
|
||||
- HWLAB v0.3 delivery authority 由 `config/hwlab-node-lanes.yaml`、`config/platform-infra/gitea.yaml` 与 `config/platform-infra/pipelines-as-code.yaml` 组合确认。NC01/v03 精确解析为 PaC consumer 后，目标 branch 的 GitHub PR merge 是唯一交付触发；完整自动链为 GitHub webhook -> Gitea controlled mirror -> immutable snapshot -> Gitea webhook -> PaC -> Tekton -> GitOps/Argo -> runtime。默认 help、status 与 Next 只给只读 status/history；自动链故障必须修 owning YAML、controller 或源码，不得用 trigger、refresh、mirror sync/flush、人工 PipelineRun 或直接 Gitea push 补齐。
|
||||
- HWLAB v0.3 delivery authority：
|
||||
- 由 `config/hwlab-node-lanes.yaml`、`config/platform-infra/gitea.yaml`
|
||||
与 `config/platform-infra/pipelines-as-code.yaml` 组合确认；
|
||||
- NC01/v03 精确解析为 PaC consumer 后，
|
||||
目标 branch 的 GitHub PR merge 是唯一交付触发；
|
||||
- 完整自动链为 GitHub webhook -> Gitea controlled mirror -> immutable snapshot
|
||||
-> Gitea webhook -> PaC -> Tekton -> GitOps/Argo -> runtime；
|
||||
- 默认 help、status 与 Next 只给只读 status/history；
|
||||
- 自动链故障必须修 owning YAML、controller 或源码，
|
||||
不得用 trigger、refresh、mirror sync/flush、人工 PipelineRun 或直接 Gitea push 补齐；
|
||||
- 调试或临时恢复确需运行面 patch 时走 `$unidesk-daddev` P2；
|
||||
- patch 不得改变交付 authority 或冒充终态；
|
||||
- 结论必须写回 owning YAML/源码并由正常 PR 自动交付；
|
||||
- 临时 patch 随后撤销或由声明式交付覆盖。
|
||||
- 进入任何 HWLAB 工作前，按 `NC01/v03` 解析 route/workspace/sourceBranch/kubeRoute/runtime namespace 做预检、快进和验证：工作面是 `NC01:/root/hwlab-v03`、source branch 是 `v0.3`、k3s route 是 `NC01:k3s`、runtime namespace 是 `hwlab-v03`、公网入口由 YAML 的 NC01 target 声明。
|
||||
- NC01 的 node-local registry 是 k3s workload/PVC，不是 host Docker registry。`hwlab nodes control-plane infra status --node NC01 --lane v03` 应显示 registry workload ready、PVC bound 和 endpoint ready；必须通过受控 `runtime-image preload` 和 `infra tools-image build/status` 补齐 BuildKit、runtime/base 和 tools image，再把 HWLAB/AgentRun status 与 web-probe smoke 作为可用性证据。
|
||||
- HWLAB 项目内长期规则入口仍以目标 repo 的 `AGENTS.md` 为准。进入已解析的目标 workspace 后，必须重新读取该 workspace 的规则文件；不能只凭主 server 的压缩上下文继续操作。
|
||||
|
||||
@@ -11,6 +11,16 @@
|
||||
- 测试 namespace 不根据 commit、instance 或任务动态生成。
|
||||
- `pikaoa` 与 `pikaoa-ci` 是正式交付保护 namespace。
|
||||
- 测试入口不得渲染、覆盖或删除保护 namespace 中的对象。
|
||||
- 生产运行面固定使用：
|
||||
- source branch：`release`；
|
||||
- consumer：`pikaoa-nc01`；
|
||||
- runtime namespace：`pikaoa`；
|
||||
- CI namespace：`pikaoa-ci`；
|
||||
- Argo Application：`pikaoa-nc01`；
|
||||
- 公网入口：`https://oa.pikapython.com`。
|
||||
- 生产交付与公网配置分别以以下 selector 为真相：
|
||||
- `config/pikaoa.yaml#releaseRuntime.targets.NC01`；
|
||||
- `config/pikaoa.yaml#delivery.targets.NC01`。
|
||||
|
||||
## 数据库边界
|
||||
|
||||
@@ -122,9 +132,49 @@
|
||||
- 不创建 namespace-local PostgreSQL；
|
||||
- 不把测试 CI/CD 变成生产交付或用户业务的阻塞门禁。
|
||||
- GitOps 接管后，手动 `test-target start|stop` mutation 仅用于暂停 Argo 自动同步后的有界调试；禁止 CLI direct-apply 与 Argo 同时写入。
|
||||
- 生产 `pikaoa-nc01` 保留 `release` source authority，但当前不 bootstrap、不生成 `.tekton`、不创建 PipelineRun。
|
||||
- 生产 `pikaoa-nc01` 已完成 bootstrap：
|
||||
- 产品 `release` 只生成 `.tekton/pikaoa-nc01-pac.yaml`；
|
||||
- 正常 `release` PR merge 是生产 PipelineRun 的唯一触发入口；
|
||||
- API、Worker、Web 并行构建并以 digest 发布到生产 GitOps branch；
|
||||
- Argo Application `pikaoa-nc01` 自动同步 `pikaoa` namespace；
|
||||
- 禁止人工补建 PipelineRun 代替 source merge。
|
||||
- 生产使用 PK01 host PostgreSQL 独立 `pikaoa` database/role，不使用 namespace-local PostgreSQL。
|
||||
- 生产初始化模式是 `fresh-database-only`，不实现旧数据迁移、兼容或回滚。
|
||||
- 版本、审计和配置一致性异常只产生 `blocking=false` warning，不作为 MVP 业务门禁。
|
||||
- PR、构建或单测不能替代固定 NodePort 原入口验收。
|
||||
|
||||
## 生产最短只读验收
|
||||
|
||||
- 先执行运行面与 Argo 对账：
|
||||
|
||||
```bash
|
||||
trans NC01:k3s kubectl get deploy,pod,svc,pvc -n pikaoa -o wide
|
||||
trans NC01:k3s kubectl get application -n argocd pikaoa-nc01
|
||||
```
|
||||
|
||||
- 运行面通过判定：
|
||||
- API、Web、Worker、FRPC Deployment 全部 Ready；
|
||||
- Pod 全部 Running 且没有新增重启；
|
||||
- 附件 PVC 为 Bound；
|
||||
- Argo 为 `Synced` 和 `Healthy`。
|
||||
- 再验证公网和共享可观测性：
|
||||
|
||||
```bash
|
||||
curl -fsSI https://oa.pikapython.com/
|
||||
bun scripts/cli.ts platform-infra observability metrics-query \
|
||||
--target NC01 \
|
||||
--query 'pikaoa_database_ready' \
|
||||
--full
|
||||
```
|
||||
|
||||
- 公网与可观测性通过判定：
|
||||
- 公网 HTTPS 返回 200；
|
||||
- 生产 API 和 Worker 的 `pikaoa_database_ready` 均为 1；
|
||||
- 使用 `$unidesk-webdev` 完成管理员桌面与移动视口登录；
|
||||
- 使用 `$unidesk-otel` 查询登录 `traceId`，span error 数为 0。
|
||||
- 密码只从 owning YAML 声明的 `sourceRef` 读取，禁止出现在 CLI 参数、日志、截图或任务报告中。
|
||||
- 完整身份/RBAC、严格一致性审计和附件备份增强属于独立后续任务，不阻塞上述 MVP 验收。
|
||||
|
||||
## 本地验证
|
||||
|
||||
- `config/fixtures/pikaoa-test-target.yaml` 只用于 renderer 和 CLI 测试。
|
||||
|
||||
@@ -15,7 +15,16 @@
|
||||
- Gitea mirror 与 Pipelines-as-Code 是 UniDesk 运维的 CI source/trigger 服务。`config/platform-infra/gitea.yaml` 和 `config/platform-infra/pipelines-as-code.yaml` 分别拥有 mirror/webhook 与 PaC Repository/consumer 配置；repo URL、snapshot、webhook、public exposure、FRP/Caddy port、token sourceRef 和 PaC params 不得隐藏在代码特例中。
|
||||
- Delivery authority resolver 必须组合上述两份 YAML，并按 consumer id、node、lane、upstream repository、branch 和 Gitea repository 精确关联。不得通过 URL 片段、repo 名称前缀或仓库专属 `if` 推断迁移状态。零匹配、多匹配和配置错误都必须返回 `unknown`、`mutation=false` 并停止生成或执行写操作。
|
||||
- PaC consumer 的唯一正式触发是目标 source branch 的 GitHub PR merge。完整自动链固定为：GitHub PR merge -> GitHub webhook -> Gitea controlled mirror -> immutable snapshot -> Gitea webhook -> PaC/Pipelines-as-Code -> Tekton -> GitOps/Argo -> runtime 运行面。
|
||||
- PR 合并后，主代理、子代理和操作者都不得用 `apply`、`closeout`、`trigger-current`、`refresh`、`sync`、`flush`、`webhook-test`、人工 PipelineRun、直接 Gitea push、本地 mirror 写入或其他补跑完成当前交付。自动链不通时必须修 owning YAML、controller 或源码，并只用修复 PR 合并产生的新正常自动事件验收。
|
||||
- PR 合并后的交付边界：
|
||||
- 主代理、子代理和操作者不得用 `apply`、`closeout`、`trigger-current`、
|
||||
`refresh`、`sync`、`flush`、`webhook-test`、人工 PipelineRun、
|
||||
直接 Gitea push、本地 mirror 写入或其他补跑完成当前交付；
|
||||
- 自动链不通时必须修 owning YAML、controller 或源码，
|
||||
并只用修复 PR 合并产生的新正常自动事件验收；
|
||||
- 必要的运行面调试或临时恢复可以走 `$unidesk-daddev` P2 最小可逆 patch；
|
||||
- patch 不得修改 source/ref authority、制造交付成功或替代终态；
|
||||
- 成立的变化必须写回 owning YAML/源码并经正常 PR 自动交付；
|
||||
- 临时 patch 随后撤销或由声明式交付覆盖。
|
||||
- Migrated consumer 的默认 help、status、`Next` 与 `REPAIR` 只能给 `status`、`history`、`events`、`logs`、只读单步下钻以及本节稳定引用。CLI 必须省略 mutation command，而不是只给命令加警告文字。`unknown` authority 同样 fail-closed。
|
||||
- 旧 `trigger-current`、`refresh` 和 mirror `sync|flush` 只允许在 owning YAML 明确解析为 `legacy-manual` 后执行，并且只在显式 `legacy-cicd` 或 `legacy-ops` scoped help 中可发现。平台 bootstrap、Secret 与配置维护属于独立职责，只在 `platform-bootstrap` 或 `platform-maintenance` scoped help 中展示，不能作为 source delivery recovery。
|
||||
- `closeout` 仅保留只读历史/诊断兼容入口，并且只能从 `compatibility-diagnostics` scoped help 发现。会 POST hook test 的 `webhook-test` mutation 入口已经删除；连通性只能通过真正只读的 status、GET 与 readiness 观察，禁止制造伪 push。
|
||||
|
||||
Reference in New Issue
Block a user