# Attachment editor blocker recovery

Date: 2026-09-17 (Asia/Shanghai)
Requirement: `Part:desktop:Part_EditAttachment`

## Root Cause and Fix

The previous implementation successfully began an attachment edit but rejected its first Apply with `No attachment task for the selected object`. FreeCAD's `Document::openTransaction` reserves a transaction ID; `hasPendingTransaction` remains false until a property mutation creates an undo record. The guard incorrectly required that record before the first mutation.

DocumentProbe now retains the selected object and the ID returned by `openTransaction`, and validates ownership against `getBookedTransactionID`. It still rejects another object's task or an externally ended transaction. Snapshots return actual attachment-session state. The mounted editor refreshes that state after errors, so a rolled-back transaction does not leave the controls trapped in edit mode.

The existing native attachment implementation and UI were retained. The previously unfinished browser cases now exercise their actual lifecycle, including leaving the task while a preview is active. The scene reserves space below its toolbar on narrow viewports.

## First Acceptance

Command: `python3 tools/run_business_acceptance.py --module Part --ids Part:desktop:Part_EditAttachment --reuse`

Result: **1 requirement passed, 14 scenario records, 14.900 seconds**.

[Formal evidence](business-evidence/f6b2a714a5f3c93e345e6c7b-20260917T050953211126.json)

Assertions cover untouched begin/cancel, preview ownership, rejected competing writes, wrong-object cancellation, Apply/Accept as one transaction, full Cancel rollback, failure cleanup/reopening, native support-driven recomputation, document isolation, undo/redo, FCStd restoration and mounted browser persistence. Browser controls also prove automatic preview cancellation on leaving the task and continued editing after reload. The case shares one native kernel and one browser workflow.

TypeScript checking, incremental DocumentProbe compilation and production build passed. No previously passed requirement was revalidated. Subsequent work in the same DocumentProbe adds section-cut session serialization; the attachment report is retained as historical execution evidence rather than falsely refreshed for that later fingerprint.

- [Desktop attachment geometry](part-attachment-business/2026-09-17T05-09-38-620Z/desktop-geometry.png)
- [Mobile task](part-attachment-business/2026-09-17T05-09-38-620Z/mobile-task.png)
- [Detailed cases](part-attachment-business/2026-09-17T05-09-38-620Z/results.json)

Desktop 1440x900 and mobile 390x844 screenshots were visually inspected. Model pixels, camera rotation and horizontal task overflow were checked.

## Continuation

The old attachment checkpoint's native lifecycle blocker and missing-browser-case boundary are resolved by this evidence. Do not rerun the former failing input or reread its source investigation merely because a previous checkpoint said it was blocked. Other generic attachment modes remain limited to the explicitly exercised native behavior; no blanket desktop parity claim is made.

Concurrent edits to shared workbench/contract files were also observed invalidating background acceptance fingerprints. Shared mutations and formal evidence runs should be serialized. Check for running builds and acceptance subprocesses before freezing the service; never freeze a build-lock owner and then wait for its lock. Thaw immediately after the protected work. Preserve the existing single scheduler and historical-validation deferral policy.

Handoff status: service active and unfrozen; cycle 9314 has a live child process (566388) and source-reading activity for Primitives and Projection on Surface. The contemporaneous coverage inventory contains 213/1508 declared executable requirements, with 1295 still undeclared. This is not a fresh-acceptance total. Section Cut remains incomplete; see [its focused recovery checkpoint](part-section-cut-recovery-checkpoint.md) for the four remaining functional boundaries.