Project Document
Check List – Hybrid Initial Solution for Quality Check Reports

1. Document Information

Project Name: Check List
Document Type: Initial Project Documentation / Concept Specification
Version: 1.0
Date: 09 April 2026
Project Phase: Initial Implementation (Hybrid model between Option 2 and Option 3)

2. Executive Summary

The purpose of the Check List project is to replace the current Excel-based quality check reporting process with a modern digital solution that supports structured report creation, image attachments, offline work, and standardized export.

The proposed initial implementation will follow a hybrid approach between a fully local web solution and a server-connected application.

In this phase:
- Node.js and MariaDB available on the server side will be used to centrally manage:
  - checklist templates,
  - report structure,
  - required fields,
  - validation rules,
  - lookup values,
  - image processing rules,
  - template versions.
- The client-side web application will be responsible for:
  - loading and caching templates,
  - creating reports offline,
  - saving reports locally as drafts,
  - switching between multiple reports,
  - attaching and resizing images directly in the browser,
  - renaming images automatically,
  - generating the final output as a ZIP file containing:
    - an Excel report file,
    - a folder with attached images.

At this stage, the final reports will not yet be stored centrally in the database.
Instead, the database will serve as a template and configuration repository, while the final report remains a file-based deliverable.

This approach provides:
- a practical and low-risk first implementation,
- offline usability,
- centralized management of checklist definitions,
- and a clear migration path toward future server-side report synchronization.

3. Project Background

The current reporting process is based on Excel files used to create quality check lists and reports. This creates a number of operational and technical limitations, including:
- manual preparation of reports,
- inconsistent structure between reports,
- difficulty enforcing required fields,
- inefficient handling of images,
- lack of standardized image naming,
- dependency on Excel files and manual file handling,
- limited support for mobile devices,
- no controlled offline workflow,
- difficult future integration with central systems.

The new solution is intended to improve data consistency, user convenience, and long-term maintainability by introducing a controlled digital workflow.

4. Project Objective

The objective of the project is to implement a digital reporting solution that replaces Excel-based checklist reporting with a structured web application that works across platforms, supports offline work, and produces a standardized ZIP-based report package.

The initial version of the solution must:
1. allow users to create quality check reports in a web application,
2. support Windows, Android, and iOS devices,
3. allow use without permanent internet access,
4. provide centrally managed checklist templates from the server,
5. allow users to save reports as drafts and continue them later,
6. allow switching between multiple reports,
7. support image attachment with automatic resizing/compression in the browser,
8. automatically rename images based on report naming rules,
9. generate the final report as a ZIP package with Excel file and images,
10. prepare the solution architecture for future server-side report synchronization.

5. Scope of the Initial Implementation

5.1 In Scope

The following functions are included in the initial project scope:

Server-side scope
- central storage of checklist templates,
- central storage of required field definitions,
- central storage of validation rules,
- central storage of lookup values / dropdown lists,
- central storage of image handling rules,
- template version management,
- API for providing templates and configuration to the web application.

Client-side scope
- responsive web application,
- dynamic rendering of checklists based on templates,
- local storage of report drafts,
- local storage of image attachments,
- report editing in offline mode,
- report auto-save,
- support for multiple local reports,
- switching between reports within the application,
- browser-based image resizing/compression,
- automatic image renaming,
- local ZIP file generation,
- local Excel file generation,
- local export of finished reports.

5.2 Out of Scope (Initial Phase)

The following items are intentionally excluded from the first implementation phase:
- central storage of completed reports in the database,
- full backend synchronization of report data,
- server-side image upload for completed reports,
- conflict handling between multiple users/devices,
- server-side draft storage,
- advanced reporting/analytics dashboards,
- workflow approvals,
- ERP/QMS integrations,
- embedding images directly inside Excel (unless later required),
- native Android/iOS applications.

These items can be considered in later project phases.

6. Proposed Solution Overview

The recommended initial solution is a hybrid offline-first web application.

Core principle:
- Templates and configuration are centrally managed on the server
- Reports are created and stored locally in the browser
- Final output is exported as ZIP

This model combines the most important business and technical benefits:
- centralized control over checklist content,
- simpler initial implementation than full synchronization,
- full support for offline report creation,
- broad device compatibility,
- structured handling of images,
- future readiness for backend expansion.

7. Business Benefits

The proposed solution provides the following business benefits:

7.1 Standardization
- consistent report structure,
- consistent validation rules,
- controlled mandatory fields,
- unified image naming convention.

7.2 Improved usability
- easier report creation compared to manual Excel editing,
- better experience on mobile devices,
- faster attachment handling,
- draft-based workflow.

7.3 Offline capability
- users can continue work even without internet access,
- templates can be loaded earlier and used later offline.

7.4 Central governance
- checklist templates are managed from one place,
- changes in required fields do not require front-end redesign,
- image limitations are centrally configurable.

7.5 Lower implementation risk
- final reports remain file-based in the first phase,
- backend complexity is limited,
- architecture remains ready for later expansion.

8. User Groups

The initial solution is intended for users involved in quality check and inspection reporting, for example:
- quality inspectors,
- production or warehouse staff performing checks,
- incoming inspection personnel,
- mobile users working on shop floor or at supplier/customer location,
- administrators responsible for checklist configuration.

9. Functional Requirements

9.1 Template Management

Checklist templates must be centrally stored on the server and provided to the web application through an API.

Each template should be able to define:
- template identifier,
- template name,
- version,
- sections/groups,
- field labels,
- field types,
- required fields,
- default values,
- validation rules,
- optional comments,
- image requirements,
- export metadata.

The application must support the use of different template versions.

Template versioning rule
- Existing draft reports must remain bound to the template version under which they were created.
- New reports should use the newest active version of the selected template.

9.2 Report Creation

The user must be able to create a new report based on a selected checklist template.

A report should include:
- report header information,
- checklist items,
- comments,
- attachments,
- report status,
- metadata (created date, updated date, template version, etc.).

Possible field types include:
- text,
- number,
- date,
- checkbox / boolean,
- dropdown / lookup list,
- pass/fail choice,
- comments,
- attachment-required items.

9.3 Draft Save and Continue Later

The application must allow the user to save incomplete reports locally as drafts.

The user must be able to:
- save a report as draft,
- leave the report,
- return later,
- continue editing from the last saved state.

Draft saving should occur:
- manually via a save function,
- automatically during editing,
- when switching between reports,
- when adding/removing attachments.

Draft reports must remain accessible from a report list/dashboard.

9.4 Switching Between Reports

The user must be able to work with multiple reports within the same application.

The application must provide a report dashboard or report manager where the user can:
- see all locally stored reports,
- filter reports by status,
- open a selected report,
- continue editing,
- duplicate a report,
- archive or delete a report,
- export a completed report.

When switching from one report to another:
- the current report must be saved automatically,
- the selected report must be loaded from local storage.

9.5 Report Statuses

The system should support at least the following statuses:
- Draft
- In Progress
- Ready for Export
- Exported
- Archived

These statuses should be visible in the report list.

Future phases may introduce additional synchronization-related statuses, but they are not required in the initial version.

9.6 Offline Mode

The application must support offline work after templates and configuration have been loaded.

Offline mode must allow:
- opening cached templates,
- creating new reports,
- editing existing drafts,
- attaching images,
- saving report progress locally,
- generating ZIP output locally.

If internet access is unavailable, the application should continue using the latest cached template data.

9.7 Image Attachment Handling

The system must support attaching images to reports.

Images may be added from:
- file picker,
- mobile device gallery,
- mobile camera (if browser/device supports direct capture).

The application must validate image files against centrally defined rules such as:
- allowed file types,
- maximum file size,
- maximum dimensions,
- output quality settings.

9.8 Browser-Based Image Resizing

Image optimization must be performed directly in the web browser on the client side.

When an image is attached, the application must:
1. read the image locally,
2. validate file type, size, and dimensions,
3. resize/compress the image if it exceeds configured limits,
4. store the optimized version locally,
5. show a preview,
6. associate the optimized image with the current report.

This functionality is required to:
- reduce storage usage,
- standardize attachment size,
- improve performance,
- maintain offline capability,
- prepare for future upload optimization.

The system should support either:
- automatic resizing,
- warning + resizing,
- or blocking oversized files,

depending on centrally configured rules.

For the initial implementation, the recommended behavior is:
- automatic optimization with user notification.

9.9 Automatic Image Renaming

The application must automatically rename attached image files according to a structured naming convention.

The naming convention should be centrally configurable and may include:
- report number,
- section code,
- sequence number,
- date or other metadata if required.

Example naming structure:
<ReportNumber>_<SectionCode>_<Sequence>.jpg

Both the original filename and generated filename should be tracked in metadata.

9.10 Validation Rules

The application must support validation based on centrally managed rules.

Validation may include:
- required fields,
- allowed values,
- numeric ranges,
- image required for selected checklist item,
- minimum/maximum number of attachments,
- checklist completeness.

Validation must distinguish between:
- draft save (allowed even if incomplete),
- ready for export (only allowed if validation passes).

9.11 Export to ZIP

The final report must be generated locally as a ZIP archive.

The ZIP file should contain:
- one Excel file,
- one image folder containing all attached images.

Recommended ZIP structure
<ReportNumber>.zip
├── <ReportNumber>.xlsx
└── images/
    ├── <image1>.jpg
    ├── <image2>.jpg
    └── ...

The Excel file must include:
- report header,
- checklist answers,
- comments,
- image file references,
- template version,
- export timestamp.

For the first version, it is recommended that:
- images remain as separate files in the ZIP package,
- images are not embedded into the Excel file unless explicitly required later.

10. Non-Functional Requirements

10.1 Platform Compatibility
The application must operate on:
- Windows browsers,
- Android browsers,
- iOS browsers.

A responsive layout is required.

10.2 Performance
The solution should perform adequately on standard office devices and mobile devices.

Special attention should be given to:
- image processing time,
- local storage performance,
- report loading speed,
- ZIP generation performance.

10.3 Usability
The interface should be simple and optimized for operational use.

The system should:
- minimize manual steps,
- provide visible save status,
- provide clear validation messages,
- support touch-based interaction,
- reduce risk of data loss.

10.4 Maintainability
The solution should be modular and designed for future expansion.

The frontend should separate:
- UI logic,
- template rendering,
- local data storage,
- image processing,
- export logic,
- future synchronization logic.

10.5 Data Integrity
The system must:
- auto-save regularly,
- preserve locally stored reports,
- bind reports to template versions,
- avoid corruption caused by later template changes.

10.6 Security
In the initial phase, security requirements may be lighter than in a fully centralized solution, but should still include:
- secure API communication when online,
- controlled access to template management,
- safe handling of local report data,
- user/session identification if introduced.

11. Technical Architecture

11.1 General Architecture

The recommended architecture for the initial implementation is:

Server Side
- Node.js application
- MariaDB database
- REST API for templates and configuration

Client Side
- browser-based web application
- local storage for reports and attachments
- local report generation and export

11.2 Server Responsibilities

The server will manage:
- checklist templates,
- template versions,
- field definitions,
- required field rules,
- lookup data,
- image processing rules,
- configuration data.

At this stage, the server will not store final report data.

11.3 Client Responsibilities

The client application will manage:
- template download and caching,
- form rendering,
- local report editing,
- draft storage,
- image resizing,
- image previews,
- automatic renaming,
- Excel generation,
- ZIP generation.

12. Recommended Technology Stack

12.1 Frontend
Recommended:
- React for the web application,
- responsive UI framework or custom responsive design,
- IndexedDB for local offline storage,
- Excel generation library,
- ZIP generation library,
- browser Canvas API (or equivalent browser-side image processing approach).

12.2 Backend
Recommended:
- Node.js
- REST API architecture

12.3 Database
Recommended:
- MariaDB

13. Data Storage Concept

13.1 Server-side Data
Stored in MariaDB:
- templates,
- template sections,
- template fields,
- validation rules,
- lookups,
- image settings,
- export settings,
- template version data.

13.2 Client-side Data
Stored locally in the browser:
- downloaded templates (cached),
- draft reports,
- report metadata,
- checklist answers,
- attachment metadata,
- optimized image files.

Recommended local storage technology
Use IndexedDB rather than basic browser local storage.

Reason:
- better support for structured data,
- support for binary image data,
- better capacity and performance,
- better fit for multiple drafts and attachments.

14. Suggested Logical Data Model

14.1 Template-related entities (server side)
Possible logical entities include:
- Templates
- Template Sections
- Template Fields
- Lookup Values
- Template Settings
- Template Versions

These should support dynamic form rendering.

14.2 Report-related entities (client side)
Each local report should contain at least:
- local report ID,
- report number or temporary identifier,
- template ID,
- template version,
- report status,
- header data,
- checklist values,
- comments,
- attachment metadata,
- created date,
- last update date.

Each attachment should contain:
- internal attachment ID,
- original filename,
- generated filename,
- MIME type,
- file size,
- dimensions,
- relation to report and field/section.

15. API Scope for Initial Phase

The initial backend API can be intentionally limited.

Suggested API scope:
- get available templates,
- get template details,
- get template version,
- get lookup data,
- get image/configuration settings,
- optional application version/configuration endpoint,
- optional authentication endpoints.

Report upload API is not required in the initial phase.

16. User Workflow

16.1 Online startup scenario
1. User opens the application.
2. Application loads latest templates and configuration from the server.
3. Templates are cached locally.
4. User can start creating reports.

16.2 Offline work scenario
1. User opens the application without internet access.
2. Application uses last cached templates.
3. User creates or continues reports.
4. Images are processed locally.
5. Drafts are saved locally.
6. User exports a ZIP file when the report is finished.

16.3 Report editing scenario
1. User creates or opens a report.
2. User fills checklist fields.
3. User adds comments and images.
4. Application auto-saves progress.
5. User may leave report as draft or continue later.
6. User marks report as ready.
7. Application validates data.
8. User exports ZIP file.

17. Risks and Constraints

17.1 Local Storage Dependency
Because reports are stored locally in the first phase, there is a dependency on browser/device storage.

Risk:
- local drafts may be lost if storage is cleared.

Mitigation:
- auto-save,
- visible draft management,
- encourage timely export/archiving,
- consider backup/import in later phase.

17.2 Browser Storage Limits
Images and multiple drafts can consume significant space.

Mitigation:
- automatic image compression,
- optimized image limits,
- archive/delete completed reports,
- monitor practical storage capacity during pilot.

17.3 Template Change During Active Reports
Changing a template could affect reports already started.

Mitigation:
- enforce template versioning,
- bind each report to the template version it started with.

17.4 No Central Report Repository Yet
The initial phase does not yet provide central report storage or reporting history.

Mitigation:
- keep ZIP export as the official output,
- plan future extension to server-side synchronization.

18. Future Expansion Path

The proposed architecture is intentionally designed to support future transition toward a more advanced server-connected model.

Future phases may include:
- upload of completed reports to backend,
- server-side report repository,
- attachment upload,
- synchronization of offline-created reports,
- user roles and permissions,
- dashboards and analytics,
- integration with other systems,
- central audit trail.

Because templates are already server-managed in the initial phase, future expansion should require fewer architectural changes.

19. Recommended Implementation Phases

Phase 1 – Hybrid Initial Solution
- template/configuration management on server,
- local report creation,
- offline-capable report editing,
- draft save and continue later,
- switching between multiple reports,
- browser-side image resizing,
- automatic image renaming,
- ZIP export.

Phase 2 – Extended Hybrid
- optional user authentication,
- optional upload of ZIP packages,
- central administration UI for templates,
- export history,
- advanced template/version control.

Phase 3 – Full Server-Based Reporting
- full report synchronization,
- central report database,
- attachment upload,
- online/offline sync handling,
- reporting dashboard and analytics.

20. Final Recommendation

The recommended starting point for the Check List project is a hybrid initial solution in which:
- Node.js + MariaDB are used from the beginning for central checklist/template management,
- the web application works across Windows, Android, and iOS,
- the application supports offline work after templates are loaded,
- reports are stored locally as drafts,
- the user can switch between reports and continue later,
- images are processed directly in the browser,
- and the final report is exported as a ZIP package with Excel and images.

This approach provides the best balance between:
- implementation speed,
- operational usefulness,
- centralized control,
- offline support,
- and future scalability.

21. Proposed Next Step

The next recommended activity is to prepare a detailed implementation specification covering:
1. screen-by-screen user flow,
2. template JSON structure,
3. local report data model,
4. API endpoint specification,
5. MariaDB schema proposal,
6. image resizing rules,
7. ZIP/Excel export format,
8. development backlog / user stories.
