## Created Created by LocalTicketBackend create. --- ## 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. --- ## 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. --- ## State changed Intake completed for existing Ticket; Orchestrator can route it. Do not start implementation until the user queues it from ready to queued. --- ## State changed Ticket queued for Orchestrator routing. --- ## 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. --- ## 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. --- ## Plan Implementation routing accepted and worktree created. Worktree plan: - Branch: `commit-intake-claims-after-launch-success` - Worktree: `.worktree/commit-intake-claims-after-launch-success` - Base: `d2a040d ticket: route intake claim and spawn cwd tickets` - Scope: implement post-success existing-Ticket Intake claim commit and focused tests. Delegation plan: - Spawn sibling coder Pod with write scope limited to `.worktree/commit-intake-claims-after-launch-success`. - Coder must run Bash commands from the child worktree, not from the main workspace. - Coder must not edit main-workspace `.yoi` / Ticket / workflow / docs records, and must not create generated memory/local/runtime/secret-like files. - Reviewer will be spawned read-only after coder reports diff/commits and validation evidence. Related queued/preflight note: - `allow-spawnpod-child-workspace-cwd` was routed as `preflight_needed` and remains queued; do not depend on the future `SpawnPod.cwd` field for this implementation. Stop/completion policy: - Because the human authorized cleanup after completion, this Orchestrator will proceed through reviewer approval, merge-completion validation, Ticket close, Pod stop, worktree removal, and branch deletion if the branch is approved and merge authority remains clear. --- ## Implementation report Coder completed and reviewer delegated. Coder result: - Pod: `coder-commit-intake-claims` - Commit: `6797be3 fix: defer intake claim until launch acceptance` - Worktree status: clean after commit. - Diff against `develop`: 1 file changed, 137 insertions, 36 deletions. Files touched by coder: - `crates/tui/src/multi_pod.rs` Coder reported implementation: - Moved existing-Ticket Intake durable claim persistence from `prepare_existing_ticket_intake_launch` to the post-launch path after `launch_ticket_role_pod_with_options(...)` succeeds. - `IntakeRegistryUpdate` now carries a deferred `ClaimTicket` update instead of marking the claim as already done. - Added `commit_intake_registry_update(...)` to centralize post-success registry/session persistence for both pre-ticket Intake session recording and existing-Ticket claim commits. - Added a transient in-flight guard via `self.sending` so repeated launch attempts in the same panel instance are rejected while launch is ongoing. - Preserved existing duplicate prevention: an already-present claim is still checked before launch and blocks duplicate Intake launch. - Preserved peer registration/handoff ordering; peer registration options are still prepared before launch, while durable claim commit happens only after launch acceptance returns. Coder reported validation: - `cargo test -p tui role_session_registry --lib` - `cargo test -p tui multi_pod --lib` - `cargo fmt --check` - `git diff --check` - `cargo run -q -p yoi -- ticket doctor` - `nix build .#yoi` Reviewer delegation: - Spawned sibling reviewer Pod: `reviewer-commit-intake-claims`. - Reviewer scope: read-only child worktree plus non-recursive parent-root read required by launch cwd validation. - Reviewer was instructed to judge against the recorded Ticket requirements and binding decisions. Pending: - Await reviewer verdict before merge-ready dossier / merge-completion. - No merge, close, final approval, or cleanup has occurred for this Ticket. ---