Lexerian Platform: Technical Architecture & Administrator Guide

This document provides a comprehensive overview of the Lexerian platform, its core pillars, security model, and implementation details for maintaining and auditing the system.

1. Core Arcxqhitecture Pillars

Lexerian is built as a unified Project Lifecycle Management (PLM) platform divided into four primary workstreams:

  1. Projects (Work Orders): High-level container for all work. Focuses on project-level metadata (Client, Status, Description).
  2. UAT (User Acceptance Testing): Focused test execution engine for validating project deliverables with end-users.
  3. Blog (Public Content): A brand-centric content archive for enterprise communication.
  4. Dashboards (Analytics): Real-time data visualization using a dynamic Pivot Table / Plotly engine.

2. Security & Sharing Model (The “Assignment Principle”)

Lexerian uses a Membership-Centric Visibility Model. Access is not granted globally but is inherited through project assignments.

Permissions Hierarchy

  • Public (Unauthenticated): Can view the Landing Page and Blog.
  • Authenticated (Project Member):
  • Can view any Project, Phase, Task, or UAT they are explicitly assigned to.
  • Can execute tests in UAT and report issues.
  • Administrative (Owner/Admin):
  • Project Creators are automatically granted ‘Owner’ status.
  • Can manage the Project Team (Invite/Assign).
  • Can edit project metadata, definitions, phase structure, and tasks.
  • Can manage the UAT test suite (Add Categories/Steps).

Implementation (Supabase RLS)

  • Projects: Visible if a record exists in project_members for the auth.uid().
  • Phases/Tasks: Inheritance-linked. Visible if the user is a member of the parent project.
  • UATs: Visible to the creator OR project members.

3. Key Feature Specifications

Project Management

  • High-Density Work Orders: Project detail pages use a corporate blue (#1e3a8a) layout.
  • Phase & Task Kanban: Work is organized into Phases (Sprints) containing Tasks (Stories).
  • Task Detail Pages: Deep-linking to /projects/[id]/tasks/[taskId] provides dual-pane editing with:
  • Acceptance Criteria: Rich text requirements.
  • Build Details: Rich text Implementation tracking.
  • Assignment Controls: Restricted exclusively to members of the parent project.

User Acceptance Testing (UAT)

  • UAT Matrix: A grid-based execution engine that tracks statuses (Pass/Fail/Retest) across multiple testers.
  • Test Case Detail View: Rich text instructions and expected results tracked per step.
  • Issue Management: Testers can log issues directly from a failed test step.

Dashboards (Analytics Engine)

  • Pivotal Insight: Powered by react-pivottable and Plotly.
  • Multi-Dimension Slicing: Data is flattened from Projects -> Phases -> Tasks to allow slicing by:
  • Project Name
  • Workflow Status
  • Assigned User (Resource Tracking)
  • Client Account
  • Visualizations: Supports Bar Charts, Line Charts, and Heatmaps.

4. Technical Stack

  • Framework: Next.js (App Router, Turbopack).
  • Database: Supabase (PostgreSQL with RLS).
  • Styling: Vanilla CSS / High-density modular components.
  • Components: Lucide Icons, Custom Rich Text Editor (ExecCommand based).

5. Deployment & CI/CD

  • Environment: Vercel.
  • Type Safety: Strict TypeScript (Enabled noImplicitAny).
  • Build Reliability: Custom type declarations (types/pivottable.d.ts) bridge legacy JS libraries with the strict TS environment.

6. Database Architecture (Supabase / PostgreSQL)

Lexerian’s backend is powered by a relational PostgreSQL schema designed for high-integrity lifecycle tracking.

Core Entity Relationship Diagram (ERD) Overview

erDiagram
PROJECT ||--o{ PROJECT_MEMBER : "assigned to"
PROJECT ||--o{ PROJECT_PHASE : "contains"
PROJECT ||--o{ UAT : "contains"
PROJECT_PHASE ||--o{ PROJECT_TASK : "contains"
UAT ||--o{ CATEGORY : "grouped by"
CATEGORY ||--o{ TEST_CASE : "contains"
TEST_CASE ||--o{ TEST_RESULT : "executed by"
TEST_CASE ||--o{ ISSUE : "results in"

Table Dictionary

projects

The root container for all professional service work.

  • id: UUID (PK)
  • name: Title of the project.
  • description: Scope of work.
  • client_name: Name of the client account.
  • status: e.g., ‘active’, ‘completed’.
  • creator_id: Pointer to the user who initialized the project.

project_members

Controls access and roles within a project.

  • project_id: FK to projects.
  • user_id: FK to auth.users.
  • role: ‘owner’ (full management), ‘admin’ (limited management), ‘member’ (read/write content).

project_phases

Represents Sprints or defined milestones.

  • project_id: FK to projects.
  • name: e.g., ‘Phase 1: Discovery’.
  • status: ‘pending’, ‘active’, ‘completed’.
  • start_date / end_date: Temporal range for the phase.

project_tasks

The atomic unit of work.

  • phase_id: FK to project_phases.
  • name: Task title.
  • assigned_to: FK to auth.users (must be a project member).
  • status: ‘ASSIGNED’, ‘IN PROGRESS’, ‘COMPLETED’.
  • acceptance_criteria: Rich text requirements.
  • build_details: Rich text technical documentation.

uats

The testing engine container.

  • project_id: FK to projects.
  • title: Name of the test suite.
  • status: Overall testing status.

test_cases

Individual steps within a UAT.

  • uat_id: FK to uats.
  • title: Step title.
  • description: Functional overview.
  • instructions: Rich text steps for the tester.
  • expected_result: The “Success” criteria.
  • setup_notes: Environment configuration requirements.

test_results

Tracking matrix for user feedback.

  • test_case_id: FK to test_cases.
  • user_id: The tester.
  • status: ‘PASS’, ‘FAIL’, ‘NOT STARTED’.
  • feedback: Qualitative notes from testing.

profiles

Extended user identity.

  • id: UUID (matches auth.users.id).
  • full_name: Human readable display name.
  • email: Primary contact.
  • avatar_url: Profile image path.