diff --git a/work-items/open/20260527-194421-pod-orchestration-system-guidance/item.md b/work-items/open/20260527-194421-pod-orchestration-system-guidance/item.md index f9658408..46735c0d 100644 --- a/work-items/open/20260527-194421-pod-orchestration-system-guidance/item.md +++ b/work-items/open/20260527-194421-pod-orchestration-system-guidance/item.md @@ -7,15 +7,29 @@ kind: feature priority: P2 labels: [pod, workflow, prompt] created_at: 2026-05-27T19:44:21Z -updated_at: 2026-06-01T00:57:03Z +updated_at: 2026-06-01T01:10:57Z assignee: null legacy_ticket: null --- ## Background -Created by tickets.sh. +Child Pod completion/status notifications are delivered as non-blocking background signals. Parent Pods that have Pod management tools should treat notifications for Pods they spawned as actionable orchestration state, but should not block the active turn merely to wait for output. + +Current guidance is too weak: agents may either ignore routine child-Pod follow-up until the user asks, or waste a turn with `sleep`/polling while waiting for a notification. The desired behavior is notification-driven follow-up at a natural stopping point. + +Prompt text belongs under `resources/prompts`; Rust code should only assemble it conditionally. ## Acceptance criteria -- TBD +- Pod management toolsが有効な Worker の system prompt に orchestration guidance が含まれる。 +- Pod management tools が無効な Worker には含まれない。 +- prompt 本文が `resources/prompts` にある。 +- guidance includes: + - spawned Pod notifications are background signals the parent should handle at a natural stopping point; + - the parent does not need to keep a turn open or call tools solely to wait for a notification; + - do not use `sleep`/polling loops just to wait for Pod output; + - read child output/diff/test evidence before treating delegated work as complete; + - do not start scheduler/auto-maintain behavior or bypass user/workflow authorization. +- Prompt assembly tests cover conditional inclusion/exclusion. +- Related focused tests and `cargo fmt --check` pass. diff --git a/work-items/open/20260527-194421-pod-orchestration-system-guidance/thread.md b/work-items/open/20260527-194421-pod-orchestration-system-guidance/thread.md index c1403734..f53b304e 100644 --- a/work-items/open/20260527-194421-pod-orchestration-system-guidance/thread.md +++ b/work-items/open/20260527-194421-pod-orchestration-system-guidance/thread.md @@ -71,4 +71,45 @@ Add two explicit rules to the Pod orchestration/system guidance: Rationale: during multi-agent work, waiting with `sleep` wastes the active turn and fights the notification model. The desired behavior is notification-driven follow-up, not artificial polling. +--- + + + +## Plan + +## Preflight classification + +implementation-ready. + +The ticket affects prompt/system guidance and conditional prompt assembly, but the desired product behavior is already specified in the ticket thread and item: include orchestration guidance only when Pod management tools are available, keep the prose in `resources/prompts`, and explicitly avoid `sleep`/polling or turn-blocking waits for child Pod output. + +## Current code map + +- `resources/prompts/`: prompt text sources; new guidance text should live here. +- Prompt assembly code/tests: locate the system prompt construction path that already conditionally includes memory/workflow/tool guidance and add a tool-availability gate for Pod orchestration guidance. +- Tool registry / available tool list: use existing tool availability rather than hard-coding a Worker kind if possible. +- Existing prompt assembly tests: add inclusion/exclusion coverage for Pod management tools available/unavailable. + +## Requirements / invariants + +- Guidance is conditional on Pod management tools being available. +- Guidance is not shown to Workers without Pod management tools. +- Guidance must not imply an auto scheduler or unauthorized workflow start. +- Guidance must say notifications can be handled at the next natural point and the parent need not keep the turn open just to wait. +- Guidance must say not to use `sleep`/polling loops merely to wait for Pod output. +- Do not change PodEvent/notification protocol, TUI notification UI, spawned registry restore, or workflow semantics. + +## Escalate if + +- The only available hook requires injecting notification-derived context without durable history. +- Conditional tool-availability detection would require broad ToolRegistry redesign. +- The implementation would change runtime notification delivery or Pod lifecycle behavior instead of prompt guidance. + +## Validation + +- Focused prompt assembly tests for conditional inclusion/exclusion. +- Any touched crate tests relevant to prompt loading/assembly. +- `cargo fmt --check`. + + ---