Stufe 4: eine Bremse -- und eine stille Sperre, die es nicht gibt

Aus dem Plan im Vault. Diese Stufe steht dort bewusst VOR Galerie und
Gespraech: Mehr Sichtbarkeit heisst mehr Angriffsflaeche, und ein
Bereich, der waechst und keine Bremse hat, waechst genau einmal.

DER TREFF HATTE SCHON MEHR, ALS MEIN PLAN ANNAHM
Stufen (WER schreiben darf: neu, dabei, stamm) und Massnahmen (wer
NICHT MEHR darf: Hinweis, Pause, Ausschluss). Gefehlt hat die Frage
dazwischen: WIE SCHNELL. Ein Stammgast konnte in einer Minute vierzig
Beitraege absetzen -- aus Aerger, aus Versehen oder per Skript.

DIE STILLE SPERRE IST VERWORFEN -- nach einer Messung, nicht nach
einem Gefuehl. `gast` ist eine Rolle mit Zugangscode, es gibt KEINE
Selbstanmeldung. Wer ausgeschlossen wird, kann sich nicht neu
anmelden. Damit loest ein Shadowban ein Problem, das dieses System
nicht hat; er bliebe ein Werkzeug, das Menschen taeuscht, ohne etwas
zu verhindern. Steht jetzt in §9 des Plans: was wir NICHT bauen.

DIE BREMSE: 10 Beitraege je Stunde und Person, nur auf den
Community-Brettern. Keine neue Tabelle -- die Antwort steht schon in
`eintraege`, eine Zaehlung ueber die letzte Stunde genuegt. Eine eigene
Tabelle waere ein zweiter Ort fuer dieselbe Wahrheit und muesste
zusaetzlich aufgeraeumt werden.

Die Absage sagt, WANN es weitergeht ("In 37 Minuten"). Ohne Zeitangabe
probiert jemand im Minutentakt weiter -- genau die Last, die man
verhindern wollte.

MEIN ERSTER ENTWURF BREMSTE DIE FALSCHE ARBEIT: Er zaehlte ALLE
Eintraege. Eine Creatorin mit zehn Content-Ideen haette danach im Treff
nichts mehr schreiben koennen. Eine Bremse, die das richtige Verhalten
bestraft, wird abgeschaltet -- und ist ab da wirkungslos.

DIE TEAM-SICHT: "Was hereinkommt", ganz oben auf der Moderationsseite,
vor den offenen Meldungen. Eine Meldung setzt voraus, dass jemand etwas
GESEHEN hat -- und wer acht Bretter durchklicken muss, tut das nicht
achtmal am Tag. Eine Zeile je Beitrag statt einer Karte: Hier
ueberfliegt man, man liest nicht. Der Inhalt steht auf dem Brett; eine
Vorschau waere eine zweite Stelle, an der derselbe Beitrag steht.

NEU: pruef-bremse (16 Pruefungen)
Die Grenze wird aus dem Code GELESEN, nicht abgeschrieben -- sonst
misst die Pruefung beim naechsten Anpassen etwas anderes als der
Server tut. Dazu die drei Fragen: Greift sie? Trifft sie die richtige
Arbeit (Content bleibt offen, das zweite Treff-Brett nicht)? Und laesst
sie den normalen Fall in Ruhe? Gegenprobe: Beitraege auf vorgestern
zurueckdatiert -- danach muss es sofort wieder gehen.

pruef-treff 66, pruef-wunschliste 30, pruef-countdown 22,
pruef-bereiche-lesend, pruef-css-klassen: gruen.

Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
2026-09-17 11:35:30 +02:00
co-authored by Claude Opus 5
parent 7eec2edf3f
commit 670940bd3a
35 changed files with 862 additions and 359 deletions
+57
View File
@@ -580,6 +580,15 @@ const BEREICHE_FUER_ALLE = Object.entries(BEREICHE)
const DRINGLICHKEITEN = ["hoch", "mittel", "niedrig"];
const STATUS = ["offen", "erledigt"];
/* Wie viele Beitraege in einer Stunde? Zehn ist reichlich fuer einen
Menschen und wenig fuer ein Skript. Die Zahl steht hier und nicht in
der Route, damit sie an genau einer Stelle steht -- die Pruefung
liest sie mit. */
export const BEITRAEGE_JE_STUNDE = 10;
/* Gilt die Bremse hier? Nur in den Community-Bereichen. Eine
Content-Planung ist Arbeit am eigenen Kanal; dort waere eine Bremse
eine Behinderung ohne Gegenwert. */
const treffBereich = (b) => TREFF_BRETTER.includes(b);
const TITEL_MAX = 160;
const TEXT_MAX = 6000;
@@ -1459,6 +1468,54 @@ bereicheRouter.post("/workspace/api/bereich/:bereich", gleicheHerkunft, (req, re
const warum = darfSchreiben(req.person, bereich);
if (warum) return res.status(403).json({ fehler: warum });
/* DIE BREMSE (17.09.2026) -- aus dem Plan im Vault, Stufe 4.
Der Treff hatte Stufen (wer ueberhaupt schreiben darf) und
Massnahmen (wer nicht mehr darf), aber nichts dazwischen: WIE
SCHNELL. Ein Stammgast konnte in einer Minute vierzig Beitraege
absetzen -- aus Aerger, aus Versehen oder weil jemand ein Skript
laufen laesst.
Ein Bereich, der waechst und keine Bremse hat, waechst genau
einmal. Deshalb steht diese Stufe im Plan VOR Galerie und
Gespraech: Mehr Sichtbarkeit heisst mehr Angriffsflaeche.
KEINE NEUE TABELLE. Die Antwort steht schon in `eintraege` --
eine Zaehlung ueber die letzte Stunde genuegt. Eine eigene
Tabelle waere ein zweiter Ort fuer dieselbe Wahrheit und muesste
zusaetzlich aufgeraeumt werden.
UND DIE ABSAGE SAGT, WANN ES WEITERGEHT. "Zu viele Beitraege"
ohne Zeitangabe laesst jemanden im Minutentakt weiterprobieren
-- das ist genau die Last, die man verhindern wollte. */
if (treffBereich(bereich)) {
const seit = new Date(Date.now() - 3600_000).toISOString();
/* NUR DIE COMMUNITY-BRETTER ZAEHLEN MIT. Beim ersten Entwurf
stand hier keine Bereichsgrenze -- dann haette eine Creatorin,
die zehn Content-Ideen eintraegt, danach im Treff nichts mehr
schreiben koennen. Eine Bremse, die die falsche Arbeit
bestraft, wird abgeschaltet. */
const felder = TREFF_BRETTER.map(() => "?").join(", ");
const { anzahl, aeltester } = db().prepare(
`SELECT COUNT(*) AS anzahl, MIN(erstellt) AS aeltester
FROM eintraege
WHERE erstellt_von = ? AND erstellt >= ?
AND bereich IN (${felder})`)
.get(req.person.id, seit, ...TREFF_BRETTER);
if (anzahl >= BEITRAEGE_JE_STUNDE) {
const frei = new Date(Date.parse(aeltester) + 3600_000);
const min = Math.max(1, Math.ceil((frei.getTime() - Date.now()) / 60000));
protokolliere("treff_bremse", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `${bereich} ${anzahl} in einer Stunde`,
});
return res.status(429).json({
fehler: `Du hast in der letzten Stunde ${anzahl} Beiträge geschrieben. `
+ `In ${min} ${min === 1 ? "Minute" : "Minuten"} geht es weiter.`,
});
}
}
const { aus, fehler } = pruefe(bereich, req.body || {}, { neu: true });
if (fehler.length) return res.status(400).json({ fehler: fehler.join(" ") });