Sechs Werkzeuge: Aufgaben suchen, Woche ansehen, Kalender auflisten,
Aufgabe anlegen, abhaken und einplanen. Welche davon ein Modell zu sehen
bekommt, haengt an den Rechten des Tokens — was nicht erlaubt ist, taucht
gar nicht erst in der Liste auf. Ein Sprachmodell bekommt keinen eigenen,
weicheren Zugang.
Bewusst wenige und grob geschnittene Werkzeuge. Ein Modell, das zwischen
zwanzig fast gleichen waehlen muss, waehlt falsch; und jedes weitere ist
eine zusaetzliche Moeglichkeit, versehentlich etwas zu aendern.
Zustandslos: Jede Anfrage steht fuer sich. Der Planer hat keine
langlaufenden Vorgaenge, und eine Sitzungsverwaltung waere Zustand, den
mehrere Container nicht teilen koennten.
Jede schreibende Nutzung steht im Protokoll. Ein Modell, das Aufgaben
anlegt, muss genauso nachvollziehbar sein wie ein Mensch — eher mehr.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Oberflaeche und der MCP-Server sollen dieselbe Stelle benutzen. Zwei
Umsetzungen desselben Vorgangs waeren zwei Gelegenheiten, die Regeln
unterschiedlich hinzuschreiben — und der Kalenderschreibweg samt
Schleifenschutz ist nichts, was man zweimal richtig hinbekommt.
Der Kern liegt bewusst nicht in einer Datei mit 'use server': Dort wird
jede exportierte Funktion zu einem Endpunkt, den der Browser aufrufen
kann. Eine Funktion, die den Akteur als Parameter nimmt, waere dann ein
offenes Tor.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Wege hinein, die es bisher nicht gab: eine Erfassungsseite fuers
Handy, die auch im Funkloch nichts verliert, und eine oeffentliche
Schnittstelle fuer fremde Anwendungen.
Die Schnellerfassung merkt sich Erfasstes zuerst im Geraet und schickt es
dann. Andersherum waere es weg, wenn der Browser mitten im Senden
geschlossen wird. Jede Erfassung traegt eine Kennung, damit eine doppelt
zugestellte Nachricht keine zweite Aufgabe ergibt.
Von einem Token liegt nur der Hash in der Datenbank; der Wert erscheint
genau einmal. Keines der drei Rechte schliesst ein anderes ein — ein
Dienst, der nur meldet, braucht den Bestand nicht zu sehen. Was von
aussen kommt, landet in der Inbox: Die Einordnung bleibt bei dem, der
plant.
Nebenbei ist die Navigation geteilt worden. Sie hatte mit dem
dreizehnten Eintrag erneut Punkte am rechten Rand verschluckt; sie nur
zu verbreitern war nach M6 die falsche Antwort.
Geprueft vor dem Merge: npm run pruefen mit 331 Unit-Tests, 62
Integrationspruefungen, Migrationstest und 33 E2E-Tests.
Offen: Die Handbuchbilder der Erfassungsseite zeigen noch eine falsche
Inbox-Zahl. Der Fehler selbst ist behoben, nur der Bildlauf kam danach
nicht mehr durch.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Erfassungsseite zaehlte die Inbox selbst und kam dabei auf eine
andere Zahl als der Zaehler in der Kopfleiste: Ideen zaehlten mit. Sie
benutzt jetzt dieselbe Abfrage. Aufgefallen ist der Widerspruch nur im
aufgenommenen Bild — im Code sah jede Seite fuer sich richtig aus.
Die Bilder der Erfassungsseite zeigen noch die alte Zahl: Der Bildlauf
liess sich danach nicht mehr durchbringen, weil Docker auf diesem Rechner
staendig haengen blieb.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Mit dem dreizehnten Eintrag verschluckte die Leiste erneut Punkte am
rechten Rand — nach M6 zum zweiten Mal. Das Problem ist nicht die Breite,
sondern die Vermischung: Einrichtung und Verwaltung sucht man nicht beim
Arbeiten. Alltag bleibt in der Leiste, alles andere liegt hinter "Mehr".
Ein <details> statt eines Menues aus Skript: Es klappt ohne JavaScript
auf und braucht keine Zustandsverwaltung.
Zurueckgezogene Tokens stehen jetzt unten. Was noch Zugang hat, ist das,
wonach man sucht.
Zwei E2E-Tests greifen den neuen Weg ueber "Mehr" auf. Ein dritter wartet
das Neuladen ab, bevor er navigiert — die Meldung kommt frueher als die
fertige Liste, und Chromium bricht die Navigation sonst ab.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Beschreibung sagt auch, was die Schnittstelle bewusst nicht kann —
Bereich setzen, Aufgaben loeschen, Zeitbloecke anfassen. Das ist eine
Entscheidung und kein Versehen, und wer davorsteht, soll es erfahren,
statt es fuer eine Luecke zu halten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zehn Faelle, davon sieben, die scheitern muessen: ohne Token, mit
erfundenem Token, mit zu wenig Rechten in beide Richtungen, abgelaufen,
zurueckgezogen, ohne Titel — und einer, der belegt, dass Status und
Bereich aus der Anfrage nicht uebernommen werden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ein Feld, ein Knopf, grosse Flaeche. Was ohne Netz erfasst wird, liegt in
IndexedDB, bis es hinausgeht — nicht in localStorage: Ein Eintrag, der
beim Aufraeumen des Speichers verschwindet, ist eine verlorene Aufgabe.
Erst anstellen, dann senden. Andersherum ginge der Eintrag verloren, wenn
der Browser mitten im Senden geschlossen wird. Jede Erfassung traegt eine
vom Geraet vergebene Kennung, damit eine doppelt zugestellte Nachricht
keine zweite Aufgabe ergibt.
Der Dienstarbeiter haelt genau diese eine Seite offline bereit und sonst
nichts. Ein halb veralteter Planer waere schlimmer als gar keiner — ein
Eingabefeld dagegen veraltet nicht, und ohne die Seite naehme die
Warteschlange im Geraet niemandem etwas ab.
Dazu das Manifest, damit sich der Planer als Anwendung ablegen laesst.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anlegen ist Verwaltungssache: Ein Token ist ein Zugang zur ganzen
Anwendung, nicht zu einer Aufgabe.
Beim Anlegen erscheint der Wert ein einziges Mal, mit dem Hinweis, dass
er danach weg ist, und einem curl-Aufruf zum Ausprobieren. Ein Ablauf
laesst sich setzen — ein Token mit Ablauf ist einer, den man nicht
vergisst.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Lesen, erfassen, aendern — mehr nicht. Status, Bereich und Projekt lassen
sich von aussen nicht setzen: Was hereinkommt, landet in der Inbox und
wird hier einsortiert, sonst raeumt ein fremder Dienst die eigene Ordnung
um.
Mit einer Kennung ist das Erfassen wiederholbar: Zweimal dasselbe ergibt
eine Aufgabe, nicht zwei. Das ist der Unterschied zwischen einer
Schnittstelle, die man gefahrlos wiederholen kann, und einer, die bei
jedem Netzhaenger Karteileichen anlegt.
Jede schreibende Nutzung steht im Protokoll, mitsamt dem Token. Lesen
nicht: Ein Dienst, der im Minutentakt abfragt, wuerde das Protokoll
unbrauchbar machen.
Alle Fehlschlaege sehen von aussen gleich aus. Ob ein Token unbekannt,
abgelaufen oder widerrufen ist, geht niemanden etwas an.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gespeichert wird nur der Hash eines Tokens. Der Klartext existiert genau
einmal — beim Anlegen, auf dem Bildschirm. Ein Token ist ein Passwort;
es gibt keinen Grund, es zurueckzulesen, und jeden Grund, es nicht zu
koennen.
Drei Rechte, und keines schliesst ein anderes ein. Ein Dienst, der nur
meldet "hier ist etwas Neues", braucht den Bestand nicht zu sehen — genau
das ist der haeufigste Fall und der, bei dem ein mitgelesener Token am
wenigsten anrichtet.
Der sichtbare Anfang "planer_..." ist Absicht: Wer so einen Wert
versehentlich in ein oeffentliches Verzeichnis schiebt, soll ihn beim
Durchsehen erkennen.
30 Tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aufgaben entstehen jetzt auch dort, wo sie anfallen: Zammad-Tickets werden
zu Aufgaben, eine Telegram-Nachricht wird zur Aufgabe, und der Spiegel
bringt dienstliche Belegung nach Hause — ohne Titel.
Ueber allem steht eine Regel: Das fremde System fuehrt Titel, Notiz,
Verweis und Faelligkeit. Bereich, Projekt, Prioritaet und geschaetzter
Aufwand gehoeren der Planung und werden nie von aussen ueberschrieben.
Ohne diese Trennung waere die Wochenplanung nach jedem Lauf kaputt.
Der Wartungsplaner ist bewusst nicht angebunden: Die Schnittstelle steht
noch nicht fest. Die Aufnahmestelle ist vorbereitet, und die Seite
"Integrationen" fuehrt ihn als sichtbare Luecke statt als Leerstelle.
Geprueft vor dem Merge: npm run pruefen mit 301 Unit-Tests, 56
Integrationspruefungen, Migrationstest und 23 E2E-Tests. Der Spiegel ist
end-to-end geprueft, weil beide Enden dieselbe Anwendung sind; Zammad und
Telegram nur gegen die Logik — dafuer fehlen Zugangsdaten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Hinweis unter dem Wochenraster erklaerte nur die grauen Balken; die
gestreiften aus der anderen Instanz fehlten darin.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Demo-Instanz redet mit niemandem mehr: Solange DEMO_MODUS gilt,
starten die Jobs fuer Zammad, Telegram und den Spiegel gar nicht erst.
Sie ist mit erfundenen Daten gefuellt und steht nur fuer Bilder — ein
Aufruf nach draussen waere bestenfalls sinnlos.
Die Kopfleiste ist breiter als die Inhaltsspalte. Mit dem elften Eintrag
passte sie dort nicht mehr, und "Einstellungen" verschwand
stillschweigend am rechten Rand. Aufgefallen ist das erst im
aufgenommenen Bild.
Der Kartentext beschrieb noch den Weg von vor dem Kopplungscode.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Direkt nach dem Einrichten wuesste man sonst erst beim naechsten Takt,
ob die Zugangsdaten stimmen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Eingang des Spiegels ist die einzige Tuer, die ohne Anmeldung
aufgeht. Vier Faelle: ohne Signatur, falsch signiert, zu alt, und der
gute Fall — bei dem eine nicht mehr geschickte Belegung auch hier
verschwinden muss.
Der Testserver bekommt dafuer dasselbe Geheimnis wie der Test. Eine
Pruefung, die immer uebersprungen wird, prueft nichts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sie zaehlt gegen die Tageskapazitaet wie jeder fremde Termin, traegt
aber keinen Betreff und ist gestreift gezeichnet — damit niemand darin
einen Termin vermutet, dem der Titel fehlt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Eine Seite zeigt je Integration, ob sie vorgesehen, eingerichtet oder
gestoert ist, wann sie zuletzt geglueckt ist und woran sie klemmt. Der
Wartungsplaner steht sichtbar als offene Luecke darin, nicht als
Leerstelle.
Telegram-Chats werden hier gekoppelt und wieder getrennt, Meldungen je
Chat einzeln geschaltet. Aufgaben bekommen einen Schalter zum Spiegeln —
einzeln und je Aufgabe, denn wer versehentlich einen ganzen Bereich
spiegelt, schickt Kundennamen nach Hause.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Telegram alle zwei Minuten, Zammad und Spiegel alle fuenfzehn. Wer dem
Bot etwas schickt, erwartet die Aufgabe gleich in der Liste; in Zammad
aendert sich dagegen nichts im Minutentakt.
Meldungen gehen jetzt auch per Telegram hinaus — mit einem Knopf zum
Abhaken, wenn es um genau eine Aufgabe geht. Eine klemmende Integration
meldet sich wie ein klemmender Kalender: erst nach dem dritten
Fehlversuch, dann aber deutlich.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zammad liest ueber die Suche und schreibt nichts zurueck. Telegram holt
per getUpdates statt per Webhook — der Planer soll auch hinter einem
Anschluss ohne feste Adresse laufen. Der Spiegel schickt Belegungen ohne
Titel und nur die ausdruecklich markierten Aufgaben.
Wer dem Telegram-Bot schreibt, ohne im Adressbuch zu stehen, bekommt
keine Antwort. Die einzige Ausnahme ist ein gueltiger Kopplungscode: Er
ist der Beweis, dass jemand mit Zugang zur Anwendung diesen Chat will.
Ohne ihn muesste man die Chatkennung von Hand eintragen — und um sie zu
erfahren, muesste der Bot Unbekannten antworten.
Jede Sendung des Spiegels traegt eine Signatur ueber den Rumpf und gilt
fuenf Minuten. Der Empfaenger antwortet auf jeden Fehlschlag gleich:
falsches Geheimnis, verstellte Uhr oder Unsinn im Inhalt sind von aussen
nicht zu unterscheiden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Was aus einem Fund wird, entscheidet fuer alle Integrationen dieselbe
Stelle: anlegen, aktualisieren, schliessen oder nichts tun.
Gefuehrt werden nur Titel, Notiz, Verweis und Faelligkeit. Bereich,
Projekt, Prioritaet und geschaetzter Aufwand gehoeren der Planung — wer
ein Ticket einsortiert und schaetzt, will nicht, dass der naechste Lauf
das wieder wegraeumt.
Dazu die Regeln des Spiegels: Aufbau der Sendung und ihre Frist. Ohne
Frist liesse sich ein abgefangenes Paket beliebig oft erneut einspielen.
21 Tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ein Zustand je Quelle haelt fest, wie weit gelesen wurde und ob es
klappt. Der Merker ist bewusst ein freier Text: Zammad braucht darin
einen Zeitstempel, Telegram den Zaehler der zuletzt geholten Nachricht.
Dazu die gespiegelte Belegung ohne Titel, das Adressbuch der erlaubten
Telegram-Chats und der Einmalcode, mit dem sich ein Chat anmeldet.
Welche Integration eine Instanz darf, entscheidet weiterhin INSTANZ. Ein
Zammad-Token in der Instanz daheim bleibt wirkungslos — das steht in den
Faehigkeiten, nicht in einer Einstellung, die sich verstellen liesse.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Planer sagt jetzt, was ansteht: Tagesueberblick am Morgen, faellige
Aufgaben, Vorlauf vor einem Zeitblock und ein Kalender, der sich nicht
abgleichen laesst. Per Web-Push, per E-Mail oder beides.
Ab Werk meldet er gar nichts. Eine Anwendung, die zu oft meldet, wird
stummgeschaltet und ist dann wertlos — deshalb ist die Einrichtung ein
bewusster Handgriff, dafuer kommt dann auch nur, was gewollt ist.
Der Nachweis einer Meldung wird vor dem Senden geschrieben: lieber eine
verpasste Nachricht als eine, die im Minutentakt erneut versucht wird.
Geprueft vor dem Merge: npm run pruefen mit 280 Unit-Tests, 47
Integrationspruefungen, Migrationstest und 20 E2E-Tests. Der Versandweg ist
gegen die Logik geprueft, nicht gegen echte Dienste — dafuer fehlen
VAPID-Schluessel und SMTP-Zugang.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Wegwerf-Instanz bekommt je Lauf ein frisch erzeugtes VAPID-Paar und
einen Mailhost, den es nie geben wird. Damit zeigen die Bilder den
eingerichteten Normalfall statt zweier Warnhinweise — und im Verzeichnis
bleibt kein privater Schluessel liegen.
Kein Push-Geraet mehr in den Demo-Daten: Seine Schluessel liegen
verschluesselt, und der Versand entfernt jedes Geraet, dessen Schluessel
er nicht lesen kann. Der erfundene Eintrag waere beim ersten Lauf wieder
verschwunden.
Dass der Browser im Bild "blockiert" meldet, laesst sich nicht abstellen:
Chromium im Kopflosbetrieb antwortet auf Notification.permission immer so.
Das Handbuch sagt es jetzt dazu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fehlen die Push-Schluessel auf dem Server, stand unter "Dieses Geraet"
trotzdem, der Browser habe blockiert — zwei Aussagen nebeneinander, von
denen nur eine zaehlt. Jetzt sagt die Karte zuerst das, was den Ausschlag
gibt.
Aufgefallen ist es erst im aufgenommenen Bild.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Einstellung haelt ueber das Neuladen, ohne eingeschalteten Weg geht
nichts hinaus, und ein unsinniger Vorlauf wird auch dann abgewiesen, wenn
er an der Oberflaeche vorbei hereinkommt.
Der Anmeldehelfer liegt jetzt einmal in e2e/hilfe.ts und fasst nach: ein
Klick, der vor der Hydratation ankommt, verpufft folgenlos — das hat die
Testlaeufe unter Last wiederholt scheitern lassen.
Der Integrationstest prueft die drei neuen Tabellen samt Kaskade.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Aufnahme kann jetzt einen einzelnen Ausschnitt statt der ganzen Seite
festhalten. Ein Bild der kompletten Einstellungsseite zeigt im Kapitel zu
den Benachrichtigungen zu wenig vom Eigentlichen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Takt passt zu den Toleranzfenstern: ein Anlass in einem
Viertelstundenfenster wird sicher getroffen, dank Sperre aber nur einmal
gemeldet. Eine Erinnerung kommt damit hoechstens ein paar Minuten frueher
als gewollt, nie spaeter.
Der Kalenderabgleich zaehlt seine Fehlversuche jetzt mit und setzt den
Zaehler bei Erfolg zurueck.
Alte Nachweise raeumt der naechtliche Lauf weg.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anmelden dieses Browsers, Liste der angemeldeten Geraete, Auswahl der
Anlaesse, Ruhezeit und Vorlauf. Ist ein Weg auf dem Server nicht
eingerichtet, steht das direkt daneben statt in einem Fehler beim
Speichern.
Der Knopf "Probe senden" umgeht Ruhezeit und Sperre absichtlich: wer
darauf drueckt, will jetzt wissen, ob es ankommt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Push ueber VAPID, Mail ueber SMTP, beide unabhaengig zuschaltbar. Die
Schluessel eines Push-Geraets liegen verschluesselt in der Datenbank.
Ein Geraet, das der Push-Dienst mit 404 oder 410 ablehnt, wird sofort
entfernt; andere Fehler zaehlen hoch und fuehren nach fuenf Versuchen
zum selben Ergebnis. Eine Liste toter Abos putzt sich so von allein.
Der Nachweis wird vor dem Senden geschrieben, nicht danach: lieber eine
verpasste Nachricht als eine, die im Minutentakt erneut versucht wird.
Weder Endpunkt noch Schluessel noch Mailinhalt landen im Protokoll.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anlaesse, Ruhezeit ueber Mitternacht, Wiederholungssperre und die
Entscheidung, ob eine Meldung jetzt hinausgeht. Ohne Datenbank und ohne
Systemzeit — der Zeitpunkt kommt immer als Parameter herein, damit sich
alles ohne Warten pruefen laesst.
Der Tagesueberblick ist von der Ruhezeit ausgenommen: wer ihn auf 06:00
stellt, bekaeme ihn sonst nie.
Die Voreinstellung ist bewusst zurueckhaltend. Wer beim ersten Start mit
Meldungen ueberschuettet wird, schaltet alles ab — und dann auch das
Nuetzliche.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Drei Tabellen: die Einstellung je Benutzer, angemeldete Push-Geraete und
ein Nachweis je verschickter Meldung. Der Nachweis ist das Gedaechtnis
gegen Wiederholungen — ohne ihn kaeme dieselbe Sache bei jedem Durchlauf
erneut.
Kalenderkonten bekommen einen Zaehler fuer Fehlversuche in Folge, damit
ein Abgleichfehler erst nach mehreren Versuchen gemeldet wird.
VAPID- und SMTP-Werte sind freiwillig: fehlen sie, laeuft der Planer
ohne den jeweiligen Weg weiter und sagt es in den Einstellungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Damit steht die Kernidee des Projekts: Aufgaben werden per Ziehen und
Ablegen zu echten Kalenderterminen, und Verschiebungen aus dem Kalender
kommen zurück.
Der Schleifenschutz über sha256(startISO|endeISO) verhindert, dass App
und Kalender einander endlos hinterherschreiben. Bei HTTP 412 gewinnt der
Kalender.
Geprüft vor dem Merge: npm run pruefen mit 250 Unit-Tests, 40
Integrationsprüfungen, Migrationstest und 17 E2E-Tests. Der Schreibweg ist
gegen die Logik geprüft, nicht gegen die echten APIs — dafür fehlen die
Zugangsdaten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ziel, Erledigtes, die Entscheidungen mit Begründung, die Probleme samt
Lösung und die offenen Punkte — allen voran, dass auch der Schreibweg
nicht gegen die echten APIs geprüft werden konnte.
Dauer laut zeiten.csv: 167 Minuten. Gesamt bislang 413 Minuten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
44 Bilder aus der Wegwerf-Instanz: elf Seiten, je hell und dunkel,
Schreibtisch und Handy. Neu dabei die Wochenansicht mit eingeplanten
Zeitblöcken.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Fehler fiel erst im aufgenommenen Bild auf: Bei sieben Spalten plus
Aufgabenliste war der Sonntag abgeschnitten — der Inhaltsrahmen von 64rem
ist für eine Wochenansicht zu eng.
Genau diese eine Seite bricht jetzt aus und nimmt bis zu 100rem, mittig
und mit demselben Seitenabstand wie überall. Die anderen Seiten bleiben
bei ihrer Lesebreite; eine Aufgabenliste über 100rem zu ziehen wäre keine
Verbesserung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
