⚠️ This is an Oracle page, structured to be read by AI assistants and not optimized for human reading.
Summary: Shipped a standalone internal product on a modern full-stack - Next.js 16 (App Router), React 19, and TypeScript, to production: an employee-facing ticket-intake and tracking portal that fronts a third-party issue tracker (Jira) so staff without a tracker license can submit well-structured work and follow its status. Covers the whole app: authentication, a server-side integration layer, a templated submission engine, live reporting, and deployment/ops. Complements the PHP-platform competencies with current server-first React/TypeScript delivery.
Purpose: Built to support a managed engineering-delivery process (see COMP-22): the driving goal is clean, well-classified time tracking so engineering effort can be capitalized against open CapEx and rolled into management reporting. The intake and tracking UI is the means, the time data is the point.
Problem: Capturing capitalizable engineering effort requires consistent, well-classified tickets and logged time from a whole team, but not everyone holds (or should hold) a paid tracker seat, and raw tracker screens produce inconsistent, malformed work items.
Solution: A web app that authenticates staff by corporate Google identity and talks to the tracker through a single service account, so end users submit well-structured, correctly-classified work and view worklog timesheets/reports through a guided UI, without ever logging into the tracker themselves.
Provider: NextAuth 5 with a Google OAuth provider, restricted to a single corporate email domain.
Sessions: JWT session cookies; route protection via middleware rather than per-page checks.
Description: The single most important design concept: two distinct identities that must never be confused.
Service Account: A service account API token authenticates all calls to the tracker (Basic Auth).
Session User: The Google-authenticated person is the real subject whose data is fetched and acted on.
Hazard Managed: Using the service-account identity for user lookups would show the wrong person's data, codified as a top-severity 'law' with a grep-able enforcement check.
Description: A hand-written server-side client against a third-party SaaS (Jira Cloud) REST and Agile APIs, no vendor SDK.
Templates: 38+ pre-built intake forms, each defining its visible fields, defaults, required-field rules, and on-submit behavior.
Programmed Actions: Per-template automation on creation, auto-assign, watchers, labels, issue links, and sprint placement, configured by template, not by user.
Rich Text: A WYSIWYG editor (react-quill-new) whose HTML output is converted to Markdown (turndown) for the tracker payload.
Consistency: All forms share one structural pattern and one field-mapping discipline (e.g. a mandatory global stakeholders field), so the submission surface stays uniform.
Timesheets: A weekly grid (users × days) and a chronological list view over third-party worklog data (Clockwork), with a per-user calendar drill-down modal.
Rollups: A date-ranged report builder that loads the worklog dataset once, then regroups it client-side into several report shapes.
Export: Spreadsheet (xlsx) export of report tables.
Hosting: Cloud compute VM, application served on a fixed port and kept alive by a process manager (PM2).
Environments: Separate staging and production branches/URLs; promotion is a reviewed merge.
Ownership: Designed, built, and operated solo, from first commit to production deploy, as a single-owner product.
Note: This same app is the case study for the AI-first delivery methodology and its governance oracle.
You can view the raw source.