Technical Requirement Document (TRD)

Scope and verification status

This public-safe document describes reviewed application source, not a live-host certification. It contains no account credentials, live records, private server paths, connection details or recovery bypass instructions. Deployment is owner-reported; Instructor access, final browser acceptance and host-specific behavior still require verification.

Technologies and architecture

The PHP 8.3-compatible application uses Laravel 13, Eloquent relational models and server-rendered Blade views. Tailwind CSS, scoped CSS, vanilla JavaScript, Vite and Chart.js support responsive pages and charts; Dompdf generates supported PDFs. Dependencies and browser assets are prepared locally. This update adds no dependency.

Named routes dispatch requests to controllers. Middleware verifies sessions and active accounts; controllers enforce ownership, role permissions and validation. Reusable services handle filtering, reports, audit, backup and recovery. Data comes from the configured relational database, not invented dashboard figures.

Workflows and decision support

Student/Instructor registration awaits Admin approval. Instructors manage their own sections and publish Face-to-face, Asynchronous, Delayed or Cancelled status posts. Approved members receive in-app notifications and can read protected history. Current status is the latest surviving publication. It is Instructor-provided advice for planning a commute, not an automated institutional cancellation decision.

The Admin dashboard aggregates real accounts, sections, posts and activities. Its bounded refresh checks about once per minute while visible and handles session expiry; other pages use normal navigation/refresh. Accessible chart tables remain available. Immediate-delivery SLAs, SMS and browser push are not claimed.

Database structure and integrity

users represents identity, role, approval, suspension, demo status and soft deletion. Normalized emails are unique across all roles and removed accounts. role_sequences allocates role-specific account numbers. Passwords are stored as adaptive hashes, never documented as plaintext database values.

sections belongs to an Instructor and stores course/section identity, schedule and room. section_members links users and sections with pending, approved or declined membership. status_updates retains authored history and removed-post tombstones. app_notifications holds recipient-specific messages and read state. activity_logs retains controlled descriptions, actor snapshots, time and optional IP information. Framework tables support sessions, reset tokens, cache, queues and migration metadata.

Foreign keys and unique constraints protect relationships. Models normalize numeric ownership keys before strict authorization comparisons. Normal removal is soft deletion, not a cascade erasing history. Section restoration reactivates the original row and preserves ID/memberships; it does not reassign ownership, approve members or revive individually removed posts. Mutations and their audit entries use transactions and appropriate locking.

Authorization, privacy and authentication

Authentication accepts registered email or School ID with CAPTCHA, throttling and stored-role portal checks. Registration requires at least 12 characters and matching password confirmation. Existing login credentials are not invalidated by that registration rule. Browser mutations use CSRF protection. Account status, demo availability and session revocation are checked server-side; hidden navigation is not authorization.

Email recovery uses expiring single-use tokens and generic public responses. Successful reset revokes session/remember-me access and requires normal login. Demo users cannot change or recover shared credentials. There is no public demo Admin; Admin credentials remain private.

Reviewed PRD/TRD pages and the Student and Instructor manuals are public read-only documentation available before registration or sign-in. The full Admin manual requires active Admin authorization. Records, profiles, reports, rosters and Admin tools retain their existing permissions. Blade escapes dynamic names and notes; secrets and reset links are not documentation content.

Reports, audit and continuity

Reports validate filters, scope records to the viewer, include institutional headers and generated date/time, and support print preview and bounded PDF output. Admin has the full configured catalog; Instructor has transaction/personal activity, and Student has approved-section history/personal activity. Audience-facing dates use a consistent local clock. Print/PDF documents remain independent of the application theme.

Authentication, account, section, status, report and backup/restore actions have centrally classified audit entries. Read-only page views and searches do not manufacture successful-action logs.

Admin can create verified database backups and files ZIPs containing the logo, reference-only settings and verification metadata. Files restore applies only the logo, not settings or source/configuration. Database restore checks format, signatures, checksums and schema compatibility, takes a verified safety backup, verifies replaced data and revokes sessions/reset tokens. Filesystem changes need separate staging, verification and recovery safeguards; a database transaction cannot roll back a replaced file.

Independent host/database recovery remains necessary. Detailed operational recovery material is kept privately, not published here. Scheduled backups remain deferred. Missing prerequisites or unsafe recovery state must refuse an operation rather than log false success.

Compatibility and limitations

Isolated local checks use SQLite; accepted integration evidence includes MariaDB 11.8.9 (MySQL-compatible), not native MySQL verification. Actual host database/PHP behavior, permissions, locking, quotas, performance, HTTPS/cookies, mail delivery and recovery readiness need owner/provider verification. Local builds do not prove those properties.

In-app manuals alone do not complete the submission's illustrated-manual requirement. Actual screenshots, captions and workflow descriptions must be assembled and reviewed in the final submission document. Institutional policy approval and live Instructor access are not asserted by this page.