Devlog 9: React Dashboard

time logged: 29hr 1m
date: 03/09/2026

The React dashboard is finally here! I completely mitigrated the old EJS dashboard with a new React app. THIS will be IS the biggest devlog yet, as it covers a lot of changes and new features. main features added is mitigration, codebase assistance, graphs, telemetary and a new api.

Heres a summary of what i changed

• renamed src/ to bot/ - this is because its related to the bot and not the server and its not where all the main files are
• mitigrated the EJS dashboard into a React app
• overhauled the UI
• deleted the pages system and the workflow to build it
• added a new RAG modal that answers questions about the repo and shows related visual assets (also includes a new rag.js file that handles retrieval and generation of answers)

The react dashboard has the following features:

• 10 pages (Home, Admin, Api, Commands, Docs, Home, Logs, AI, Sitemap, Status)
• 12 components
• 8 utilities js exports in the utils/ folder
• 404 page (with routing) & Error Boundary modal page
• public AI assistant page with repository-aware retrieval and related visual assets
• command API with stable IDs, command help, and captured command responses (so API can be called from the dashboard)
• public status, logs, metrics, command, and AI API endpoints
• admin feedback controls for filtering, viewing, replying, marking read/unread, and deleting (they dont work on windows only linux)
• CPU, memory, disk, and network telemetry with responsive graphs and hover data tooltips (so satisfying)

Current React Architecture

The active client source lives in server/client/src/. Vite builds it into server/client/dist/, which is served by server/server.js. React Router renders the page routes declared in server/client/src/components/utils/routes.js. The server still owns the HTTP status code: known browser routes receive the React shell with 200, while unknown browser routes receive the same shell with 404 so the client can render the NotFound page without hiding the correct HTTP semantics.

The old EJS dashboard and static page-generation flow are no longer the active dashboard path. The bot remains in bot/, separate from the dashboard server, and the server uses explicit Node http handlers under server/api/.

RAG and Command APIs

The new /ai page sends questions to POST /api/ask. server/lib/rag.js retrieves relevant repository text while excluding priv/, .env files, dependencies, logs, and build output. It can identify related image assets such as the calculator flowchart without parsing binary image contents. If configured, the retrieved context is sent to the AI provider; otherwise the endpoint returns a local configuration message and source metadata.

Commands are exposed through GET /api/commands, GET /api/commands/:id, and POST /api/commands/:id. The API adapter reuses the same command modules as Slack and captures their responses. The Commands page provides the interactive runner, while the AI page remains focused on repository questions. Explicit natural-language requests can still ask the RAG service to execute a recognised slash command and return its result.

Limitations

The migration exposed several boundaries that are now documented in docs/: authentication and CSRF, the webhook protocol, API registration, setup, and RAG behaviour. Runtime persistence is still file-backed through server/database/store.js; an external database remains a future adapter project rather than a required dependency.

Linux systemd controls and deployment scripts are intended for the hosted environment. On Windows local development, the dashboard, APIs, telemetry, and React pages work, but system service actions and Bash deployment are not expected to succeed. The dashboard must be rebuilt and restarted after production client or server changes.

Devlog 8 - server hosted dashboard finally happened

time logged: 17hr 47min 45s
date: 16/08/2026

The server hosted dashboard is finally here! It is hosted with the webhook, connected to the bot, and shows logs, status, and other information.

architecture

The Slackzilla server-hosted dashboard is the web control centre sitting alongside the webhook (runs on the same port). The server runs the dashboard, API routes, authentication/session handling, CSRF protection, logging, monitoring and administrative controls. The dashboard has been moving from the earlier static local/pages prototype (see devlog 7) towards an EJS-based server-rendered architecture, with shared layouts/partials and a global dashboard styling system. The server also handles the GitHub deployment webhook on port 9000, while Nginx sits in front of the application. The dashboard is intended to expose things such as bot status, logs, statistics, monitoring, API documentation and admin controls rather than sshing into the server and running commands manually

I’ve been separating the dashboard’s presentation layer, API layer and server logic. During development, I encountered and fixed several contract problems where route modules expected helpers such as context.sendError() and context.sendOk() that the runtime context did not provide. I also changed the authentication-aware API/SSE routes so unauthenticated requests return proper JSON/HTTP responses rather than accidentally redirecting an EventSource connection into an HTML login page. The dashboard has admin-only functionality, CSRF protection and server-side authentication, whilst the bot itself uses Slack’s Events/Slash Command mechanisms for incoming Slack activity. Slack’s Events API delivers subscribed events to the HTTP endpoint, while slash commands are sent to the configured app endpoint via HTTP POST.

/api/admin routes are protected by an authenticated admin session and CSRF protection. Admin authentication uses a session cookie, which is only created after logging in through rylvion.hackclub.app/admin/login. The admin password is never stored in plaintext. It is stored as a PBKDF2-HMAC-SHA512 hash in the server environment, using a random salt and a high iteration count. The dashboard does not allow the password to be created or changed, so the server environment must be updated manually before restarting the service. CSRF tokens are generated server-side and sent to the authenticated client via a cookie. For POST requests, the client must return the token in the X-CSRF-Token header, preventing unauthorised or forged requests from triggering admin actions.

/api/ (excluding /api/admin) has no authentication

Port 9000 is used for the webhook and the dashboard whilst the bot itself runs on socket mode.

The api that currently has these endpoints
base url: https://rylvion.hackclub.app/api/

• GET /api/status - returns the bot status and other information
• GET /api/logs - returns the bot logs from slackzilla.log as JSON, including the file size in bytes
• POST /api/admin/control - allow the admin to control the accepts several actions such as start, stop, restart, redeploy, refresh, refresh-logs, refresh-status (self explanatory actions) with dangerous actions (such as redeploy, restart and stop ) contains a confirmation prompt to prevent accidental execution of the action.
• GET /api/admin/feedback - returns database feedback as JSON
• GET /api/admin/feedback/:id - returns the feedback with the given ID as JSON
• POST /api/admin/feedback/:id - allows the admin to control and accepts 3 actions such as delete, read, unread, respond.
• GET /api/admin/events- is a SSE (Server Sent Event) endpoint that allows the admin to receive real time events from the server such as logs, status, feedbacks and other information about the bot.

Devlog 7 - Adding a Web Dashboard (locally)

time logged: 9hr 58m
date: 31/07/2026

███████╗██╗      █████╗  ██████╗██╗  ██╗███████╗██╗██╗     ██╗      █████╗
██╔════╝██║     ██╔══██╗██╔════╝██║ ██╔╝╚══███╔╝██║██║     ██║     ██╔══██╗
███████╗██║     ███████║██║     █████╔╝   ███╔╝ ██║██║     ██║     ███████║
╚════██║██║     ██╔══██║██║     ██╔═██╗  ███╔╝  ██║██║     ██║     ██╔══██║
███████║███████╗██║  ██║╚██████╗██║  ██╗███████╗██║███████╗███████╗██║  ██║
╚══════╝╚══════╝╚═╝  ╚═╝ ╚═════╝╚═╝  ╚═╝╚══════╝╚═╝╚══════╝╚══════╝╚═╝  ╚═╝

added a local prototype view of the web dashboard for slackzilla, its hosted on Github Pages and is a static site that is not connected to the bot yet, it shows the design and layout of the dashboard and how it will look when its connected to the bot. the dashboard is designed to be responsive and works on both desktop and mobile devices. it has a clean and modern design that is easy to navigate.

for Github Pages hosting, i used gh-pages branch which meant creating a seperate workflow (pages.yml) to build and deploy the dashboard to the dist/ folder. before that i needed a way to make it minified and optimised for production, so i used terser, clean-css and html-minifier-terser to minify the js, css and html files respectively, i do realise that this meant adding extra dependencies to the project (even though its not linked to the bot yet). The deployment website will be hosted on the bot’s server (rylvion.hackclub.app) and on the same port as the webhook server

i also added new logging functionality that return smth like this the one below, this helps me track the usage of the commands and see how many times they have been used, when they were last used and by whom. this will be useful for the dashboard to show command usage statistics and manage command permissions.

{
  "commands": {
    "sz-hash": {
      "count": 3,
      "lastUsedAt": "2026-07-23T13:27:28.116Z",
      "lastUser": "rylvion",
      "lastUserId": "U0A84FA2NP2"
    }
  }
}

TL;DR: added a local prototype view of the web dashboard for slackzilla, its hosted on Github Pages and is a static site that is not connected to the bot yet, it shows the design and layout of the dashboard and how it will look when its connected to the bot and logging functionality that return command usage statistics and manage command permissions.

• introduced a new logging system that logs to both console and a file.
• added command usage tracking to record how often each command is used.
• enhanced server.js to serve dashboard, logs, and status pages.
• improved webhook handling and added signature verification.
• added a new metrics utility and feedback.js for tracking command usage statistics.

next devlog will be about connecting the dashboard to the bot & server and making it functional, its gonna be a long one so stay tuned for that

Devlog 6 - command buffet

time logged: 6hr 37m 19s
date: 22/07/2026

okay since most of the major architectural refactors are done, i can finally focus on adding more commands to Slackzilla. this devlog is about the new commands that i added to the bot, which are mostly utility commands that can be used for various purposes.

• base64 encoding
• hashing - supports multiple algorithms, default: sha256
• decoder - decodes every algorithm that hashing supports
• random ids(uuid)
• secure tokens
• random numbers
• unix date conversion
• text case conversion (camel, pascal, snake, kebab)
• character counter
• rock paper scissors
• magic 8ball (the only entertainment command added in this devlog)

the trickier parts were the input parsers. hash has to decide whether the first word is an algorithm or part of the text, case needs to split words without mangling the content too much, and unix has to switch between timestamps and readable dates without getting confused by weird inputs. i also added guardrails for invalid ranges and missing text so the bot gives a useful reply instead of just silently failing.

the fun commands were the easiest win. 8ball just picks from a response list, and rps does a quick match against the player choice and the bot choice to decide whether it was a win, lose, or tie. it is very low stakes code, which is honestly refreshing after the manifest workflow stuff from last time.

all utilities commands all have a help command associated to it

the current utilities commands include:

• /sz-base64 - encodes a string to base64
• /sz-hash - generates a hash of a string, default: sha256
• /sz-decode - decodes a base64 encoded string
• /sz-uuid - generates a random uuid
• /sz-token - generates a random secure token
• /sz-random - generates a random number in a given range
• /sz-unix - converts a unix timestamp to a human-readable date and vice versa
• /sz-case - converts a string to camelCase, PascalCase, snake_case, or kebab-case
• /sz-count - counts the number of characters in a string
• /sz-rps - plays rock paper scissors with the bot
• /sz-calc - evaluates mathematical expression

so all of it has a 2nd argument for help, so for example /sz-hash help will show the usage and examples of the command.

i also added on package.json, 2 new scripts

    "validate-commands": "ajv validate -s schemas/command.schema.json -d src/data/commands.json",
    "cmd-stats": "node scripts/stats.js"

one to validate the commands.json file against the command.schema.json file, and another to provide statistics about the number of commands in the commands.json file. this will help me keep track of how many commands are in the bot and also make sure that the commands.json file is valid before a pull request is merged.

currently, the bot has 22 commands in total, and 11 of them are utility commands (10 of them got added into this devlog (excluding the /sz-8ball that also was added in this devlog, but is an entertainment command)). the other 11 commands are the ones that were already in the bot before this devlog.

i need some feedback on what other commands i should add to the bot, so if you have any ideas, please let me know. (im running out of ideas *sighs*)

im also planning on adding a web dashboard to the bot, which will allow users to see the bot’s status, logs, and other information in a more user-friendly way. this will be a big change, so stay tuned for that in the next devlog

TL;DR: added a bunch of new slash commands for Slackzilla, kept the implementations small and native where possible, and tightened up the input handling so the new tools fail a little more gracefully.

Devlog 5 - manifest workflow

time logged: 7hrs 6min 16 sec
date: 21/07/2026

ok so i kinda lied in the last devlog. this ended up being another major architectural change to slackzilla. the slack manifest system was always the most brittle part of the pipeline and manually maintaining manifest.json was a guaranteed way to let things drift. today i finally automated the entire manifest workflow. the new setup makes commands.json and meta.js the single source of truth. i wrote a manifest generator that loads all metadata like descriptions colours oauth scopes bot info and merges it with the command definitions to build a complete slack manifest object. once assembled it writes manifest.json and syncs it during deployment. validation is baked directly into the generator. i wired AJV into both stages. every command is validated against command.schema.json and the final manifest is validated again against slack’s official schema. if anything fails the generator stops immediately with a clear error instead of producing a broken file. this caught several issues especially after i moved all schemas into a dedicated schemas/ directory to clean up the project structure.

the github actions workflow also got a major overhaul. every push now generates the manifest validates commands and manifest rotates the slack configuration token updates github secrets syncs the manifest through the slack api and deploys the bot. changing a slash command in commands.json now updates both the bot and the slack app config automatically. no more manual edits to manifest.json or the slack app settings. the entire pipeline is now self maintaining and fully automated. token rotation was the biggest pain. slack configuration tokens only last twelve hours so storing them in github secrets was not enough. i created a fine grained github PAT with permission to modify repo secrets and wrote rotateManifestToken.js to handle the full refresh cycle. it rotates the manifest token receives a new refresh token and updates both secrets so the next deployment does not break.

i spent way too long debugging an invalid_refresh_token error. note that slack’s copy button does not copy the existing refresh token it generates a new pair. every time i clicked it the previously saved token became invalid instantly. once i realised that i started updating github secrets immediately after copying the new pair so everything stayed in sync. after that the rotated token still was not being passed correctly between github actions steps. i switched to GITHUB_OUTPUT so the rotation step could hand the new token to the manifest sync step. then slack started returning not_authed which led to another rabbit hole. the manifest update endpoint requires the token in the correct auth header not the request body. once i fixed the request format the entire pipeline finally ran clean end to end. See figure 2 for github actions workflow

TL;DR slackzilla now auto generates its slack manifest validates everything with AJV rotates configuration tokens syncs the manifest during deployment and updates the bot server with minimal manual work. after a lot of debugging around token rotation schema mismatches and github actions quirks the deployment pipeline is basically self maintaining except refreshing the github PAT every ninety days.

Devlog 4: calc and roll commands

time logged: 2 hr 20 minutes
date: 17/07/2026

today i spent some time reading the Java Shunting Yard Algorithm implementation on GeeksforGeeks. The example focuses entirely on converting an infix expression into postfix form. It scans the expression character by character, places operands directly into the output string, and uses a stack to manage operators based on precedence and associativity. Once the scan is complete, any remaining operators are appended to produce a postfix expression like 5238-52^^/+. The Java version supports operators including +, -, *, /, and ^, and it handles parentheses, but it stops after producing the postfix representation. It does not evaluate the numerical result.

after reading that, i wanted something more complete for Slackzilla. I used the same core idea of converting infix to postfix, but I extended it in several ways. My implementation tokenises the input instead of reading one character at a time, which allows it to support multi digit numbers and decimals. I added unary minus detection so expressions like -3 or 5*-2 behave correctly. One challenge was distinguishing unary minus from subtraction. The parser has to determine whether it starts with a number or subtracts two values depending on the previous token. I kept exponentiation with the correct right associativity. Once the postfix array is built, I added a second stage that evaluates the postfix expression using a number stack. This lets the function return the final computed value rather than just the postfix notation. The result is a more flexible and practical version of the algorithm that fits naturally into Slackzilla and can evaluate real expressions interactively.

after finishing the calculator command, I also added another command to Slackzilla called /sz-roll. This command allows users to simulate dice rolls directly inside Slack. It supports normal dice notation like d6, custom dice sizes like d20, multiple dice such as 2d6, and modifiers like 2d20+5. I added parsing logic to split the dice expression into the amount of dice, number of sides, and any modifier before rolling each dice individually and calculating the final total.

I also added a /sz-roll help and /sz-calc help command which explains how to use the command and shows examples of supported formats.

also i spent A LOT of time making the flowchart to describe this more than the implementation itself. I think it will be useful for future reference and for anyone else who wants to understand how the algorithm works.

i also added json schema validation for commands.json as talked in devlog 2 the commands.json is the source of truth, so i addded a validator.yml to validate the json schema of commands.json and make sure it is valid before a pull request is merged. This will help prevent errors and ensure that the commands are correctly defined.

TL;DR: added a calculator using the Shunting Yard algorithm with postfix evaluation, plus a flexible dice rolling command. Also added help commands, a flowchart and automated JSON schema validation.

also ill add way more devlogs from now on since most of my last devlogs were major architecture refactor, unless there is a major change, i will just add a small devlog to add a new command/small feature, fix a bug, improve an existing feature and add more documentation.

Devlog 3 - github actions webhook request (13/07/2026)

time logged: 6hr 01min

i added a webhook dispatcher that automatically triggers a deployment whenever i commit to the main branch. Instead of manually pulling changes on the server and restarting the service myself, the GitHub Action now sends a signed webhook to my deployment server, which verifies it and runs the deploy script for me.

i also added 2 more commands

• /sz-meme - this makes a meme
• /sz-echo [str] - this echoes the string

you can see the flowchart below and see the full devlog 3 here (hyperlinked)

TL;DR whenever i commit the server automatically receives it and slackzilla updates to the latest version

Devlog 2 - server setup & modular command system & more [03/07/2026]

time logged: 10hr 59 min
so since the last devlog, i’ve have worked on LOADS of things including behind the scene (this doesnt get tracked on hacaktime :( ), i dont even know if this will hit the char limit, but anyways, here are the logs
EDIT: IT DID HIT THE CHAR LIMIT, turns out the original devlog was ~9.6k characters 💀 while the limit is only 4k, so this is the shortened version. the full one is still in priv/devlogs/devlog2.md if anyone wants the extended edition.z

Commits logs

e47c48ac0970b49015e920607a59657259122f2f - made the cur proj into more modular featuring dynamic command loading system w commands.json as the source of truth

on this, i figured out that packing every single thing into one file is a bad idea, so i made a modular command system that loads commands dynamically from a commands.json file, this way, i can add new commands without having to touch the main bot.js file, and also, it makes it easier to manage commands since they are all in one place

03b07ffc6f44d0231f9073f637caee1f9437705a) - added more detailed server logging with time & user at the start of most console logs onto terminal [coloured output]

this was way more of a pain than i thought it was gonna be. after countless rounds of testing i finally got it working how i wanted. the ansi colours kept either leaking into the rest of the terminal or resetting back to the default colour when i needed them to go back to the current log level. i was genuinely losing my mind because every “fix” just broke something else. after hours of messing around i ended up making a wrapper so instead of resetting after things like the username or command, it switches back to whatever the current log level colour is (info, success or error), then only resets once right at the end of the log. it took way longer than it should’ve and nearly made me give up, but it finally does exactly what i wanted and nothing leaks anymore.added src/utils/logger.js and switched almost every console.log over to it. it adds timestamps, users, commands and coloured log levels.and changed all the console logs in src/bot.js and src/cmds/ to use the new logger api

b81c739cc06edba2895695e51dbbf88d8868f19f - overhauled readme

well as the name implies its pretty self explanatory lol but i massively expanded the README with better documentation and setup instructions.

Server setup

find more info in the setup guide on Step 7 out of 8 in https://stardance.hackclub.com/missions/slack-bot/guide#step-7

i had to apply for a Nest server and get SSH access.yeah so basically my starting gear is a potato server (2GB RAM, 16GB storage) but that’s more than enough for this bot. i also got to mess around with linux for a bit (yes i am a windows user). honestly… i kinda liked it and i’m like 80% convinced i’ll switch one day (but too much of a hassle to switch rn, but maybe in the future).

after installing everything, setting up the environment variables and creating a systemd service, i finally got the bot running 24/7.TL;DR: i got the bot running 24/7 in the server and it works perfectly fine, and i can now add new commands without having to touch the main bot.js file, and also, and added detailed server logging with time & user

aight y’all i spent an ENTIRE HOUR writing this devlog and THEN i had to rewrite a shortened down version, y’all better rate me 9/9 for story telling, rylvion signing out 🫡 pls see my full devlog version

• booking flow (4 steps process)
• home/pricing/loads of other pages
• rlly advanced github actions
• more stuff that i cant remember

wireframes: https://app.moqups.com/7pztHxaFX9Yz5oI0v58osy9wUSSnmtnt/view/page/aaef4bdbf

slackzilla

after countless testing of figuring out why my bot isnt working, i found out the reason… well sort of… it seems so that the bot doesnt read my messages nad only respond to app commands idk how to make it respond to my messages if it not a cmd but anyways here are the logs

7be9077de2a487f7be8a779123420295dc9bff7e - add MIT license
9ceb9c2fe638f91ab6b0a14326437c9a5f32f499 - add initial bot setup (just for testing!]
66eb775434c871f063fd57daf0bdfc7bd66501f1 - add launch.json, .env.example (like formats), README.md, add stuff to bot.js

btw this isnt hosted (will host soon) or anything and to use it you have to use the cmd prefix (sc-) e.g., /sz-ping