Goal: Kanban Cards with Deleted Items — Phase 1 (backend)

Today, when an operator scans or opens a kanban card whose underlying Item has been deleted, the operations backend fails with AppError.IncompatibleState (HTTP 500) — the card cannot be viewed, and a single deleted-item card can fail an entire card-list page. Phase 1 changes that behavior at the backend only: a card that references a deleted Item resolves successfully everywhere the backend serves or renders it, carries the item’s last-known data, and reports — on the card’s item reference — that the item is deleted, along with who deleted it and when. Printed cards reflect the deleted state. Surfacing the marker in the web UI is intentionally deferred to a later phase so this phase stays tightly scoped to the backend.

Linear Tickets

PDEV-547 — Kanban Cards Referencing Deleted Items: the originating defect — scanning a deleted item’s card throws KanbanCard references Non-Existing Item (500).
PDEV-672 — New items create with 0 cards by default: related context — the same ItemListener observer (its deletion callback is the no-op this phase implements).

Repositories

Repository	Role	Planned Changes
`operations`	Primary	Resolve deleted-item references on all kanban card read/render paths; expose deleted state + provenance on the card `item` reference; mark deletion on both printed cards and item Label/Breadcrumb prints (a deleted item already resolves for printing via record-id fetch — marking only, no resolution change).
`documentation`	Project docs	This goal and the phase’s requirements/specification/verification siblings.

The design and analysis for this work already live in the workbooks notebook notebooks/kanban-cards-with-deleted-items/ (see Reference Documents). arda-frontend-app is not touched in this phase.

Success Criteria

Scanning or opening a kanban card whose Item has been deleted returns a successful response (no HTTP 500), and the response carries the item’s last-known data (including its name).
A list / by-status / by-page query that includes one or more deleted-item cards returns the full page successfully — a single deleted-item card never fails the whole page.
The card’s item reference in API responses reports the item as deleted (retired) and carries deletion provenance: the deleting actor and the deletion time.
Printing reflects deletion across both print surfaces: a deleted-item kanban card prints and visibly indicates the item was deleted, and a deleted item’s Label / Breadcrumb print is likewise marked deleted (the Label/Breadcrumb path already resolves a retired item via its record id, so this is a marking change).
Cards whose Item is not deleted are unchanged — no behavior or contract regression; the new reference fields are additive and default to the not-deleted state.

Context

Item deletion in operations is a soft delete: the bitemporal store retains the full item payload behind a retired flag, so a deleted item’s data (including its name) remains retrievable. The current failure is not missing data — it is that the kanban read/render paths resolve the referenced item while excluding retired records, get nothing, and fail closed with IncompatibleState (HTTP 500). This phase makes those paths tolerate and surface the retired item instead of failing.

This is Phase 1 of a larger effort. It establishes the backend behavior and the information (deleted state + provenance on the card reference) that later phases build on — notably the web-UI deleted marker and any order-queue behavior.

Scope

In Scope

All operations kanban-card read and render paths resolve a deleted-item reference gracefully (no 500): single-card detail (scan), detail-by-record, and list / by-status / by-page queries.
The card’s item reference exposes the item’s deleted/retired state and deletion provenance (who deleted it, and when).
Printing / PDF output reflects the deleted state on both the kanban card print (KanbanCardPrintInfo) and the item Label / Breadcrumb print (ItemPrintInfo). The item-print path already resolves a retired item (record-id fetch returns retired rows), so this is marking only — no resolution change.

Out of Scope

Any arda-frontend-app / web-UI change (on-screen deleted badge, deleted-item discoverability). Deferred to a later phase that consumes the API fields this phase exposes.
Procurement / order-queue behavior, including the in-flight-order read path that independently errors on a deleted item (tracked as a separate concern).
Preventing new orders for a deleted item (M3-style enforcement).
Capturing a deletion reason at delete time (N1), a deleted-items browse/discovery surface (N3), a pre-delete impact warning (N4), and receiving guidance for in-flight cards (N5).

Constraints

Backend-only — no changes to arda-frontend-app in this phase.
Additive, non-breaking API/contract changes only; existing consumers keep working and new reference fields default to the not-deleted state.
No change to procurement / order behavior.
US-English / en-US conventions for all content.

Reference Documents

workbooks › notebooks/kanban-cards-with-deleted-items/design/phase-1-min.md — the phase-1 design (model changes, sequence diagrams, testing strategy).
workbooks › notebooks/kanban-cards-with-deleted-items/findings.md — code survey: where it breaks and why deleted-item data survives.
workbooks › notebooks/kanban-cards-with-deleted-items/card-display-exploration.md — front-end consumers of the card/item data (informs the later UI phase).
workbooks › notebooks/kanban-cards-with-deleted-items/work-board.md — Design Topics DT-001…DT-005 (scope, representation, semantics, procurement deferral).