C1: src/worker.ts and src/server.ts only imported 5 of 10 BullMQ
workers. ai/bulk/maintenance/reports/webhooks were never started, so
in production: webhooks never delivered, no maintenance crons (DB
backups, session cleanup, retention sweeps, alerts, analytics refresh,
calendar sync), no scheduled reports, no AI features, no async bulk.
All 10 are now imported and held against GC.
R2-C1: Bulk archive's runBulk callback discarded the return value
from archiveClientWithDecisions, so Documenso envelopes marked for
void in the wizard were never queued and next-in-line notifications
never fired. Now we collect the per-archive (dossier, result) pairs
and replay the same post-commit fan-out the single-client route uses.
R2-C2: Archived-client header's Restore icon was hovering destructive-
red because an unconditional hover:text-foreground was overriding the
later conditional. Restore now hovers emerald; archive still hovers
red.
1175/1175 vitest passing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the single window.confirm() with a 3-stage wizard:
- preflight: counts auto/needs-reason/blocked (POST /bulk-archive-preflight)
- reasons: carousel through high-stakes clients capturing per-client
reason (≥5 chars) — bulk endpoint accepts reasonsByClientId map
- confirm: shows the final archivable count and submits
Low-stakes still auto-archives with safe defaults; blocked clients
are skipped with a per-row reason in the preflight summary.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The new smart-archive backend (d07f1ed) is now wired to the existing
bulk-archive endpoint. Previously /api/v1/clients/bulk just called the
legacy archiveClient — bypassing the dossier and the per-client
decisions. That's now a regression hazard: a power-user could bulk-
archive a client mid-deposit with no audit trail.
New behaviour:
- bulk action='archive' fetches the dossier per client.
- Low-stakes clients (open through eoi_signed) auto-archive with the
same default decisions the single-client modal would pick: release
available/under-offer berths, retain sold berths, cancel active
reservations, leave invoices, leave Documenso envelopes pending,
acknowledge signed documents inline.
- High-stakes clients (deposit_10pct and beyond) refuse with a clear
message: "open the client to confirm + supply a reason". The bulk
summary surfaces the failure per row so the user knows which clients
need individual handling.
- Pre-flight blocker check (e.g. active reservation on a sold berth)
also rejects with a per-row error instead of crashing.
The proper "bulk wizard" UI (per-high-stakes-client confirmation panel
with reason fields) is still TODO — this commit just makes the existing
button safe.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Until now the only bulk action anywhere was Archive on the interests
list — implemented as parallel fan-out with no per-row failure
reporting. The bulk BullMQ worker was a TODO stub with no producers.
- bulk-helpers.runBulk wraps a per-row loop and returns
{results, summary} for the caller. Page-size capped at 100.
- New endpoints: /api/v1/{interests,clients,yachts,companies}/bulk
with a Zod discriminated union over the action. Interests support
change_stage + add_tag + remove_tag + archive; clients/yachts/companies
support archive + add_tag + remove_tag. Each action is permission-gated
individually (delete vs edit vs change_stage).
- interest-list, client-list, yacht-list expose the new actions in the
bulk-action toolbar with dialogs for stage / tag selection. Failure
summaries surface via window.confirm.
- bulkWorker stub gets a docblock explaining the v1 sync-only choice
and what the queue is reserved for (CSV imports, port-wide migrations,
bulk emails to >100 recipients).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
