GSGurmilan Singh
02 / Opssemble LiteActive development · core workflow implemented

What isn’t ready, and what just went wrong.

Opssemble Lite is a university final project for coordinating event areas, tasks, exceptions, and readiness. The core workflow is implemented while interface evidence, tests, and public documentation are still being prepared.

Context
University final project
Role
End-to-end developer
Stack
React 18 · Node.js · Fastify 5 · MySQL 8
Authorization
Server-side event roles
Assistant
Optional · Ollama or Groq
Status
Active development

01 / Product

Tasks, exceptions, and readiness in one product.

Areas hold tasks, problems become tracked exceptions with severity, and readiness is computed from what's still open.

implemented coverage

  • StructureEvents, typed areas, tasks with status and priority
  • ExceptionsSeverity, status, resolution note and resolver
  • ReadinessPer-area and event-wide scores with blockers
  • RecordsReports, CSV & print export, activity log, dashboard

02 / Architecture

Feature modules across the interface and API.

Both the API and the React app are organized around the same product areas, and every backend feature follows the same routes → controller → service → repository → schema shape.

implemented API modules · routes / controller / service / repository / schema per folder

autheventsareastasksexceptionsreadinessevent membersqrreportsactivitytemplatesdashboardsettingsadminaimailusers

Cross-cutting pluginsdb · auth · rate limit · uploads · error handler

03 / Core workflow

From event structure to scoped access.

The application connects event records, server-side roles, calculated readiness, and revocable area access.

Structure and exceptions

Areas contain the work and the problems.

Tasks carry status, priority, and due dates. Exceptions record severity, resolution status, and the resolver.

Authorization

Every write is checked by the API.

Members hold one of four event roles — owner, coordinator, operator, viewer — and server-side checks decide what each role can change.

Readiness

The score is derived from open work.

A critical open exception or blocked task blocks an area; ready requires completed tasks with no critical blockers.

Area access and records

QR access stays scoped and revocable.

Only the SHA-256 hash of each area token is stored. Reports, CSV exports, activity records, and the dashboard use the same application data.

04 / Access & security

Account and event access are enforced by the API.

These are implemented controls, not a general security guarantee.

Sessions
JWT sessions carried in HttpOnly cookies; passwords hashed with bcrypt.
Sign-in
Email and password with emailed verification codes, Google OAuth 2.0, password reset, and an optional recovery email.
Enumeration & abuse
Generic login errors, failed-attempt delays, and lockouts.
Tokens
Verification, reset, and QR area tokens are stored only as SHA-256 hashes.

decision 01

Authorize every write against the caller’s event role

Constraint
Four roles act on the same event from different devices.
Decision
Role checks live in the API beside input validation.
Result
The interface reflects permissions that the server already enforces.
Trade-off
Every new write endpoint requires an authorization rule and test.

technical artefact · area token lifecycle (revocable at any time)

  1. MintOwner or coordinator issues an area token
  2. StoreOnly the SHA-256 hash persists
  3. ScanLogin-gated area context page
  4. ActActions scoped by the caller’s event role

backend hardening, from code

  • Query safetyParameterized SQL across repositories
  • HTTP headersHelmet security headers and a CORS policy
  • UploadsFile validation by magic-byte signature
  • Rate & emailRequest rate limiting; transactional email via Nodemailer

05 / AI assistance

Optional assistance, no write authority.

The application works without AI. When configured, one service can use local Ollama or hosted Groq to draft, scaffold, explain, and summarize event content; results do not bypass normal write endpoints.

assistant capabilities

  • DraftingTask and exception drafts from a short prompt
  • Event scaffoldingSuggested areas and tasks for a new event
  • Gap & readinessGap checks, readiness explanations, and blocker summaries
  • Q&A & retrospectiveEvent question answering and retrospective drafting

guardrails, from configuration and code

  • Per-user rate limitingRequests per rolling window
  • Context capsBounded input size per request
  • Output capsBounded response size and timeouts
  • No write authorityEvent data changes only through the same authorized endpoints as manual edits

06 / Current boundaries

Core workflow implemented; public evidence still in progress.

Scope
An active-development university project, not a commercial production SaaS.
Metrics
No load, uptime, or usage figures are published.
Evidence
Public screenshots, repository documentation, and test reporting are still required.
Assistant
Runs only when Ollama or a Groq key is configured.

what it demonstrates

React product work, a layered Fastify API, relational data, authentication, roles, QR-scoped access, and controlled AI assistance.

next evidence

Sanitized screenshots, focused tests, setup documentation, and a public repository are the next publication steps.