Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

review: approve pod orchestration guidance

Browse Source
This commit is contained in:
Keisuke Hirata 2026-06-01 10:24:27 +09:00
parent 5af9a5b1b6
commit d6e36a3268
No known key found for this signature in database
2 changed files with 37 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
work-items/open/20260527-194421-pod-orchestration-system-guidance/item.md
View File

@ -7,7 +7,7 @@ kind: feature
priority: P2
labels: [pod, workflow, prompt]
created_at: 2026-05-27T19:44:21Z
updated_at: 2026-06-01T01:10:57Z
updated_at: 2026-06-01T01:24:27Z
assignee: null
legacy_ticket: null
---

36
work-items/open/20260527-194421-pod-orchestration-system-guidance/thread.md
View File

@ -112,4 +112,40 @@ The ticket affects prompt/system guidance and conditional prompt assembly, but t
- `cargo fmt --check`.
---
<!-- event: review author: hare at: 2026-06-01T01:24:27Z status: approve -->
## Review: approve
External reviewer recommendation: approve.
Summary:
- Static Pod orchestration guidance was added under `resources/prompts/common/pod-orchestration.md` and registered through the prompt catalog.
- The guidance is appended to the materialized system prompt only when available tool names include Pod-management capabilities.
- The gate uses registered tool definitions, not Worker kind, matching the ticket boundary.
- The prompt explicitly covers background notifications, natural stopping points, not keeping a turn open solely to wait, no `sleep`/polling loops for Pod output, evidence-before-completion, and no scheduler/authorization bypass.
Intent / requirement mapping:
- Included when Pod management tools are enabled: satisfied.
- Omitted when Pod management tools are disabled: satisfied.
- Prompt body lives under `resources/prompts`: satisfied.
- Conditional prompt assembly tests exist: satisfied.
Invariant check:
- No changes to PodEvent/notification protocol, TUI notification UI, spawned registry restore, Pod lifecycle behavior, scheduler/auto-maintain behavior, or notification-derived context injection.
- The implementation adds static guidance based on durable tool availability, not transient notification state.
Blockers: none.
Non-blocking follow-ups:
- A future small test could pin the intended "any Pod-management tool is enough" semantics with a single representative tool.
- Tool-name class recognition could be centralized later if more prompt gates need it.
Reported validation from coder was considered sufficient:
- `cargo test -p pod pod_orchestration`
- `cargo test -p pod prompt::catalog`
- `cargo fmt --check`
---