Upgrade 1.1 → 1.2

This upgrade adds the uploaded-file direct lifecycle without removing legacy columns or service methods.

Database migration

Register UploadedFileDirectLifecycle1785744000000 from @sdcorejs/nestjs/features in the consumer TypeORM datasource and run the normal migration command before deploying the new code.

The migration adds exact metadata, staging/final lifecycle, visibility/status, fixed temporary expiry, checksum/ETag evidence, and three cleanup/lookup indexes. Existing rows are conservatively backfilled as private, ready, permanent attachments. sizeBytes, contentType, completedAt, and expiredAt remain null for legacy rows because they cannot be reconstructed reliably.

Configuration and storage

• Add @aws-sdk/s3-request-presigner wherever optional S3 dependencies are installed explicitly.
• For Spaces, configure endpoint, region, and addressing style separately from cdnBaseUrl.
• Keep generic frontend initiate private. Set allowPublicUploads: true only for reviewed internal public use cases, then select publicAccessMode: 'object-acl' or 'external'.
• Add origin CORS for the exact browser origin, PUT, content type, signed metadata, and optional checksum header.
• Import ScheduleModule.forRoot() and verify both pending and temporary cron expressions.

Legacy publicFiles: true still normalizes permanent uploads to public behavior, but the migration does not assume old rows are public and temporary files are never made public. Explicitly backfill only a reviewed set of legacy public row IDs.

Compatibility and rollout

The legacy multipart upload/download endpoints, Buffer service overload, findById, key/CDN reference methods, and columns remain. The direct flow adds initiate, complete, detail, delete, and local content routes. New HTTP serializers omit storage keys and persisted URL references.

Deploy in this order: database migration, bucket/CORS/CDN policy, application code, cleanup workers, then public internal opt-in. Test private direct upload and a temporary boundary before rollout.

The migration down() removes lifecycle data. Roll application/worker code back and drain pending uploads before using it. See the published docs/migration-1.2-uploaded-file-direct-upload.md guide for SQL verification and rollback precautions.