design(mcp): build_item_modify_ui — diff-decorated item modify card (#721 child)

[dougborg]

Child of #721 (modify-card redesign umbrella). Applies the #551 framework to item modify / delete (product / material / service sub-types).

Scope

Single new entrypoint build_item_modify_ui(response, *, confirm_request, confirm_tool) in prefab_ui.py.

Covers callers:

• modify_item (foundation/items.py) — handles all three item sub-types (product / material / service) via the existing item_type sub-discrimination
• delete_item (foundation/items.py) — same

Note: this is structurally similar to build_item_detail_ui (the get-item card from #698) — same entity, different operation surface (modify vs read).

Dispatched via _modification.to_tool_result on entity_type == \"product\" | \"material\" | \"service\" (item modify carries the sub-type in the entity_type field per current code path — verify during implementation).

Content

New _ITEM_FIELD_SPEC enumerating every field on the item response shape. Likely shares structure with build_item_detail_ui's field rendering — consider whether to extract a shared item-field-spec or keep the create-side (which isn't in the create-cards scope) separate.

Sub-type variance: Product / Material / Service have different fields:

• Product: is_producible, is_sellable, default_supplier_id, lead_time, MOQ, variants, configs, purchase_uom
• Material: similar but no producible flag
• Service: minimal — no variants, no purchase_uom

The entity-view spec can encode sub-type variance via per-field visible_when conditions (or by dispatching to a sub-spec based on item_type). Decide during implementation; matches the sub-type-variance pattern from build_item_detail_ui.

Title verb: modify → "Item Modify"; delete → "Item Delete". Sub-type goes in the badge (Product / Material / Service).

Tasks

• Implement build_item_modify_ui using shared helpers.
• Add _ITEM_FIELD_SPEC (or three sub-specs for product/material/service) to prefab_ui.py.
• Extend _STATUS_BUCKETS with item statuses if any (items don't really have a workflow status — may just need archived/active flags rendered as badges via the extra_badges mechanism in _render_card_header).
• Add entity_type dispatch in _modification.to_tool_result for the three item sub-types. Consider whether to collapse into one entity_type == \"item\" branch internally with sub-type branching in the entrypoint, or keep three branches.
• Tests: TestBuildItemModifyUI with sub-type-variance coverage (product / material / service fixtures).

Acceptance

• build_item_modify_ui renders the full item entity view (with sub-type variance) with diff decoration + per-field status.
• Each of modify_item / delete_item dispatches correctly for all three item sub-types.
• Existing tests pass.

Cross-link

• feat(mcp): redesign build_item_detail_ui per #537 four-tier framework #698 (build_item_detail_ui — the read-side item card). Consider sharing the entity-view spec between read and modify; both surface the same item.