some new more file were added

Author: shadil-rayyan

.github/workflows/ci.yml

@@ -0,0 +1,29 @@
+name: ci 
+on:
+  push:
+    branches:
+      - master 
+      - main
+permissions:
+  contents: write
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Configure Git Credentials
+        run: |
+          git config user.name github-actions[bot]
+          git config user.email 41898282+github-actions[bot]@users.noreply.github.com
+      - uses: actions/setup-python@v5
+        with:
+          python-version: 3.x
+      - run: echo "cache_id=$(date --utc '+%V')" >> $GITHUB_ENV 
+      - uses: actions/cache@v4
+        with:
+          key: mkdocs-material-${{ env.cache_id }}
+          path: ~/.cache 
+          restore-keys: |
+            mkdocs-material-
+      - run: pip install mkdocs-material 
+      - run: mkdocs gh-deploy --force

.gitignore

@@ -0,0 +1,48 @@
+# MkDocs build output
+site/
+
+# MkDocs cache
+.mkdocs_cache/
+
+# Python bytecode
+__pycache__/
+*.py[cod]
+*$py.class
+
+# Virtual environments
+.venv/
+venv/
+ENV/
+env/
+
+# Python packaging
+build/
+dist/
+*.egg-info/
+.eggs/
+
+# Pip
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Pytest / coverage
+.pytest_cache/
+.coverage
+.coverage.*
+htmlcov/
+
+# IDEs & editors
+.vscode/
+.idea/
+*.swp
+*.swo
+
+# OS files
+.DS_Store
+Thumbs.db
+
+# Logs
+*.log
+
+# Jupyter (if used)
+.ipynb_checkpoints/

docs/architecture/0verview.md

@@ -0,0 +1,50 @@
+
+
+## Architecture Overview
+
+This repository may appear to follow a microservices architecture; however, this was **not the original design objective**.
+
+Each service was developed **independently and at different times**, with the intention of being **hosted and operated individually**. The current repository functions as a **central hub (Gecian Hub)** that brings these services together.
+
+Gecian Hub primarily serves as a **showcase, collaboration, and discovery layer**, while adjacent or related services maintain their **own value, specialization, and autonomy**.
+
+## Repository Structure
+
+* The repository aggregates multiple **independently developed services**.
+* These services are **loosely coupled** and designed to function independently.
+* Gecian Hub acts as a **coordinator and interface**, not as a monolithic application.
+* For **future maintenance and security purposes**, the frontend of individual services may be integrated into the Gecian Hub, while their backends can be migrated or connected to the Gecian backend **without merging everything into a single system**.
+  This separation is intentional and exists to support **tighter security controls and better isolation**.
+
+## Backend & Frontend Architecture
+
+* Both the **frontend and backend are implemented using Next.js**.
+* Server-side functionality is handled through **Next.js API routes and server components**, where appropriate.
+* The system follows a **minimal data policy**:
+  **only data strictly required for functionality is collected and processed**.
+
+⚠️ **Important**
+The collection or storage of unnecessary user or system data is strictly prohibited. Any violation may result in **security, compliance, or operational issues**.
+
+## Storage Strategy
+
+* **Indexed storage** is used wherever possible to optimize read and write performance.
+* The architecture is designed to operate within **free-tier hosting limitations**.
+* Storage usage and access patterns are carefully planned to **avoid hitting platform-imposed limits**.
+
+## Performance & Cost Optimization
+
+* Client-side load is kept **as low as possible**.
+* Heavy computation is avoided on the client whenever feasible.
+* **Selective caching** is applied across both frontend and backend layers to reduce redundant requests and improve performance.
+* Network calls are minimized, and shared resources are reused where appropriate.
+
+## Key Design Principles
+
+* Modular and loosely coupled services
+* Cost-efficient and **free-tier friendly** architecture
+* Minimal client payload
+* Indexed and optimized storage
+* Selective and intentional caching
+* **Privacy-first and security-conscious** data handling
+

docs/architecture/technology.md

@@ -0,0 +1,207 @@
+Below is a **clean, corrected, and professional version** of your document with the **Analytics** and **Security tooling (Snyk + Dependabot)** sections properly added.
+I’ve kept the tone suitable for **2025, a student-driven volunteer project**, and something you can confidently include in **reports, approvals, and resumes**.
+
+---
+
+# 🧱 Technology Stack & Rationale
+
+This document outlines the technologies used in the project and the reasoning behind each choice. The stack is intentionally selected to be **simple, cost-effective, secure, and suitable for a student-driven, volunteer-based team in 2025**.
+
+---
+
+## Frontend & Backend
+
+### Next.js (Frontend & Backend)
+
+Both the **frontend and backend are built using Next.js**.
+
+**Reasons for choosing Next.js:**
+
+* Simpler development model compared to managing React separately with additional backend frameworks
+* Built-in support for **SEO, Server-Side Rendering (SSR), and fast initial load times**
+* Widely known and adopted by students and developers in **2025**
+* Strong ecosystem with extensive **npm package** support
+* Unified framework reduces architectural complexity and onboarding time
+
+Using Next.js for both frontend and backend allows the team to maintain a **single, consistent technology stack**, which is critical for long-term maintainability in a volunteer project.
+
+---
+
+## Authentication & Security
+
+### Firebase Authentication
+
+Authentication is handled using **Firebase Authentication**.
+
+**Reasons for choosing Firebase Auth:**
+
+* Free to use within the project’s scope
+* Authentication and security infrastructure is managed by **Google**
+* Supports multiple authentication methods and additional security factors
+* Eliminates the need to implement and maintain custom authentication logic
+* Reduces risks related to **student and user data leakage**, which would be a serious concern
+
+Firebase may also be used for limited storage or related services when appropriate.
+
+---
+
+## Database
+
+### Neon (PostgreSQL)
+
+The project uses **Neon** as the PostgreSQL database provider.
+
+**Reasons for choosing Neon:**
+
+* Generous **free-tier offering**
+* Fully managed PostgreSQL with modern scaling capabilities
+* Cost-effective for student projects
+* Seamless integration with Next.js and modern JavaScript stacks
+
+This choice aligns with the project’s goal of remaining **free-tier friendly while production-ready**.
+
+---
+
+## Hosting & Deployment
+
+### Netlify
+
+The application is hosted on **Netlify**.
+
+**Hosting decision background:**
+
+* Initially explored **Cloudflare Workers (Node.js runtime)**
+
+  * Dropped due to limitations in full Node.js environment support
+
+* Netlify was selected because:
+
+  * Native integration with **GitHub organizations**
+  * No requirement to fork repositories into personal accounts
+  * Simplified CI/CD and deployment workflows
+
+While platforms like Vercel are popular, **Netlify better fits the team structure, access control needs, and workflow constraints** of this project.
+
+---
+
+## Testing Strategy
+
+### End-to-End (E2E) Testing
+
+**Playwright** is recommended for E2E testing.
+
+**Reasons for choosing Playwright:**
+
+* Supports modern browser automation
+* Can generate automation scripts from recorded user interactions
+* Lighter and easier to configure than Selenium
+* Suitable for both functional and UI testing
+
+**Alternatives considered:**
+
+* **Selenium** – Industry standard, but heavy and complex
+* **Cypress** – Good option, but setup and configuration can be more opinionated
+
+---
+
+### Unit & Component Testing
+
+* **Jest**
+* **React Testing Library**
+
+These tools are recommended for unit and component testing. Adoption may increase as team familiarity grows.
+
+---
+
+## CI / CD
+
+### GitHub Actions
+
+CI/CD is implemented using **GitHub Actions**.
+
+**Reasons for choosing GitHub Actions:**
+
+* Native integration with GitHub repositories
+* Centralized automation within the GitHub ecosystem
+* Matches the current skill level of the team
+* Simplifies automation for:
+
+  * Builds
+  * Tests
+  * Security checks
+  * Deployments
+
+---
+
+## Analytics & Monitoring
+
+### Google Analytics
+
+The project integrates **Google Analytics** for usage and traffic analytics.
+
+**Reasons for choosing Google Analytics:**
+
+* Free and industry-standard analytics platform
+* Provides **real-world usage data** (active users, sessions, engagement)
+* Enables contributors to truthfully state analytics-related experience on their resumes
+* Helps the team make **data-driven decisions** instead of assumptions
+
+Having real production analytics allows contributors to present their experience in a **measurable and verifiable format** (e.g., *“Managed analytics for a production PWA with X monthly users”*).
+
+---
+
+## Security Tooling
+
+### Dependency & Vulnerability Management
+
+To maintain security without heavy operational overhead, the project integrates:
+
+#### **Dependabot**
+
+* Automated dependency updates
+* Pull requests for vulnerable packages
+* Native GitHub integration
+* Helps keep dependencies up-to-date with minimal manual effort
+
+#### **Snyk**
+
+* Scans for vulnerabilities in:
+
+  * npm dependencies
+  * Application code
+* Provides clear remediation guidance
+* Acts as an additional security layer beyond Dependabot
+
+These tools help ensure that **security issues are identified early**, which is critical for a publicly accessible student platform.
+
+---
+
+## Project Management & Collaboration
+
+### GitHub-Native Tooling
+
+The project relies entirely on **GitHub’s ecosystem**:
+
+* **GitHub Issues** – Bug tracking and task management
+* **GitHub Discussions** – Design discussions and community interaction
+* **GitHub Projects** – Planning, roadmaps, and task boards
+
+**Why not Slack, Jira, etc.?**
+
+* This is a **college project with volunteer contributors**
+* External tools introduce unnecessary complexity
+* Such tools require high discipline and constant engagement
+* GitHub provides sufficient functionality while keeping everything centralized
+
+---
+
+## Guiding Principles Behind Technology Choices
+
+* Free-tier friendly
+* Simple onboarding for new student contributors
+* Secure by default
+* Minimal operational overhead
+* Fully GitHub-integrated workflow
+* Practical and sustainable for a volunteer-driven academic project
+
+---

docs/first-year.md

@@ -0,0 +1,37 @@
+
+
+## First-Year Student Onboarding Plan
+
+### 1. During Admission Time
+
+* When **first-year students arrive for admission**, our team or volunteers can be present at the **entrance**.
+* Politely inform them:
+
+  * If they want to know more about the college website and services
+  * They can **visit the website**
+  * They can also **install it as an app**
+* Keep the explanation **short and friendly**.
+
+---
+
+### 2. After Admissions Are Completed
+
+* During the **first or second week**, conduct an **orientation session**:
+
+  * **Offline class** (preferred, if possible)
+  * **Online class** if offline is not possible
+* In this session:
+
+  * Explain the **entire app**
+  * Show how to **use key features**
+  * Explain **how to install the app**
+
+---
+
+### 3. Target Audience
+
+* The **main focus should be first-year students**.
+* Most features of the app are **especially useful for first years**, so they should be the **priority audience**.
+
+
+if we repeat this for 4 year by then we may get above 1000 user 

docs/goals.md

@@ -0,0 +1,3 @@
+
+**Goal:**
+Get everyone to install the **Gecian Hub app** on their phone and **use it regularly**.