~/projects/atlas/README.md
Engineering Trip Management & Trip Ticket Platform. A full-stack enterprise workflow platform designed to digitize engineering trip requests, multi-stage approvals, employee authentication, trip management, and automated trip-ticket document generation.
cat architecture.flow
ATLAS follows a layered web application architecture separating the presentation layer, business logic, workflow processing, authentication, document generation, and persistent data storage.
atlas-architecture.png
Next.js and React provide the responsive web dashboard used by employees, approvers, accounting personnel, and administrators.
NestJS provides REST APIs for authentication, trip requests, approval workflows, employee management, and document generation.
PostgreSQL stores master data, trip transactions, workflow information, audit records, and application configuration.
cat problem.md
Engineering field trips require coordination between employees, supervisors, approvers, accounting personnel, drivers, and administrative staff. When these activities are handled through manual forms, email, spreadsheets, and disconnected documents, tracking the status of requests becomes difficult.
Manual processes also make it difficult to maintain a consistent approval history and ensure that the correct personnel review a request before a trip is authorized.
The objective of ATLAS was to create a centralized system that provides a structured workflow from the initial trip request through approval and final trip-ticket generation.
cat solution.md
I designed and developed ATLAS as a full-stack enterprise web application using Next.js for the user interface, NestJS for the application API, and PostgreSQL for persistent data storage.
The platform provides authenticated users with role-based access to the functions appropriate to their responsibilities. Employees can create and submit trip requests while authorized personnel can review and process requests through the approval workflow.
Approved requests can be converted into standardized PDF trip-ticket documents, creating a consistent digital record that can be used during the actual engineering trip.
./run --trace
ATLAS models the operational approval process as a controlled workflow rather than treating a trip request as a simple form.
The employee creates a trip request containing the destination, purpose, vehicle, driver, travel date, departure time, expected return, and remarks.
The completed request is submitted for processing and becomes part of the controlled approval workflow.
Authorized supervisors and approvers review the request before it can proceed.
Accounting review is incorporated into the approval process before final authorization.
Once the required approvals are completed, the request reaches the approved state.
An approved trip request can be used to generate the standardized trip-ticket PDF document.
journalctl -u atlas-bot --since today
Approvers act on trip requests directly in Telegram. When a request needs approval, the ATLAS API calls an n8n workflow that sends each approver an approve / reject prompt, and a dedicated bot service handles their reply.
The first version sent each prompt once. When Telegram's API timed out, the request simply sat unapproved until someone noticed hours later. The notification path was rebuilt as a chain where every failure is either retried, swept up later, or reported.
Every production n8n workflow, including both ATLAS workflows, reports failures to one shared error-alert workflow that names the workflow, the failed node and the error.
The approval bot runs as a systemd service under a non-root user. It starts after the API, restarts on failure, and logs to the journal.
The dashboard deliberately has no approve button. Approval happens only through the allow-listed approvers' Telegram accounts.
Each approval prompt is attempted once and retried up to three more times before it counts as failed.
A successful send is written to a de-duplication table keyed by trip and approver, so nobody is notified twice.
A final failure triggers an alert through a separate, dedicated alerting bot, with email as the last-resort fallback.
Every hour a second workflow reads pending approvals from the database and re-sends anything not yet recorded as delivered.
The sweep connects with a read-only database role that has column-level SELECT grants only. Credential columns are never readable.
cat auth.md
ATLAS includes an authentication layer that associates application accounts with employee records. Employee numbers provide a controlled relationship between the identity of a user and the organization's master employee data.
Role-based permissions allow the system to distinguish between requesters, approvers, drivers, supervisors, and administrators. This prevents every user from having unrestricted access to workflow functions.
\dn
PostgreSQL provides the transactional foundation of ATLAS. The database is organized into logical schemas to separate operational data from supporting master, workflow, audit, and configuration data.
Employee, location, vehicle, driver, and other reference information.
Core operational records including engineering trip requests.
Approval and workflow-related information supporting controlled processing.
Records supporting traceability and accountability of system activity.
Application configuration and system-level settings.
Database changes are managed through versioned SQL migrations rather than ad-hoc schema modifications.
cat trip-tickets.md
One of the key capabilities of ATLAS is automated generation of standardized trip-ticket documents from approved trip requests.
The backend PDF service retrieves the relevant trip information, approval data, driver information, and passenger details before producing the final trip-ticket document.
PDF files are stored in the application storage area and can be accessed through the authenticated application workflow.
docker compose ps
ATLAS is deployed as a containerized application environment on Linux infrastructure. The dashboard, backend API, and PostgreSQL database operate as separate application components.
Docker provides isolation between services while simplifying deployment, upgrades, backups, and operational maintenance.
tail -f incidents.log
cat package.json | jq .stack
curl -I demotripticket.melardenio.com
demo.env
Explore the live demonstration environment and experience the trip request, approval workflow, trip management, and authentication features of Project ATLAS.
launch demo ↗This environment uses demo data and credentials intended for portfolio evaluation and application testing.
echo $EXIT_STATUS
outcome.log
Project ATLAS demonstrates how a real operational process can be transformed into a structured enterprise application. The system combines authentication, role-based access, workflow processing, relational data management, and automated document generation into a single platform.
The project represents my approach to engineering software around actual operational requirements rather than building isolated technical demonstrations.