# Training Record Attachment UI Refactor Report

## Scope

- Refactor attachment UI in training record create, edit, and review flows
- Remove duplicate upload area from the attachment list section
- Keep existing API, permissions, validation, and workflow behavior unchanged

## Files Changed

- `src/components/file-uploader.tsx`
- `src/features/training-records/components/training-record-attachment-list.tsx`
- `src/features/training-records/components/training-record-certificate-manager.tsx`
- `src/features/training-records/components/training-record-form.tsx`

## Before vs After

- Before: form page showed one upload area in the form and another upload-capable attachment manager after save
- Before: attachment section title used wording that looked like another upload area
- After: upload UI appears only in editable create/draft/revision flows
- After: attachment section is a compact read-focused list titled `ไฟล์ที่แนบ`
- After: empty state is reduced to a simple inline message with no oversized placeholder card

## Refactoring Summary

- Added a shared `TrainingRecordAttachmentList` component for compact attachment display
- Reused the shared list in the review page through `TrainingRecordCertificateManager`
- Extended `FileUploader` with an optional `showFileList` flag so the dropzone can stay upload-only where needed

## Functional Verification

- Create: upload area visible, attachment list visible, pending files shown in list, no duplicate dropzone
- Edit Draft / Needs Revision: upload area visible, existing files downloadable, deletable, and new pending files shown in the same list
- Waiting / Approved / Rejected view: attachment list remains readable and download-only, no upload dropzone shown

## Responsive Testing

- Layout uses stacked action buttons on small screens and inline actions on larger screens
- Attachment rows wrap long filenames and avoid horizontal overflow

## Regression Testing

- Business logic for upload, delete, and permission checks remains in existing mutations and route handlers
- Submit workflow changes from the previous task are preserved

## Risks

- Pending local files are labeled `รอบันทึก` until the record save/upload sequence completes
- Download action still opens the existing file URL in a new tab, matching current behavior

## Recommendations

- If users want a stronger distinction between “pending local files” and “saved attachments”, we can add a small badge style later without touching the workflow