b1tranger/b1t-acad

1. Repository type and deployment boundary

- This is a static, client-side university resources portal built with vanilla HTML, CSS, and JavaScript.

- There is no application backend in the repo; all navigation, filtering, search, theming, and content presentation happen in the browser.

- The site is intended for Netlify hosting and includes PWA assets (manifest.json, sw.js, js/pwa.js).

2. Primary entry points and page structure

- The top-level HTML pages define the main information architecture: index.html, Departments.html, References.html, FAQ/…, submission.html, and multiple pages under misc/.

- These pages act as feature islands rather than one monolithic app, with shared scripts and styles reused across them.

- md-viewer.html suggests a lightweight markdown rendering page for documentation or content pages.

3. Core content domains

- The site is organized around a few major student-resource sections:

- Course / QBank browser

- Department + semester navigation

- References / curated external resources

- FAQ and notices

- Student contribution/submission workflows

- The misc/ folder contains broader content hubs such as notice.html, student.html, tutorial.html, campus.html, and university_projects.html.

4. Resource discovery and search flow

- js/search-courses.js powers course lookup, likely by title, acronym, or course code as described in the README.

- js/qbank-browser.js appears to be the main browsing layer for question-bank collections.

- Results are not stored in a database; they likely resolve to prebuilt links or static folder targets in Google Drive / cloud storage.

5. Department and semester subsystem

- Departments.html is supported by js/departments.js and js/departments-data.js.

- The architecture here is data-driven: department metadata is kept in a JS data file, then filtered/rendered by client-side logic.

- Semester selection is a dedicated concern, with js/academic-calendar.js and archived notes indicating URL query handling and semester selector behavior.

- The system’s boundary is important: department pages are assembled in-browser from static metadata, not fetched from an API.

6. Reference and external-link subsystem

- References.html and several js/Links/drop-link-*.js modules suggest a structured, menu-based catalog of outbound resources.

- This section likely acts as a curated directory rather than hosted content.

- External targets include drives, books, guides, and resource collections; the repo mostly provides navigation and classification, not the assets themselves.

7. Contribution and submission flow

- submission.html and related docs under agentic-note/doc_submission/ indicate a contribution path for notes/questions/resources.

- js/anon-share.js suggests some kind of anonymous sharing or submission integration.

- From an architecture standpoint, this is the main “ingress” boundary where user-generated content enters the ecosystem, likely through forms linked to external services rather than a custom server.

8. Theming and UI shell

- js/theme.js plus global styles in style.css and section styles in css/*.css provide the visual system.

- The site supports dark mode by default and a gray/light mode, so theme state is a cross-cutting browser concern.

- Shared layout pieces like css/top.navbar.css, css/menu.css, and css/preloader.css indicate a reusable chrome across pages.

9. PWA and offline-ish capabilities

- manifest.json, sw.js, and js/pwa.js show that the site is packaged as a progressive web app.

- This means the architecture includes a lightweight offline/cache layer, but still centered on static delivery.

- There is also an archived older PWA implementation under archive-old-design-1/OLD FILES/PWA/, showing the feature evolved over time.

10. Content assets and media

- Static assets live under images/ and doc/, including a PDF academic calendar and course-list imagery.

- The repo relies on prebuilt media for presentation and documentation rather than runtime-generated assets.

- This keeps the runtime simple: browser loads HTML/CSS/JS plus local images/docs.

11. Legacy/archived design boundary

- archive-old-design-1/ and archive-old-design-2/ preserve previous site generations, scripts, and semester/course pages.

- These folders are not the primary runtime surface; they are historical reference and backup architecture.

- For a diagram, treat them as a separate archive zone, not part of the active request path.

12. Documentation and operational notes

- README.md, doc/DOCUMENTATION.md, and the extensive agentic-note/ directory provide project history, implementation plans, and change logs.

- agentic-note/ is clearly meta-documentation for maintainers, not end-user runtime content.

- The documentation reinforces that this is a student-maintained resource archive, with evolving content organization rather than a service-oriented backend architecture.