florian.wilde/betreuungs-cockpit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 22 Wiki Activity

Absenderanschrift des Betreuers fehlt in jedem Schreiben #21

New Issue
Closed
opened 2026-08-23 16:54:53 +00:00 by florian.wilde · 2 comments
florian.wilde commented 2026-08-23 16:54:53 +00:00
Owner
Copy Link
Copy Source

Problem

Jedes Schreiben, das die Anwendung erzeugt, geht ohne Rücksendeadresse
hinaus. Im Absenderblock steht nur der Name, und in der Datumszeile fehlt
der Ort — statt „Bayreuth, 23.08.2026" steht dort nur das Datum.

Der Grund steht als Kommentar im Code: In briefkopfBauen()
(src/lib/vertraege/briefkopf.ts) sind betreuerStrasse, betreuerPlz
und betreuerOrt fest auf null gesetzt, weil es diese Felder im
Datenmodell nicht gibt.

Warum das mehr ist als Schönheit

Ein förmliches Schreiben an eine Versicherung oder Behörde ohne
Absenderanschrift wirkt unseriös und macht es der Gegenstelle unnötig
schwer zu antworten. Betroffen ist alles, was Schreiben erzeugt:
Rückkaufswert-Anfrage, Serienabfrage, Kündigung, Sachstandsanfrage,
eigene Vorlagen.

Was ich will

  • Straße, PLZ und Ort des Betreuers lassen sich einmal hinterlegen —
    vermutlich am Benutzer, weil sie zu mir gehören und nicht zur betreuten
    Person
  • Der Absenderblock zeigt sie, die Datumszeile trägt den Ort
  • Fehlt die Angabe, entsteht eine sichtbare Lücke wie überall sonst,
    keine stille Leerstelle

Akzeptanzkriterien

  • Die eigene Anschrift lässt sich in den Einstellungen hinterlegen
  • Sie erscheint im Absenderblock aller erzeugten Schreiben
  • Die Datumszeile lautet „Ort, Datum", sobald ein Ort hinterlegt ist
  • Ohne hinterlegte Anschrift bleibt es beim Namen allein — kein
    halber Block mit leeren Zeilen
  • Auch der Platzhalter für eigene Vorlagen kennt die Absenderangaben

Hinweis

Migration nötig (Felder am Benutzer). Betrifft Etappen ab 1.6.

Angelegt auf Zuruf im Chat, nicht aus dem Dashboard — bitte in Nebula
nachtragen.

## Problem Jedes Schreiben, das die Anwendung erzeugt, geht ohne Rücksendeadresse hinaus. Im Absenderblock steht nur der Name, und in der Datumszeile fehlt der Ort — statt „Bayreuth, 23.08.2026" steht dort nur das Datum. Der Grund steht als Kommentar im Code: In `briefkopfBauen()` (`src/lib/vertraege/briefkopf.ts`) sind `betreuerStrasse`, `betreuerPlz` und `betreuerOrt` fest auf `null` gesetzt, weil es diese Felder im Datenmodell nicht gibt. ## Warum das mehr ist als Schönheit Ein förmliches Schreiben an eine Versicherung oder Behörde ohne Absenderanschrift wirkt unseriös und macht es der Gegenstelle unnötig schwer zu antworten. Betroffen ist **alles**, was Schreiben erzeugt: Rückkaufswert-Anfrage, Serienabfrage, Kündigung, Sachstandsanfrage, eigene Vorlagen. ## Was ich will - Straße, PLZ und Ort des Betreuers lassen sich einmal hinterlegen — vermutlich am Benutzer, weil sie zu mir gehören und nicht zur betreuten Person - Der Absenderblock zeigt sie, die Datumszeile trägt den Ort - Fehlt die Angabe, entsteht eine sichtbare Lücke wie überall sonst, keine stille Leerstelle ## Akzeptanzkriterien - [ ] Die eigene Anschrift lässt sich in den Einstellungen hinterlegen - [ ] Sie erscheint im Absenderblock aller erzeugten Schreiben - [ ] Die Datumszeile lautet „Ort, Datum", sobald ein Ort hinterlegt ist - [ ] Ohne hinterlegte Anschrift bleibt es beim Namen allein — kein halber Block mit leeren Zeilen - [ ] Auch der Platzhalter für eigene Vorlagen kennt die Absenderangaben ## Hinweis Migration nötig (Felder am Benutzer). Betrifft Etappen ab 1.6. _Angelegt auf Zuruf im Chat, nicht aus dem Dashboard — bitte in Nebula nachtragen._
florian.wilde added the in-arbeit label 2026-08-23 17:37:15 +00:00
florian.wilde started working 2026-08-23 17:37:32 +00:00
florian.wilde commented 2026-08-23 17:37:58 +00:00
Author
Owner
Copy Link
Copy Source

🤖 Claude Code hat mit der Umsetzung begonnen.

  • Branch: feat/21-absenderanschrift
  • Verstanden als: Meine eigene Anschrift gehört einmal hinterlegt und dann in jedes erzeugte Schreiben — als Absenderblock und als Ort in der Datumszeile.
  • Geplantes Vorgehen:
    • Straße, PLZ und Ort am Benutzer, nicht an der betreuten Person: Sie gehören zu mir und gelten für alle Akten. Migration über den neuen Wrapper aus #24 — das ist zugleich sein erster echter Einsatz.
    • absenderBlock() und datumsZeile() können die Felder bereits, sie bekommen sie nur nie geliefert. Es fehlt also die Datenquelle, nicht die Logik.
    • Eingabe unter Mein Konto, dort steht schon der Name.
    • Zwei neue Platzhalter für eigene Vorlagen (#7), damit sie die Absenderangaben auch nutzen können.
    • Fehlt die Anschrift, bleibt es beim Namen allein — kein halber Block mit leeren Zeilen, und kein Komma ohne Ort in der Datumszeile.

Nebenbei löse ich den offenen Nachweis aus #25 ein: Diese Migration ist die erste ausstehende, seit die fünf Migrationskommentare geändert wurden. Wenn migrate deploy dabei über die abweichenden Prüfsummen stolpert, zeigt es sich hier.

Zeiterfassung läuft.

🤖 **Claude Code hat mit der Umsetzung begonnen.** - Branch: `feat/21-absenderanschrift` - Verstanden als: Meine eigene Anschrift gehört einmal hinterlegt und dann in jedes erzeugte Schreiben — als Absenderblock und als Ort in der Datumszeile. - Geplantes Vorgehen: - Straße, PLZ und Ort am Benutzer, nicht an der betreuten Person: Sie gehören zu mir und gelten für alle Akten. Migration über den neuen Wrapper aus #24 — das ist zugleich sein erster echter Einsatz. - `absenderBlock()` und `datumsZeile()` können die Felder bereits, sie bekommen sie nur nie geliefert. Es fehlt also die Datenquelle, nicht die Logik. - Eingabe unter *Mein Konto*, dort steht schon der Name. - Zwei neue Platzhalter für eigene Vorlagen (#7), damit sie die Absenderangaben auch nutzen können. - Fehlt die Anschrift, bleibt es beim Namen allein — kein halber Block mit leeren Zeilen, und kein Komma ohne Ort in der Datumszeile. Nebenbei löse ich den offenen Nachweis aus #25 ein: Diese Migration ist die erste ausstehende, seit die fünf Migrationskommentare geändert wurden. Wenn `migrate deploy` dabei über die abweichenden Prüfsummen stolpert, zeigt es sich hier. Zeiterfassung läuft.
florian.wilde worked for 51 minutes 2026-08-23 18:29:29 +00:00
florian.wilde commented 2026-08-23 18:31:09 +00:00
Author
Owner
Copy Link
Copy Source

🚀 Umgesetzt und nach main übernommen.

  • Merge-Commit: b6b579a
  • Pull Request: #32 (gemergt)
  • Fassung: v1.10.0 (getaggt)
  • Gesamtaufwand: 00:52

Was geändert wurde

  • Mein Konto → Meine Anschrift: Straße, PLZ und Ort. Die Anschrift hängt am Benutzer, nicht an der betreuten Person — sie gehört zu dir und gilt für alle Akten.
  • Sie steht im Absenderblock jedes erzeugten Schreibens, der Ort außerdem in der Datumszeile („Bayreuth, den 23.08.2026").
  • Zwei neue Platzhalter für eigene Vorlagen: {{betreuer_anschrift}} und {{betreuer_ort}}.
  • Ein Absender-Typ statt eines bloßen Namens, durchgereicht bis in den Serienlauf — der baute bisher { name } und hätte die Anschrift sonst still verloren.

Nicht die Logik fehlte, sondern die Datenquelle: absenderBlock() und datumsZeile() konnten die Felder längst.

So prüfst du es

  1. git switch main && git pull, dann npm run db:deploy und npm run dev
  2. Mein Konto öffnen → Karte Meine Anschrift → Straße, PLZ, Ort eintragen, speichern.
  3. Dokumente → Schreiben (freies Schreiben).
    Erwartet: Oben stehen Name, Straße, „PLZ Ort" untereinander; darunter die Datumszeile mit Ort.
  4. Einen Rückkaufswert oder eine Kündigung aus einem Vertrag heraus erzeugen.
    Erwartet: dasselbe im Kopf.
  5. Gegenprobe: Unter Mein Konto nur den Ort stehen lassen, Straße und PLZ leeren.
    Erwartet: Der Absenderblock besteht wieder nur aus dem Namen; die Datumszeile behält den Ort. Keine leeren Zeilen.

Zur vollen Testsuite, in Klartext: Sie meldete zunächst 2 Fehlschläge von 125 — beide im Passkey-Test „lässt ein Gerät ohne Nutzerverifikation nicht herein". Ursache waren zwei verwaiste Datensätze Ungesichertes Gerät aus einem abgebrochenen früheren Lauf, die eine Strict-Mode-Verletzung ausgelöst haben. Nach dem Aufräumen läuft die Datei in beiden Projekten grün (6/6). Mit dieser Änderung hat es nichts zu tun.

Ohne Freigabeschritt gemergt — auf ausdrücklichen Zuruf im Chat für die Reihe #21–#28.

🚀 **Umgesetzt und nach `main` übernommen.** <!-- claude-status branch: feat/21-absenderanschrift merge: b6b579a pr: 32 zeit_sekunden: 3117 --> - Merge-Commit: `b6b579a` - Pull Request: #32 (gemergt) - Fassung: **v1.10.0** (getaggt) - Gesamtaufwand: 00:52 **Was geändert wurde** - **Mein Konto → Meine Anschrift**: Straße, PLZ und Ort. Die Anschrift hängt am Benutzer, nicht an der betreuten Person — sie gehört zu dir und gilt für alle Akten. - Sie steht im **Absenderblock jedes erzeugten Schreibens**, der Ort außerdem in der **Datumszeile** („Bayreuth, den 23.08.2026"). - Zwei neue Platzhalter für eigene Vorlagen: `{{betreuer_anschrift}}` und `{{betreuer_ort}}`. - Ein `Absender`-Typ statt eines bloßen Namens, durchgereicht bis in den Serienlauf — der baute bisher `{ name }` und hätte die Anschrift sonst still verloren. Nicht die Logik fehlte, sondern die Datenquelle: `absenderBlock()` und `datumsZeile()` konnten die Felder längst. **So prüfst du es** 1. `git switch main && git pull`, dann `npm run db:deploy` und `npm run dev` 2. **Mein Konto** öffnen → Karte *Meine Anschrift* → Straße, PLZ, Ort eintragen, speichern. 3. **Dokumente → Schreiben** (freies Schreiben). Erwartet: Oben stehen Name, Straße, „PLZ Ort" untereinander; darunter die Datumszeile mit Ort. 4. Einen Rückkaufswert oder eine Kündigung aus einem Vertrag heraus erzeugen. Erwartet: dasselbe im Kopf. 5. Gegenprobe: Unter *Mein Konto* nur den Ort stehen lassen, Straße und PLZ leeren. Erwartet: Der Absenderblock besteht wieder nur aus dem Namen; die Datumszeile behält den Ort. **Keine** leeren Zeilen. **Zur vollen Testsuite, in Klartext:** Sie meldete zunächst **2 Fehlschläge von 125** — beide im Passkey-Test „lässt ein Gerät ohne Nutzerverifikation nicht herein". Ursache waren zwei verwaiste Datensätze `Ungesichertes Gerät` aus einem abgebrochenen früheren Lauf, die eine Strict-Mode-Verletzung ausgelöst haben. Nach dem Aufräumen läuft die Datei in beiden Projekten grün (6/6). Mit dieser Änderung hat es nichts zu tun. Ohne Freigabeschritt gemergt — auf ausdrücklichen Zuruf im Chat für die Reihe #21–#28.
florian.wilde removed the in-arbeit label 2026-08-23 18:31:17 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blockiert
Offene Rueckfrage, Uhr steht
 in-arbeit
Claude arbeitet daran, Stopwatch laeuft
 zu-testen
Umgesetzt, PR offen, wartet auf Test
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
florian.wilde (Florian Wilde)
No Assignees
1 Participants
Notifications
Total Time Spent: 51 minutes
florian.wilde
51 minutes
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: florian.wilde/betreuungs-cockpit#21