Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity
2f62092413
yoi/.yoi/tickets/open/20260607-220225-commit-intake-claims-after-launch-success/thread.md

16 KiB
Raw Blame History

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.

Implementation report

Merge-ready dossier: Intake claim commit timing

Ticket id/slug:

  • 20260607-220225-commit-intake-claims-after-launch-success / commit-intake-claims-after-launch-success

Branch/worktree:

  • Branch: commit-intake-claims-after-launch-success
  • Worktree: .worktree/commit-intake-claims-after-launch-success
  • Current branch commit:
    • 6797be3 fix: defer intake claim until launch acceptance

Intent / invariant check:

  • Durable local Intake claims now represent confirmed launched/restorable Intake Pods, not speculative launch attempts.
  • Existing-Ticket Intake durable claim persistence is deferred until after launch_ticket_role_pod_with_options(...).await? returns successfully with launch/run acceptance evidence.
  • Existing live/restorable claims still block duplicate Intake launch before launch preparation.
  • In-flight duplicate prevention is transient via self.sending, not durable.
  • Peer registration/handoff ordering is preserved; peer options are prepared before launch and durable registry commit happens only after launch returns.
  • Ticket workflow-state semantics, Orchestrator lifecycle, Companion routing, and unrelated stale-claim cleanup policy were not changed.

Implementation summary:

  • Removed the pre-launch claim_ticket(...) call from prepare_existing_ticket_intake_launch.
  • Changed IntakeRegistryUpdate so existing-Ticket Intake carries a deferred ClaimTicket update.
  • Added commit_intake_registry_update(...) to centralize post-success registry/session persistence.
  • Added focused tests for deferred claim commit, exactly-one claim/session on repeated commit, and conflict-as-diagnostic/no-overwrite behavior.

Files touched:

  • crates/tui/src/multi_pod.rs

Coder / reviewer Pods:

  • Coder: coder-commit-intake-claims
  • Reviewer: reviewer-commit-intake-claims

Review evidence:

  • Reviewer verdict: approve.
  • Reviewer confirmed the old pre-launch claim write was removed, deferred claim commit occurs only after successful launch_ticket_role_pod_with_options(...).await?, existing-claim duplicate blocking remains, peer registration/handoff ordering is preserved, and added tests cover the targeted registry boundary.

Validation performed by coder and/or reviewer:

  • 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

Blockers fixed or rejected findings:

  • No reviewer blockers.

Residual risks:

  • No full mocked/integration test drives launch_intake_with_handoff through spawn/connect/run-acceptance failure and then asserts the registry stays empty. Reviewer judged the explicit await? before commit_intake_registry_update sufficient for this Ticket.
  • If post-success registry commit fails, launch has already succeeded and the UI reports a registry warning rather than rolling back the launched Pod. This matches the post-success-commit direction and remains an operational diagnostic case.

Dirty state:

  • Child worktree is clean at 6797be3.
  • Main workspace has unrelated newly created Ticket records for other Intake work; they are outside this branch's touched paths and are understood.

Parent/human decision needs:

  • User has authorized merge-completion and cleanup after approved work. Proceeding to merge-completion unless post-merge validation fails.