49 lines
3.0 KiB
Markdown
49 lines
3.0 KiB
Markdown
---
|
|
title: "Commit Intake ticket claims only after successful launch"
|
|
state: "closed"
|
|
created_at: "2026-06-07T22:02:25Z"
|
|
updated_at: "2026-06-08T03:32:46Z"
|
|
queued_by: "workspace-panel"
|
|
queued_at: "2026-06-08T03:06:07Z"
|
|
---
|
|
|
|
## Background
|
|
|
|
Panel Clarify / existing-Ticket Intake launch currently writes a local Ticket claim before the Intake Pod launch has actually succeeded. If the Pod launch later fails, the claim can remain and make the Ticket look claimed by a ghost/stale Intake Pod.
|
|
|
|
Observed behavior:
|
|
|
|
```text
|
|
Ticket <id> has a stale local Intake claim for <pod_name>; explicit reclaim/diagnostic is required before starting a replacement.
|
|
```
|
|
|
|
This is especially visible when the first Clarify launch for an unclaimed Ticket fails because of profile/scope or other launch errors. The Ticket was never successfully claimed by a real Intake Pod, but the local registry blocks a replacement as if it had been.
|
|
|
|
## Goal
|
|
|
|
Ensure local Intake Ticket claims represent confirmed launched/restorable Intake Pods, not speculative launch attempts.
|
|
|
|
## Requirements
|
|
|
|
- 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 the claim is committed.
|
|
- If the implementation keeps the current pre-claim structure, every launch failure path must reliably roll back the just-created claim.
|
|
- Prefer committing the claim after successful launch over rollback-heavy pre-claiming.
|
|
- Failed first launch for an unclaimed Ticket must not leave a stale local claim.
|
|
- Successful existing-Ticket Intake launch must still write the local claim and role-session record.
|
|
- Duplicate launch prevention during an in-flight launch should use transient/in-memory pending state or another non-durable mechanism, not a durable claim that can outlive a failed launch.
|
|
- Existing stale claims should remain diagnostic/manual-reclaim territory unless the implementation can safely distinguish claims created by the current failed attempt.
|
|
- Keep the behavior that live/restorable existing claims prevent starting a second Intake Pod.
|
|
- Preserve Ticket Intake handoff peer registration behavior where possible.
|
|
- Do not change Ticket workflow-state semantics, Orchestrator lifecycle, or Companion routing.
|
|
|
|
## Acceptance criteria
|
|
|
|
- A simulated Intake launch failure for a previously unclaimed Ticket leaves no local claim file/record for that Ticket.
|
|
- A simulated successful Intake launch writes exactly one claim for the launched Pod.
|
|
- Retrying after a failed launch is not blocked by a ghost/stale claim from the failed attempt.
|
|
- Existing live/restorable claims still block duplicate Intake launch and direct the user to the existing Pod.
|
|
- Tests cover failure before spawn, failure after spawn/connect or initial Run rejection/timeout if practical, and successful launch.
|
|
- Focused TUI/registry tests pass.
|
|
- `cargo test -p tui ... --lib`, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.
|