# Airport NavCom E-Inspection System (MVP)

A simple inspection-management web app for an airport **Telecommunications & Navigation Division**.
It lets the division plan, assign, execute, validate, follow up, and report on **daily / weekly / monthly**
inspections of navigation, communication, surveillance, power, and facility equipment.

Built with **Node.js + Express + SQLite** and a **plain HTML/CSS/JS** frontend. No build step, no framework.

> This is a demo MVP. It uses **demo role access** (click a role to enter) — there is no real
> authentication, password, or session security.

## Roles

| Role | What they can do |
|------|------------------|
| **Technician** | See assigned tasks, start inspections, fill checklists, record conditions, raise findings, submit for validation, complete follow-ups |
| **Supervisor** | Schedule & assign inspections, monitor progress, validate / return results, manage findings & follow-ups, view reports |
| **Management** | Read-only KPI dashboard (compliance, findings, trends, critical issues) and periodic reports |
| **Administrator** | Manage master data: users & roles, equipment / facilities / areas, checklist templates (deactivate instead of delete when history exists) |

When you log in as **Technician** you pick which technician you are (their assigned tasks are shown).

## Running locally

```bash
npm install
npm start
```

Then open **http://localhost:3000**.

The SQLite database (`database.sqlite`) is created and seeded with realistic demo data automatically on
first run. To reset the demo data, stop the server, delete `database.sqlite*`, and start again.

> The app uses a fixed demo "today" of **2026-06-03** so the seeded dashboards (today / upcoming / overdue)
> always have data.

## Project structure

```
package.json      # dependencies + "npm start"
server.js         # Express app + REST API
database.js       # SQLite schema, auto-create + seed
database.sqlite   # auto-generated on first run
public/
  index.html      # role selection + SPA shell + modal
  style.css       # styling
  script.js       # SPA logic (state in localStorage)
README.md
```

## Database tables

- **users** — name, role, department, active
- **equipment** — equipment / facilities / locations / areas (name, type, location, area, active)
- **checklist_templates** — daily / weekly / monthly checklists (items stored as JSON)
- **inspections** — the inspection lifecycle (status, schedule, assignment, checklist results as JSON, validation)
- **findings** — field findings *and* their follow-up lifecycle in one table

## Key API endpoints

```
GET    /api/dashboard?role=&user=         role-aware dashboard data
GET    /api/inspections?assigned_to=&status=&type=
GET    /api/inspections/:id
POST   /api/inspections
PUT    /api/inspections/:id
DELETE /api/inspections/:id
POST   /api/inspections/:id/transition    {action: start|submit|validate|return|assign|reschedule|cancel, role}
GET    /api/findings?open=1&urgency=
POST   /api/findings
PUT    /api/findings/:id
POST   /api/findings/:id/transition       {action: accept|assign-followup|submit-followup|resolve|close|escalate, role}
GET    /api/users  /api/equipment  /api/checklists   (+ POST/PUT/DELETE for admin master data)
GET    /api/reports?type=daily|weekly|monthly
```

Lifecycle transitions are **lightly role-gated** (e.g. a technician can't validate, a supervisor can't mark
*In Progress*) to demonstrate the multi-role concept — this is intentionally simple, not production auth.

## Main user journey (inspection lifecycle)

1. **Supervisor** creates an inspection, picks equipment + checklist, and assigns a technician.
2. **Technician** sees it on their dashboard → opens it → **Start** → fills the checklist (marking items
   normal/abnormal, adding notes) → optionally **raises a finding** → **Submits for validation**.
3. **Supervisor** reviews the result → **Validates** (→ *Completed*) or **Returns for revision** (→ technician fixes & resubmits).
4. Findings flow: supervisor **accepts** → **assigns follow-up** → technician **submits follow-up result** →
   supervisor **verifies/resolves** → **closes** (or **escalates** critical findings).
5. **Management** views compliance, trends, critical findings, and reports.

## Intentionally excluded (out of MVP scope)

Real authentication / sessions / passwords, file uploads (evidence is captured as text notes), real
push/email notifications, advanced charting libraries (simple CSS bars are used instead), predictive
analytics, external system integrations, and the optional Reporting Officer role.
