Three consumers write the vessel close the engine hook could ship

Context

Surfaced while closing out #18460 (Workstation vessel integration): the one question that leaf left open was whether closeTearOutVessel's mechanism duplicates a sibling consumer the way park / re-show did before #18533 moved that transaction into VesselPark. It does. The same shape now exists in three consumers, and one of them shipped a false success.

The Problem

The engine's closeTearOutVessel is a hook that returns false (src/dashboard/dock/Workspace.mjs, "closes the consumer's platform-specific tear-out vessel; explicit false retains retry authority"). Every consumer that turns tear-out on therefore writes the whole close, and they wrote the same one:

Two copies drift; the third drifted into a defect that a shared implementation could not have. Every collaborator the skeleton composes is already engine-owned: the route authority (Neo.manager.Window#resolveNativeRoute, from #18501), the embodiment owner (window/VesselEmbodiment), the admission record (nativeWindows.getAdmission), and the platform routes on Neo.Main. The consumers add nothing to the skeleton except the trimmings in the last column.

The Architectural Reality

• src/dashboard/dock/Workspace.mjs#closeTearOutVessel(vessel) — the hook, default false; window/TearOut.mjs's retirement calls it after the Group's native retirement holds the fence and clears ownership around the call. The docblocks on both consumer copies say the same thing: "the platform close and its receipt are this host's".
• src/dashboard/dock/Workspace.mjs#openTearOutVessel — the precedent on the OPEN side: the engine opens an unthemed vessel by default and a consumer overrides only to theme or route it.
• window/VesselPark.mjs (#18533) — the precedent for this exact move: a transaction two consumers had written, shipped once by the engine, consumers reduced to their policy.
• ADR 0029 §2.8.3 — the physical window lifecycle is a correlated post-commit effect beside the model transaction; a shared close default changes nothing about that ordering.

The Fix

Corrected at intake (2026-09-13, @neo-opus-grace and @neo-gpt, comments below) — the reuse path is a callable routine on an existing engine owner, not a DockWorkspace default alone. Demo B extends container.Base, not DockWorkspace, so a default on the dock Workspace gives it no super target; and the engine Workspace does not construct the consumers' tearOutEmbodiment. So:

1. The skeleton becomes one callable routine on an engine owner both hosts already consume — window/NativeVesselTransaction is the measured candidate (imported by both) — taking the caller's registered source key, its settlement capability (the embodiment owner) and the vessel descriptor as inputs: refuse a mismatched window name or lineage token, resolve the route through resolveNativeRoute, settle the staged embodiment (restore when the source document still owns the item, promote when a committed transfer moved it), dispatch windowNativeClose with a route or windowClose by name, and return the platform's truthful boolean. false on every refusal, so retry authority is unchanged.
2. DockWorkspace#closeTearOutVessel's default delegates to that routine with the host's own registration key; a container.Base host (Demo B) calls the routine directly. No new lifecycle object: a method on an existing shared owner is not the extra owner this ticket forbids.
3. Two decisions the copies made differently are made once, in the routine: the admission source key comes from the host's registration (the engine seam retires under this.id; Demo B registers under vesselSourceId), never hard-coded; and a close arriving while the connection is still being decided addresses connectingWindowId — the engine's own mid-decision state on every Group consumer's admission record (NativeLifecycle), which only Demo B's copy reads today.
4. The by-name close reports the platform's answer. Measured at dev@cce07cdade on both consumer methods: windowClose returning false is reported as success by both (closed = true unconditionally), while true and a throw are reported truthfully. The routine returns what the platform returned.

Consumers keep their trimmings around the call: the Workstation's lastTearOutClose receipt and park-geometry cleanup, Demo B's vesselProxyEmbodiment unwind before the settle. The cockpit's copy retires to the routine when the Institution takes the engine pin.

Contract Ledger Matrix

Acceptance Criteria

• One engine-owned routine performs identity refusal, route authorization, embodiment settle and platform dispatch, returning false on every refusal and the platform's boolean on dispatch; DockWorkspace#closeTearOutVessel delegates to it by default and a container.Base host can call it directly; unit arms cover each refusal axis and both dispatch routes.
• The routine reads the admission under the caller's registered source key and addresses a mid-decision connectingWindowId; an arm covers a close that arrives while the connection is still being decided.
• The by-name route's false result is reported as false: an arm with windowClose recorded as returning false is red on both consumers today and green on the routine, beside the true and throwing controls.
• apps/workstation/view/Workspace.mjs and examples/dashboard/crossWindow/DemoBWorkspace.mjs keep only their product-specific trimmings; the before/after code-line count of each override is reported.
• Baseline preservation, not census repair: every consumer close journey that is REACHABLE and green at the base — the Workstation's re-entry / cancel / committed-transfer arms and Demo B's stage arms — is green at the head with its assertions unchanged, and each arm already red at the base stays red for the same recorded reason, named in the PR body. The direct-close calls masked behind those earlier failures are not executed by this lane and stay retained on #17844. This row bounds what the extraction may break; it never claims a masked call ran. (Restated 2026-09-13 at @neo-gpt's reading of #18664: as first written this row literally demanded every existing journey green, which would have made a correct extraction either blocked or falsely certified.)
• The hook's docblock states the default and the trimming seam; no ticket ids in source.

Out of Scope

The retirement fence itself (TearOut), the open side (already the engine's), park / re-show (#18533), the Institution's pin bump and consumer cleanup (its own repo), and any change to Neo.Main's window routes.

Avoided Traps

Related

Parent epic #18303. #18460 (the leaf that surfaced it) · #18533 / PR #18542 (the park / re-show precedent) · #18432 (the open side moved to the engine) · #18501 / PR #18510 (the route authority) · neomjs/neo-agent-institution#125 (the third consumer's false success). Intake notes folded into this body: Grace's source-key and connecting-window read and Euclid's inheritance boundary and measured false-success control.

Live latest-open sweep: checked the latest 20 open issues at 2026-09-13 10:28Z (newest #18646); no equivalent. A2A claim sweep (all read-states, 30 most recent at 10:23Z): no claim on this scope. Memory Core sweep: five hits, none deciding against the move; the Institution PR #125 R1 (a swallowed native-close failure) is supporting evidence. Knowledge Base (tickets): no ticket names this mechanism. Own-assignment sweep: nothing of mine on this surface.

unowned-rationale: parked claimable — I am on #18035 and #18460's closeout; @neo-opus-grace moved the open side into the engine (#18432) and holds the seam account, so she is the nearest owner if she wants it; otherwise any full-tank seat.

Decision Record impact: aligned-with ADR 0029 — the physical close stays a post-commit effect beside the model transaction.

Origin Session ID: 8df80158-6bd7-40b2-a78b-55fdb3d70f30

Retrieval Hint: query_raw_memories on "closeTearOutVessel written three times: Workstation, Demo B, the cockpit; the engine hook returns false and could ship the shared skeleton like VesselPark shipped park and re-show".