b31bd9b515a4ef8b7bd7b74333d323d2927a28ad
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
b31bd9b515 |
Zwei bis drei Bilder je Supportmeldung -- und zwei Funde unterwegs
VanVan im Support, Meldung #11, VIERMAL gemeldet: „Hier im Supportbereich kann man immer nur ein Bild hinzufuegen bei einer Meldung. 2-3 waeren besser." Und in der zweiten Runde der Satz, auf den es ankommt: „wenn man es nacheinander versucht hinzuzufuegen wird das Bild immer nur ersetzt." EINE TABELLE STATT NEUER SPALTEN `support_bilder` haelt ab jetzt JEDES Supportbild -- das der Meldung (`runde_nr` NULL) und das einer Antwort (`runde_nr` = Runde). Die Alternative waere `bild2_datei`, `bild3_datei` gewesen, und beim vierten Bild wieder. Eine Zeile je Bild kennt keine Obergrenze im Schema; die Grenze steht an EINER Stelle im Code (`BILDER_MAX = 3`) und kommt von dort in die Oberflaeche, statt dort ein zweites Mal zu stehen. DIE ACHT VORHANDENEN BILDER WANDERN MIT. Ohne diesen Schritt haette die neue Tabelle ab heute recht und die alten Bilder waeren unsichtbar -- ohne Fehler, ohne rote Zeile, nur acht leere Karten. Der Umzug steht NACH der Spaltennachruestung: Er liest `urteil_bild_datei`, und die gibt es in einer bestehenden Datenbank erst, nachdem sie ergaenzt wurde. Stuende er davor, scheiterte er genau dort, wo es darauf ankommt -- live, waehrend lokal alles gruen bliebe, weil jede Pruefung ihre Datenbank frisch anlegt. DREI BILDER IN EINER ANFRAGE `x-bilder: 20481,15320` sagt, wo zu schneiden ist, der Rumpf ist die Aneinanderreihung. `multipart/form-data` haette einen Zerleger gebraucht, den dieses Haus nicht hat; drei Anfragen nacheinander haetten den Zustand „Meldung da, Bild zwei laedt noch" erzeugt -- genau den, gegen den die Kommentare an dieser Route schon vorher argumentieren. Die Summe muss auf das Byte stimmen, und jedes Stueck wird einzeln an seinen ersten Bytes erkannt: Wer falsch schneidet, bekommt eine Absage, kein verfaelschtes Bild. Ohne den Kopf gilt der ganze Rumpf als ein Bild -- derselbe Satz mit einer Laenge, damit eine Seite aus dem Zwischenspeicher weiterlaeuft. EINE ROUTE STATT DREI. `/:id/bild` und `/:id/runde/:nr/bild` sind weg; es gibt `/:id/bild/:bid`. Wohin ein Bild gehoert, steht in seiner Zeile -- der Weg muss es nicht wiederholen. Die Meldungsnummer bleibt trotzdem im Pfad: Sie ist die Sichtbarkeitsfrage, und beides muss zusammenpassen (gemessen). ZWEI FUNDE, DIE DIE PRUEFUNG GEMACHT HAT UND NICHT ICH 1. UEBER DIE SEITE KAM GAR KEIN BILD MEHR AN. Beim Melden stand kein `Content-Type`. Das ging gut, solange der Rumpf eine einzelne Datei war -- ein `File` bringt seinen Typ mit. Ein `Blob` aus mehreren hat keinen, `fetch` schickt die Zeile dann gar nicht, `express.raw` fuehlt sich nicht zustaendig, und der Server bekam einen leeren Rumpf. Die Meldung waere durchgegangen, der Text angekommen, die Bilder weg -- ohne Fehlermeldung. Alle Pruefungen am Server waren dabei gruen; gefunden hat es erst der echte Browser. 2. DAS KREUZ DES DRITTEN BILDES LAG AUF DEM ZWEITEN. Der Entfernen-Knopf ist 44 px breit und absolut gesetzt, der Kasten aber nur so breit wie sein Bild. Bei einem schmalen Bild ragt er darueber hinaus -- wer „das zweite weg" antippt, loescht das dritte. `min-width`/`min-height` loesen das an der Ursache: Ein Kasten ist nie schmaler als der Knopf in ihm. WAS ICH FALSCH ANGENOMMEN HATTE: Ich hatte eingebaut, dass ein Nachtrag in derselben Runde die Bilder ersetzt. Die Pruefung dazu wurde rot -- zu Recht: Eine zweite Antwort in derselben Runde kann es nicht geben, die erste verlaesst den Stand „wartet". Der Code waere nie gelaufen und damit nie pruefbar gewesen. Er ist weg; an seiner Stelle steht der Beweis, dass er nicht fehlt. DREI WEITERE ROTE ZEILEN, DIE NICHT ZU DIESEM UMBAU GEHOERTEN * `manager-ziele.js` hatte einen ZWEITEN Notnagel (`frageNach ? … : confirm(…)`). `nachfrage.js` hat denselben laengst, und zwar mit dem vollstaendigen Text; der hiesige war der kuerzere und haette gewonnen. Zwei Antworten auf dieselbe Frage -- gemeldet von `pruef-nachfrage`. * Zwei Mittelpunkte in `reaktion.css` standen woertlich im `content`. Sie liegen im Latin-1-Block, wo `pruef-zeichen` die Truemmer einer verunglueckten Kodierung sucht. Jetzt als Escape -- im Browser nachgemessen, es steht Zeichen fuer Zeichen dasselbe da. * Das Aufraeumen nach 90 Tagen loeschte nur das EINE Bild der Meldung; die Bilder aus den Antwortrunden blieben ohne Zeile auf der Platte liegen. Die Liste kommt jetzt aus einer Abfrage statt aus einer Spalte und kann deshalb nicht wieder unvollstaendig sein. GEPRUEFT pruef-support 78 -> 104 ok darunter: der Umzug der alten Bilder auf einer eigenen Wegwerf-Datenbank -- zweimal und dreimal gestartet, nichts verdoppelt, Datum von damals erhalten pruef-support-bilder NEU, 36 ok (echter Browser) dreimal nacheinander waehlen ergibt drei, das vierte wird mit einem Satz abgelehnt, dasselbe zaehlt nicht doppelt, einzeln entfernen laesst die anderen stehen, alle drei laden wirklich (naturalWidth), Kreuze 44x44 und keines verdeckt (mit Gegenprobe per Deckel), nichts ragt auf 390 px heraus pruef-nachfrage 69 -> 74 ok pruef-struktur 102 ok, 413 Routen (vorher 414: zwei weg, eine neu) pruef-zeichen 7 ok (vorher 1 Fehler) pruef-aufbewahrung 45 ok pruef-manager-ziele 216 ok pruef-ports 10 ok · pruef-portnummern 41 ok (die neue Pruefdatei verschiebt die abgeleiteten Nummern) NUR DAS AGENTURHAUS IST BETROFFEN. Die Supportseite liegt unter `/workspace`; am Crew-Haus aendert sich keine Zeile. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
2fb92f86f3 |
Die Routenwache war unvollstaendig -- 13 Routen waren ihr unsichtbar
GEFUNDEN ALS FEHLALARM, GEBLIEBEN IST EIN ECHTER FUND.
pruef-struktur meldete:
assets/js/manager-ziele.js: Schnittstelle gibt es nicht
-> /workspace/api/manager-ziele
Nachgesehen statt geglaubt: Die Seite ruft diese Adresse NIE auf. In
Zeile 31 steht `const BASIS = '/workspace/api/manager-ziele'`, benutzt
wird ausschliesslich `${BASIS}/stand`, `${BASIS}/eintraege`,
`${BASIS}/eintrag/${id}`.
DER EIGENTLICHE FUND LAG EINE EBENE TIEFER. Der SERVER registriert
seine Routen genauso:
const BASIS = "/workspace/api/manager-ziele";
managerZieleRouter.get(`${BASIS}/stand`, ...)
Die Sammelregel verlangte aber, dass ein Routenpfad direkt mit
`/workspace/` beginnt. ALLE DREIZEHN Routen dieses Moduls fehlten
damit in der Liste -- gemessen, nicht geschaetzt. Die Wache war also
nicht zu streng, sie war UNVOLLSTAENDIG: Zu diesen Routen konnte sie
gar nichts sagen, weder dass es sie gibt noch dass es sie nicht gibt.
Und weil die Aufrufe dorthin ebenfalls zusammengesetzt sind, ist es
nie aufgefallen -- ausser an dieser einen nackten Konstanten.
Server-Routen eingelesen: 401 -> 414
GEAENDERT
1. Einfache Praefix-Konstanten werden je Datei aufgeloest. Mehr
nicht: Wer seinen Pfad aus drei Variablen zusammensetzt, bleibt
unauffindbar -- und das ist richtig so, denn geraten wird hier
nicht. Ohne bekannten Wert wird GAR NICHTS eingetragen; eine
geratene Route waere schlimmer als eine fehlende, weil sie einen
toten Aufruf als lebendig durchgehen liesse.
2. Eine nackte Praefix-Konstante im Browser gilt als Praefix, wenn
es Routen DARUNTER gibt. Abgeleitet, nicht aufgezaehlt -- eine
Ausnahmeliste mit „manager-ziele" darin waere die naechste, die
niemand pflegt.
GEGENPROBEN IN BEIDE RICHTUNGEN, weil die neue Regel etwas
durchlaesst:
eine Praefix-Konstante wird als Praefix erkannt (Routen darunter)
eine erfundene Adresse OHNE Routen darunter bleibt ein Fund
und eine echte Route bleibt eine echte Route, kein Praefix
DAZU VIER SCHLUSSZEICHEN. Die Wache fuer das deutsche
Anfuehrungszeichen meldete vier Stellen in denselben zwei Dateien:
`„${was}" löschen?` und drei Geschwister. Berichtigt auf `“`.
UND EINE KORREKTUR AN MIR: Ich habe pruef-struktur heute dreimal als
„99 ok, Exitcode 0" protokolliert und dabei zwei rote Zeilen
uebersehen -- mein Filter zeigte nur die ersten drei FEHL-Zeilen und
die Zahl der gruenen. Gefunden habe ich es erst, als dieselbe Pruefung
spaeter Exitcode 1 meldete. Nachgemessen mit `git stash`: Die zwei
Funde stecken auch in HEAD, sie sind also nicht aus meiner laufenden
Arbeit gekommen. Eine Zusammenfassung, die nur die gruenen Zeilen
zaehlt, ist keine.
GEPRUEFT: pruef-struktur 102 ok, 0 Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
baf8288433 |
Korrigieren duerfen jetzt beide: Spicy Media und DogFather
Filipe auf die Rueckfrage, wer fremde Eintraege richtigstellen darf: „ja spicy und dogfather". Die Vorlage kannte dort nur DogFather („Vergangene Monate sind gesperrt ... Ausnahme: DogFather"). Das gilt ab jetzt fuer beide -- und zwar fuer BEIDE Faelle, nicht nur fuer einen: * einen fremden Eintrag aendern oder loeschen * einen abgeschlossenen Monat dafuer kurz oeffnen ES IST EINE MENGE UND KEINE ZWEITE LISTE. `darfKorrigieren()` gibt `siehtAlles()` zurueck -- dieselbe Menge, die schon ueber die Team-Uebersicht und die Zielzahlen entscheidet. Eine eigene Aufzaehlung derselben zwei Rollen waere die, die beim naechsten Umbau auseinanderlaeuft. Und inhaltlich gehoert es zusammen: Wer alle Zahlen sieht und die Ziele setzt, muss einen Zahlendreher gerade ruecken koennen; zwei verschiedene Grenzen fuer „darf alles sehen" und „darf etwas richtigstellen" koennte spaeter niemand mehr erklaeren. Der Name der Variablen hiess vorher `istAdmin` -- also die Rechnung statt ihrer Bedeutung. Jetzt heisst sie, was sie beantwortet. NACHVOLLZIEHBAR BLEIBT ES UNVERAENDERT: Jede Korrektur an einem fremden Eintrag und jede Aenderung an einem abgeschlossenen Monat steht mit Name, Rolle und Zeit im Protokoll -- geprueft wird jetzt ausdruecklich, dass dort auch `spicy` auftaucht. GEPRUEFT: 206 Pruefungen, 0 Fehler (vorher 194) Die Grenze wird in beide Richtungen gemessen, nicht nur in eine: Spicy aendert wirklich (200, und der neue Wert steht in der Datenbank), Spicy loescht wirklich -- aber ein Manager und ein fremder Scout werden weiterhin abgewiesen (403), und danach steht immer noch der Wert von Spicy da. Ohne diese Gegenproben hiesse „Spicy darf" moeglicherweise „jeder darf". Loeschen ist eigens geprueft: PATCH und DELETE sind zwei Routen, und zwei Routen koennen auseinanderlaufen. Auch die Freigabe fuer alte Monate wird nach Spicys Korrektur wieder geschlossen gemessen -- eine geoeffnete Tuer ist kein Erfolg. EINE MEINER PRUEFUNGEN WAR WIEDER FALSCH, NICHT DER CODE: Ich hatte erwartet, dass ein Manager mit einer fremden Nummer in der Adresse „nicht bearbeitbar" bekommt. Er bekommt `true` -- weil er gar keine fremde Liste bekommt, sondern seine eigene; die Nummer wird fuer ihn schlicht nicht beachtet. Richtiges Verhalten, falsche Frage. Gemessen wird jetzt, was zaehlt: dass bei ihm kein einziger fremder Eintrag ankommt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b46f75484f |
Ein Klick statt eines Formulars -- der Schnell-Eintrag
Filipe mit dem Bildschirmfoto der Zeilen: „ich will das viel perfekter
und geiler. will dass es viel einfacher ist. am besten so wenig wie
moeglich zu tippen. fertige sachen, bereit um ab zu gehen."
GEZAEHLT, WAS EIN EINTRAG VORHER KOSTETE -- das war der Punkt:
Manager Meeting Knopf, Dialog, Speichern 2 Klicks + Fenster
Schulung dazu die Art waehlen 3 Klicks + Fenster
Werbung dazu den Link tippen 2 Klicks + tippen
Creator dazu den Namen tippen 2 Klicks + tippen
Ein Fenster fuer die Aussage „ich war heute im Meeting" sind drei
Handgriffe fuer null Angaben. Vier Aufgaben im Monat, acht Klicks,
acht Fenster.
JETZT
Manager Meeting EIN Klick („Heute eingetragen")
Schulung EIN Klick (zwei fertige Knoepfe)
Werbung Einfuegen + Eintragen, kein Tippen
Creator ein Klick je Lead -- oder mehrere Namen auf
einmal einwerfen
Am echten Bildschirm nachgemessen: 0/2 vorher, EIN Klick, 1/2 nachher,
„Rueckgaengig" bringt 0/2 zurueck. Nicht „der Knopf ist da", sondern
„danach steht eine andere Zahl dort".
DREI ENTSCHEIDUNGEN DAHINTER
1. DER WEG NIMMT EINE LISTE. „Drei Creator auf einmal" ist EIN
Vorgang. Wer drei Namen aus Discord kopiert, hat das Monatsziel in
einem Zug erledigt -- das ist der eigentliche Gewinn, nicht der
gesparte Klick.
JEDER EINTRAG WIRD EINZELN GEPRUEFT UND EINZELN BEANTWORTET. Die
ganze Liste zurueckzuweisen, weil ein Name schon dasteht, waere
die bequeme und die falsche Loesung: Dann weiss niemand, welcher
der drei das Problem war, und tippt alles noch einmal. Geprueft
wird genau dieser Fall -- zwei gehen durch, einer wird im Klartext
abgelehnt, mit Namen.
2. KEINE SICHERHEITSABFRAGE VORHER, SONDERN „RUECKGAENGIG" DANACH.
Eine Nachfrage bei jedem Klick waere der Handgriff, den wir gerade
abgeschafft haben, in neuer Verkleidung. Sie kostet jeden; das
Zuruecknehmen kostet nur den, der sich vertippt hat. Acht Sekunden
statt drei -- lang genug, um es mit einem Daumen zu treffen.
3. DIE ZULETZT GEWAEHLTE ART IST VORGEWAEHLT -- abgeleitet aus dem
letzten Eintrag, nicht in einer Einstellung gespeichert. Eine
Spalte „Lieblingsart" waere ein zweiter Bestand, der veralten
kann; der letzte Eintrag veraltet nie.
WAS MIR DABEI AUFGEFALLEN IST
Ein Ein-Klick-Knopf macht den Doppeltipper zur wahrscheinlichsten
Fehleingabe -- bei „Heute eingetragen" merkt man nichts davon, es gibt
ja keine Angabe. Zwei Meetings an einem Tag zu VERBIETEN waere aber
falsch, sie sind moeglich. Also ein Hinweis statt einer Sperre:
„Fuer diesen Tag stehen jetzt 2. War das Absicht?" -- und das
Zuruecknehmen liegt ohnehin daneben. Mit Gegenprobe, dass beim ERSTEN
keine Warnung kommt; sonst waere sie keine Warnung, sondern ein
Begleittext.
AUSSERDEM
* Die Zeilen bauen sich beim Eintragen nicht mehr neu, sondern
ziehen nur die Zahlen nach. Sonst verschwaende das Feld, in dem
man gerade tippt, unter der Hand.
* „Einfuegen" holt den Link aus der Zwischenablage -- mit drittem
Ausgang: Firefox gibt sie ohne Erweiterung nicht her, und dann
wird das gesagt, statt dass ein Knopf stumm bleibt.
* Im Dialog drei fertige Tage (Heute / Gestern / Vorgestern) statt
eines Kalenders. Was nicht mehr in diesen Monat gehoert, wird gar
nicht erst angeboten -- am 1. und 2. fallen welche weg.
* Der Dialog heisst jetzt „Mehr Angaben" und ist die Ausnahme fuer
Notiz oder altes Datum. Dass er fuer etwas Normales gebraucht
wurde, war sein Fehler.
GEPRUEFT: 194 Pruefungen, 0 Fehler (vorher 168)
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f6d2437985 |
Manager-Ziele zu Ende gebaut -- und dabei zwei Loecher gefunden
Filipe: „perfektioniere alles jetzt sofort, es muss ready sein."
Die Vorlage Punkt fuer Punkt gegen das Gebaute gehalten, nicht gegen
meine eigene Liste von heute Mittag. Vier Punkte standen noch offen,
und auf dem Weg dorthin sind zwei Fehler aufgefallen, nach denen
niemand gesucht hat.
DIE ZWEI FEHLER ZUERST -- beide gefunden durch Messen, nicht Denken
1. EINE GELOESCHTE PERSON HAETTE IHRE ZAHLEN MITGENOMMEN.
`mz_eintrag.person_id` stand auf ON DELETE CASCADE. Die Vorlage
sagt aber: „Wer die Rolle verliert, sieht die Kachel nicht mehr;
die Daten bleiben fuer den DogFather erhalten." Mit CASCADE waere
genau das nicht wahr gewesen -- `DELETE FROM personen` haette den
Monatsverlauf eines Menschen lautlos mitgenommen.
Jetzt SET NULL, und Name und Rolle stehen zusaetzlich als Text am
Eintrag (dieselbe Bauweise wie bei support_meldungen). Die Rolle
ist nicht Zierde: Ohne sie wuerde ein abgeschlossener Monat
rueckwirkend an den Zielzahlen einer anderen Rolle gemessen.
Der Umbau laeuft auf dem Bestand von heute Mittag -- Spaltenliste
AUS PRAGMA abgeleitet, nicht gepflegt, und geprueft werden Zeilen
UND Spalten. Am 11.09.2026 hat genau so ein Umbau drei Spalten mit
Inhalt verloren, ohne Fehlermeldung, bei unveraenderter Zeilenzahl.
2. MEIN EIGENER SPERR-TRIGGER HAETTE DAS LOESCHEN BLOCKIERT.
ON DELETE SET NULL ist kein Loeschen, sondern ein UPDATE auf
person_id. Der Trigger sah eine Aenderung an einem abgeschlossenen
Monat und brach ab -- `DELETE FROM personen` waere damit
gescheitert, an einer Stelle, die mit Monatszielen nichts zu tun
hat. Erlaubt ist jetzt genau eine Aenderung an einem alten Monat:
dem Eintrag seinen Besitzer zu nehmen. Als BEDINGUNG und nicht als
`UPDATE OF <spaltenliste>` -- eine Liste muesste jemand pflegen.
Weil `CREATE TRIGGER IF NOT EXISTS` eine geaenderte Fassung nicht
erneuert, wird die alte am INHALT erkannt und ersetzt. Eine
Fassungsnummer muesste jemand hochzaehlen, und das wird vergessen.
DIE VIER OFFENEN PUNKTE DER VORLAGE
04 Jede Aufgabenzeile hat ihr eigenes Zeichen -- aus dem Haus
(`window.Bereiche`), nicht neu gezeichnet: Trichter, Bildschirm,
Buch, Rahmen. Das Statuszeichen bleibt daneben; ein eingefaerbtes
Aufgabenzeichen allein traegt die Stufe nicht.
05 „Farbiger Rand + Badge": Eine Kachel, an der eine Warnung haengt,
traegt jetzt einen feinen Saum -- JEDE Kachel, nicht nur diese.
Eine Regel, die nur an einer Stelle gilt, wird beim naechsten Mal
vergessen.
08 Die Team-Tabelle ist sortierbar: jede Spalte ein Knopf (kein
anklickbares <th> -- das erreicht die Tastatur nicht), mit
aria-sort, und sortiert wird nach ANTEIL statt nach nackter Zahl.
Dazu eine Ampel-Spalte mit Wort. Auf dem Handy verschwindet die
Kopfzeile im Kartenmodus, deshalb steht das Sortieren zusaetzlich
in der Leiste -- sonst waere es auf einem Telefon nicht
vorhanden.
09 Wer die Rolle verliert, steht weiter in der Uebersicht, als
„nicht mehr dabei" und mit der Rolle von damals. Wer geloescht
wurde, erscheint als zusammengefasste Zeile unter dem
mitgeschriebenen Namen.
WAS DER SAUM MICH GELEHRT HAT
Er stand zuerst in start.css und war wirkungslos -- der Browser
lieferte weiter den Faseschatten. Der Grund steht seit dem 25.09.2026
in module.css: `:is()` uebernimmt die Spezifitaet seines staerksten
Arguments, und `.gruppe[data-gruppe]` macht die ganze Modulliste
(0,2,0) -- genau so stark wie `.kachel[data-warn="ja"]`, bei
Gleichstand gewinnt die zuletzt geladene Datei. Dieselbe Falle wie
damals bei den Fokusringen, dieselbe Antwort: Was gegen die Modulform
gewinnen muss, gehoert in die Datei mit der Modulform. Gemerkt habe
ich es nur, weil die Bildmessung den errechneten Schatten AUSGIBT
statt ein Bild zu machen.
Beim Herausschneiden blieb eine Klammer zu viel in start.css stehen --
gefunden von pruef-css-klassen („eine schliessende Klammer ohne
oeffnende"), bevor sie still CSS verschluckt hat.
AUSSERDEM BEHOBEN
* Spicy Media sah an einer FREMDEN Liste „Bearbeiten" und „Loeschen",
und der Server antwortete mit 403. Ein Knopf, der nichts tut, ist
schlimmer als kein Knopf.
* Klick auf eine Person klappt jetzt alle vier Zeilen auf. Die
Vorlage verspricht „zeigt deren Eintraege" -- zugeklappt zeigte
der Klick nur Zahlen.
* Der CSV-Export kennt drei Staende statt zwei: „pflichtig", „neu,
noch ohne Pflicht", „nicht mehr dabei". Vorher hiess beides „nein".
* Das Aufklappen baute die ganze Liste neu und riss den
angeklickten Knopf weg (Fokus sprang nach oben).
GEPRUEFT: 168 Pruefungen, 0 Fehler (vorher 141)
Neu darunter: der Umbau auf einem echten Alt-Bestand (Zeilen, Spalten,
Inhalt, Indizes, Trigger, und ein zweiter Lauf, der nichts mehr tut),
das Loeschen einer Person mit Eintraegen aus einem abgeschlossenen
Monat -- mit Gegenprobe, dass dieselbe Sperre den INHALT weiterhin
nicht aendern laesst.
Zwei meiner neuen Pruefungen haben zuerst sich selbst gemessen statt
den Code: Eine verglich gegen einen Eintrag, den sie vorher geloescht
hatte (404 sah aus wie ein haltender Riegel), die andere meldete eine
fehlende Spalte, die nur ihr eigener Handeinsatz verursacht hatte.
Beide berichtigt.
Am Bildschirm nachgemessen bei 412 px und 1280 px: kein waagerechtes
Schieben, kein eigenes Beruehrziel unter 40 px, genau EINE Kachel mit
Saum und zwanzig ohne.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
db656f6e14 |
Manager-Ziele: vier feste Monatsaufgaben, die sich selbst zuruecksetzen
Filipe mit der Vorlage „Prompt · Kachel Agentur-Aufgaben" (02.10.2026):
Scouts, Manager, DogFather und Spicy Media bekommen vier Pflichten je
Monat -- Creator rekrutieren, Manager-Meeting, Schulung oder Community
Talk, Werbung auf TikTok -- mit Fortschritt, Ampel, Warnungen und
einem Monatsschnitt, der nichts loescht.
DREI ENTSCHEIDUNGEN, DIE VON DER VORLAGE ABWEICHEN -- alle abgestimmt:
1. DIE KACHEL HEISST „Manager-Ziele", nicht „Agentur-Aufgaben".
Es gibt bereits eine Kachel „Agentur" und eine „Aufgaben". Eine
dritte mit beiden Woertern im Namen waere auf einem Handy nicht
mehr auseinanderzuhalten.
2. DIE ZIELZAHLEN GELTEN JE ROLLE, und DogFather UND Spicy Media
duerfen sie aendern. Ein Scout muss nicht dieselbe Zahl schaffen
wie die Leitung.
3. DIE SCOUT-PIPELINE IST ANGEBUNDEN, in beide Richtungen: Vorschlaege
aus uebergebenen Leads, Namensvorschlaege beim Tippen, die
Verbindung bleibt am Eintrag gespeichert. Aber NICHTS zaehlt von
selbst -- gezaehlt wird nur, was ein Mensch bestaetigt hat. Ein
Zaehler, der sich allein fuellt, ist einer, dem niemand glaubt.
WAS ANDERS GEBAUT IST, ALS ES NAHELAG
DAS ZIEL WIRD PRO MONAT EINGEFROREN (`mz_ziel` hat den Monat im
Schluessel). Laege nur ein aktueller Wert in `einstellungen`, schriebe
jede spaetere Aenderung rueckwirkend den ganzen Verlauf um: Ein Monat,
der mit 2/2 abgeschlossen war, staende nach einer Erhoehung auf 4
ploetzlich als „nicht erreicht" da. Ein Verlauf, der sich rueckwirkend
aendert, ist keiner. Es gibt deshalb gar keinen Weg, den laufenden
Monat umzuschreiben -- gespeichert wird immer in den naechsten.
DIE SPERRE VERGANGENER MONATE SITZT IN DER DATENBANK, nicht im Code
(drei Trigger). Die Ausnahme fuer DogFather laesst sich in SQLite
nicht ueber die Sitzung abfragen, also ist sie ein sichtbarer Vorgang:
`mz_freigabe` wird fuer die eine Handlung geoeffnet, im `finally`
wieder geschlossen und verfaellt nach zwei Minuten von selbst. Jede
Korrektur steht mit Name und Zeit im Protokoll.
DER LAUFENDE MONAT STEHT IN EINER TABELLE (`mz_lage`), nicht in
`strftime(...,'localtime')`. Sonst entschiede die Zeitzone des Servers,
und am Monatsersten zwischen 00:00 und 02:00 griffe die Sperre fuer
den falschen Monat. Gerechnet wird durchgehend in Europe/Berlin
(identisch mit dem Europe/Luxembourg der Vorlage, aber dieselbe
Zeitrechnung wie der Rest des Hauses).
KEIN ZWEITER ZAEHLER FUER DIE KACHELWAND. Rand und Abzeichen auf der
Startseite kommen aus `workspace-hinweise.js` und damit aus derselben
Rechnung wie die Seite (`standFuer`). Zwei Rechnungen ueber dieselbe
Sache laufen auseinander, und zwar lautlos.
KEIN IMPORTKREIS ZU workspace-push.js. Die Erinnerungen entstehen hier
als Liste (`zielRufe`), verschickt werden sie im vorhandenen
Fuenf-Minuten-Takt. Der Tag steht im Merkmal -- dadurch geht pro
Person hoechstens EINE Meldung am Tag heraus, obwohl der Lauf
288-mal stattfindet.
GETRENNTE HAEUSER: Auf crew.dogfather-universe.com gibt es diese
Kachel nicht, auch nicht fuer DogFather. Gemessen, nicht angenommen.
GEPRUEFT (141 Pruefungen, 0 Fehler) -- mit Gegenproben zu jeder Sperre
* Vier Rollen kommen herein, drei bekommen 404 (nicht 403), und die
ANZAHL steht in der Bedingung. „Alle abgewiesen" waere auf einer
leeren Liste wahr.
* Die Ampel wird mit EINGESETZTEN Tagen gemessen, nie gegen die
Wanduhr -- diese Pruefung sagt am 16. November dasselbe wie heute.
(gate-oeffnung.mjs im Shop war gruen, bis der Kalender sie
ueberholte.)
* Die Datenbank lehnt einen Eintrag im Vormonat selbst ab; danach
wird nachgewiesen, dass die Freigabe nur EINMAL gewirkt hat.
* Neun Absagen mit dem jeweils richtigen Grund -- und eine
Instagram-Adresse, die durchgehen MUSS, weil sonst nur bewiesen
waere, dass die Pruefung streng ist, nicht dass sie richtig ist.
* Am 7. des Monats ist Ruhe: Ohne diese Zeile bewiese der
Erinnerungs-Block nur, dass immer etwas kommt.
ZWEI BEFUNDE KAMEN AUS DER MESSUNG, NICHT AUS DEM NACHDENKEN
* Beim Aufklappen einer Zeile wurde die ganze Liste neu gebaut --
der angeklickte Knopf existierte danach nicht mehr, der Fokus
sprang an den Seitenanfang. Gefunden hat es die Bildmessung, der
die Schaltflaeche unter der Hand wegbrach.
* Zwei meiner Messungen waren falsch, nicht der Code: Der
Haus-Test schickte den Keks nicht mit (401 statt 404), und
`Response.text()` entfernt ein BOM beim Dekodieren -- der Export
hatte eines, die Pruefung sah es nur nicht. Jetzt wird in Bytes
gemessen.
Kachelton 47 (#7368ff) ist mit tools/kachel-farbe-einzeln.mjs gegen
alle 46 vorhandenen gerechnet, nicht ausgesucht: Abstand 0,0899,
Kontrast 4,61:1. Beruehrziele, waagerechtes Schieben und
Schriftgroessen sind am Bildschirm bei 412 px und 1280 px nachgemessen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|