Implement consistent error handling strategy across the codebase:

• Issue: Email handler catches and sends error emails (inconsistent with "fail fast" philosophy)
• Decision needed: Should we retry on transient failures (SQLite lock, network issues)?
• Consider: Dead-letter queue for failed email processing
• File: emailHandler.ts:29-39

The hardDeleteProcessedRecords() function is implemented but never invoked.

• Action: Create Val.town cron trigger to run cleanup periodically (daily or weekly)
• Function: InboxService.hardDeleteProcessedRecords() (InboxService.ts:88)
• Recommendation: Daily cron at low-traffic time

Current implementation returns attachment metadata. Consider adding direct download capability:

• Current: GET /:recordId/attachments → returns JSON list of attachments
• Add option 1: GET /:recordId/attachments/:blobId → download specific attachment
• Add option 2: GET /attachments/:blobId → direct blob download (simpler)
• File: httpHandler.ts:30-56

Email endpoint could be spammed even with allowlist (minor concern for personal use).

• Note: Val.town provides some platform-level rate limiting
• Consider: Application-level throttling for email processing
• Consider: Max emails per sender per time window

attachmentBlobIds array has no guaranteed order preservation.

• Impact: Low - usually not critical for inbox use case
• Consider: Add explicit ordering metadata if needed
• File: InboxService.ts (inboxRecordSchema)

After implementing fixes, update the following:

• PROJECT.md - Update API documentation for GET /:recordId/attachments endpoint
• PROJECT.md - Document that cleanup requires cron setup (once implemented)
• CLAUDE.md - Add note about error handling philosophy consistency