> For the complete documentation index, see [llms.txt](https://jordan-7.gitbook.io/jordan-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jordan-7.gitbook.io/jordan-docs/internal/briefs/2026-07-27.md). # MegaChat brief — 2026-07-27 ## Objectives overnight * Ship yesterday's approved work to production and confirm it is actually serving * Fix the two holes where things quietly disappear: the spend meter forgetting on every deploy, and whatever was happening to fan recordings * Make alarms reach a person instead of a log file * Then find whatever else matters, unsupervised ## The headline **The bounty feature — fans record clips for a streamer who isn't on MegaChat yet, streamer claims and plays them, everyone gets paid — had no clips in it.** Not "clips that don't last". None. The contribution record had a field pointing at a recording, and nothing anywhere ever read that field. No part of the bounty flow ever accepted a video file. And a MegaChat is recorded *into a room*, which a streamer who hasn't signed up doesn't have — so there wasn't even a place to put one. The escrow, the payout maths, the anti-cheating watermark, the verification — all of that was real and working. It was all keeping careful accounts of something that did not exist. A streamer who did everything right would have claimed their handle, installed the overlay, gone live, and had nothing to play. Built the missing piece: recordings are now stored durably, held for the 90 days the product promises, and the streamer can actually fetch and play them back. Tested the whole way through — a fan contributes, uploads a recording, the streamer claims, and the exact bytes come back out the other end. **Second one, found by walking the same path end to end:** the moment a streamer tried to go live, the server threw an error. A function had been deleted in an earlier redesign and one caller was left behind pointing at it. Every test missed it because they all set up sessions by reaching past the web layer instead of going through it. Fixed, plus a check that now catches that whole category — if anyone deletes a function and leaves a caller, a test fails immediately instead of a streamer finding out. ## Also fixed * **The spending cap could be bypassed by deploying.** The meter kept everything in memory, so every deploy reset the day's total to zero. A leak that spanned a restart was invisible to the exact system built to catch leaks. It now remembers across restarts, and on startup it *asks the video service* who is actually connected rather than guessing. When it can't ask, it deliberately errs toward over-counting — an early false alarm is recoverable, a missed leak is not. * **We were never actually checking whether storage survives deploys.** The health check just confirmed a setting was filled in, which proves nothing. It now leaves a marker and looks for it on the next boot, so the answer is evidence instead of an assumption. * **Alarms now reach you.** Budget warnings, the long-session alarm, and storage filling up can post to Discord or Slack. It stays quiet when nothing is set up, never breaks anything if the destination is down, and won't spam you if something flaps. Fired a real test message and watched it arrive. * **Three follow-ups from the OBS black-screen fix**, one of which was quietly rebuilding the original expensive bug: in a locked-down OBS the overlay was getting a new identity on every reload, and since it reloads itself whenever the connection drops, that meant stacking up billed connections. Also: two overlays open now cost double, so that's detected and shown to you rather than hidden. * **Confirmed your Twitch thumbnail actually shows up**, not just that the setting saves. Your room is carrying the Twitch channel in production right now; the picture appears when you're live. ## Problems and how we handled them * I got the test-quality audit wrong on the first pass and corrected it — I flagged 48 cases as weak because they didn't import our code directly. They drive the real thing over the network against real money, which is the strongest kind of test, not the weakest. * One of my own new checks reported a bug that wasn't there: it was reading a comment I'd written *about* the deleted function and treating it as real code. * Nearly committed a file that would have made the storage check permanently lie — it would have reported "storage is safe" on a fresh machine with no storage attached. Caught and excluded. ## Outstanding * **Nothing lets a fan actually record a bounty clip yet.** The storage and the plumbing are in; the record-and-send screen isn't built. I stopped rather than invent a new product screen unsupervised. **This is now the single thing standing between the bounty feature and being usable.** * **You: paste a Discord or Slack webhook address into the settings** so alarms reach your phone. Two minutes, and then hit the test button to confirm. * **You: confirm the hosting service isn't set to sleep when idle.** Carried over. * **Still no way to reverse a payout once it's sent.** I wrote up the options and recommended one — hold back about 20% of each payout for two weeks, so reversing is just "don't send the rest" rather than chasing someone. Not built; it's your call. * The payment path is still tested against a copy of itself rather than the real thing. It's now checked for drift, but properly fixing it needs a funded test wallet. ## Outlook: bullish, with one caveat sharpened * Two genuinely serious defects found and fixed, both of which would have been discovered by the first real streamer instead of by us. That is the good version of a bad night. * The money-safety work is now real rather than assumed: the cap survives deploys, storage survives deploys *provably*, and alarms leave the building. * The caveat is sharper than yesterday, not softer: the bounty mechanic is closer to working than it has ever been **and** we now know it has never once been walked end to end by a human. Everything above was found by doing that for the first time. The remaining recording screen is small; the lesson is that "all the parts are built" and "the thing works" are different claims. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://jordan-7.gitbook.io/jordan-docs/internal/briefs/2026-07-27.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.