plan: parallel ticket preflight
This commit is contained in:
parent
e88ecd1903
commit
08397f3f3b
|
|
@ -7,7 +7,7 @@ kind: task
|
|||
priority: P2
|
||||
labels: [migrated]
|
||||
created_at: 2026-05-27T00:00:16Z
|
||||
updated_at: 2026-05-27T00:00:16Z
|
||||
updated_at: 2026-05-30T04:54:03Z
|
||||
assignee: null
|
||||
legacy_ticket: tickets/tui-picker-live-pending-pods.md
|
||||
---
|
||||
|
|
|
|||
|
|
@ -4,4 +4,55 @@
|
|||
|
||||
Migrated from tickets/tui-picker-live-pending-pods.md. No legacy review file was present at migration time.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: hare at: 2026-05-30T04:54:03Z -->
|
||||
|
||||
## Plan
|
||||
|
||||
## Preflight implementation plan
|
||||
|
||||
Classification: implementation-ready.
|
||||
|
||||
No blocking preflight gap remains. The product rule is settled: reachable live Pods must be visible/attachable even if durable session-log metadata is incomplete, but missing session logs must not make them restorable.
|
||||
|
||||
Implementation detail to preserve:
|
||||
- Treat “pending live” as a display/model condition, not persisted state.
|
||||
- Use reachable `LivePodInfo` plus incomplete stored/session summary or runtime-only segment id to improve row order/preview/debug ids.
|
||||
- Do not mark the Pod restorable unless stored metadata has a usable active segment/session under existing restore rules.
|
||||
|
||||
Current code map:
|
||||
- `crates/tui/src/picker.rs`: picker construction, row rendering, live attach socket override.
|
||||
- `crates/tui/src/pod_list.rs`: shared model merge/sort/truncation/actions; current sort is updated_at desc only; `merge_live` already supplements segment id from runtime.
|
||||
- `crates/tui/src/main.rs`: selected live row attaches via socket override before restore fallback.
|
||||
- `crates/tui/src/multi_pod.rs`: also uses `PodList`, so ordering effects should be checked.
|
||||
- `crates/pod/src/discovery.rs`: List/Attach/Restore behavior is related but out of scope.
|
||||
- `crates/pod-registry/src/table.rs`: runtime allocation segment id source.
|
||||
- `crates/pod-store/src/lib.rs`: pending active segment metadata; do not persist runtime supplementation.
|
||||
|
||||
Implementation phases:
|
||||
1. Change `PodList::from_sources` sorting to reachable-live first, then updated_at desc, then pod_name asc; truncation remains after sorting.
|
||||
2. Make reachable live pending preview explicit, e.g. `[live, pending segment]`, when durable summary is incomplete.
|
||||
3. Preserve and test runtime segment id supplementation for display/debug ids only.
|
||||
4. Add focused `pod_list` tests for live-first-before-truncation, live pending runtime segment attach-only behavior, and live-only runtime segment attach-only behavior.
|
||||
5. Adjust existing sort/multi-pod tests only as needed.
|
||||
6. Keep `PodDiscovery::inspect` / `AttachOrRestorePod` behavior out of scope; record follow-up if needed.
|
||||
|
||||
Critical risks:
|
||||
- Live attachability and restoreability must stay separate.
|
||||
- Do not persist runtime segment supplementation to pod-store.
|
||||
- Sort must happen before truncation.
|
||||
- Do not duplicate picker-specific merge/sort logic; fix shared `PodList`.
|
||||
- Rank reachable live rows, not unreachable registry allocations.
|
||||
- Preview wording must not imply restoreability.
|
||||
- Multi-Pod dashboard ordering may change; reviewer should check it remains intended.
|
||||
|
||||
Validation plan:
|
||||
- `cargo test -p tui pod_list`
|
||||
- `cargo test -p tui picker`
|
||||
- `cargo test -p tui multi_pod`
|
||||
- `cargo test -p tui`
|
||||
- `cargo fmt --check`
|
||||
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ kind: bug
|
|||
priority: P2
|
||||
labels: [pod, events, orchestration, context]
|
||||
created_at: 2026-05-29T16:30:47Z
|
||||
updated_at: 2026-05-29T16:30:47Z
|
||||
updated_at: 2026-05-30T04:54:02Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
|
|
|||
|
|
@ -4,4 +4,46 @@
|
|||
|
||||
Created by tickets.sh create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: hare at: 2026-05-30T04:54:02Z -->
|
||||
|
||||
## Plan
|
||||
|
||||
## Preflight implementation plan
|
||||
|
||||
Classification: implementation-ready.
|
||||
|
||||
No product/API decision is needed before coding. `ScopeSubDelegated` remains a valid typed `PodEvent` for registry side effects and upward propagation, but must not enter the agent-visible notification/history/auto-kick lane.
|
||||
|
||||
Current code map:
|
||||
- `crates/protocol/src/lib.rs`: `PodEvent` variants and protocol roundtrip tests.
|
||||
- `crates/pod/src/controller.rs`: idle `Method::PodEvent` handler applies side effects, pushes notification, and auto-kicks; running-path handler applies side effects and pushes into `NotifyBuffer`.
|
||||
- `crates/pod/src/ipc/event.rs`: transport helpers and `apply_event_side_effects`; `ScopeSubDelegated` registers grandchild and re-emits upward.
|
||||
- `crates/pod/src/ipc/notify_buffer.rs`: agent-visible notification/history lane.
|
||||
- `crates/pod/src/ipc/interceptor.rs`: drains `NotifyBuffer` into session history/context.
|
||||
- Existing tests: controller tests for visible `TurnEnded`, pod events tests for `ScopeSubDelegated` registry/re-emission, protocol roundtrips.
|
||||
|
||||
Implementation phases:
|
||||
1. Add `PodEvent::should_notify_agent()` classification in `protocol`: true for `TurnEnded`, `Errored`, `ShutDown`; false for `ScopeSubDelegated`.
|
||||
2. Gate idle-path notification/auto-kick in `controller.rs`: always apply side effects; only push notify and schedule `RunForNotification` when `should_notify_agent()` is true.
|
||||
3. Gate running-path notification buffering the same way.
|
||||
4. Update comments/docs in protocol/controller/notify/event modules to distinguish control-plane side effects from agent-visible notifications.
|
||||
5. Add focused tests.
|
||||
|
||||
Critical risks:
|
||||
- Never skip `apply_event_side_effects` for `ScopeSubDelegated`.
|
||||
- Gate both idle and running receive paths.
|
||||
- Do not change wire serialization or remove the event.
|
||||
- Do not demote `ShutDown`; it remains agent-visible.
|
||||
- Do not use rendering availability as the visibility decision.
|
||||
|
||||
Validation plan:
|
||||
- Protocol test for `should_notify_agent` classification.
|
||||
- Controller test: idle `ScopeSubDelegated` updates side effects as needed but creates no `SystemItem::PodEvent`, no auto-started LLM request, and parent remains idle.
|
||||
- Keep/verify existing positive `TurnEnded` auto-kick test.
|
||||
- Existing `pod_events_test` should still pass for registry/re-emission.
|
||||
- Run `cargo test -p protocol pod_event`, `cargo test -p pod --test pod_events`, focused controller pod-event tests, and `cargo fmt --check`.
|
||||
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ kind: feature
|
|||
priority: P2
|
||||
labels: [pod, manifest, tools, workflow]
|
||||
created_at: 2026-05-29T20:55:40Z
|
||||
updated_at: 2026-05-30T02:53:19Z
|
||||
updated_at: 2026-05-30T04:54:02Z
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
---
|
||||
|
|
|
|||
|
|
@ -19,4 +19,55 @@ Clarified selector semantics:
|
|||
`inherit` is explicitly not the same as reusing the Profile source that created the parent. It extracts reusable fields from the parent resolved Manifest and still replaces runtime-bound/authority fields such as `pod.name` and concrete `scope.allow` with the SpawnPod inputs. Reusing the parent's original Profile source can be considered later as a separate feature if needed.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: hare at: 2026-05-30T04:54:02Z -->
|
||||
|
||||
## Plan
|
||||
|
||||
## Preflight implementation plan
|
||||
|
||||
Classification: implementation-ready.
|
||||
|
||||
No product/API decision is needed before coding. The ticket already fixes the important semantics: omitted/default uses the effective child default profile, `inherit` derives reusable config from the spawner's resolved Manifest, named/source-qualified selectors resolve discovered profiles, path selectors are rejected, and `SpawnPod.scope` remains the only delegated capability.
|
||||
|
||||
Important implementation notes:
|
||||
- Do not rely on process `current_dir()` for SpawnPod profile discovery. Use the Pod cwd (`spawner_pwd`) explicitly by adding/exposing a resolver helper that resolves from a registry discovered for that cwd.
|
||||
- Resolve profiles and build child config before pod-registry reservation where possible, so invalid profile selectors do not mutate registry/scope.
|
||||
- `inherit` means derive from the parent resolved Manifest, not from the parent's original Profile source.
|
||||
- Path-like values, `path:<...>`, `.lua`/legacy suffix selectors, and absolute/relative paths must fail closed in `SpawnPod.profile`.
|
||||
- Existing hidden `--spawn-config-json` remains the internal handoff; do not exec child with `--profile`.
|
||||
- Existing prompt-loader source limitations are out of scope; preserve current behavior.
|
||||
|
||||
Current code map:
|
||||
- `crates/pod/src/spawn/tool.rs`: `SpawnPodInput`, static description, spawn lifecycle, `build_spawn_config_json`.
|
||||
- `crates/pod/src/controller.rs`: `register_pod_tools`, currently snapshots parent model/trace and registers spawn tools.
|
||||
- `crates/manifest/src/profile.rs`: `ProfileDiscovery`, `ProfileRegistry`, `ProfileSelector`, `ProfileResolver`.
|
||||
- `crates/manifest/src/config.rs`: `PodManifestConfig`, merge/resolve/defaults.
|
||||
- `crates/pod/src/main.rs`: hidden `--spawn-config-json` loading takes precedence and uses builtins-only prompt loader.
|
||||
- `crates/pod/src/prompt/catalog.rs` and `resources/prompts/internal.toml`: central prompt catalog for templated tool description.
|
||||
|
||||
Implementation phases:
|
||||
1. Add manifest profile resolver helper for registry/cwd-explicit selection.
|
||||
2. Add `SpawnPodInput.profile` and a SpawnPod-specific selector parser for `default`, `inherit`, and registry selectors only.
|
||||
3. Add shared available-profile formatter for tool description and error diagnostics.
|
||||
4. Move SpawnPod tool description into prompt catalog/minijinja and render it during tool registration; discovery failures should render diagnostics, not fail Pod startup.
|
||||
5. Build child `PodManifestConfig` from selected profile Manifest or inherited parent Manifest, replacing `pod.name`, replacing `scope.allow`, clearing `scope.deny`, and optionally overriding only `worker.instruction`.
|
||||
6. Preserve existing lifecycle: registry reservation/rollback, scope revocation, spawned registry write, callback wiring, child socket wait, initial `Method::Run` confirmation.
|
||||
7. Update docs/workflows with `project:coder`, `project:reviewer`, optional `project:orchestrator`, and `inherit` examples.
|
||||
|
||||
Critical risks:
|
||||
- Do not merge profile/inherited scope with explicit SpawnPod scope; explicit scope replaces capability.
|
||||
- Do not call CLI-style profile parser in a way that allows path profiles through SpawnPod.
|
||||
- Description and diagnostic profile lists should share formatting.
|
||||
- Prompt catalog key coverage is build-time enforced.
|
||||
|
||||
Validation plan:
|
||||
- Unit tests for selector parsing, formatter, config builder override/replacement behavior.
|
||||
- Manifest tests for cwd/registry-explicit resolver helper.
|
||||
- Prompt catalog rendering test.
|
||||
- SpawnPod integration tests for omitted default, inherit, project profile, invalid selector pre-reservation failure, ambiguity suggestions, and scope replacement.
|
||||
- Run `cargo test -p manifest profile`, `cargo test -p pod spawn_pod`, relevant prompt catalog tests, `cargo fmt --check`, and `./tickets.sh doctor`.
|
||||
|
||||
|
||||
---
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user