How it all works

The architecture, the two guarantees worth checking rather than believing, and exactly which parts of your tournament are read from the tab rather than configured.

Why the three tools do not know about each other

They share a Tabbycat client and nothing else. No shared database, no shared state, no tool reading another's output. That separation is doing real work.

The clearest example: the fold's public page is built directly from the tab and never reads any private draft of a break-round draw. So a room that has not been drawn yet is genuinely empty on the public page, rather than merely hidden — there is nothing there to leak. Wiring the tools together would make that a matter of care instead of a matter of fact.

The read-only guarantee

One file talks to Tabbycat. It subclasses the HTTP session class and overrides the single method every request funnels through, raising on anything that is not a read, before a packet leaves the machine.

SAFE = {"GET", "HEAD", "OPTIONS"}

class _GetOnlySession(requests.Session):
    def request(self, method, url, *a, **kw):
        if str(method).upper() not in SAFE:
            raise ReadOnlyViolation(...)
        return super().request(method, url, *a, **kw)

There is no write function in the toolkit to call and no setting that enables one. The single POST anywhere is the sign-in form, and it runs on a separate, throwaway session that is closed immediately; only its cookies are carried into the read-only client.

You do not have to take that on faith, and if you are asking a tab director for an account you should not:

python3 tests/test_release.py

What is read from your tab, and what you configure

You configure four things. Everything else is read, every run.

This is the claim most worth being suspicious of, because almost every tool like this is quietly bound to the tournament it was written at. So the repository ships the means to check it rather than an assurance:

$ python3 demo/verify.py

Riverbend Open 2027         4 teams a debate · 9 prelims · 5 elim rounds · 2 categories
Ashfield Invitational 2027  2 teams a debate · 5 prelims · 3 elim rounds · 1 category
Kestrel Bay Novice Cup      4 teams a debate · 4 prelims · break not announced

Every tool ran against every tournament with no code changed.

The pattern that shows up twice: two mechanisms, not one

Both the fold and the feedback tool protect something, and both do it the same way — because one mechanism is never enough to trust.

In both cases the second mechanism is a deploy gate, not a warning. The refresh script will not publish a build that fails it. That distinction is the difference between a check and a habit.

Failures are made loud on purpose

The most dangerous bug in a tool like this is not a crash. It is a soft failure that produces a plausible page.

A transient error on one endpoint was once being swallowed and treated as an empty result — so the public site announced that a break had not happened, over a break that had been out for a day. No error, no log line. Both of the things that fixed it are now general principles here:

• An empty result that is also a real state must never be inferred from a failure. “No break yet” is a true state before the break, which is exactly why it may not be guessed at.
• Compare against the last known good. A successful response with an empty body is indistinguishable from “not announced”, so retrying cannot catch it; only noticing that something used to be there can.

Extending it

The things most likely to want changing, and where they are:

Next: what it will not do →