refactor: retire legacy todo note runtime
This commit is contained in:
Codex
@@ -67,7 +67,6 @@ bun scripts/cli.ts artifact-registry deploy-service --service frontend --env dev
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env prod --service project-manager --commit <full-sha>
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env prod --service oa-event-flow --commit <full-sha>
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env prod --service code-queue-mgr --commit <full-sha> --dry-run
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env prod --service todo-note --commit <full-sha>
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env dev --service findjob --commit <full-sha> --dry-run
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env dev --service pipeline --commit <full-sha> --dry-run
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env dev --service met-nonlinear --commit <full-sha> --dry-run
|
||||
@@ -85,7 +84,7 @@ bun scripts/cli.ts artifact-registry deploy-service --service code-queue --env d
|
||||
|
||||
`deploy-backend-core` 是旧兼容入口，当前作为标准路径已禁用。Backend-core CD 必须使用 `bun scripts/cli.ts deploy apply --env dev --service backend-core --commit <full-sha>` 或 `bun scripts/cli.ts deploy apply --env prod --service backend-core --commit <full-sha>`，由 deploy reconciler 先执行共同的 artifact-consumer guardrail，再调用通用 `deploy-service` consumer。旧入口只能返回 structured deprecated 结果，不得绕过 `deploy apply --env ...`。
|
||||
|
||||
`deploy-service` 是标准化后的最小通用 artifact consumer。它目前支持 dev/prod `backend-core`、`baidu-netdisk`、prod/dev `frontend`、`mdtodo`、`claudeqq`、`project-manager`、`oa-event-flow`、`code-queue-mgr`、`todo-note`、`findjob`、`pipeline`、`met-nonlinear` 和 `k3sctl-adapter`，以及 dev-only `code-queue` dry-run。Decision Center 已迁移到 NC01 YAML-first k8s + GitHub repo storage，不再把 D601 artifact registry 作为当前生产 deploy truth。其余 artifact consumer 路径都必须先通过 D601 registry 的 commit-pinned manifest 校验，再执行拉取、导入/retag、部署和健康验证；`code-queue --env dev --dry-run` 必须显示 `requiresSupervisorApproval=true`、`selfBootstrapGuard`、commit tag/digest provenance、pull-only/no-build build boundary 和不会影响 production scheduler/runner/active tasks 的 `affectedRuntime` / `excludedTargets`；非 dry-run DEV apply 必须返回 supervisor/human authorization gate，不能由正在运行的 Code Queue task 自举执行；`code-queue --env prod` 必须返回 structured unsupported，不能回退到生产 artifact deploy、rollout 或 manifest 变更；`code-queue-mgr` 的 prod live apply 仍需 supervisor 单独确认，`met-nonlinear` 与 `k3sctl-adapter` 当前只提供 plan/dry-run：
|
||||
`deploy-service` 是标准化后的最小通用 artifact consumer。它目前支持 dev/prod `backend-core`、`baidu-netdisk`、prod/dev `frontend`、`mdtodo`、`claudeqq`、`project-manager`、`oa-event-flow`、`code-queue-mgr`、`findjob`、`pipeline`、`met-nonlinear` 和 `k3sctl-adapter`，以及 dev-only `code-queue` dry-run。Decision Center 与 Todo Note 均已迁移到 NC01 YAML-first k8s + GitHub repo storage，不再把 D601 artifact registry 作为当前生产 deploy truth。其余 artifact consumer 路径都必须先通过 D601 registry 的 commit-pinned manifest 校验，再执行拉取、导入/retag、部署和健康验证；`code-queue --env dev --dry-run` 必须显示 `requiresSupervisorApproval=true`、`selfBootstrapGuard`、commit tag/digest provenance、pull-only/no-build build boundary 和不会影响 production scheduler/runner/active tasks 的 `affectedRuntime` / `excludedTargets`；非 dry-run DEV apply 必须返回 supervisor/human authorization gate，不能由正在运行的 Code Queue task 自举执行；`code-queue --env prod` 必须返回 structured unsupported，不能回退到生产 artifact deploy、rollout 或 manifest 变更；`code-queue-mgr` 的 prod live apply 仍需 supervisor 单独确认，`met-nonlinear` 与 `k3sctl-adapter` 当前只提供 plan/dry-run：
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts artifact-registry deploy-service --service baidu-netdisk --commit <full-sha> --run-now
|
||||
@@ -94,7 +93,6 @@ bun scripts/cli.ts artifact-registry deploy-service --service frontend --env pro
|
||||
bun scripts/cli.ts artifact-registry deploy-service --service frontend --env dev --commit <full-sha> --run-now
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env prod --service project-manager --commit <full-sha> --run-now
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env prod --service oa-event-flow --commit <full-sha> --run-now
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env prod --service todo-note --commit <full-sha> --run-now
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env prod --service findjob --commit <full-sha> --run-now
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env prod --service pipeline --commit <full-sha> --run-now
|
||||
bun scripts/cli.ts artifact-registry deploy-service --env dev --service mdtodo --commit <full-sha> --run-now
|
||||
|
||||
@@ -178,7 +178,7 @@ This matrix is the single review surface for the remaining D601 service lane. It
|
||||
| `k3sctl-adapter` | UniDesk-managed D601 direct Compose control bridge, outside the native k3s fault domain; it is the control path for k3s-managed services and must not be moved into k3s. | `CI.json` source-build supported through `ci publish-user-service --service k3sctl-adapter`; artifact is `127.0.0.1:5000/unidesk/k3sctl-adapter:<commit>` from the UniDesk Dockerfile. | Artifact consumer exposes plan/dry-run only for service/container `k3sctl-adapter`; live replacement is supervisor-only because replacing the bridge can remove the repair path for k3s. | No normal dev target. DEV acceptance is read-only bridge health, service catalog/proxy checks and dry-run contract review only. | Dry-run/read-only only in this lane. Real prod replacement requires explicit supervisor confirmation, rollback proof and out-of-band recovery access. | Must remain recoverable while k3s may be broken; worker automation must not self-replace or k3s-manage the bridge. | Write a supervised bridge-upgrade runbook with rollback and out-of-band access checks; keep CLI dry-run as the standard preflight. |
|
||||
| `code-queue` | Production execution plane is D601 native k3s (`unidesk` namespace) behind `k3sctl-adapter`; dev execution plane is `unidesk-dev` scheduler/read/write/provider-egress-proxy. Main-server `code-queue-mgr` is a separate control-plane sidecar. | `CI.json` source-build supported through `ci publish-user-service --service code-queue` for dev image validation only; artifact is `127.0.0.1:5000/unidesk/code-queue:<commit>`. | Reviewed dev-only k3s artifact consumer updates only `unidesk-dev` Code Queue objects. `deploy plan --env prod --service code-queue` and `artifact-registry deploy-service --env prod --service code-queue` must stay unsupported. | Allowed only as dry-run/source evidence here; a later human-approved dev live apply may consume the artifact into `unidesk-dev` outside the running Code Queue task. | Not implemented and not authorized. No production artifact deploy, manifest mutation, scheduler/runner restart, interrupt or cancel is allowed. | Production still has hostPath/source and active-run safety boundaries; self-deploy would couple the deployment actor to the target being replaced. | Keep dev dry-run coverage; design a separate supervisor-approved production CD consumer before any prod mutation is considered. |
|
||||
| `decision-center` | NC01 k8s user service; prod runs `unidesk/deployment/decision-center` and `unidesk/service/decision-center` selected by `config/unidesk-host-k8s.yaml`. | Source image may still be built from the UniDesk Dockerfile, but production release evidence is YAML-first NC01 k8s state plus GitHub repo storage, not D601 registry artifact consumption. | D601 k3s artifact consumer is retired for the current production path. Desired state must include NC01 target, namespace, GitHub repo `pikasTech/decision-center-data`, base path `data`, and Secret sourceRef for `decision-center-github-ssh`. | Dev gate remains focused product validation: record CRUD, diary lifecycle, doc-number uniqueness and frontend visibility. It must not require a D601 `decision-center-dev` runtime as current truth. | Prod acceptance verifies NC01 `/health`, records, diary editor, frontend page, no public business ports, GitHub storage read/write and Secret presence/fingerprint. | Product completeness and manual UI acceptance can remain open, but PostgreSQL is index/cache only and D601 artifact evidence is not storage/deploy truth. | Keep YAML-first NC01 deploy and GitHub storage checks sufficient so future desired-state edits cannot reintroduce old D601/PostgreSQL truth. |
|
||||
| `todo-note` | NC01 k8s user service; prod runs private `unidesk/deployment/todo-note` and `unidesk/service/todo-note` selected by `config/unidesk-host-k8s.yaml`. | `CI.json` assigns production to `platform-infra pipelines-as-code`; consumer `unidesk-host` reuses Repository `sentinel-nc01-v03`, builds the vendored Dockerfile and publishes a digest-pinned image. | GitOps/Argo CD owns the Todo Note Service/Deployment. The full host renderer supplies shared catalog and Secret objects but skips Todo Note runtime objects to avoid dual ownership. | PaC plan, render and health checks must prove the NC01 namespace, digest pin, private ClusterIP and no Secret material in GitOps output. | Prod acceptance verifies six migrated lists, 1167 history rows, action/undo/redo writes, GitHub `todo-note/` read/write, PostgreSQL cache alignment, frontend and CLI access. | CC01 old runtime and legacy Compose metadata remain only until import and live write verification pass. | Retire CC01 and legacy `deploy.json`/Compose Todo ownership after the verified migration; keep PaC/Argo and GitHub storage as sole truth. |
|
||||
| `todo-note` | NC01 k8s user service; prod runs private `unidesk/deployment/todo-note` and `unidesk/service/todo-note` selected by `config/unidesk-host-k8s.yaml`. | `CI.json` assigns production to `platform-infra pipelines-as-code`; consumer `unidesk-host` reuses Repository `sentinel-nc01-v03`, builds the vendored Dockerfile and publishes a digest-pinned image. | GitOps/Argo CD owns the Todo Note Service/Deployment. The full host renderer supplies shared catalog and Secret objects but skips Todo Note runtime objects to avoid dual ownership. | PaC plan, render and health checks must prove the NC01 namespace, digest pin, private ClusterIP and no Secret material in GitOps output. | Six lists, 1167 history rows, action/undo/redo writes, GitHub `todo-note/` read/write, PostgreSQL cache alignment, frontend and CLI access passed. | CC01 container and legacy `config.json`/`deploy.json`/Compose ownership are retired. | Keep PaC/Argo and GitHub storage as the sole truth; do not restore the old runtime path. |
|
||||
|
||||
Minimum evidence for this lane is:
|
||||
|
||||
@@ -232,7 +232,7 @@ This table freezes the boundary between standard artifact services, upstream ima
|
||||
| `server rebuild backend-core` | `bootstrap-keep` | Local main-server Compose build/recreate, serialized by Compose lock and validated after up. Docs forbid using it for Rust iteration or standard prod CD. | Recovery-only path; standard production path is D601 CI artifact plus `deploy apply --env prod --service backend-core`. | Backend-core artifact CD rollback proven under outage conditions; recovery runbook can repair a broken core without local Rust build. | Removing too early can block recovery when core or registry relay is degraded. | Keep; not removable next stage. |
|
||||
| `server rebuild frontend` | `bootstrap-keep` | Local main-server Compose build/recreate for production frontend; maintenance-only and not release evidence. | Standard frontend release is CI `unidesk/frontend:<commit>` plus dev/prod artifact consumer and health/image-label verification. | Equivalent pull-only repair command, registry rollback, and frontend health verification runbook. | Local dirty bundle can become accidental production truth; deleting too early removes emergency UI repair. | Keep for now; degrade only after pull-only repair is proven. |
|
||||
| `server rebuild baidu-netdisk` | `bootstrap-keep` | Local main-server Compose build/recreate for Baidu Netdisk; maintenance-only. | D601 CI source-build artifact plus dev/prod pull-only consumer. | Pull-only repair and token/staging persistence validation. | Dirty rebuild can hide token/staging regressions; premature deletion can block storage service repair. | Keep for now; degrade after pull-only repair is proven. |
|
||||
| `server rebuild todo-note` | `allowed-remove-later` after cutover | Legacy main-server/CC01 Compose recovery path used only until the NC01 import is verified. | NC01 PaC/Argo delivery plus GitHub-backed rollback and storage verification. | Six lists, 1167 history rows, temporary write/undo/redo/delete lifecycle, GitHub revision and PostgreSQL cache alignment are verified on NC01. | Removing before import proof can lose the only recoverable old runtime; retaining it afterward can reintroduce split-brain writes. | Remove the catalog/deploy/Compose entry and stop the old container immediately after cutover evidence passes. |
|
||||
| `server rebuild todo-note` | `removed` | Legacy main-server/CC01 Compose recovery path retired after NC01 import verification. | NC01 PaC/Argo delivery plus GitHub-backed rollback and storage verification. | Six lists, 1167 history rows, temporary write/undo/redo/delete lifecycle, GitHub revision and PostgreSQL cache alignment are verified on NC01. | Restoring it can reintroduce split-brain writes. | Keep the command, catalog/deploy/Compose entry and old container absent. |
|
||||
| `server rebuild code-queue-mgr`, `project-manager`, `oa-event-flow` | `bootstrap-keep` | Local main-server Compose rebuild for internal or direct main-server services; some have artifact consumer validation, while live prod apply may remain gated. | Convert each to CI artifact plus pull-only consumer and live health commit verification where supported; keep recovery entry until equivalent repair exists. | Per-service artifact consumer, runtime deploy metadata, rollback, and persistence validation. | Dirty local rebuilds can bypass `deploy.json`; deleting before rollback can break main-server service recovery. | Keep; reassess service by service. |
|
||||
| `server rebuild provider-gateway` | `bootstrap-keep` | Local Compose rebuild for the main-server provider gateway. | Keep as bridge repair; normal upgrades should use protected provider upgrade or artifact path when available. | Same provider-gateway recovery proof as above. | May strand host-level observability and maintenance dispatch. | Keep. |
|
||||
| `server rebuild filebrowser*`, `database`, `code-queue`, `k3sctl-adapter`, unknown services | `allowed-remove-later` for silent fallback only | Historically the CLI threw a generic usage error; no valid main-server Compose rebuild exists for these objects. | Structured `unsupported-server-rebuild` result; no job creation, no source build, no Compose mutation. | Operators must use documented upstream digest, k3s artifact, bridge repair, or manual-risk path instead. | Generic errors can lead operators to invent hand-built fallback commands. | Silent/generic fallback is removed; do not delete the real upstream/bootstrap runtime paths. |
|
||||
@@ -255,7 +255,7 @@ This table freezes the boundary between standard artifact services, upstream ima
|
||||
| `server rebuild frontend` and `server rebuild baidu-netdisk` | Maintenance / non-standard | docs classify as maintenance-only; standard release requires CI artifact plus dev/prod artifact consumer | keep until recovery runbooks have equivalent pull-only repair commands |
|
||||
| `server rebuild backend-core` | Diagnostic/recovery only; not Rust iteration or prod CD | docs forbid Rust iteration and prod backend-core artifact CD through this command | keep for bootstrap/recovery until backend-core artifact CD and rollback are proven under outage conditions |
|
||||
| `server rebuild dev-frontend-proxy`, `code-queue-mgr`, `project-manager`, `oa-event-flow`, `provider-gateway` on main-server Compose | Bootstrap / recovery / diagnostic | still serialized through Compose lock and post-up validation | reassess service by service after artifact consumers exist |
|
||||
| `server rebuild todo-note` on the legacy runtime | Migration-only, then remove | allowed only until NC01 import and GitHub read/write verification complete | remove after cutover evidence and stop the old runtime to prevent split-brain writes |
|
||||
| `server rebuild todo-note` on the legacy runtime | Removed | NC01 import and GitHub read/write verification completed | keep absent to prevent split-brain writes |
|
||||
| `provider.upgrade mode=schedule` for provider-gateway | Must be retained | protected upgrade path with validation; Host SSH self-rebuild remains forbidden | do not delete; it is the provider-gateway recovery path |
|
||||
| D601 direct `docker build`, `kubectl apply`, `docker compose up --build` used by deploy executor for native k3s setup or approved recovery | Bootstrap / recovery | limited to native k3s initialization or documented recovery; dev backend-core CD is now artifact-only; Code Queue prod is not enabled | convert only after artifact consumers or native bootstrap replacements exist |
|
||||
| D601 direct Code Queue / old `codex deploy` | Must stay disabled/degraded | compatibility command throws; docs classify direct deployment as forbidden | wait for controlled Code Queue dev/prod CD worker |
|
||||
|
||||
@@ -62,7 +62,7 @@ PipelineRun 失败或长时间未完成时，先按定点 `control-plane status
|
||||
- `server logs` 返回 `logs/` 文件日志和 Docker 容器日志的尾部，默认限制输出大小，避免日志爆炸。实现必须只读取文件末尾字节，不得为了 tail 先把巨大日志完整读入 CLI 内存。
|
||||
- `server cleanup plan|run --confirm [--min-age-hours N] [--limit N]` 是主 server Docker 镜像高水位治理入口。`plan` 生成 dry-run 计划，不执行删除；`run --confirm` 只删除同一 classifier 选出的 stale Docker images，高风险候选必须额外 `--include-high-risk` 才会执行。默认 `--min-age-hours 24`，避免把刚发布或刚验证的镜像列为 stale。输出必须包含 active containers/images、受保护镜像、candidate stale images、估算释放空间、风险等级、执行/跳过结果和人工审批线索。计划必须保守白名单：保留 running containers 使用的 image ID，保留 stopped containers 引用的 image ID 直到人工先复核容器，保留 `deploy.json`/`CI.json` 当前 commit-pinned artifact、Compose stable image、上游 digest pin 和 provider-gateway runner image；`protectedStorage` 必须显式列出 PostgreSQL named volume、Baidu Netdisk `.state`、D601 registry storage 和 Docker volumes/host data policy。该入口禁止 `docker system prune`、`docker image prune`、`docker builder prune`、`docker volume rm`、`docker compose down -v`、数据库清理或 host data `rm` 命令。
|
||||
- `gc plan|run --confirm|db-trace|policy|remote` 是主 server 和受控 provider 的磁盘高水位一次性缓解与长期防膨胀入口。`plan` 只读输出候选、风险、估算收益和保护对象；`run` 必须显式 `--confirm`；`gc remote <providerId> ...` 通过 UniDesk SSH 透传执行远端 GC，`--target-use-percent N` 会在 `summary.target` 中报告目标水位所需释放量、候选估算、预计水位、缺口和 safe-stop 决策。默认只包含 allowlisted `/tmp` 诊断目录；非 allowlist stale `/tmp` 直接子项必须显式 `--include-stale-tmp`，并只允许删除 `/tmp` 一级子项且避开系统 socket/session 前缀。G14/HWLAB registry retention、受限 core dump、保护对象、safe-stop 线和长期收益表的权威规则见 `docs/reference/gc.md`。
|
||||
- `server rebuild <backend-core|frontend|dev-frontend-proxy|provider-gateway|todo-note|code-queue-mgr|project-manager|baidu-netdisk|oa-event-flow>` 创建异步 job，先构建目标服务镜像，随后在 `.state/locks/server-compose.lock` 串行保护下用 `--no-deps --force-recreate` 替换目标 service 并等待容器 `healthy/running`。`todo-note` 仅是 CC01/旧 Compose 迁移回退入口，NC01 导入和 GitHub 写验证完成后必须从该 allowlist 删除；正式 Todo Note 发布走 PaC/Argo。D601 Code Queue 执行面不由 `server rebuild` 管理；Rust backend-core 常规迭代不得用该命令在 master server 编译，只有明确的 backend-core 主 server 上线例外可以按限流、异步轮询和 health 证据执行，规则见 `docs/reference/dev-environment.md`。
|
||||
- `server rebuild <backend-core|frontend|dev-frontend-proxy|provider-gateway|code-queue-mgr|project-manager|baidu-netdisk|oa-event-flow>` 创建异步 job，先构建目标服务镜像，随后在 `.state/locks/server-compose.lock` 串行保护下用 `--no-deps --force-recreate` 替换目标 service 并等待容器 `healthy/running`。Todo Note 的 CC01/旧 Compose 回退入口已在迁移验收后删除；正式发布只走 NC01 PaC/Argo。D601 Code Queue 执行面不由 `server rebuild` 管理；Rust backend-core 常规迭代不得用该命令在 master server 编译，只有明确的 backend-core 主 server 上线例外可以按限流、异步轮询和 health 证据执行，规则见 `docs/reference/dev-environment.md`。
|
||||
- `provider attach <providerId> [--master-server URL] [--up] [--force]` 在新计算节点生成两项配置的 provider-gateway 挂载包：`.state/provider-<ID>.env` 默认只包含 `UNIDESK_MASTER_SERVER` 与 `PROVIDER_ID`，`provider-<ID>.yml` 固定 Docker socket、`pid: "host"`、`restart: always`、只读 `/workspace` 和 SSH 维护私钥挂载；`--up` 会立即执行生成的 `docker compose up -d --build`。`provider triage <providerId> [--observed-error text] [--observed-scope scope] [--microservice id ...] [--full|--raw]` 是只读多信号健康裁决入口，会把单路径 `provider is not online`、SSH 超时、registry 失败和 service proxy 失败归类成 `runner-local-observation-gap`、`service-degraded`、`provider-degraded` 或 `global-blocker`。默认输出只返回裁决、scope、失败/降级/未知信号和有界 evidence 摘要，完整 evidence 必须显式加 `--full` 或 `--raw`；推荐交叉验证命令仍包含 `debug health`、`debug dispatch <providerId> host.ssh --wait-ms 15000`、`trans <providerId> argv true`、`artifact-registry health --provider-id <providerId>`、`microservice health k3sctl-adapter`、`microservice health code-queue` 和 `codex tasks --view supervisor --limit 20`。
|
||||
- `platform-db postgres plan|status|export-secrets|apply --config config/platform-db/postgres-pk01.yaml` 管理 YAML 声明的 PK01 host-native PostgreSQL。`plan` 和 `status` 只读采集远端 host、PostgreSQL、TLS、DNS alias 和 Secret 形态；`export-secrets --confirm` 只按 YAML 物化本地 Secret source/export 文件，不触碰远端 PostgreSQL；`apply --confirm` 默认创建本地异步 job，`apply --confirm --wait` 用远端 root-owned job 收敛 systemd PostgreSQL、TLS、`pg_hba`、role/database、Secret export 和备份 timer。输出不得打印密码或完整 `DATABASE_URL`。跨节点消费者使用 YAML 中的 `connectionHost` 直连 PK01 公网 endpoint，DNS alias 不作为 `sslmode=require` 切库 blocker，PK01 规则见 `docs/reference/pk01.md`。
|
||||
- `trans <route> [operation args...]` / `tran <route> [operation args...]` 通过 backend-core 内网 WebSocket broker 和 provider-gateway 的 Host SSH / WSL SSH 维护桥连接目标节点；`route` 基础形态是 provider id，例如 `D601` 或 `G14`，也可以扩展为纯定位路径 `provider:plane[:namespace:resource[:container]]`，例如 `D601:win`、`D601:win/c/test`、`G14:k3s`、`D601:k3s` 或 `G14:k3s:<namespace>:<workload>`。WSL provider 的 Windows plane 固定使用 `win`，不得使用 `win32`；Windows route 中 `win` 只负责定位，operation 直接写 `ps`、`cmd`、`git` 或 fs helper，不要写成 `trans D601:win/... win ps`。Windows operation 必须显式区分：`ps` 执行 Windows PowerShell heredoc 或一行 PowerShell 命令，`cmd` 执行 cmd.exe/batch，`skills` 发现 Windows skill 目录。需要 Windows cwd 时用 `trans D601:win/c/test ps`、`trans D601:win/c/test cmd cd`、`trans D601:win/c/test git diff --check` 或 `trans D601:win/c/test git commit -m 'message'`，CLI 自动设置 UTF-8/Python 编码默认值；`cmd` 额外设置 `chcp 65001`。非交互远端命令优先使用 `trans <providerId> argv ...`；需要 POSIX shell 脚本、管道、变量或循环时必须在 operation 位置显式写 `sh` 或 `bash`，例如 `trans G14 sh <<'SH'`、`trans G14:k3s sh <<'SH'`、`trans G14:k3s:<namespace>:<workload> sh <<'SH'` 或 `trans D601:/workspace bash <<'BASH'`。`sh` 明确表示目标 `/bin/sh`，`bash` 明确表示目标 Bash；`script` 和 `shell` operation 已移除并会失败，避免隐藏 shell 方言。Windows PowerShell 必须写 `trans <provider>:win ps <<'PS'`。一行远端 shell 逻辑使用 `sh -- '<单个字符串>'` 或 `bash -- '<单个字符串>'`；顶层 remote option parser 必须保留命令已经开始后的 `--`，不得把它吞成全局选项结束符。需要远端改文本文件时默认优先使用 `<route> apply-patch < patch.diff`；需要可靠传输非文本或整文件时使用 `<route> upload <local-file> <remote-file>` 和 `<route> download <remote-file> <local-file>`，CLI 会按字节数与 SHA-256 自动校验并在 provider-gateway stdin/argv 限制下切换客户端分块策略；需要旧 helper 时显式使用 `<provider>:k3s:<namespace>:<workload> apply-patch-v1` 或 `<providerId> apply-patch-v1`。ssh-like 命令遇到 timeout/kex/255 类失败时，CLI 会在 stderr 追加一行 `UNIDESK_SSH_HINT` JSON，提示改用 `sh`/`bash` stdin heredoc、argv 或 provider triage 交叉验证。
|
||||
@@ -161,7 +161,7 @@ UniDesk/HWLAB Web 开发、HWLAB `web-probe run|script|observe|screenshot`、fak
|
||||
|
||||
定点状态查询优先使用后台 job 输出的稳定对象名：PipelineRun 用 `hwlab g14 control-plane status --lane v02 --pipeline-run <name>`，已知 source commit 用 `--source-commit <full-sha>`。不要在 source branch 可能继续推进时用默认最新 head status 判定历史 run 成败；默认最新 head 口径只适合判断当前 lane 是否整体最新。`control-plane status` 会汇总 source、mirror、Tekton、Argo、runtime workload 和公网探针，可能比普通只读命令慢；高频轮询应先用 `job status` 或更窄的 status，完整 status 留给阶段收口和异常定位。
|
||||
|
||||
`server rebuild` 与 `server start`、`server stop` 一样必须通过返回的 job id 确认结果；不要把连续 `server rebuild` 命令理解成“前一个重建已完成”，因为两个命令只是在快速创建异步 job。重建 frontend 只保留为维护/非标准路径；标准 frontend 发布必须先运行 `ci publish-user-service --service frontend --commit <full-sha>`，再运行 `deploy apply --env dev --service frontend` 和 `deploy apply --env prod --service frontend`，并验证 `/health.deploy.commit`。重建 dev 入口薄代理使用 `bun scripts/cli.ts server rebuild dev-frontend-proxy`。Todo Note 正式发布使用 `platform-infra pipelines-as-code --target NC01 --consumer unidesk-host`；`server rebuild todo-note` 只在迁移验收前用于旧运行面回退。重建 Code Queue Manager、Project Manager、Baidu Netdisk 和 OA Event Flow 后端仍分别使用各自 `server rebuild` 与 `microservice health/proxy` 验证。D601 Code Queue 执行面由 D601 k3s/k8s 控制面代管；Decision Center 与 Todo Note 由 NC01 k8s 代管并写入同一个 GitHub repo 的独立 base path；persistent dev backend-core/frontend 仍走 artifact consumer，当前 Code Queue 仍不得通过维护通道直连 D601 做部署。不得把 `docker rm` 手工兜底当成正式交付步骤。
|
||||
`server rebuild` 与 `server start`、`server stop` 一样必须通过返回的 job id 确认结果；不要把连续 `server rebuild` 命令理解成“前一个重建已完成”，因为两个命令只是在快速创建异步 job。重建 frontend 只保留为维护/非标准路径；标准 frontend 发布必须先运行 `ci publish-user-service --service frontend --commit <full-sha>`，再运行 `deploy apply --env dev --service frontend` 和 `deploy apply --env prod --service frontend`，并验证 `/health.deploy.commit`。重建 dev 入口薄代理使用 `bun scripts/cli.ts server rebuild dev-frontend-proxy`。Todo Note 正式发布使用 `platform-infra pipelines-as-code --target NC01 --consumer unidesk-host`；旧 `server rebuild todo-note` 已删除。重建 Code Queue Manager、Project Manager、Baidu Netdisk 和 OA Event Flow 后端仍分别使用各自 `server rebuild` 与 `microservice health/proxy` 验证。D601 Code Queue 执行面由 D601 k3s/k8s 控制面代管；Decision Center 与 Todo Note 由 NC01 k8s 代管并写入同一个 GitHub repo 的独立 base path；persistent dev backend-core/frontend 仍走 artifact consumer，当前 Code Queue 仍不得通过维护通道直连 D601 做部署。不得把 `docker rm` 手工兜底当成正式交付步骤。
|
||||
|
||||
新部署入口优先使用受控 deploy path。`deploy apply --env dev --service backend-core` 是 D601 k3s artifact consumer，消费 `ci publish-backend-core` 产出的成品镜像；`deploy apply --env dev|prod --service frontend` 和 `deploy apply --env dev|prod --service baidu-netdisk` 是 artifact-consumer 样板；Decision Center 是 NC01 YAML-first + GitHub storage 样板，Todo Note 是 NC01 PaC/Argo + 同仓独立 base path 样板；旧的 `codex deploy` 已禁用。部署后必须用 live commit/digest 与存储验证证明不是旧服务。
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ TypeScript 运行时固定为 Bun for CLI, frontend, provider-gateway and TypeSc
|
||||
|
||||
`microservices` 定义挂载在计算节点或主 server Docker 中的非核心用户服务。用户服务是挂在 UniDesk 核心服务上的用户业务能力，缺少这些服务时 UniDesk 核心仍必须能运行。该数组保存外部业务仓库引用、provider 映射、节点后端端口和 UniDesk frontend 集成入口；NC01 host-k8s 用户服务改由 `config/unidesk-host-k8s.yaml` 声明并渲染到 backend-core catalog。`backend.public` 必须为 `false`，`backend.frontendOnly` 必须为 `true`，`backend.allowedPathPrefixes` 必须限制到业务 API 前缀，`backend.allowedMethods` 必须显式列出允许代理的 HTTP 方法；浏览器只能通过 frontend 同源代理访问这些后端。详细规则见 `docs/reference/microservices.md`。
|
||||
|
||||
Todo Note 的正式配置位于 `config/unidesk-host-k8s.yaml`：backend-core 访问 NC01 私有 ClusterIP `todo-note:4288`，允许 `GET/HEAD/POST/DELETE`，GitHub `pikasTech/decision-center-data/todo-note` 是权威存储，PostgreSQL 是 cache。旧 `config.json` Todo 条目只在 CC01 迁移回退期存在，验收后必须删除。Code Queue 使用 `deployment.mode=k3sctl-managed`、`backend.proxyMode=k3sctl-adapter-http` 和 `nodeBaseUrl=k3s://code-queue`，只允许通过 frontend/backend-core -> `k3sctl-adapter` -> Kubernetes API service proxy -> k3s/k8s Service 单一路径访问，不能配置业务容器直连、NodePort 或 provider-gateway direct path；D601 的 FindJob 只允许 `GET/HEAD` 展示型读取路径；D601 的 Pipeline 允许 `GET/HEAD/POST`，其中 `POST` 只用于 Pipeline 后端 `/api/node-control/...` 的 append prompt、guide 和 redo/restart 等受控 node 操作。
|
||||
Todo Note 的正式配置位于 `config/unidesk-host-k8s.yaml`：backend-core 访问 NC01 私有 ClusterIP `todo-note:4288`，允许 `GET/HEAD/POST/DELETE`，GitHub `pikasTech/decision-center-data/todo-note` 是权威存储，PostgreSQL 是 cache。CC01 迁移验收完成后，旧 `config.json` Todo 条目已删除，不得恢复。Code Queue 使用 `deployment.mode=k3sctl-managed`、`backend.proxyMode=k3sctl-adapter-http` 和 `nodeBaseUrl=k3s://code-queue`，只允许通过 frontend/backend-core -> `k3sctl-adapter` -> Kubernetes API service proxy -> k3s/k8s Service 单一路径访问，不能配置业务容器直连、NodePort 或 provider-gateway direct path；D601 的 FindJob 只允许 `GET/HEAD` 展示型读取路径；D601 的 Pipeline 允许 `GET/HEAD/POST`，其中 `POST` 只用于 Pipeline 后端 `/api/node-control/...` 的 append prompt、guide 和 redo/restart 等受控 node 操作。
|
||||
|
||||
## Compose Env Generation
|
||||
|
||||
|
||||
@@ -60,7 +60,7 @@ swap 管理不能被强塞进所有热路径。`server start/status` 可以暴
|
||||
|
||||
## Single Service Rebuild
|
||||
|
||||
前端、本机 provider-gateway、dev-frontend-proxy 或主 server 承载的 Code Queue Manager/Project Manager/Baidu Netdisk/OA Event Flow 用户服务需要非版本化本地重建时，统一使用 `bun scripts/cli.ts server rebuild <service>`。Todo Note 已由 NC01 PaC/Argo 代管；`server rebuild todo-note` 只在 CC01 数据迁移验收完成前作为旧运行面回退入口，完成后必须从 CLI 和 Compose 删除。Decision Center 和 Todo Note 的正式路径都是 NC01 YAML-first k8s + GitHub storage；`deploy apply --env dev|prod --service frontend|baidu-netdisk|mdtodo|claudeqq` 和 dev-only `deploy apply --env dev --service code-queue` 仍是对应服务的 artifact consumer 路径。直管微服务不能把脏工作树或手工重建作为部署真相。Rust backend-core 常规迭代和 dev artifact CD 不得在 master server 用 `server rebuild backend-core` 替代 D601 CI；唯一例外是已提交的 backend-core 修复需要上线到主 server Compose runtime 时，可以用 `server rebuild backend-core` 受控编译并替换该服务，要求限流并发、异步 job/status 轮询、容器 health 验证和 issue 证据回写。D601 Code Queue 执行面、File Browser、FindJob、Pipeline、MET Nonlinear 和 ClaudeQQ 部署在计算节点，不属于主 server Compose 可重建服务；其中 D601 Code Queue 执行面不得再通过 `codex deploy` 或维护通道直连 D601 部署，且本阶段 prod artifact deploy/rollout/manifest mutation 仍 unsupported。特例冻结清单和下一阶段删除判断见 `docs/reference/cicd-standardization.md`。
|
||||
前端、本机 provider-gateway、dev-frontend-proxy 或主 server 承载的 Code Queue Manager/Project Manager/Baidu Netdisk/OA Event Flow 用户服务需要非版本化本地重建时，统一使用 `bun scripts/cli.ts server rebuild <service>`。Todo Note 已由 NC01 PaC/Argo 代管；CC01 数据迁移验收后，`server rebuild todo-note`、Compose service 与 `deploy.json` 条目均已删除，不得恢复。Decision Center 和 Todo Note 的正式路径都是 NC01 YAML-first k8s + GitHub storage；`deploy apply --env dev|prod --service frontend|baidu-netdisk|mdtodo|claudeqq` 和 dev-only `deploy apply --env dev --service code-queue` 仍是对应服务的 artifact consumer 路径。直管微服务不能把脏工作树或手工重建作为部署真相。Rust backend-core 常规迭代和 dev artifact CD 不得在 master server 用 `server rebuild backend-core` 替代 D601 CI；唯一例外是已提交的 backend-core 修复需要上线到主 server Compose runtime 时，可以用 `server rebuild backend-core` 受控编译并替换该服务，要求限流并发、异步 job/status 轮询、容器 health 验证和 issue 证据回写。D601 Code Queue 执行面、File Browser、FindJob、Pipeline、MET Nonlinear 和 ClaudeQQ 部署在计算节点，不属于主 server Compose 可重建服务；其中 D601 Code Queue 执行面不得再通过 `codex deploy` 或维护通道直连 D601 部署，且本阶段 prod artifact deploy/rollout/manifest mutation 仍 unsupported。特例冻结清单和下一阶段删除判断见 `docs/reference/cicd-standardization.md`。
|
||||
|
||||
backend-core 的 Dockerfile 必须把 Rust 依赖构建和业务源码构建拆开：先只复制 `Cargo.toml` / `Cargo.lock`，用临时 `src/main.rs` 填充 release 依赖层；再复制真实 `src/` 并编译最终 `backend-core` 二进制。这样同一 builder 上只改业务源码时可以复用依赖层，避免每次重新编译全部 crate。该缓存策略只改善后续源码迭代；全新 builder 的第一次冷编译仍然需要下载和编译依赖，若要把第一次也做快，长期方案应是预构建依赖 builder image、BuildKit registry cache 或由 CI 发布 commit-pinned runtime image 后让部署侧只 pull 成品镜像。
|
||||
|
||||
|
||||
@@ -127,7 +127,7 @@ Todo Note follows the same NC01 YAML-first and GitHub-backed operating model as
|
||||
- Durable state is GitHub repo `pikasTech/decision-center-data`, branch `main`, base path `todo-note`. Decision Center keeps base path `data`, so the services share one repository without sharing object paths. PostgreSQL is an index/cache only.
|
||||
- GitHub SSH credentials come only from the YAML-declared Secret sourceRef shared with Decision Center; CLI output exposes presence and fingerprints, never key material.
|
||||
- Controlled release evidence is `platform-infra pipelines-as-code plan|apply|status|closeout --target NC01 --consumer unidesk-host`, followed by `microservice health todo-note` and storage diagnostics.
|
||||
- CC01 migration uses `POST /api/storage/import` with an explicit confirmed snapshot, then `/api/storage/status` and `/api/storage/verify`. Acceptance must preserve all six lists, the complete undo/redo history and every reminder-notification ledger row before the old runtime is retired.
|
||||
- CC01 migration completed through `POST /api/storage/import`: all six lists, 1167 history rows and the reminder-notification ledger were preserved; DB/Git hashes and a create/add/update/undo/redo/delete lifecycle passed before the old container and legacy Compose/deploy ownership were retired.
|
||||
|
||||
## D601 Direct Compose Consumers
|
||||
|
||||
|
||||
Reference in New Issue
Block a user