jdbr0505/immujel

1. Overall shape

- This is a static Progressive Web App front end, deployed on Vercel and GitHub Pages.

- The repository is organized by feature/page folders rather than by a server-side app framework.

2. Client-side app shell

- index.html, styles.css, animations.js, auth.js, and js/ui.js appear to provide the shared shell, global styling, animations, and common UI/auth behavior used across the site.

- 404.html, offline.html, manifest.json, sw.js, and js/sw-register.js support PWA behavior and graceful fallback when the app is unavailable.

3. Page-level feature boundaries

- NavBar's/ contains content pages such as FL.html, Programas.html, Sobre Nosotras.html, noticiero.html, publicacion.html, and semanario.html.

- These are separate static routes/pages, likely linked through a shared navigation experience rather than a router in a SPA framework.

4. Authentication subsystem

- The Login/ folder is a self-contained auth area with login.html/js, signup.html/js, update-password.html/js, and supporting styles.

- Login/Login_supabase.js suggests the auth flows are backed by Supabase Auth.

- email-confirmacion.html is part of the email verification / recovery flow.

5. Admin and content management

- Admin/Admin.html, Admin.js, and Admin_cms.js define an administrative interface.

- This likely acts as a lightweight CMS or moderation console for managing site content, users, or submissions, separated from public pages.

6. Forms and user submissions

- Forms/form.html, form.js, and form_styles.css represent a distinct submission workflow.

- Based on the presence of Supabase SQL and notification automation, form submissions likely persist to Supabase and may trigger downstream notifications.

7. Backend platform boundary: Supabase

- The supabase/ directory and Supabase SQL/ scripts show that Supabase is the main backend service.

- The project relies on Supabase for auth, database, storage, row-level security, triggers, and notifications.

8. Database and security provisioning

- Supabase SQL/TODO_EN_UNO.sql, alter_storage_rls.sql, and trigger-fix scripts indicate schema setup and maintenance are handled as SQL migrations/scripts.

- setup_notificaciones.sql and setup_push_subscriptions.sql point to notification tables, subscription tracking, and push-related persistence.

9. Server-side automation

- supabase/functions/send-notification/index.ts is a Supabase Edge Function.

- This is the main server-side executable in the repo and is likely invoked by database events or client calls to send notifications.

10. PWA and offline distribution

- manifest.json, sw.js, and offline.html define the installable/offline experience.

- js/sw-register.js registers the service worker, making the site usable as an app-like experience on mobile and desktop.

11. Content, assets, and static hosting

- Images/ holds the visual asset pool used across pages.

- sitemap.xml supports search indexing, while IMMUJEL.xml is an additional XML asset used for site data or metadata.

12. Deployment topology

- The app is hosted as static files on Vercel and GitHub Pages.

- Runtime behavior beyond the browser is limited mainly to Supabase services: auth, database/storage, and edge functions.

13. High-level data flow

- User interacts with public pages or forms in the browser.

- Auth and data operations go to Supabase.

- Database rules/triggers and the send-notification function handle automated side effects.

- The service worker caches assets and serves offline.html when network access is unavailable.

14. Architecture summary for a diagram

- Draw this as a browser-first static PWA with separate page modules for public content, login, forms, and admin.

- Put Supabase outside the app boundary as the backend platform, with SQL-managed schema/security and one edge function for notifications.

- Add service worker/offline cache as a client-side infrastructure layer, and show deployment via Vercel/GitHub Pages.