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
+33
View File
@@ -832,6 +832,39 @@ treffRouter.delete("/workspace/api/treff/massnahme/:id", gleicheHerkunft, nurTea
}
});
/* =====================================================================
WAS HEREINKOMMT (17.09.2026) -- aus dem Plan im Vault, Stufe 4.
Ein Moderator musste bisher acht Bretter durchklicken, um zu sehen,
ob etwas Neues da ist. Das tut niemand achtmal am Tag -- und was
niemand ansieht, moderiert auch niemand.
ALLE BRETTER IN EINER LISTE, das Neueste zuerst. Ohne Inhalt zu
wiederholen: Titel, Brett, wer, wann. Wer mehr will, klickt.
KEINE NEUE TABELLE UND KEINE ZWEITE WAHRHEIT: Es ist dieselbe
Abfrage auf `eintraege`, nur ueber alle Community-Bretter statt eins.
Die Bretterliste kommt aus TREFF_BRETTER -- dieselbe, aus der auch
die Kacheln und die Schreibregeln kommen. Eine eigene Liste hier
waere beim naechsten Brett auseinandergelaufen, und zwar still. */
treffRouter.get("/workspace/api/treff/zulauf", nurTeam, (req, res) => {
try {
const felder = TREFF_BRETTER.map(() => "?").join(", ");
const zeilen = db().prepare(`
SELECT e.id, e.bereich, e.art, e.titel, e.status, e.erstellt,
p.name AS von_name, p.rolle AS von_rolle
FROM eintraege e
LEFT JOIN personen p ON p.id = e.erstellt_von
WHERE e.bereich IN (${felder})
ORDER BY e.erstellt DESC, e.id DESC
LIMIT 40`).all(...TREFF_BRETTER);
res.json({ zulauf: zeilen.map(mitRollenname) });
} catch (f) {
console.error("[treff] Zulauf:", f?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
treffRouter.get("/workspace/api/treff/massnahmen", nurTeam, (req, res) => {
try {
const zeilen = db().prepare(`