chore: update misc stuff (#296)

Author: cybercoder-naj

.env.template

@@ -18,6 +18,8 @@ PGCA=
 
 # For secret message
 DUCKDUCKGOOSE=
+
+# For API Requests
 NUXT_PUBLIC_API_BASE_URL=
 
 # For Discord OAuth API
@@ -45,6 +47,5 @@ NODEMAILER_PASS=
 # For Discord Webhook Integration
 DISCORD_ANNOUNCEMENT_WEBHOOK=
 
-
 # For Con4 API
 CON4_API_KEY=

CONTRIBUTING.md

@@ -1,13 +1,3 @@
-# Contributing to Logestic
+# Contributing to IC Hack '25
 
-## Reporting Issues
-
-😥 Use the Issues tab to write what is wrong/required in the project.
-
-## Solving Issues
-
-1. ❗ All PRs must reference an issue.
-2. 🗣 If there is an issue you want to work on, ask on the issue thread if you want to work on it.
-3. 🍴 Fork this repository and create a new branch `pr-[number]/[short description]` according to the issue.
-4. ✍ Fix the issue.
-5. 🎆 Open a PR and wait until a moderator merges it in.
+You'll know what you have to do.

README.md

@@ -37,15 +37,6 @@ This is the first time IC Hack tech systems will have extensive documentation. E
 
 ## Development rules
 
-### Working on issues
-
-We use ClickUp to keep track of the progress of the project. To pick up an issue:
-
-1. Assign yourself in any card from the "Backlog". This should automatically put your card under "Pending".
-1. Alternatively, create an issue and add yourself as the asignee and place it in the "Pending" list.
-1. Then [create a branch](#creating-a-branch) and [open a draft pr](#creating-a-pr).
-1. Once the PR is approved and merged, move the card to "Completed".
-
 ### Creating a branch
 
 No person can directly on the main branch. Hence you need to create a new branch to introduce any changes to the codebase.
@@ -58,18 +49,9 @@ No person can directly on the main branch. Hence you need to create a new branch
 You should create a PR **as soon as** you create a branch.
 
 1. If the PR is not ready, create a _Draft_ PR. This is so that others know what is being worked on and can provide some feedback before you are knee deep into the feature.
-1. The actual commit messages within your PR **does not follow** any conventional naming pattern. However, your PR title must follow `type: description` format, similar to your branch name.
+1. The actual commit messages within your PR **does not follow** any conventional naming pattern. However, your PR title must follow `type(scope): description` format, similar to your branch name.
 1. If any of the repo admins approve your PR and you need to need to update your branch, consider rebase to avoid making another commit for the admins to review again.
 
-#### PR <> ClickUp Integration
-
-1. When you create a comment, in the description include the following text: `Link CU-86bzr6uwe`, you will find your taskId in the ClickUp Card you are working.
-1. You can use special commit messages to change the status of your card. E.g. a commit message can be, `updated the readme #86bzr6uwe[in review]`.
-   1. Use `#<taskId>[in progress]` to move your card into "In Progress".
-   1. Use `#<taskId>[in review]` to move your card into "In Review".
-   1. Use `#<taskId>[blocked]` to move your card into "Blocked".
-1. When merging, your commit description should include `#<taskId>[completed]` to move your card into "Completed".
-
 ## Our Team
 
 ### IC Hack '25
@@ -83,6 +65,13 @@ You should create a PR **as soon as** you create a branch.
 
 - [@Harini-Sritharar](https://github.com/Harini-Sritharar)
 - [@JoshXL23 | Joshua Gonsalves](https://github.com/JoshXL23)
+- [@georgedecesare](https://github.com/georgedecesare)
+
+#### Additional Credits
+
+- [@Who23 | Aditya Shrivastava](https://github.com/Who23) for registration scripts and users admin page
+- [@Saim-Khan1](https://github.com/Saim-Khan1) for implementing "Add to Google/Apple wallet" feature
+- [@invisi-splat | Bowen Zhu](https://github.com/invisi-splat) for working on hackspaces code.
 
 ## License
 

docs/concepts/repository-pattern.md

@@ -0,0 +1,5 @@
+# Serverless Computing
+
+::: warning
+this page is yet to finish
+:::

docs/concepts/serverless-computing.md

@@ -1,5 +1,5 @@
 # Server Sent Events
 
-::: warn
-this page is yet to finish
+::: warning
+IC Hack '25 never got to using this.
 :::

docs/concepts/sse.md

@@ -1,5 +1,5 @@
 # Third Party Cookies
 
-::: warn
+::: warning
 this page is yet to finish
 :::

docs/concepts/third-party-cookies.md

@@ -5,6 +5,8 @@ authors:
   - George Decesare
 ---
 
+# Announcement
+
 The schema is quite simple. It is a table of announcements where each announcement has some information. The `pinUntil` field are those announcements which need to be scheduled at the top before the others **if and only if** the current datetime is before the datetime mentioned in `pinUntil`.
 
 | Field    | Type       | Description        |

docs/directory-structure/server/modules/announcement.md

@@ -3,7 +3,7 @@
 Every sub-directory inside the `server/` directory is considered a **module**. A module _in this project_ contains their routes and possibly a schema.
 These modules are _pluggable_ in the server code. In `src/app.ts`, you can import the module and route it with the `.route(url, app)` function by Hono.
 
-## Modules
+---
 
 These certain modules are considered `core` since they the bare bones of what makes IC Hack. There is no special folder these but it is logical to lay them flat because _technically, then can be installed/uninstalled at will_.
 

docs/directory-structure/server/modules/index.md

@@ -1,5 +1,9 @@
 # Routes
 
+::: warning
+Formatting required for this page. See the src markdown file for now.
+:::
+
 ## Announcements (/annoucement)
 
 GET /sse --> SSE to get all annoucements. "authenticated"

docs/directory-structure/server/routes.md

@@ -1,7 +1,7 @@
 # Subdomain Routing 
 
 ::: info
-This is now deprecated
+This was deprecated by [PR#163](https://github.com/icdocsoc/ichack/pull/163)
 :::
 
 The application runs in the Server-side rendering (SSR) mode. This means the HTML document is rendered on the server, and sent to the browser. The JavaScript files soon follow along and the JavaScript code then renders it again on the client side, giving the page the interactivity. 

docs/directory-structure/subdomain-routing.md

@@ -6,6 +6,10 @@ order: 3
 
 Copy the `.env.template` file to `.env.local` and `.env.test` and fill in the values with the correct information. Ask the admins for credentials for staging and prod environemnts. Read [Bun's docs](https://bun.sh/docs/runtime/env) to understand the naming convention and how to force using one env file.
 
+::: warning
+This page is not up to date
+:::
+
 ## Dev setup (`.env.local`)
 
 ```bash

docs/getting-started/environment-variables.md

@@ -1,5 +1,5 @@
 ---
-order: 5
+order: 6
 ---
 
 # MacOS Issue

docs/getting-started/macos-issue.md

@@ -0,0 +1,30 @@
+---
+order: 5
+---
+
+# Post Mortems
+
+This page is a retrospective of everything that went well and wrong with the project.
+
+## IC Hack '25
+
+Nishant had a vision of the website and it become true. Well, 90% true but it was a massive achievement by the entire tech team and additional contributors. The codebase has been built to last with well-thought out design choices, placement of code, directory structure, code hygiene etc. 
+
+> The project was incomplete but it worked like fully-functioning well-oiled machine.
+
+It was incomplete in the sense we were very time crunched that the last few commits leading upto the final deployment were shitty. But there were no tech problems at all. All raised issues during the event were human errors.
+1. The Admin UI doesn't work on mobile, the Team's UI doesn't work on Mobile. The Dashboard had problems with components overflowing and not enough time to debug it. 
+2. There was no live-updates from the server hence we had to use 5-10 second polling.
+3. We noticed a small issue where the main app would run out of memory and crash itself every 4 hours. This is a suspected memory leak in the application. An update in [Bun v1.2.2](https://bun.sh/blog/bun-v1.2.2#javascript-uses-10-30-less-memory-at-idle) suggests that there were memory issues in previous versions. This is still untested, so the exact source of the memory leak is not yet found. However, this periodic crash didn't effect any user. The system booted back up within minutes. 
+4. Some design choices were bad and some code hygiene started dropping a couple days before the event. There are plans to start refactoring them a few weeks before IC Hack'26 official development.
+
+The Postgres instance was running normally however it may be a good idea to look into daily database backups upto the event and N-hourly backups during the event. We hope that future builds of the repository does not have to grind until the last moment. This repo, as it stands today, is built and designed to last 
+
+Bun started to become a bit of a pain in the ass. It is promising with an extremely fast execution and build time with great in-built features. However, since it is still new and immature, random errors kept coming up; nothing too bad to stop development for a long time. There were some dependency issues with Nuxt and Bun; however that was simply Nishant's error, corrected in [PR#184](https://github.com/icdocsoc/ichack/pull/184)
+
+A couple of ideas we missed we:
+1. Make the profile scanning at registration increment a counter. There was no way of telling which user had entered our premises from the volunteer app. We had to use the `qr` table to check how many hackers are in the event - which is not accurate since hackers don't link their QR codes immediately.
+2. QR codes should contain a link instead of plain-text UUID. This way, hackers don't have to visit the website to scan their wristband (they are welcome to if needed). The volunteer app can simply extract the UUID from the url with the in-website camera to make the requests.
+3. A whitelist and blacklist tag for wristband UUIDs. This is not a big problem since we have a physical restraint on the scanning it (eg volunteers are instructed not to scan a qr code not on the person's wrist, or scan any picture, etc). It is never a bad idea to be extra safe.
+4. On the technical side of things, a table for meals/event check-ins/etc should be present. This table is a read access to hackers and exclusive write/read access to gods/admin/volunteers. Semantically, it makes sense to segregate this from the `profiles` table which is write/read access by the hackers.
+5. `POST /auth/create` is kind of a BS route. We never implemented this feature in the admin UI. A script to directly target the database is fine and less cumbersome.

docs/getting-started/post-mortems.md

@@ -10,14 +10,16 @@ The initial development started in **July 2024** with the Hono server. Minor ref
 
 ## Second Architecture
 
-Around **November 2024**, the codebase was completely refactored ([PR#54](https://github.com/icdocsoc/ichack/pull/54)) to support the serverless architecture of [Digital Ocean App Platform](../technologies/digital-ocean). The first architecture was a bit of a pain configuring the environment variables and on-boarding new users. This simplified the repository greatly and easier to deploy and manage.
+Around **November 2024**, the codebase was completely refactored ([PR#43](https://github.com/icdocsoc/ichack/pull/43)) to support the [serverless architecture](../concepts/serverless-computing) of [Digital Ocean App Platform](../technologies/digital-ocean). The first architecture was a bit of a pain configuring the environment variables and on-boarding new users. This simplified the repository greatly and easier to deploy and manage.
 
 As a result, we end up with the `website` application that is a single Nuxt4 application. This was connected to the Hono server with the `serverHandlers` property of `NuxtConfig`. The application smartly filtered pages and re-routed requests from `admin.ichack.org` and `my.ichack.org` accordingly from server middlewares and custom page routing defined in `apps/router.options.ts`.
 
 The other application was `landing` that existed as a layer. We leveraged the fact that a Nuxt layer can be a stand-alone application. This app was statically generated and the files were uploaded to [Cloudflare Pages](../technologies/cloudflare) via [GitHub Actions](../technologies/github-actions).
 
 `admin` and `my` remained as layers connected to the parent application for separation concerns. These layers extended `common` for the API requests they perform and `ui25` for the common UI components. As earlier, `admin` used [Nuxt UI v2](../technologies/nuxt-ui) and continued to do so.
 
+Soon, we realised we were building something great and massive. We renamed the repository from ichack25 to simply ichack ([PR#54](https://github.com/icdocsoc/ichack/pull/54)) for future years to build upon this for many years to come. :tada:
+
 ### Nuxt 3 --> Nuxt 4
 
 We decided to migrate the application to use Nuxt 4 instead. It was a bit of a migration to do so. This resulted a change in the Directory Structure.

docs/getting-started/project-timeline.md

@@ -8,7 +8,7 @@ order: 2
 
 This is not an exhaustive list.
 
-- [Bun](../tech-stack/bun) v1.1.18
+- [Bun](../tech-stack/bun) v1.1.44
 - Node v22.2.0
 - [Docker](../technologies/docker) v26.1.3
 - [PostreSQL](../tech-stack/postgresql) v16.3
@@ -30,7 +30,7 @@ Execute `bun install` in the route directory.
 
 ### Setup the Database
 
-1. If the schema has been updated and your local instance of postgres is not synced with it, you can reset this by executing `bun reset-db`.
+1. If the schema has been updated and your local instance of postgres is not synced with it, you can reset this by executing `bun backend:push-schema`.
 2. Seed the database with some predefined entries by executing `bun run scripts/seed.ts` while the database is running. This file contains the email and password to login as a `god`.
 
 ### Environment Variables

docs/getting-started/running-the-project.md

@@ -21,7 +21,7 @@ features:
   - title: Backend in Hono
     details: Hono is a modern library for building REST servers.
     icon: 
-      src: https://hono.dev/images/logo-small.png
+      src: https://hono.dev/images/logo.svg
   - title: Monorepo with all the tools needed
     details: Includes the landing page, internal page, admin page, backend server.
     icon: 🔧

docs/index.md

@@ -2,7 +2,7 @@
 
 Follow the [Nuxt](https://nuxt.com) documentation [here](https://nuxt.com/docs/getting-started/introduction). 
 
-Nuxt is a great Vue-based meta-framework to build full stack applications. It comes with a built-in [Nitro server](https://nitro.unjs.io/) (which we largely ignore because of the lack of features and poor documentation, we use Hono instead). Nuxt's documentation, however, was good and now it's even better; so have a thorough read of it (including some complex stuff like [Layers](https://nuxt.com/docs/getting-started/layers) and [configuration](https://nuxt.com/docs/api/nuxt-config)). Here, we are going to touch upon rendering modes:
+Nuxt is a great Vue-based meta-framework to build full stack applications. It comes with a built-in [Nitro server](https://nitro.unjs.io/) (which we largely ignore because of the lack of features and poor documentation, we use Hono instead). Nuxt's documentation, however, was good and now it's even better; so have a thorough read of it (including some complex stuff like [Layers](https://nuxt.com/docs/getting-started/layers) and [configuration](https://nuxt.com/docs/api/nuxt-config)). 
 
 ::: warning
 If you ever see an error like *"Hydration mismatch"* on your console, **DO NOT IGNORE IT AND AIM TO FIX IT ASAP!!**
@@ -23,7 +23,7 @@ Nishant and Jay worked with Nuxt 3 for IC Hack '24 and this made total sense to
 Nuxt 4 is practically out at this time of writing. However, it is in beta build right now and we don't wish to experiment, especially since we were experimenting with the backend. Additionally, Nuxt 4 is not very different than Nuxt 3, apart from a few breaking changes. So it doesn't matter much anyway.
 
 ::: info
-With the [2nd architecture PR](../getting-started/project-timeline), we have migrated to Nuxt4.
+With the [2nd architecture PR](../getting-started/project-timeline), we migrated to Nuxt4.
 :::
 
 ## Bad things about Nuxt.

docs/tech-stack/nuxt.md

@@ -8,4 +8,4 @@ This is a full [Cloud VM](../concepts/cloud-vm).
 
 ## Digital Ocean App Platform.
 
-This is their self-managed serverless provider.
+This is their self-managed [serverless](../concepts/serverless-computing) provider.