docs: align queue supervision with AgentRun
This commit is contained in:
Codex
@@ -1,10 +1,10 @@
|
||||
# Code Queue 指挥监督策略
|
||||
# AgentRun Queue 与旧 Code Queue 指挥监督策略
|
||||
|
||||
本文定义在人工或 lead-agent 指挥官监督下，把 Code Queue 作为并行交付基础设施使用的长期运行模型。本文是协同策略，不替代 `docs/reference/microservices.md`、`docs/reference/observability.md`、`docs/reference/user-service-delivery.md` 或 Code Queue runtime 合同。
|
||||
本文定义在人工或 lead-agent 指挥官监督下，使用 AgentRun Queue 作为新任务并行交付基础设施、使用旧 Code Queue 作为历史归档和残留任务停止入口的长期运行模型。本文是协同策略，不替代 `docs/reference/microservices.md`、`docs/reference/observability.md`、`docs/reference/user-service-delivery.md`、`docs/reference/agentrun.md` 或 Code Queue runtime 合同。
|
||||
|
||||
## 范围
|
||||
|
||||
当一个交付目标过大，无法由单个 Code Queue 任务完成，并且必须拆分到多个队列、服务或基础设施 lane 时，使用本策略。
|
||||
当一个交付目标过大，无法由单个 AgentRun task 完成，并且必须拆分到多个队列、服务或基础设施 lane 时，使用本策略。
|
||||
|
||||
本策略适用于：
|
||||
|
||||
@@ -12,15 +12,15 @@
|
||||
- 需要多个隔离 worktree 的跨服务修复；
|
||||
- 用户服务开发过程中暴露出来的基础设施缺陷；
|
||||
- 后续验证、retry、验收和任务接力协调；
|
||||
- 指挥官为了保持 Code Queue 任务推进而做的手动监督工作，但不接管 worker 的具体实现。
|
||||
- 指挥官为了保持 AgentRun 任务推进而做的手动监督工作，但不接管 worker 的具体实现。
|
||||
|
||||
本文不授权绕过正常部署、Git 或生产安全规则。
|
||||
|
||||
## 运行原则
|
||||
|
||||
指挥官对最终结果负责，Code Queue task 对边界明确的执行负责。
|
||||
指挥官对最终结果负责，AgentRun task 对边界明确的执行负责。
|
||||
|
||||
指挥官应维护交付目标、活跃队列、阻塞点、证据缺口和下一步恢复动作的实时地图。Code Queue worker 应收到自包含 prompt，prompt 中必须有足够上下文，不能依赖 GitHub issue 可见性或聊天历史。
|
||||
指挥官应维护交付目标、活跃队列、阻塞点、证据缺口和下一步恢复动作的实时地图。AgentRun worker 应收到自包含 prompt，prompt 中必须有足够上下文，不能依赖 GitHub issue 可见性或聊天历史。
|
||||
|
||||
集中指挥的目标是提升交付吞吐和可用性，而不是把每个缺陷都变成一次性的人工修补。
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
|
||||
## HWLAB / #20 监督口径
|
||||
|
||||
`pikasTech/unidesk#20` 只承载 UniDesk 指挥控制面：command/control、Code Queue、CLI、基础设施、PR 收口和治理态势。HWLAB 产品功能、用户体验、M3 验收、DEV runtime、发布收敛和用户反馈必须进入 `pikasTech/HWLAB` issue/PR，并由 `pikasTech/HWLAB#7` 或 HWLAB 侧对应看板承载；#20 只能保留指挥侧路由行、关联 task、阻塞分类和回链，不复制 HWLAB 产品验收口径。更新 #20 时优先使用 `bun scripts/cli.ts gh issue update|board-row ... --board-issue 20`，该 guard 会拒绝把 HWLAB 产品 issue 行写入 #20，并提示改写到 `pikasTech/HWLAB`。HWLAB 指挥侧固定入口、热修边界和长期 source of truth 见 `docs/reference/hwlab.md`。
|
||||
`pikasTech/unidesk#20` 只承载 UniDesk 指挥控制面：command/control、AgentRun Queue、旧 Code Queue 归档、CLI、基础设施、PR 收口和治理态势。HWLAB 产品功能、用户体验、M3 验收、DEV runtime、发布收敛和用户反馈必须进入 `pikasTech/HWLAB` issue/PR，并由 `pikasTech/HWLAB#7` 或 HWLAB 侧对应看板承载；#20 只能保留指挥侧路由行、关联 task、阻塞分类和回链，不复制 HWLAB 产品验收口径。更新 #20 时优先使用 `bun scripts/cli.ts gh issue update|board-row ... --board-issue 20`，该 guard 会拒绝把 HWLAB 产品 issue 行写入 #20，并提示改写到 `pikasTech/HWLAB`。HWLAB 指挥侧固定入口、热修边界和长期 source of truth 见 `docs/reference/hwlab.md`。
|
||||
|
||||
当 HWLAB 是当前优先级最高的推进对象时，所有派单 prompt 的开头都必须显式引用 `DC-DCSN-P0-2026-003`，并说明任务究竟服务于 M3 虚拟硬件可信闭环的哪一环。如果任务只是在做发布前置、诊断、证据收口或文档治理，也必须明确写出它不抢占 M3 P0。
|
||||
|
||||
@@ -76,7 +76,7 @@ HWLAB M3 口径使用同一分级：只读报告、fixture、LOCAL/DRY-RUN 和 d
|
||||
|
||||
## 任务设计
|
||||
|
||||
每个 Code Queue task 都必须有清晰且狭窄的 ownership 边界。
|
||||
每个 AgentRun task 都必须有清晰且狭窄的 ownership 边界。
|
||||
|
||||
- 尽量每个任务只负责一个服务、模块或基础设施缺陷。
|
||||
- 每个任务使用共享 workspace 下自己的 detached worktree。
|
||||
@@ -87,7 +87,7 @@ HWLAB M3 口径使用同一分级：只读报告、fixture、LOCAL/DRY-RUN 和 d
|
||||
|
||||
靠近生产的任务 prompt 必须明确禁止在 master server 上跑已知可能 OOM 的重型本地检查，并说明哪些验证应在 D601 CI、dev env 或目标服务容器中执行。
|
||||
|
||||
当一个指挥机需要突发创建大量 Code Queue 任务时，submit 默认应串行或接近串行。为了避免控制面在确认任务前被打爆，可以使用短本地锁或短延迟，尤其是在低内存主机上。目标是保持任务创建可观测且稳定，而不是最大化瞬时入队吞吐。
|
||||
当一个指挥机需要突发创建大量 AgentRun 任务时，`queue submit` 默认应串行或接近串行。为了避免控制面在确认任务前被打爆，可以使用短本地锁或短延迟，尤其是在低内存主机上。目标是保持任务创建可观测且稳定，而不是最大化瞬时入队吞吐。
|
||||
|
||||
## 模型和成本路由
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
- repo-tree.md (This repository structure reference)
|
||||
- cli.md (CLI command model and async job contract)
|
||||
- config.md (Config and runtime rules)
|
||||
- code-queue-supervision.md (Supervisor policy for parallel Code Queue delivery programs)
|
||||
- code-queue-supervision.md (Supervisor policy for AgentRun Queue delivery programs and legacy Code Queue archive review)
|
||||
- deployment.md (Docker stack deployment and health criteria)
|
||||
- frontend.md (Frontend layout and design rules)
|
||||
- provider-gateway.md (Provider connection and host SSH maintenance bridge)
|
||||
|
||||
@@ -42,7 +42,7 @@ The default release flow for a user-service change is:
|
||||
- The CI artifact producer is not a deploy executor. It must not mutate the production namespace, restart production services, or update `deploy.json`.
|
||||
- `CI.json` may list `blocked` source-build entries when the source input is known but the publish/CD boundary is not yet reviewed. It may also list `upstream-image` entries for image-only services such as File Browser; those entries pin upstream digest and mirror intent but must not be treated as Dockerfile builds.
|
||||
- Every production release must finish with a manual acceptance step after the automated checks pass.
|
||||
- Multi-service delivery programs may use Code Queue parallelization, but the supervisor must follow `docs/reference/code-queue-supervision.md`: tasks need self-contained prompts, isolated worktrees, bounded queue concurrency, explicit acceptance evidence, and infrastructure defects split into separate follow-up tasks when they block several lanes.
|
||||
- Multi-service delivery programs may use AgentRun Queue parallelization, but the supervisor must follow `docs/reference/code-queue-supervision.md`: tasks need self-contained prompts, isolated worktrees, bounded queue concurrency, explicit acceptance evidence, and infrastructure defects split into separate follow-up tasks when they block several lanes. Legacy Code Queue remains an archive/read-only troubleshooting surface for old tasks, not a new-task dispatch path.
|
||||
|
||||
## Upstream Image Services
|
||||
|
||||
|
||||
Reference in New Issue
Block a user