citrus-cms/resources/views/guide/test-pack-mobile-screen-plan.md

Test Pack Base Status – Mobile Screen Plan (Updated)

1. Scope and Data Source

• Target Page: Test Pack Base Status (/admin/types/test-pack-base-status)
• Backend: Dynamic Resource API /{table}/read and /{table}/update. The table will be resolved via the module slug.
• Reference: Fitup Entry (list + filters, detailed bottom sheet on card tap).

Rule: No fields will be added or displayed on the screen unless they are in this list.

---

2. Field Layout (Star = main frame, others = detail sheet)

Main Screen (on list card – fields marked with *)

Field	Note
test_package_number	*
subcontractor	*
tp_general_status	*
welding_status	*
welding_progress	*
test_type	*
test_pressure	*
test_status	*
golden_joints	* (Can be abbreviated as "GJ" on screen)

Total 9 fields will be displayed in the main frame (on the card).

Detail Screen (bottom sheet – fields without stars)

• punch_list_download
• test_pack_download
• rfi_no
• rfi_date
• test_date
• leakage_test_pressure
• leakage
• leakage_test_date
• test_package_sent_date
• status
• test_package_approval_date
• walkdown_date
• punch_status
• a_punch_point_open
• b_punch_point_open
• c_punch_point_open
• ndt_status
• cleaning_blowing_drying_rfi
• responsible_cleaning
• cleaning_blowing_drying_status
• cleaning_blowing_drying_date
• cleaning_blowing_drying_rfi_no
• reinstatement_rfi
• responsible_reinstatement
• reinstatement_status
• reinstatement_date

Backend column names will be used identically; if necessary, mappings will be handled in the DTO.

---

3. Filtering (Only These Options)

Since test_pack_base_statuses does not contain design_area, wps_no, iso_number, or spool_number information, there are no filters based on these fields.

Filter options (only these):

• test_type
• test_number
• welding process
• welding status

The filter panel will show a dropdown/autocomplete strictly for these four fields.

---

4. Readonly / Editable / Filters

• Filters: The four fields listed above (test_type, test_number, welding process, welding status).
• Readonly / Editable: To be communicated by the user; uncommunicated fields may proceed with a recommendation.
• No extra fields: No fields not on the list in this plan will be added or visible.

---

5. Architecture and File Structure (Summary)

• Data: test_pack_remote_datasource, test_pack_dto, test_pack_list_response, test_pack_repository_impl.
• Domain: test_pack_base_status entity, test_pack_repository, get_test_pack_list_usecase, update_test_pack_usecase, get_distinct_values_usecase (only for test_type, test_number, welding process, welding status).
• Presentation: test_pack_provider, test_pack_entry_screen, test_pack_item (9 main fields: test_package_number, subcontractor, tp_general_status, welding_status, welding_progress, test_type, test_pressure, test_status, golden_joints/GJ), test_pack_detail_sheet (detailed fields listed above).
• Sidebar: Test Pack Base Status / Test Pack Entry menu item → TestPackEntryScreen.

Distinct values API calls only apply to filter fields: test_type, test_number, welding process, welding status.

---

6. Implementation Sequence

1. Clarify the backend table and column mappings for these fields.
2. Feature folder + data (DTO must solely contain fields in this plan: 9 main + detail list).
3. Domain (entity, repo, use cases).
4. DI registrations.
5. Provider (list + distinct only for the 4 filter fields).
6. Main screen (filters: test_type, test_number, welding process, welding status).
7. List card (9 main fields: test_package_number, subcontractor, tp_general_status, welding_status, welding_progress, test_type, test_pressure, test_status, golden_joints/GJ).
8. Detail sheet (all detailed fields without stars).
9. Sidebar menu.
10. Final adjustment according to readonly/editable specification.