mirrors/pikasTech-unidesk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: clarify code queue supervisor responsibilities

Browse Source
This commit is contained in:
Codex
2026-05-20 02:10:16 +00:00
parent c28b7cdebc
commit 8f316db317
1 changed files with 3 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/code-queue-supervision.md
+3 -1
View File
@@ -24,6 +24,8 @@ The supervisor should keep a live map of the delivery goal, active queues, block
The goal of central supervision is to increase delivery throughput and availability without turning every defect into a manual one-off fix.
The supervisor's end goal is to keep the broader development wave moving: track queue progress, correct course early, review completed work for quality, and schedule the next round of tasks so the delivery program keeps compounding instead of stalling after one batch finishes.
## Task Design
Every Code Queue task must have a narrow ownership boundary.
@@ -33,7 +35,7 @@ Every Code Queue task must have a narrow ownership boundary.
- State the write scope, validation scope, commit/push requirement, and forbidden actions directly in the prompt.
- Include the relevant background in the prompt itself; issue links are supporting references, not required context.
- Prefer existing queues and create new queues only when the existing lanes cannot express the ownership boundary.
- Keep queue concurrency bounded by real execution capacity. A target around five concurrent lanes is the normal operating point; the supervisor may expand up to about ten concurrent lanes when the active tasks have distinct write scopes, heartbeat/trace evidence is healthy, and the extra tasks remove real secondary friction rather than merely filling slots.
- Keep queue concurrency bounded by real execution capacity. A target around five concurrent lanes is the normal operating point; the supervisor should push toward ten concurrent lanes when the active tasks have distinct write scopes, heartbeat/trace evidence is healthy, and the observed success rate stays acceptable. If success quality starts to slip, back off before expanding further.
Prompts for production-adjacent work must explicitly forbid heavy local checks on the master server when those checks are known to risk OOM, and must tell the worker which validation belongs in D601 CI, dev env, or a target service container.