- renewTenancy service:
- permanent / fee_simple / strata_lot → mutate-in-place (startDate
moves forward, endDate may extend or null out)
- fixed_term / seasonal → end the current row at its existing endDate
+ mint a successor with previousTenancyId chain. newEndDate required.
- transferTenancy service: end-and-spawn — end current row at
transferDate, mint fresh active row with transferredFromTenancyId
pointing back. New client + yacht cross-validated against port +
ownership constraint (assertClientOwnsOrRepresentsYacht).
- POST /api/v1/tenancies/[id]/renew + /transfer routes gated on
tenancies.manage + module-enabled.
- TenancyRenewDialog (tenure-aware copy explains in-place vs successor),
TenancyTransferDialog (ClientPicker + YachtPicker with owner-scoped
filter). Both mounted on tenancy-detail.tsx alongside Edit + End.
- Validators: renewTenancySchema + transferTenancySchema in
src/lib/validators/tenancies.ts.
Verified: tsc clean, 1493/1493 vitest.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Migration 0086: berth_tenancies.previous_tenancy_id +
transferred_from_tenancy_id self-FKs + partial indexes. Per
docs/tenancies-design.md these chain renewal / transfer successors
to predecessors for fixed-term and seasonal lineage. Schema mirrored
in tenancies.ts with AnyPgColumn typed-import.
- POST /api/v1/tenancies (generic create): accepts berthId in the
body so client + yacht tab entry points don't have to bounce through
/api/v1/berths/[id]/tenancies. Same createPending service helper.
- TenancyCreateDialog: <TenancyCreateDialog open clientId? yachtId?
berthId? /> with all three pickers; pre-fills the carrier from the
parent entity. POSTs to /api/v1/tenancies; "Create" and
"Create and activate" CTAs both wire to the new endpoint.
- Mounted on ClientTenanciesTab + YachtTenanciesTab behind
<PermissionGate resource="tenancies" action="manage"> so reps can
mint tenancies directly from those tabs without bouncing through
the berth page.
- TenancyEditDialog: edit metadata only (start/end dates, tenure type,
notes) via the new action='update' branch on the [id] PATCH route.
Status transitions stay on activate/end/cancel. Wired into the
tenancy detail page header. Outer wrapper unmounts on close so the
form re-initialises from current row data without setState-in-effect.
- updateTenancy service helper + PATCH action='update' branch added.
Audit-logged + emits berth_tenancy:activated to invalidate detail
query caches.
Renew + Transfer dialogs deferred — both need lineage UX decisions
(tenure-aware mutate-in-place vs new-row spawn; client/yacht swap
semantics) and the self-FK columns this commit lands are the
underpinning. Next sub-task.
Verified: tsc clean, 1493/1493 vitest, migration applied.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
