docs: add next stage cicd dispatch matrix
This commit is contained in:
@@ -210,3 +210,33 @@ The test checks that dev targets only `unidesk-dev`, prod exposes no runtime dep
|
||||
This precheck uses lightweight parsing and dry-run evidence only. It intentionally does not run full `check`, e2e, Playwright, or other broad browser/runtime test suites on the master server because those are outside the precheck scope and may exceed master-server resource limits. `backend-core` and D601 `code-queue` production validation are also out of scope; backend-core dev rollout can be attempted only through the existing D601 dev path, and a provider-offline result is an infrastructure blocker rather than permission to validate production.
|
||||
|
||||
The structured read-only preflight entrypoints are `artifact-registry status|health` and `ci publish-user-service --dry-run`. Remote runners may call them through the frontend passthrough path, and the result must classify missing backend-core, database, provider or registry channels as `runnerDisposition=infra-blocked`. The detailed probe list remains in `missingChannels`; the stable runner-facing domain list is `missingControlChannels` with only `backend-core`, `database`, `provider` and `registry`. Those cases are infrastructure blockers, not business failures and not a license to retry a real publish. A non-dry-run publish may be attempted only where `controlledPublish` points: D601 CI, namespace `unidesk-ci`, PipelineRun `unidesk-user-service-artifact-publish`.
|
||||
|
||||
## Next Stage Dispatch Matrix
|
||||
|
||||
This matrix describes the next promotion stage after dry-run coverage is in place. It favors correctness over throughput, keeps `backend-core` and D601 `code-queue` dev-only, and splits dev and prod only where the runtime policy already allows it.
|
||||
|
||||
| Service class | Target branch | CI current state | CD current state | DEV acceptance | PROD acceptance | Blockers | Suggested model |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| `backend-core` | `master` | source-build supported | dev target-side rollout only | Rust build + dev rollout proof on D601; no prod gate in this phase | not authorized | keep Rust iteration on D601 dev path; no prod validation | `GPT-5.5` |
|
||||
| `code-queue` | `master` | source-build supported, dev-only | dev-only k3s consumer | dev artifact validation for `unidesk-dev` scheduler/read/write/provider-egress-proxy | not implemented; must remain unsupported | production boundary, hostPath/source contract, scheduler/egress dependency health | `GPT-5.5` |
|
||||
| `frontend` | `master` | source-build supported | dev + prod artifact consumer | commit-pinned dev rollout and `/health.deploy.commit` | commit-pinned prod recreate and UI route verification | none beyond standard artifact/CD checks | `GPT-5.5` |
|
||||
| `baidu-netdisk` | `master` | source-build supported | dev + prod artifact consumer | pull-only dev validation plus auth and proxy checks | pull-only prod recreate plus live commit and proxy checks | secret presence and `/health.auth` gate | `GPT-5.5` |
|
||||
| `project-manager` | `master` | source-build supported | dev + prod artifact consumer | dev artifact validation with `/api/projects` | prod artifact validation with live commit proof | none beyond standard artifact/CD checks | `MiniMax` for dry-run/reporting, `GPT-5.5` for release sign-off |
|
||||
| `oa-event-flow` | `master` | source-build supported | dev + prod artifact consumer | dev artifact validation with `/api/diagnostics` | prod artifact validation with live commit proof | none beyond standard artifact/CD checks | `MiniMax` for dry-run/reporting, `GPT-5.5` for release sign-off |
|
||||
| `todo-note` | `master` | external source-build supported | dev + prod artifact consumer | dev recreate with PostgreSQL-backed deploy metadata | prod recreate with matching `deploy.commit` and `deploy.requestedCommit` | external repo fetch and runtime metadata consistency | `DeepSeek` for digesting external-source evidence, `GPT-5.5` for final gate |
|
||||
| `decision-center` | `master` | source-build supported | dev + prod k3s consumer | dev gate with record CRUD, diary lifecycle, doc-number uniqueness and frontend visibility | manual prod acceptance after dev gate; verify health, records, diary editor and live commit | doc-management completeness, PostgreSQL truth, no public business ports | `GPT-5.5` |
|
||||
| `mdtodo` | `master` | source-build supported | dev + prod k3s consumer | dev rollout with deployment metadata and `/health` or `/live` proof | prod rollout with service proxy verification and live commit proof | no NodePort/hostPort/public backend exposure | `MiniMax` for prompt prep, `GPT-5.5` for approval |
|
||||
| `claudeqq` | `master` | source-build supported | dev + prod k3s consumer | dev rollout with Deployment metadata and health via Kubernetes API proxy | prod rollout with same commit-pinned artifact contract | NapCat/backend port exposure must stay private | `MiniMax` for prompt prep, `GPT-5.5` for approval |
|
||||
| `findjob` | `master` | source-build supported | dev + prod direct Compose consumer | pull-only dev validation on D601 with image labels and `/api/health` | pull-only prod recreate with live commit proof | target-side compose health/labels only, no public business ports | `DeepSeek` for dry-run matrix drafting, `GPT-5.5` for final gate |
|
||||
| `pipeline` | `master` | source-build supported | dev + prod direct Compose consumer | pull-only dev validation on D601 with image labels and `/health` | pull-only prod recreate with live commit proof | runtime contract is commit-label + compose service identity | `DeepSeek` for dry-run matrix drafting, `GPT-5.5` for final gate |
|
||||
| `met-nonlinear` | `master` | source-build supported | dev dry-run only | runtime-verification-blocked until long-running TS service image contract is fixed | not authorized | image contract mismatch between ML Dockerfile and TS runtime service | `GPT-5.5` |
|
||||
| `k3sctl-adapter` | `master` | source-build supported | plan/dry-run only | no normal dev target; only control-bridge health and recovery evidence | prod live apply requires supervisor confirmation | bridge recovery, k3s fault-domain isolation, no worker self-replacement | `GPT-5.5` |
|
||||
| `filebrowser` / `filebrowser-d601` | `master` | upstream-image blocked | pull-only mirror target | digest resolution, mirror governance and private proxy health only | not in this phase | upstream digest/mirror worker not yet implemented | `DeepSeek` for evidence summarization, `GPT-5.5` for blocker resolution |
|
||||
|
||||
Planned parallelism for the next wave should be three lanes:
|
||||
|
||||
1. Lane A: `frontend`, `baidu-netdisk`, `project-manager`, `oa-event-flow`.
|
||||
2. Lane B: `decision-center`, `mdtodo`, `claudeqq`, `todo-note`.
|
||||
3. Lane C: `findjob`, `pipeline`, `met-nonlinear`, `k3sctl-adapter`, `code-queue`, `backend-core`.
|
||||
|
||||
Lane C must stay split into dev-only work for `backend-core` and `code-queue`, plus read-only or dry-run work for `met-nonlinear` and `k3sctl-adapter`. `backend-core` and `code-queue` must not be promoted into prod acceptance tasks in this phase.
|
||||
|
||||
@@ -29,6 +29,7 @@ CLI 可以从 `master` 快速演进,但必须兼容 `deploy.json` 固定的 CI
|
||||
- `dev-env validate [--manifest path] [--kubectl-dry-run]` 离线校验 D601 `unidesk-dev` namespace、dev PostgreSQL 底座和 dev workload manifest。默认检查 `src/components/microservices/k3sctl-adapter/k3s/dev/unidesk-dev-foundation.k8s.yaml`;也可显式校验 `src/components/microservices/k3sctl-adapter/k3s/dev/unidesk-dev-core.k8s.yaml` 或 `src/components/microservices/k3sctl-adapter/k3s/dev/unidesk-dev-code-queue.k8s.yaml`。所有 namespaced 对象必须只落到 `unidesk-dev`,foundation manifest 必须包含 `postgres-dev` StatefulSet/Service、dev secret/config、迁移 Job 和 DB URL guard,core manifest 必须包含 `backend-core-dev`/`frontend-dev` Deployment/Service,Code Queue dev manifest 必须包含 `code-queue-scheduler-dev`、`code-queue-read-dev`、`code-queue-write-dev`、dev provider egress proxy,以及只读挂载宿主 `/home/ubuntu/.agents/skills` 到容器 `/root/.agents/skills` 的 `skills-dir` volume。加 `--kubectl-dry-run` 时额外执行 `kubectl apply --dry-run=client --validate=false -f <manifest>`,仍不 apply 资源。
|
||||
- `dev-env prewarm-images [--image image] [--provider-id D601] [--no-pull] [--proxy-url URL] [--pull-timeout-ms N] [--dry-run]` 创建异步 job,通过 UniDesk SSH 维护桥在 D601 上把开发底座依赖镜像从 Docker 缓存导入原生 k3s containerd。默认镜像是 `postgres:16-alpine` 和 `rancher/mirrored-library-busybox:1.36.1`,用于避免 `postgres-dev` 与 local-path helper pod 卡在外部 registry 拉取。该命令固定验证 `/etc/rancher/k3s/k3s.yaml` 指向的 native k3s 上下文,并输出 `dev_env_containerd_image_ready=...` 作为成功判据;它不 apply manifest、不修改生产 `unidesk` namespace。
|
||||
- `artifact-registry plan|render|status|health|install|deploy-backend-core|deploy-service` 管理 D601 host-managed CNCF Distribution registry 的声明、安装、只读检查和 pull-only artifact CD。该 registry 固定为 D601 loopback `127.0.0.1:5000`,由 systemd + Docker Compose 管理,位于 native k3s 故障域外;`deploy-service` 只拉取 CI 已发布的 commit-pinned 镜像、retag/recreate 或导入 native k3s,并做 live commit 验证,不构建 runtime source。`deploy-backend-core` 是 deprecated 兼容名,标准 backend-core prod CD 入口是 `deploy apply --env prod --service backend-core`。长期规则见 `docs/reference/artifact-registry.md`。
|
||||
- `commander contract|plan --dry-run|approval request --dry-run` 是 host Codex 指挥官直管微服务第一阶段 contract 入口。当前只返回 `phase=source-contract`、service/API/state/bridge/prompt/trace/#20/#46/ClaudeQQ 审批边界和 dry-run 计划,不启动 daemon、不打开 SSH/PTY/stdio、不注入 prompt、不发送 ClaudeQQ。`plan` 与 `approval request` 必须带 `--dry-run`;缺少时返回 `error=dry-run-required`。长期规则见 `docs/reference/host-codex-commander.md`。
|
||||
- `gh auth status [--repo owner/name]` 探测 GitHub 操作前置条件并输出脱敏 JSON:是否存在 `gh` binary、是否存在 `GH_TOKEN`/`GITHUB_TOKEN` 或可用 `gh auth token` fallback、REST API 是否可达、目标 repo 是否可见、issue 是否可读。degraded reason 必须归类为 `missing-binary`、`missing-token`、`auth-failed`、`network-proxy-failed`、`permission-denied`、`repo-not-found`、`repo-forbidden`、`issue-not-found`、`pr-not-found`、`scope-insufficient`、`validation-failed`、`invalid-response` 或 `unsupported-command`,不得打印 token;失败对象必须包含 `runnerDisposition=infra-blocked|business-failed`,runner 应优先用该字段分流。
|
||||
- `gh issue list [--state open|closed|all] [--limit N] [--repo owner/name] [--json number,title,state,url,updatedAt,createdAt,author,labels]` 通过 GitHub REST 列出 issue,默认 `state=open`、`limit=30`,输出稳定 JSON 且不依赖系统 `gh` binary。`--limit` 会映射到 GitHub `per_page` 并限制返回数量,避免一次拉爆上下文;未知 state 或未知 `--json` 字段必须结构化失败并带 `runnerDisposition=business-failed`。GitHub issues API 可能混入 PR,CLI 会从 `.data.issues` 中过滤 pull request。
|
||||
- `gh issue read <number> [--repo owner/name] [--json body,title,state,comments]` 通过 GitHub REST 读取 issue title/body/state/url 和 comments,默认输出 JSON;`view` 只保留为兼容别名。兼容旧脚本的 `--json body` 和 `--json body,title,state,comments` 字段选择,且正文仍稳定暴露在 `.data.issue.body`,避免调用方因为 JSON 路径变化把空值当成正文。字段白名单是 `body,title,state,comments,number,url,author,createdAt,updatedAt`,未知字段必须结构化失败并带 `runnerDisposition=business-failed`。`gh issue create --title <title> --body-file <file> [--label label[,label...]]... [--dry-run]`、`gh issue update <number> --mode replace|append --body-file <file> [--title ...] [--dry-run]`、`gh issue comment create <number> --body-file <file> [--dry-run]`、`gh issue comment delete <commentId> [--dry-run]`、`gh issue close|reopen <number> [--dry-run]` 都走 REST,不依赖 `gh` binary。`--label` 仅用于 `issue create`,支持重复传入和逗号分隔;`--dry-run` 会展示解析后的 labels 与 request plan,正式创建时把 labels 放入 GitHub REST create-issue payload,GitHub 返回不存在 label 等 422 校验失败时 CLI 结构化返回 `validation-failed`,不静默成功。`gh issue delete <number>` 是结构化 `unsupported-command`,因为 GitHub REST 不支持 issue 硬删除;生命周期删除语义请使用 `close`。
|
||||
|
||||
@@ -189,6 +189,8 @@ ClaudeQQ 是面向用户的主动提醒通道,不是 #24 简报更新的自动
|
||||
|
||||
重启 Code Queue backend、重建 Code Queue backend 容器、重启 Code Queue 执行面,或对运行中 Code Queue 任务执行 interrupt/cancel 这类会改变执行状态的操作,都属于高风险干预。即使看起来是最小恢复动作,指挥官也必须先通过 ClaudeQQ 向用户上报原因、影响范围和拟执行动作,并等待用户明确同意;未获得同意前只能做只读诊断、记录 issue、更新看板和准备恢复方案。
|
||||
|
||||
host Codex 指挥官正规化后仍受同一条高风险边界约束。`docs/reference/host-codex-commander.md` 中的直管微服务只能把 host Codex 保活、SSH/PTY/stdio bridge、prompt plan、trace summary、#20/#46 issue 入口和 ClaudeQQ 审批记录产品化;它不是 Code Queue runner,也不是 Code Queue 自部署通道。第一阶段 `bun scripts/cli.ts commander ...` 只允许输出 contract/dry-run 计划,不得实际重启 backend、interrupt/cancel task、读取 token 明文、打开 bridge 或发送 ClaudeQQ。
|
||||
|
||||
当多信号裁决显示 provider 服务器、D601 执行面或关键维护桥疑似需要人工检查时,指挥官可以在更新 #24/#40 等记录之外,通过 ClaudeQQ 额外提醒用户检查 provider 服务器状态。提醒只在首次确认、状态恶化、恢复或需要用户介入时发送,不能在每轮轮询中重复轰炸。ClaudeQQ 提醒是 best-effort:若 ClaudeQQ 本身依赖同一条故障 provider/k3sctl 链路而不可达,指挥官应把通知失败的原因写入 #24 或对应 blocker issue,并继续按轮询和恢复规则推进。
|
||||
|
||||
在 UniDesk CLI 中,`bun scripts/cli.ts provider triage <providerId>` 是只读多信号裁决入口,适合作为 worker 和指挥官的统一健康判断前置。它必须至少保留这些合同:`provider is not online` 这类单路径失败只应落到 `decision=retryable-transient` / `blockingDisposition=runner-local-observation-gap`,不得直接输出 `global-offline`;只有 provider-gateway/SSH/k3s/scheduler 等多个独立关键路径同时失败且缺少健康交叉证据,才允许输出 `decision=global-offline`;registry 或单个 service proxy 失败但 heartbeat、SSH 或节点视图仍健康时,应输出 `decision=service-degraded`。`recommendedCrossChecks` 必须包含 `debug health`、`debug dispatch <providerId> host.ssh --wait-ms 15000`、`ssh <providerId> argv true`、`artifact-registry health --provider-id <providerId>`、`microservice health k3sctl-adapter`、`microservice health code-queue` 与 `codex tasks --view supervisor --limit 20`。
|
||||
|
||||
@@ -0,0 +1,231 @@
|
||||
# Host Codex Commander Contract
|
||||
|
||||
本文定义第一阶段的 host Codex 指挥官正规化设计。当前阶段只建立 source/contract、CLI dry-run stub、状态模型和安全边界;不部署、不重启、不上线 production,也不实现会实际执行后台动作的守护进程。
|
||||
|
||||
## 目标边界
|
||||
|
||||
host Codex 指挥官是独立用户服务/基础设施:在 master server host 上保留一个常驻 Codex 指挥会话,由未来的直管微服务负责保活、prompt 注入、trace 采集和高风险动作请示。它不替代 Code Queue runner,也不让 Code Queue 自己上线自己。
|
||||
|
||||
服务边界固定为三层:
|
||||
|
||||
- host Codex 进程:运行在 master server host 的常驻 Codex 指挥会话,只负责监督、派单、审阅和恢复计划。
|
||||
- 直管控制微服务:运行在 host 侧或能直接接入 host TTY/stdio 的受控位置,负责发现/启动计划、SSH/PTY/stdio bridge、事件持久化、prompt plan、trace summary 和审批状态。
|
||||
- UniDesk/Code Queue/ClaudeQQ:Code Queue 继续作为任务执行面,GitHub issue 继续作为长期记录,ClaudeQQ 作为高风险动作请示入口。
|
||||
|
||||
第一阶段只允许这些产物:
|
||||
|
||||
- `docs/reference/host-codex-commander.md` 长期 contract;
|
||||
- `bun scripts/cli.ts commander contract` 和 `commander plan --dry-run` 这类只读/dry-run 输出;
|
||||
- contract test 证明 CLI 不执行 live operation;
|
||||
- 后续任务拆分。
|
||||
|
||||
## 非目标
|
||||
|
||||
当前阶段明确不做:
|
||||
|
||||
- 不启动、停止或重启任何常驻 commander daemon;
|
||||
- 不打开真实 PTY、stdio 或 SSH bridge;
|
||||
- 不向 host Codex 注入真实 prompt;
|
||||
- 不发送 ClaudeQQ 消息;
|
||||
- 不部署、不重启、不上线 prod;
|
||||
- 不直接重启 Code Queue backend,不重建 Code Queue backend 容器,不重启 Code Queue 执行面;
|
||||
- 不 cancel 或 interrupt 运行中的 Code Queue task;
|
||||
- 不读取、打印或持久化 token 明文。
|
||||
|
||||
这些动作即使未来实现,也必须先通过本文的审批和安全边界。
|
||||
|
||||
## CLI Contract
|
||||
|
||||
统一入口:
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts commander contract
|
||||
bun scripts/cli.ts commander plan --dry-run [--session-id primary]
|
||||
bun scripts/cli.ts commander approval request --action <action> --dry-run [--reason text] [--task-id id]
|
||||
```
|
||||
|
||||
所有命令默认输出 JSON,失败也必须有结构化 stdout 和非零退出码。`plan` 和 `approval request` 在第一阶段必须要求 `--dry-run`;没有 `--dry-run` 时必须返回 `ok=false`、`error=dry-run-required`,不能降级成真实执行。
|
||||
|
||||
`commander contract` 必须暴露:
|
||||
|
||||
- `phase=source-contract`;
|
||||
- `serviceId=host-codex-commander`;
|
||||
- `daemonImplemented=false`;
|
||||
- `liveOperationsImplemented=false`;
|
||||
- 需要的 host Codex 发现/启动计划、SSH/PTY/stdio bridge、prompt guidance、trace summary、#20/#46 issue 入口、ClaudeQQ 审批入口;
|
||||
- `safetyBoundary`。
|
||||
|
||||
`commander plan --dry-run` 必须输出:
|
||||
|
||||
- process discovery signal 列表;
|
||||
- host Codex start command shape,但 `enabled=false`;
|
||||
- SSH/PTY/stdio bridge 设计和 guardrail;
|
||||
- prompt guidance pipeline;
|
||||
- trace summary sources 和 summary shape;
|
||||
- #20/#46 read/write 入口;
|
||||
- ClaudeQQ high-risk approval command shape;
|
||||
- `mutation=false`。
|
||||
|
||||
`commander approval request --dry-run` 只生成审批草案。允许的 `--action` 固定为:
|
||||
|
||||
- `code-queue-backend-restart`
|
||||
- `code-queue-backend-rebuild`
|
||||
- `code-queue-execution-plane-restart`
|
||||
- `code-queue-task-interrupt`
|
||||
- `code-queue-task-cancel`
|
||||
- `prod-runtime-mutation`
|
||||
|
||||
输出中 `claudeqq.mutation=false`、`sendImplemented=false`。真实发送和审批消费属于后续阶段。
|
||||
|
||||
## Future API Contract
|
||||
|
||||
后续微服务 API 以 REST 为主,所有写入口默认异步、有 request id、有事件序列、有 redaction 结果:
|
||||
|
||||
| Method | Path | 用途 | 第一阶段状态 |
|
||||
| --- | --- | --- | --- |
|
||||
| GET | `/health` | 服务健康、版本、日志路径、state root | contract only |
|
||||
| GET | `/api/commander/contract` | 返回本文对应机器可读 contract | contract only |
|
||||
| GET | `/api/commander/sessions` | 列出 host Codex session 摘要 | contract only |
|
||||
| POST | `/api/commander/sessions/:sessionId/plan-start` | 生成发现/启动计划 | contract only |
|
||||
| POST | `/api/commander/sessions/:sessionId/prompt-plan` | 生成 prompt 注入计划 | contract only |
|
||||
| GET | `/api/commander/trace-summary` | 读取有界 trace summary | contract only |
|
||||
| POST | `/api/commander/issues/:issueNumber/write-plan` | 生成 #20/#46 写入计划 | contract only |
|
||||
| POST | `/api/commander/approvals` | 创建 ClaudeQQ 高风险请示草案 | contract only |
|
||||
|
||||
后续实现不得绕过现有 CLI/服务边界。GitHub issue 写入仍使用 `bun scripts/cli.ts gh issue ... --body-file`、dry-run-first 和并发 guard;Code Queue 读写仍优先使用 `codex task/tasks/steer/read` 等正式入口。
|
||||
|
||||
## State Model
|
||||
|
||||
状态根目录规划为 `.state/commander/`。后续服务至少拆成这些文件或等价表:
|
||||
|
||||
- `sessions/<sessionId>.json`:host Codex session 摘要、pid/cwd 指纹、bridge 状态、lastSeq、heartbeat;
|
||||
- `events/<sessionId>.jsonl`:prompt、trace、approval、bridge lifecycle 事件;
|
||||
- `approvals/<approvalId>.json`:ClaudeQQ 请示草案、状态、授权绑定动作、过期时间;
|
||||
- `locks/<name>.lock.d/`:启动、prompt injection、issue write、approval consume 的互斥锁;
|
||||
- `redactions/<eventId>.json`:脱敏摘要,不保存明文 secret。
|
||||
|
||||
session 状态:
|
||||
|
||||
| State | 含义 |
|
||||
| --- | --- |
|
||||
| `unknown` | 没有足够信号判断 host Codex 是否存在 |
|
||||
| `discovered` | 通过 state/process/bridge heartbeat 找到候选会话 |
|
||||
| `planned` | 只生成启动或接管计划,尚未执行 |
|
||||
| `starting` | 后续 live executor 正在启动或 attach |
|
||||
| `running` | heartbeat 和 trace 新鲜 |
|
||||
| `attention_required` | 需要人工判断或审批 |
|
||||
| `stopping` | 后续 live executor 正在退出 |
|
||||
| `stopped` | 会话已终止 |
|
||||
| `degraded` | bridge、trace 或状态持久化部分失败 |
|
||||
|
||||
prompt 状态:`draft`、`planned`、`queued_for_injection`、`injected`、`rejected`、`failed`。
|
||||
|
||||
approval 状态:`draft`、`requested`、`approved`、`rejected`、`expired`、`consumed`。审批只能绑定一个具体 action、taskId 或 target,不得作为泛授权复用。
|
||||
|
||||
## Bridge Contract
|
||||
|
||||
SSH bridge 只复用现有 UniDesk Host SSH / WSL SSH 维护桥。它用于 provider 只读诊断、受控维护命令和未来已审批恢复动作;不得作为 provider-gateway 自重建通道,也不得绕过 provider.upgrade 调度规则。
|
||||
|
||||
PTY bridge 用于 host Codex 交互会话保活和窗口化 transcript 采集。后续实现必须:
|
||||
|
||||
- 有 heartbeat;
|
||||
- stdout/stderr 分流或标注;
|
||||
- 按 seq 写入事件;
|
||||
- 默认有 byte/line 上限;
|
||||
- prompt 注入前先落 plan 和 redaction summary;
|
||||
- 注入失败必须可见,不得静默重试。
|
||||
|
||||
stdio bridge 用于非交互 Codex 或 helper subprocess。它必须有 argv 记录、cwd、env key allowlist、exit code、timeout 和 bounded output。env 只能记录 key 存在性或来源,不能记录值。
|
||||
|
||||
## Prompt Guidance
|
||||
|
||||
prompt 注入前必须按顺序执行:
|
||||
|
||||
1. 分类意图和风险;
|
||||
2. 汇总当前 #20/#46/task/queue 的有界上下文;
|
||||
3. 运行 forbidden-action guard;
|
||||
4. 对 prompt 和上下文做 secret-like redaction;
|
||||
5. 持久化 prompt plan;
|
||||
6. 后续 live executor 仅在 policy pass 后注入。
|
||||
|
||||
遇到 Code Queue backend 重启/重建、执行面重启、task interrupt/cancel、prod mutation、token 访问、破坏性 Git 操作时,必须转入 ClaudeQQ 审批草案,而不是注入执行 prompt。
|
||||
|
||||
## Trace Summary
|
||||
|
||||
trace summary 不是 raw transcript dump。默认输出应包含:
|
||||
|
||||
- `taskId`、`sessionId`、`lastSeq`;
|
||||
- 当前状态和 freshness;
|
||||
- 最近关键事件;
|
||||
- open questions;
|
||||
- recommended next actions;
|
||||
- redactionsApplied;
|
||||
- drill-down 命令。
|
||||
|
||||
原始 transcript 必须分页读取,默认不在 summary 中展开。summary 可以引用 Code Queue `codex task --trace`、`codex output`、host Codex event JSONL 和 approval event,但不能把任一路径失败升级为全局故障,仍需遵守 `docs/reference/code-queue-supervision.md` 的多信号裁决规则。
|
||||
|
||||
## Issue Entrypoints
|
||||
|
||||
#20 是 Code Queue 总看板入口。读取优先:
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts gh issue board-audit --board-issue 20 --dry-run
|
||||
bun scripts/cli.ts gh issue board-row list --board-issue 20
|
||||
```
|
||||
|
||||
写入必须先 dry-run,再带 body SHA 或 updatedAt:
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts gh issue board-row update <issueNumber> --board-issue 20 --field progress --value <text> --expect-body-sha <sha>
|
||||
```
|
||||
|
||||
#46 是每日指挥简报入口。读取:
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts gh issue read 46 --json body,title,state,updatedAt
|
||||
```
|
||||
|
||||
写入:
|
||||
|
||||
```bash
|
||||
bun scripts/cli.ts gh issue update 46 --body-profile commander-brief --body-file <file> --expect-updated-at <ts>
|
||||
```
|
||||
|
||||
所有 Markdown 正文必须来自 `--body-file`,禁止把正文拼入 shell 参数。任何 issue 写入都不能自动触发 ClaudeQQ,除非该动作本身是高风险请示或用户通知策略明确要求。
|
||||
|
||||
## Safety Boundary
|
||||
|
||||
第一阶段所有 commander CLI 输出都必须是 `mutation=false`。
|
||||
|
||||
未来 live executor 在没有用户明确同意前也不得执行:
|
||||
|
||||
- 重启或重建 Code Queue backend;
|
||||
- 重启 Code Queue 执行面;
|
||||
- interrupt 或 cancel 运行任务;
|
||||
- 修改 production runtime;
|
||||
- 读取或输出 token 明文;
|
||||
- 直写 PostgreSQL 修补任务状态;
|
||||
- 破坏性 Git 操作;
|
||||
- 绕过 GitHub issue body-file 和并发 guard。
|
||||
|
||||
高风险动作流程固定为:
|
||||
|
||||
1. 生成 ClaudeQQ 请示草案,说明原因、影响范围、拟执行动作和可回滚性;
|
||||
2. 发送给配置的主用户私聊入口;
|
||||
3. 等待明确批准;
|
||||
4. 将批准绑定到唯一 action 和 target;
|
||||
5. 执行前再次校验审批未过期且未被消费;
|
||||
6. 执行后写入 #46 或对应 issue 的结果摘要。
|
||||
|
||||
ClaudeQQ 不可达时,不得把请求视为已批准;只能记录通知失败和继续只读诊断。
|
||||
|
||||
## Next Stage Tasks
|
||||
|
||||
可派单的下一阶段任务:
|
||||
|
||||
- 实现 `src/components/microservices/host-codex-commander` 服务骨架,提供 `/health` 和 `/api/commander/contract`,仍不启动 live bridge。
|
||||
- 增加 `.state/commander/` 文件状态读写模块和 redaction 单元测试。
|
||||
- 实现只读 host Codex process discovery,输出候选 pid/cwd/age,不 attach、不 kill。
|
||||
- 实现 trace summary 聚合器,读取 mock event JSONL 和 Code Queue bounded trace。
|
||||
- 实现 ClaudeQQ approval draft service,不发送消息,只落审批草案和 preview。
|
||||
- 设计第二阶段 live PTY/stdio bridge 的权限、日志、锁和超时测试。
|
||||
Reference in New Issue
Block a user