ticket: route intake claim and spawn cwd tickets
This commit is contained in:
parent
50c5743fa0
commit
d2a040d77a
|
|
@ -6,11 +6,13 @@ status: open
|
|||
kind: task
|
||||
priority: P1
|
||||
labels: [tui, panel, ticket, intake, bug]
|
||||
workflow_state: intake
|
||||
workflow_state: 'inprogress'
|
||||
created_at: 2026-06-07T22:02:25Z
|
||||
updated_at: 2026-06-07T22:02:25Z
|
||||
updated_at: '2026-06-08T03:08:26Z'
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
queued_by: 'workspace-panel'
|
||||
queued_at: '2026-06-08T03:06:07Z'
|
||||
---
|
||||
|
||||
## Background
|
||||
|
|
|
|||
|
|
@ -5,3 +5,138 @@
|
|||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: Intake at: 2026-06-08T02:41:28Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Intake refinement
|
||||
|
||||
The existing Ticket is sufficiently specified for Orchestrator routing and implementation planning.
|
||||
|
||||
- readiness: implementation_ready
|
||||
- needs_preflight: true
|
||||
- risk_flags: [persistence, launch-lifecycle, ticket-claims, panel-intake, peer-registration]
|
||||
|
||||
Binding decisions / invariants for implementation:
|
||||
|
||||
- Durable local Intake claims must represent confirmed launched/restorable Intake Pods, not speculative launch attempts.
|
||||
- Prefer post-success claim commit over rollback-heavy pre-claiming.
|
||||
- Duplicate prevention while launch is in flight must use transient/non-durable state, not a durable claim that can survive a failed launch.
|
||||
- Existing live/restorable claims must continue to prevent duplicate Intake launch.
|
||||
- Existing stale claims remain diagnostic/manual-reclaim territory unless a claim can be safely identified as created by the current failed launch attempt.
|
||||
- Preserve Ticket Intake handoff peer registration where possible.
|
||||
- Do not change Ticket workflow-state semantics, Orchestrator lifecycle, or Companion routing in this work.
|
||||
|
||||
Implementation latitude remains: choose the smallest local mechanism for transient in-flight protection and test seams, provided the acceptance criteria cover failed launch before durable claim commit and successful launch claim creation.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: intake_summary author: Intake at: 2026-06-08T02:41:34Z -->
|
||||
|
||||
## Intake summary
|
||||
|
||||
Existing bug Ticket refined and marked ready. The requested behavior is to commit local Intake Ticket claims only after launch success/acceptance evidence, avoid durable speculative pre-claims, keep successful existing-Ticket Intake launches claiming exactly once, preserve live/restorable duplicate prevention, and leave unrelated stale-claim cleanup as manual/diagnostic. Readiness is implementation_ready; needs_preflight is true because the work touches Pod launch lifecycle, local role-session claim persistence, panel Intake behavior, and handoff/peer-registration boundaries. Suggested risk flags: persistence, launch-lifecycle, ticket-claims, panel-intake, peer-registration.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: Intake at: 2026-06-08T02:41:34Z from: intake to: ready reason: intake_ready field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
Intake completed for existing Ticket; Orchestrator can route it. Do not start implementation until the user queues it from ready to queued.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: workspace-panel at: 2026-06-08T03:06:07Z from: ready to: queued reason: queued field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
Ticket queued for Orchestrator routing.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: orchestrator at: 2026-06-08T03:08:19Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
Routing decision: implementation_ready
|
||||
|
||||
Reason:
|
||||
- The Ticket and Intake thread now contain binding decisions/invariants for the launch-claim lifecycle, so the remaining work is bounded implementation and test design.
|
||||
- Although Intake marked `needs_preflight: true`, the recorded refinement already fixes the key persistence/launch-lifecycle boundaries: durable claims must represent confirmed launched/restorable Intake Pods, in-flight duplicate prevention must be transient, existing live/restorable claims continue to block, and existing stale claims remain diagnostic/manual-reclaim territory.
|
||||
- The relevant code map is local enough for coder delegation: role-session claim persistence in `role_session_registry.rs`, existing-Ticket Intake preparation/finish flow in `multi_pod.rs`, panel claim display in `workspace_panel.rs`, and Ticket role launch handoff/peer registration surfaces.
|
||||
|
||||
Evidence checked:
|
||||
- Ticket body requirements and acceptance criteria.
|
||||
- Thread: Intake refinement binding decisions, intake summary, and `ready -> queued` event.
|
||||
- Workspace state: no matching branch/worktree exists; main has unrelated Ticket-record edits and a separate `allow-spawnpod-child-workspace-cwd` preflight decision, both understood and outside the implementation paths.
|
||||
- Code map search for `claim_ticket`, role-session registry, existing Ticket Intake launch preparation, launch finish, handoff/peer registration, and local claim display.
|
||||
- Ticket doctor: 0 errors; existing warnings are unrelated legacy closed-Ticket diagnostics.
|
||||
|
||||
IntentPacket:
|
||||
|
||||
Intent:
|
||||
- Ensure existing-Ticket Intake local claims are durable only after launch success/acceptance, so failed first launches do not leave ghost/stale claims that block retries.
|
||||
|
||||
Binding decisions / invariants:
|
||||
- Durable local Intake claims must represent confirmed launched/restorable Intake Pods, not speculative launch attempts.
|
||||
- Prefer post-success claim commit over rollback-heavy pre-claiming.
|
||||
- Duplicate prevention while launch is in flight must use transient/non-durable state if needed.
|
||||
- Successful existing-Ticket Intake launch must still write exactly one local claim and role-session record.
|
||||
- Existing live/restorable claims must continue to prevent duplicate Intake launch and direct the user to the existing Pod.
|
||||
- Existing stale claims remain diagnostic/manual-reclaim territory unless the implementation can safely identify a claim created by the current failed launch attempt.
|
||||
- Preserve Ticket Intake handoff peer registration where possible.
|
||||
- Do not change Ticket workflow-state semantics, Orchestrator lifecycle, Companion routing, or unrelated stale-claim cleanup policy.
|
||||
|
||||
Requirements / acceptance criteria:
|
||||
- Do not write a durable local Ticket claim until Intake Pod launch has succeeded with sufficient acceptance evidence; at minimum spawn/connect/initial `Method::Run` acceptance should complete before durable claim commit.
|
||||
- Failed launch for a previously unclaimed Ticket must leave no local claim file/record for that Ticket.
|
||||
- Retrying after failed launch must not be blocked by a ghost/stale claim from that failed attempt.
|
||||
- Successful launch must write exactly one claim for the launched Pod.
|
||||
- Existing live/restorable claims must continue to block duplicate Intake launch.
|
||||
- Tests should cover failure before spawn, failure after spawn/connect or initial Run rejection/timeout if practical, and successful launch.
|
||||
|
||||
Implementation latitude:
|
||||
- Coder may choose the smallest local transient in-flight guard/test seam.
|
||||
- Coder may restructure the existing pre-claim flow into post-success claim commit, or keep a pre-claim shape only if rollback is reliable and simple; post-success is preferred.
|
||||
- Coder may add focused unit tests around `MultiPodApp`/registry state rather than E2E launch tests if the launch boundary is mocked through existing launch result types.
|
||||
|
||||
Escalate if:
|
||||
- Claim commit cannot be delayed until launch acceptance without changing Ticket role launcher APIs broadly.
|
||||
- Peer registration/handoff ordering conflicts with post-success claim commit.
|
||||
- Existing live/restorable duplicate prevention requires durable pre-claim semantics.
|
||||
- Test coverage would need invasive runtime/E2E infrastructure beyond focused TUI/registry seams.
|
||||
|
||||
Validation:
|
||||
- Focused TUI/registry tests for existing-Ticket Intake claim timing.
|
||||
- `cargo test -p tui role_session_registry --lib` if registry tests are added/changed.
|
||||
- `cargo test -p tui multi_pod --lib` or focused equivalent selected by coder.
|
||||
- `cargo fmt --check`.
|
||||
- `git diff --check`.
|
||||
- `cargo run -q -p yoi -- ticket doctor`.
|
||||
- Because TUI launch/claim behavior is touched, final merge-completion should include `nix build .#yoi`.
|
||||
|
||||
Current code map:
|
||||
- `crates/tui/src/role_session_registry.rs`: durable local role-session registry and `claim_ticket` persistence.
|
||||
- `crates/tui/src/multi_pod.rs`: `prepare_existing_ticket_intake_launch`, `launch_intake_with_handoff`, `finish_intake_launch`, `IntakeLaunchRequest`, `IntakeLaunchResult`, peer registration/handoff flow, related tests.
|
||||
- `crates/tui/src/workspace_panel.rs`: local claim display/status and existing claim duplicate UX.
|
||||
- `crates/client/src/ticket_role.rs`: launch/acceptance boundary to preserve conceptually if touched.
|
||||
|
||||
Critical risks / reviewer focus:
|
||||
- No durable claim may be left after simulated launch failure for a previously unclaimed Ticket.
|
||||
- Successful launch must still claim exactly once.
|
||||
- Existing live/restorable claims must still block duplicate launch.
|
||||
- Transient in-flight guard must not become a durable stale claim.
|
||||
- Peer registration/handoff behavior should not regress silently.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: orchestrator at: 2026-06-08T03:08:26Z from: queued to: inprogress reason: orchestrator_acceptance field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
Accepted queued implementation after reading the Ticket, workspace state, and Intake claim lifecycle code map. This acceptance precedes worktree creation and coder/reviewer Pod spawning.
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,16 +1,18 @@
|
|||
---
|
||||
id: '20260608-011036-allow-spawnpod-child-workspace-cwd'
|
||||
slug: 'allow-spawnpod-child-workspace-cwd'
|
||||
title: 'Allow SpawnPod to specify child workspace cwd'
|
||||
title: 'Allow SpawnPod to specify child cwd'
|
||||
status: 'open'
|
||||
kind: 'task'
|
||||
priority: 'P2'
|
||||
labels: ['pod', 'spawn', 'workspace', 'worktree', 'orchestration']
|
||||
workflow_state: 'intake'
|
||||
labels: ['pod', 'spawn', 'cwd', 'worktree', 'orchestration']
|
||||
workflow_state: 'queued'
|
||||
created_at: '2026-06-08T01:10:36Z'
|
||||
updated_at: '2026-06-08T01:10:36Z'
|
||||
updated_at: '2026-06-08T03:07:33Z'
|
||||
assignee: null
|
||||
legacy_ticket: null
|
||||
queued_by: 'workspace-panel'
|
||||
queued_at: '2026-06-08T03:06:04Z'
|
||||
---
|
||||
|
||||
## Background
|
||||
|
|
@ -26,55 +28,59 @@ Pod の cwd は main workspace のままになる。必ず作業対象が child
|
|||
This works but is fragile and awkward:
|
||||
|
||||
- Coder can forget to `cd` before commands.
|
||||
- Tool cwd, profile/project discovery, AGENTS.md, and runtime workspace identity remain main-workspace biased.
|
||||
- Bash/tool execution starts from the main workspace even when all edits should happen in the child worktree.
|
||||
- Command snippets are noisy and error-prone.
|
||||
- Child worktree behavior is controlled by prompt discipline rather than runtime configuration.
|
||||
|
||||
`SpawnPod` currently has no LLM-facing cwd/workspace field; internally child processes are launched with `Command::current_dir(self.spawner_pwd)`.
|
||||
`SpawnPod` currently has no LLM-facing `cwd` field; internally child processes are launched with `Command::current_dir(self.spawner_pwd)`.
|
||||
|
||||
This ticket is **not** about changing the child Pod's runtime workspace root. A spawned child remains in the same project/workspace context as its parent. The improvement is only to let the child process/tool cwd point at a child worktree inside that workspace.
|
||||
|
||||
## Goal
|
||||
|
||||
Allow `SpawnPod` callers to specify the child Pod's runtime workspace/cwd, so implementation Pods can be started directly inside their child worktree while keeping explicit scope delegation and orchestration authority boundaries.
|
||||
Allow `SpawnPod` callers to specify the child Pod's process/tool `cwd`, so implementation Pods can start directly inside their child worktree while inheriting the parent workspace context and keeping explicit scope delegation.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Add a `SpawnPod` input field for child runtime workspace/cwd.
|
||||
- Candidate names: `workspace`, `workspace_root`, or `cwd`.
|
||||
- Prefer terminology aligned with `introduce-runtime-workspace-root-context` if that lands first.
|
||||
- When omitted, preserve current behavior: child cwd/workspace defaults to the spawner Pod's pwd.
|
||||
- When provided:
|
||||
- Add a `SpawnPod` input field named `cwd` for the child process/tool working directory.
|
||||
- When omitted, preserve current behavior: child cwd defaults to the spawner Pod's pwd.
|
||||
- `cwd` must not change the runtime workspace root.
|
||||
- Child Pods inherit the parent workspace/project context.
|
||||
- Profile discovery, project records, Ticket config, workflow registry, memory root resolution start point, and Pod identity policy should continue to use the inherited runtime workspace context unless another explicit design says otherwise.
|
||||
- When `cwd` is provided:
|
||||
- Validate the path is absolute.
|
||||
- Validate the path exists and is a directory.
|
||||
- Validate the parent has at least read authority for the path.
|
||||
- Set the child process `current_dir` to that path.
|
||||
- Pass the runtime workspace context to the child Pod/profile resolver consistently if such context exists.
|
||||
- Ensure Bash/tool default cwd uses that path.
|
||||
- Ensure delegated scope remains explicit and independent from cwd.
|
||||
- cwd does not grant permission by itself.
|
||||
- Child write scope must still be supplied through `scope` and validated against parent/delegation authority.
|
||||
- Child read/write scope must still be supplied through `scope` and validated against parent/delegation authority.
|
||||
- Support the standard worktree case:
|
||||
- child cwd/workspace = `<repo>/.worktree/<task-name>`;
|
||||
- inherited workspace root = main repo;
|
||||
- child cwd = `<repo>/.worktree/<task-name>`;
|
||||
- child read scope may include main repo if needed;
|
||||
- child write scope is the child worktree or narrower.
|
||||
- Update `worktree-workflow` and `multi-agent-workflow` to prefer spawning Coder Pods with cwd/workspace set to the child worktree instead of telling them to `cd` every time.
|
||||
- Update `worktree-workflow` and `multi-agent-workflow` to prefer spawning Coder Pods with `cwd` set to the child worktree instead of telling them to `cd` every time.
|
||||
- Keep main workspace authority responsibilities explicit:
|
||||
- ticket orchestration progress, final review/approval/close, and merge authority remain with Orchestrator/main workspace unless intentionally delegated.
|
||||
- Ensure child worktree `.yoi` sparse rules and `.yoi/memory` behavior remain intact.
|
||||
- Add diagnostics if requested cwd/workspace is not permitted or invalid.
|
||||
- Add diagnostics if requested cwd is not permitted or invalid.
|
||||
|
||||
## Design questions
|
||||
## Design notes
|
||||
|
||||
- Should the field be named `cwd` for OS process current directory, or `workspace_root` to align with runtime identity/profile discovery?
|
||||
- Should `workspace_root` affect default Pod name if `name` is explicitly required by `SpawnPod`?
|
||||
- How should profile discovery behave when child cwd is a worktree containing tracked `.yoi` project records but not `.yoi/memory`?
|
||||
- Should reviewer Pods also use child worktree cwd by default, or keep main workspace cwd for comparing main vs branch? The workflow should state the preferred pattern.
|
||||
- The field should be named `cwd`, not `workspace_root`, because SpawnPod children should not move into a different workspace. They only need a different process/tool working directory inside the same workspace context.
|
||||
- `cwd` should not affect default Pod name. `SpawnPod.name` is already explicit.
|
||||
- `cwd` should not affect Profile selection or project profile discovery.
|
||||
- Reviewer Pods may use main workspace cwd or child worktree cwd depending on review style; workflow guidance should state the recommended default rather than make `cwd` imply review authority.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
- `SpawnPod` can launch a child Pod with process cwd set to an explicit child worktree path.
|
||||
- `SpawnPod` can launch a child Pod with process/tool cwd set to an explicit child worktree path.
|
||||
- The child Pod's Bash tool starts fresh shells rooted at that child worktree without requiring `cd` in every command.
|
||||
- Omitting the field preserves current behavior.
|
||||
- Omitting `cwd` preserves current behavior.
|
||||
- Invalid/non-directory/out-of-scope cwd requests fail with clear errors.
|
||||
- cwd/workspace selection does not grant implicit read/write permission.
|
||||
- cwd selection does not grant implicit read/write permission and does not alter inherited workspace context.
|
||||
- Worktree/multi-agent workflows are updated to use the new field for coder Pods.
|
||||
- Tests cover omitted/default cwd, explicit valid cwd, invalid cwd, and permission denial.
|
||||
- Tests cover omitted/default cwd, explicit valid cwd, invalid cwd, permission denial, and workspace-context inheritance.
|
||||
- Focused tests, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.
|
||||
|
|
|
|||
|
|
@ -5,3 +5,72 @@
|
|||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: ticket-intake at: 2026-06-08T02:46:39Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
## Intake readiness classification
|
||||
|
||||
- readiness: implementation_ready
|
||||
- needs_preflight: true
|
||||
- risk_flags: [authority-boundary, scope-delegation, pod-runtime, workspace-context, workflow-guidance]
|
||||
|
||||
The Ticket is specific enough for Orchestrator routing: it fixes the public tool input name (`cwd`), default behavior when omitted, the distinction between process/tool cwd and inherited workspace context, and the invariant that `cwd` grants no authority by itself. Preflight remains required because the change touches SpawnPod delegation authority, scope validation, runtime cwd behavior, and workflow guidance.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: intake_summary author: ticket-intake at: 2026-06-08T02:46:46Z -->
|
||||
|
||||
## Intake summary
|
||||
|
||||
Existing Ticket updated rather than duplicated. Scope is to add an optional `cwd` field to `SpawnPod` so child Pods can run process/tool commands from a child worktree while inheriting the parent workspace context. Required invariants: omitted `cwd` preserves current spawner pwd behavior; provided `cwd` is absolute, existing directory, and within parent read authority; cwd does not grant read/write permission, change workspace root, alter Profile discovery, or affect Pod naming; delegated scope remains explicit. Worktree and multi-agent workflow guidance should prefer coder Pods with child-worktree cwd. Ticket is implementation-ready for routing, with preflight recommended because it touches authority/scope/runtime/workflow boundaries.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: ticket-intake at: 2026-06-08T02:46:46Z from: intake to: ready reason: intake_ready field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
Intake classified the existing Ticket as ready for Orchestrator routing. The user or panel may now queue it; implementation must still wait for Orchestrator acceptance and any preflight/routing decision.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: state_changed author: workspace-panel at: 2026-06-08T03:06:04Z from: ready to: queued reason: queued field: workflow_state -->
|
||||
|
||||
## State changed
|
||||
|
||||
Ticket queued for Orchestrator routing.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: orchestrator at: 2026-06-08T03:07:33Z -->
|
||||
|
||||
## Decision
|
||||
|
||||
Routing decision: preflight_needed
|
||||
|
||||
Reason:
|
||||
- The Ticket is well specified, but Intake explicitly records that preflight remains required because this touches SpawnPod delegation authority, scope validation, runtime cwd behavior, and workflow guidance.
|
||||
- The proposed `cwd` field must preserve a strict authority boundary: cwd changes process/tool working directory only, does not grant read/write permission, does not change workspace context, and does not affect Profile discovery or Pod naming.
|
||||
- This needs a short binding design note before coder delegation so reviewer can judge schema, validation, runtime launch, and workflow-guidance changes against recorded authority invariants rather than implementation convenience.
|
||||
|
||||
Evidence checked:
|
||||
- Ticket body requirements, design notes, and acceptance criteria.
|
||||
- Thread: Intake classification, risk flags, and latest `ready -> queued` event.
|
||||
- Workspace state: no matching branch/worktree exists; main workspace has unrelated Ticket-record edits.
|
||||
- Code map search for SpawnPod input/launch, cwd/current_dir, scope validation, and workflow guidance paths.
|
||||
- Ticket doctor: 0 errors; existing warnings are unrelated legacy closed-Ticket diagnostics.
|
||||
|
||||
Next action:
|
||||
- Run `ticket-preflight-workflow` before implementation delegation.
|
||||
- Preflight should record: `cwd` schema/name, required validation (`absolute`, existing directory, within parent read authority), whether cwd must also be readable by delegated child scope or only by parent authority at launch, exact relationship to child process `current_dir` and Bash default cwd, unchanged workspace/profile/Pod-name semantics, diagnostics, and workflow guidance updates.
|
||||
- Leave this Ticket queued for now; do not transition `queued -> inprogress`, create `.worktree/allow-spawnpod-child-workspace-cwd`, or spawn coder/reviewer Pods until preflight records implementation readiness.
|
||||
|
||||
Escalate if:
|
||||
- cwd validation would require broad capability model changes.
|
||||
- Setting child process cwd cannot be separated from workspace-root/Profile discovery.
|
||||
- Tool default cwd cannot be made consistent without changing Bash/tool execution semantics more broadly.
|
||||
|
||||
---
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user