src/app/api/v1/documents/%5Bid%5D/download/%5B...slug%5D/route.ts

import { withAuth, withPermission } from '@/lib/api/helpers';

import { downloadHandler } from './handlers';

export const GET = withAuth(withPermission('documents', 'view', downloadHandler));
feat(documents): path-style download URLs for rep-facing readability Storage paths stay UUID-flat per the established CRM pattern (every other content type — brochures, berth PDFs, invoices, reports, templates, expense receipts — uses the same shape). The new catch-all /api/v1/documents/[id]/download/[...slug] route serves files keyed on doc id but rebuilds the slug from current state and 404s on mismatch — a hand-edited or stale link can't render the wrong filename or fold a wrong-folder path into a forwarded URL. URLs in shared links / browser tabs read like 'Deals 2026/Q1/contract.pdf' even though storage keys remain UUIDs. listDocuments + getDocumentById now hydrate a `downloadUrl` field per row (null when no file is attached yet) so UI consumers don't reconstruct paths. Filename is batch-fetched via files-table join to keep the query builder shape unchanged. Tests: 5 integration cases — happy-path stream, wrong-folder slug, wrong-filename slug, orphaned doc (no fileId), cross-port (tenancy isolation). Storage backend swapped to a real FilesystemBackend in a tempdir so the byte-streaming path is exercised end-to-end. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> 2026-05-10 16:50:16 +02:00			`import { withAuth, withPermission } from '@/lib/api/helpers';`

			`import { downloadHandler } from './handlers';`

			`export const GET = withAuth(withPermission('documents', 'view', downloadHandler));`