yoi/.yoi/tickets/00001KX6CRVBE/thread.md

作成

LocalTicketBackend によって作成されました。

---

Decision

Follow-up to 00001KX6BPY7M. Deletion/cleanup policy is intentionally manual-first:

• No automatic prune based on age or capacity in this ticket.
• Backend presents a plan with reasons, blockers, linked Worker/Workdir ids, retention, pinned state, and expected revision/digest.
• User or explicit orchestration authority selects targets and executes cleanup.
• Pinned Worker history is protected.
• Clean workdir files are cache and may be manually cleaned when not linked to running Workers.
• Dirty orphan workdirs require recovery/discard decision, not normal prune.

---

Decision

Clarification: because 00001KX6BPY7M is already in progress, this follow-up ticket explicitly owns implementation of Worker pinned state beyond merely consuming it in prune logic.

Scope added here:

• Persist pinned flag or equivalent Worker retention field in Backend registry.
• Add Backend Worker pin/unpin mutation API.
• Include pinned state in Worker list/detail and prune plan.
• Ensure manual cleanup execution rejects pinned Worker history and protected linked records.

---

Decision

Lifecycle clarification:

• Worker lifecycle should stay simple: running -> stopped -> delete.
• Do not introduce archived as a Worker lifecycle state in this ticket.
• Worker is the storage unit for Session/transcript history; deleting a Worker deletes or removes access to that history.
• Pinned remains necessary and blocks Worker deletion.
• Workdir files are cache and should be manually deletable.
• Dirty workdir deletion is allowed only with explicit confirmation that changes will be discarded.
• Compression/archive storage for Session history is out of scope and should be a separate storage policy if needed later.

---

Intake summary

Marked ready by yoi ticket state.

---

State changed

Marked ready by yoi ticket state.

---

State changed

Ticket を workspace-panel が queued にしました。

---

Decision

Routing decision: blocked_by_dependency_or_missing_authority

Reason:

• Ticket is a manual delete / cleanup follow-up that depends on the Backend Worker/Workdir registry and link authority from 00001KX6BPY7M。
• 00001KX6BPY7M is currently inprogress on branch work/00001KX6BPY7M-worker-workdir-registry and under external review。
• This Ticket touches the same store schema, server APIs, Worker/Workdir projections, retention/managed-unmanaged semantics, and cleanup safety rules。
• Starting this Ticket now would create a high-conflict parallel branch and could implement delete/cleanup behavior against an unreviewed registry model。
• Therefore this routing pass leaves the Ticket queued and does not record queued -> inprogress, create a worktree, or spawn role Pods。

Evidence checked:

• Ticket body / thread / artifacts。
• TicketRelationQuery(00001KX6CRVBE): 0 typed relations, but Ticket body/order context makes 00001KX6BPY7M a practical implementation prerequisite。
• TicketOrchestrationPlanQuery(00001KX6CRVBE): prior record 0 件だったため、今回 after 00001KX6BPY7M と waiting-capacity note を記録。
• TicketList: queued はこの Ticket 1件、inprogress は 00001KX6BPY7M 1件。
• Orchestrator worktree git status: clean on orchestration。

Next action:

• 00001KX6BPY7M の implementation/review/merge outcome を待つ。
• registry/link model が merge されたら、この Ticket を再 routing し、updated orchestration branch から start する。

Escalate if:

• 人間が 00001KX6BPY7M とこの Ticket を同一 combined worktree で統合実装する方針に切り替えたい場合。

---

Decision

Routing decision: accept for implementation

Reason:

• Previously recorded prerequisite 00001KX6BPY7M has now been reviewed, merged into orchestration branch, final-validated, closed, and its child implementation worktree/branch cleaned up。
• TicketRelationQuery(00001KX6CRVBE) shows no typed blockers。
• Queue contains this Ticket and there are no other inprogress Tickets。
• Ticket is concrete and well scoped: manual Worker delete / Workdir cleanup plan and execution on top of Backend Worker/Workdir registry/link authority。

Accepted plan:

• Create dedicated implementation worktree /home/hare/Projects/yoi/.worktree/00001KX6CRVBE-manual-cleanup on branch work/00001KX6CRVBE-manual-cleanup from current orchestration branch。
• Route implementation to sibling Coder Pod。
• Route external review to sibling Reviewer Pod after Coder commit/validation。
• Orchestrator retains merge, final validation, Ticket close, and cleanup authority。

Design constraints for implementation:

• Cleanup/delete is manual-first only; no automatic prune policy。
• Worker lifecycle remains running -> stopped -> delete; do not introduce archived lifecycle state。
• pinned Worker/history is protected in plan generation and execution。
• Workdir file cleanup blocks when linked to running Workers。
• Dirty Workdir discard is explicit and separate from ordinary clean cleanup。
• Execution must reject stale plan revision/digest。
• Browser-facing responses/UI must not expose raw Runtime paths。
• Workdir/Worker canonical records should remain Backend/registry based and safe after execution。

---

State changed

Prerequisite registry/link model is now closed and merged. Accepting queued manual cleanup Ticket for implementation before creating worktree or spawning role Pods.

---

Implementation report

Implementation progress report:

• Coder Pod yoi-coder-00001KX6CRVBE-manual-cleanup completed implementation in /home/hare/Projects/yoi/.worktree/00001KX6CRVBE-manual-cleanup on branch work/00001KX6CRVBE-manual-cleanup。
• Implementation commit: ba44391acfdb8076c06ced9324b74d6cc63910ab feat: add manual worker workdir cleanup。
• Orchestrator inspected the worktree status, branch log, commit stats, and git diff --check 5f762a6c..HEAD; worktree was clean and diff check passed。

Coder-reported implementation summary:

• Added Backend Worker retention APIs for pin/unpin registry rows; Worker list/detail carries pinned / retention_state; pin/unpin mutates Backend registry only and does not affect Runtime processes。
• Added manual Runtime cleanup plan API with separate Worker delete and Workdir cleanup/delete candidates, action kind, reason/blocking reason, linked ids, pinned state, cleanliness/file status, running-link state, and safe reclaim-byte placeholder。
• Added manual cleanup execution API requiring expected plan revision/digest; rejects stale plans, pinned Worker/history delete, running-linked Workdir cleanup, and dirty cleanup without explicit discard confirmation; allows safe removed/missing Workdir registry deletion。
• Added Browser UI for manual cleanup preview/execution on Runtime Workdirs page and Backend-only pin/unpin controls on Worker page。
• Added focused tests for plan generation, stale rejection, pinned protection, running-linked Workdir blocking, dirty confirmation, removed/missing record delete, and raw path redaction。

Coder-reported validation passed:

• git diff --check
• cargo test -p yoi-workspace-server --lib
• cargo test -p worker-runtime --features ws-server,fs-store
• cargo check -p yoi
• cd web/workspace && deno task check && deno task test
• yoi ticket doctor
• nix build .#yoi --no-link

Next action:

• Route to external Reviewer Pod before merge/close decisions。

---

Review: request changes

External review result: request_changes

Blocker:

• Dirty Workdir safety is not implemented against real Runtime/filesystem state。
• Cleanup plan decides WorkdirDirtyDiscard solely from WorkdirRegistryRecord.cleanliness (crates/workspace-server/src/server.rs:1689-1695)。
• Runtime observation sync always writes cleanliness: "clean" for observed Workdirs (server.rs:4179-4199) and there is no code outside tests that records "dirty" (rg "cleanliness.*dirty|dirty.*cleanliness" only finds plan/test use)。
• Execution then treats such targets as WorkdirCleanCleanup and calls Runtime cleanup without dirty confirmation (server.rs:1851-1852)。
• Runtime cleanup uses forced removal (crates/worker-runtime/src/working_directory.rs:505-508)。
• This violates acceptance items requiring safe dirty/clean status representation and explicit confirmation before dirty discard。

Test gap:

• The dirty confirmation test seeds a synthetic registry row with cleanliness = "dirty" (server.rs:5436-5449, 5551-5580), so it does not catch the real path where Runtime/workdir sync overwrites or fails to detect dirty files。

Positive evidence:

• pin/unpin API/routes and retention projection exist (server.rs:1544-1584, 2032-2072, 4008-4022)。
• plan/execution endpoints include digest/revision stale checks and pinned/running-link blocking (server.rs:1766-1840)。
• UI preview/execution and pin controls are present without raw path fields。

Non-blocking note:

• estimated_reclaim_bytes is present but always None; confirm whether “when safe” requires actual byte estimation before approval。

---