Update packages to address GHSA-9qr9-h5gf-34mp

.github/prompts/audit-docs.md

@@ -0,0 +1,65 @@
+---
+title: 'Audit and Update docs/ Directory'
+scope: 'repo'
+targets:
+    - 'docs/'
+    - 'codebase'
+labels:
+    - 'documentation'
+    - 'audit'
+    - 'mermaid'
+---
+
+Purpose:
+While reviewing the #activePullRequest, analyze the entire #codebase and ensure
+that the #file:docs directory is fully up to date, consistent, and accurate based
+on the current implementation.
+
+What to do:
+
+1. Audit the `docs/` directory against the real codebase
+    - Identify documentation gaps, inaccuracies, outdated explanations, or missing sections.
+    - Cross-check code comments, architecture, directory structure, core modules, exposed APIs, utilities, and workflows.
+
+2. Update documentation as necessary
+    - Revise outdated sections.
+    - Add missing content.
+    - Rewrite unclear explanations.
+    - Add short code snippets where they meaningfully clarify how something works.
+
+3. Use visual diagrams as frequently as appropriate
+    - Prefer Mermaid diagrams to explain architecture, flows, relationships, state transitions, data movement, or component interactions.
+    - Choose diagram types that best communicate the system (e.g., `flowchart`, `sequenceDiagram`, `classDiagram`, `stateDiagram`, `gitGraph`).
+    - When explaining logic, system or architecture, include Mermaid diagrams when applicable.
+
+4. Ensure architectural accuracy
+    - Validate that the documented behavior matches real code.
+    - If implementation diverges from existing docs, update docs to match real behavior.
+
+5. Maintain a concise, structured writing style
+    - Keep explanations clear and self–contained.
+    - Avoid unnecessary verbosity.
+    - Highlight important behaviors or assumptions explicitly.
+
+6. Make changes directly
+    - Modify documentation files.
+    - Add new files if needed.
+    - Update diagrams.
+    - Include only meaningful and defensible changes; do not generate placeholder text.
+
+Goal:
+Produce a clean, accurate, comprehensively updated `docs/` directory that fully
+reflects the current implementation, backed by diagrams and practical examples.
+
+Acceptance checklist (use as review checklist):
+
+- [ ] Audit `docs/` for correctness against actual code
+- [ ] Fix or update inaccurate/outdated pages
+- [ ] Add missing sections or examples
+- [ ] Add Mermaid diagrams where helpful
+- [ ] Ensure examples are runnable/accurate
+- [ ] Run repository `validate` (format, lint and testing) are passing and fix markdown lint issues. For example #file:package.json `npm run validate`
+
+Notes:
+
+- Prefer concrete changes only; avoid adding placeholders or speculative content.

docs/architecture/components/index.md

@@ -25,11 +25,11 @@ flowchart TD
 
 ## 🔍 Component Details
 
-- **Navbar:** Top navigation bar, links to sections. Handles navigation, accessibility, and analytics logging.
+- **Navbar:** Top navigation bar, links to sections. Handles navigation, accessibility, and logs analytics via `logAnalyticsEvent`.
 - **Banner:** Header section, may include avatar and intro. Displays profile and branding.
-- **ProjectsGrid:** Displays project cards in a grid. Handles filtering, analytics, and responsive layout.
-- **Publications:** Lists publications with metadata. Supports links to external resources.
-- **Footer:** Social media links and copyright. Includes contact and resume links.
+- **ProjectsGrid:** Displays project cards in a grid. Located at `src/components/projects/ProjectsGrid.tsx`. Handles filtering, analytics (uses `logAnalyticsEvent`), and responsive layout.
+- **Publications:** Lists publications with metadata. Located at `src/components/publications/Publications.tsx`. Supports external links and logs analytics on interactions.
+- **Footer:** Social media links and copyright. Located at `src/components/footer/Footer.tsx`. Includes contact and resume links and logs analytics.
 - **CookieSnackbar:** Shows cookie consent. Manages cookie state and user interaction.
 - **StarsBackground:** Visual background effect. Renders animated stars for visual appeal.
 

docs/architecture/components/projects.md

@@ -10,9 +10,10 @@ The projects grid is displayed using the `ProjectsGrid` component located in [Pr
 
 ### Key Elements
 
-- **State Management:** Uses React `useState` to toggle featured/all projects.
-- **Grid Layout:** Responsive grid via MUI Grid/Stack.
-- **Project Cards:** Thumbnail, name, title, employer, resource links.
+- **State Management:** Uses React `useState` and local component state to manage view toggles and UI interactions.
+- **Grid Layout:** Responsive grid via MUI `Grid`/`Stack` and CSS-in-JS styles.
+- **Project Cards:** Thumbnail, name, title, employer, resource links. The component imports the project data from `src/data/projects.ts`.
+- **Analytics:** The component calls `logAnalyticsEvent` for user interactions (e.g., clicking a project link or viewing details).
 
 ### Flowchart
 
@@ -79,9 +80,9 @@ flowchart LR
 
 ### Adding Thumbnail Images
 
-To add a thumbnail image for the new project, place the image in the appropriate directory:
+To add a thumbnail image for a new project, place the image in the appropriate directory:
 
-1. **Navigate to the images directory**: Go to the [public image projects directory](../../public/images/projects).
+1. **Navigate to the images directory**: Go to the `public/images/projects` directory.
 2. **Create a new directory**: Create a new directory with the project ID (e.g., `new-project`).
 3. **Add the thumbnail image**: Place the thumbnail image in the new directory and name it `thumbnail.webp`. Recommended to use `.webp` format for better performance.
 

docs/architecture/components/publications.md

@@ -11,8 +11,8 @@ The publications list is displayed using the `Publications` component located in
 ### Key Elements
 
 - **Styling**: The component uses inline styles to manage the appearance of publication metadata.
-- **List Layout**: The publications are displayed in a responsive list layout using Material-UI's Stack and Typography components.
-- **Publication Cards**: Each publication is displayed as a card with a title, authors, metadata, and an abstract.
+  -- **List Layout**: The publications are displayed in a responsive list layout using Material-UI's `Stack` and `Typography` components.
+  -- **Publication Cards**: Each publication is displayed as a card with a title, authors, metadata, and an abstract. Data is imported from `src/data/publications.ts` and the component logs user interactions via `logAnalyticsEvent`.
 
 ### Flowchart
 
@@ -29,7 +29,7 @@ flowchart LR
 
 ## Adding New Publications
 
-To add new publications, you need to update the `publications` array in [publications.ts](../../src/data/publications.ts).
+To add new publications, update the `publications` array in `src/data/publications.ts`.
 
 ### Steps to Add a New Publication
 

docs/architecture/components/socials.md

@@ -27,7 +27,7 @@ flowchart LR
 
 ## Adding New Social Media Links
 
-To add new social media links, you need to update the `socials` array in [socials.ts](../../src/data/socials.ts).
+To add new social media links, update the `socials` array in `src/data/socials.ts`.
 
 ### Steps to Add a New Social Media Link
 

docs/architecture/configs.md

@@ -19,14 +19,22 @@ Configs manage environment variables, service integrations, and global settings
 
 ## 🔍 Usage Examples
 
-### Importing Firebase Config
+### Firebase configuration and usage
+
+The runtime `src/configs/firebase.ts` exposes two named functions you should use from the app:
 
 ```ts
-import firebaseConfig from '@configs/firebase';
+import { init, logAnalyticsEvent } from '@configs/firebase';
+
+// Initialize Firebase (call once on app start)
+init();
 
-// Initialize Firebase app
+// Log analytics events anywhere in the app
+logAnalyticsEvent('my_event', { foo: 'bar' });
 ```
 
+There is no default export in the implementation — use the named exports above.
+
 ### Using Environment Variables
 
 ```ts
@@ -35,6 +43,8 @@ const apiKey = process.env.NEXT_PUBLIC_API_KEY;
 
 ### Sentry Configuration
 
+Sentry is configured via the repository's `sentry.*.config.ts` files. Use Sentry's Next.js SDK initialization patterns in those files; the app uses the standard `@sentry/nextjs` entrypoints. Example usage in application code:
+
 ```ts
 import * as Sentry from '@sentry/nextjs';
 

docs/architecture/pwa.md

@@ -39,58 +39,43 @@ flowchart TD
 
 ### Manifest Generation (`src/app/manifest.ts`)
 
-Instead of a static `manifest.json`, we use a TypeScript file to generate the manifest dynamically. This allows for type safety and easier maintenance.
+The app exports a `MetadataRoute.Manifest` from `src/app/manifest.ts`. Next.js will expose this manifest to the browser as `/manifest.webmanifest` when the app is built and served. Using a TypeScript manifest lets you keep manifest values close to application code and use type safety.
 
-```typescript
-// src/app/manifest.ts
+Example usage (the app's implementation returns a full `MetadataRoute.Manifest` object and the root layout references the manifest at `'/manifest.webmanifest'`):
+
+```ts
+// src/app/manifest.ts (exports a Next.js manifest)
 import type { MetadataRoute } from 'next';
 
 export default function manifest(): MetadataRoute.Manifest {
 	return {
 		name: "Alexander Sullivan's Portfolio",
 		short_name: "Alexander Sullivan's Portfolio",
-		// ... other properties
 		icons: [
-			{
-				src: '/icon/android-chrome-192x192.png',
-				sizes: '192x192',
-				type: 'image/png',
-			},
-			// ... other icons
+			{ src: '/icon/android-chrome-192x192.png', sizes: '192x192', type: 'image/png' },
+			// ...
 		],
+		// ...other fields
 	};
 }
 ```
 
 ### Service Worker Lifecycle
 
-While `next-pwa` previously handled service worker generation, native Next.js apps can use manual service worker registration or rely on standard browser caching headers.
+This project includes a manual service worker implementation at `public/sw.js` and registers it from the client. The app registers the service worker in two places:
 
-```mermaid
-sequenceDiagram
-    participant User
-    participant Browser
-    participant Network
-    participant Cache
-
-    User->>Browser: Visits Site
-    Browser->>Network: Request Resources
-    Network-->>Browser: Return Resources
-    Browser->>Cache: Cache Static Assets (via Headers)
-
-    opt Offline Mode
-        User->>Browser: Visits Site (Offline)
-        Browser->>Cache: Check Cache
-        Cache-->>Browser: Return Cached Assets
-    end
-```
+- `src/components/ServiceWorkerRegister.tsx` — a small client component that calls `navigator.serviceWorker.register('/sw.js')` inside a `useEffect`.
+- `src/app/page.tsx` — the home page also calls `navigator.serviceWorker.register('/sw.js')` during its initial `useEffect` (this is a defensive duplicate to ensure registration on client navigations).
+
+The service worker uses a cache-first / stale-while-revalidate strategy for static assets and network-first for navigation requests. See `public/sw.js` for the exact implementation.
 
 ## Customization
 
 To modify PWA settings:
 
-1. **Manifest**: Edit `src/app/manifest.ts` to change app name, colors, or icons.
+1. **Manifest**: Edit `src/app/manifest.ts` to change app name, colors, or icons. The root layout uses `manifest: '/manifest.webmanifest'` so changes will propagate at runtime.
 2. **Icons**: Add or replace images in `public/icon/` and update the manifest accordingly.
+3. **Service Worker**: Edit `public/sw.js` to customize caching strategies or precached assets.
 
 ## Related Docs
 

docs/architecture/service-worker.md

@@ -0,0 +1,43 @@
+# Service Worker Implementation
+
+This file documents the service worker implementation used by the site.
+
+## Where it lives
+
+- Service worker file: `public/sw.js`
+- Registration client: `src/components/ServiceWorkerRegister.tsx`
+- Root layout also renders `ServiceWorkerRegister` in `src/app/layout.tsx`.
+
+## Behavior summary
+
+- The service worker precaches a small set of core assets (`/`, `/manifest.webmanifest`, `/icon/favicon.ico`).
+- Navigation requests (HTML) use a **network-first** strategy with a cache fallback.
+- Static assets use a **cache-first** with background stale-while-revalidate update flow.
+- The worker skips cross-origin requests, Next.js dev paths (`/_next/`) and API calls.
+
+## How the app registers the service worker
+
+The app registers the SW from a client component that runs inside the browser:
+
+```tsx
+import { useEffect } from 'react';
+
+export default function ServiceWorkerRegister() {
+	useEffect(() => {
+		if ('serviceWorker' in navigator) {
+			navigator.serviceWorker
+				.register('/sw.js')
+				.then((reg) => console.log('Service Worker registered with scope', reg.scope))
+				.catch((err) => console.error('Service Worker registration failed:', err));
+		}
+	}, []);
+
+	return null;
+}
+```
+
+The home page (`src/app/page.tsx`) also attempts to register the same `'/sw.js'` as a defensive measure for client navigations.
+
+## Customizing caching
+
+Edit `public/sw.js` to change `PRECACHE_URLS`, cache names, or strategy. Keep the SW path at `/sw.js` to match the registration call.

docs/usage/setup.md

@@ -39,11 +39,16 @@ This guide walks you through installing, configuring, and running the AlexJSully
 
 ## ⚙️ Configuration
 
-- **Environment Variables:**
-    - See `.env.example` (if present) for required variables.
-    - Configure Firebase, Sentry, and other integrations as needed.
+- **Environment Variables (common keys):**
+    - `NEXT_PUBLIC_FIREBASE_API_KEY`
+    - `NEXT_PUBLIC_FIREBASE_ID`
+    - `NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID`
+    - `NEXT_PUBLIC_FIREBASE_APP_ID`
+    - `NEXT_PUBLIC_FIREBASE_MEASUREMENT_ID`
+    - `NEXT_PUBLIC_SENTRY_DSN` (if Sentry is used in your environment)
+      Place these keys in a local `.env` file during development. Do not commit `.env` to git.
 - **Path Aliases:**
-    - Use TypeScript aliases (see `tsconfig.json`).
+    - Use TypeScript aliases (see `tsconfig.json`). The project exposes aliases like `@components`, `@data`, `@configs`, `@helpers`, and `@images` for cleaner imports.
 
 ## 🧪 Testing & Validation