—Hello again proggers—

Back at it. This round wasn't visualizer polish or UI cleanup, it was Song Wars/SQ backend stuff and a Discord bot that didn't exist yesterday. Less "make it pretty," more "make it not lie to people."

Cat or dog? AcceptingSubmissions

print(f"I try to make stu{2f} which {actually_closes} {2day}")

Okay let's get into it~

—Yap—

Turns out "turn off the fee toggle" and "actually prevent the fee-gated action" are two different things, and I had only been doing the first one. Also built an entire close-queue flow because apparently streamers want to stop taking requests sometimes, which, fair. And then there's a Discord bot now. That happened too.

scope creep? never heard of her

—The Great Suffering—

1 — The Free Skip Loophole

Turning off "Skip fee" or "Super Skip fee" removed the option from the public request page (sq.html/sq.js) just fine. What it did NOT do was stop the backend from accepting skip/super-skip attempts anyway — submit, upload, promote, all of it. Toggle says no, server says sure why not. Backend now actually rejects those attempts when the toggle's off, closing the gap where a disabled tier was quietly still free.

the frontend was lying and the backend believed it

Still preserved: turning a toggle ON with a $0 amount is a real, intentional free tier. That distinction stays.

2 — Close Queue Didn't Exist

There was a "Queue enabled" toggle, but no way to just... stop taking requests without digging into settings. Added a real AcceptingSubmissions flag, separate from that, plus a one-click "Close Queue"/"Reopen Queue" button right next to "Copy Submit URL" in the header. No settings menu detour required.

When closed, the public page still shows now-playing and queue count, just hides the request/skip/super-skip forms behind a "requests are closed" banner. Streamer can keep browsing and playing from the existing queue the whole time, since the app's queue view was never gated on "enabled" to begin with.

3 — Now Playing Was Just Empty This Whole Time

Found this one by accident while wiring Close Queue: the public page's "Now Playing" section never actually populated for anyone who wasn't the owner, because the backend just wasn't sending track info to non-owner viewers. Fixed alongside everything else.

4 — A Discord Bot Shows Up

New discord-bot/ folder, Node.js + TypeScript, discord.js, with a full PLANNING.md for the design: PIN-based pairing so the streamer generates a short-lived PIN in-app and runs /link-queue in Discord with no secrets ever touching chat, a scoped bot-token concept kept separate from the full owner token, and a (guildId, channelId) → room mapping so one bot instance can serve many servers.

/queue, /request, /skip, /superskip are fully wired against the existing public SQ API and build clean. /link-queue, /close-queue, /open-queue are stubbed with TODOs since they need backend PIN/token endpoints that don't exist yet, which is now the next backend work item.

Everything typechecks and builds clean across the board — Rust release build, Spectralis.App, and the bot's tsc.

—FAQ (no one asked these but they are here)—

Q: Was the fee toggle actually broken this whole time? A: The frontend toggle worked. The backend just didn't care what the frontend said. Now it does.

Q: Why does Spectralis need a Discord bot? A: Because apparently the request queue living only on a web page wasn't enough surface area. Now it can also live in your server.

Q: Is the bot usable yet? A: Half of it. /request and friends work today. /link-queue needs backend endpoints that are next on the list.

Q: What's PIN-based pairing? A: Streamer gets a short-lived PIN in-app, runs one Discord command with it, done. No tokens or secrets ever posted in chat.

Q: Anything left over from last devlog? A: Chat template drift is still an EDITH problem, not a Spectralis one. Wrong repo, wrong devlog.

—This is the end*—

*end for now, PIN endpoints permitting

CYA!!!

Migration note: Imported from the original project journal. Publication date is estimated from the supplied sequence and approximately 13 work hours per day. Hours are a retrospective estimate. Original publication timestamps and media files were not included in the archive.