schalli
9641592a8c
WIP-Uebergabe vor Etappe 2. Der Arbeitsbaum ist sauber, alles gepusht, die CI gruen — pausiert wird an einer Etappengrenze, nicht mitten in einer Aufgabe. Die Uebergabe haelt vier Anti-Patterns fest, die alle aus tatsaechlichen Fehlschlaegen dieser Sitzung stammen. Der wichtigste: auf einem ungeprueften Fundament bauen. forTenant() war kaputt, und ohne die empirische Probe waere das erst nach dem Scharfschalten aufgefallen — als stiller Datenverlust, weil der LDAP-Loeschzweig leere Ergebnisse als "Gruppe verschwunden" deutet. Ebenfalls festgehalten, weil beides Zeit gekostet hat: eine grep-Zaehlung, die Kommentare mitzaehlte (36 vermeintliche Aufrufstellen, tatsaechlich 6), und die falsche Compose-Datei auf dem Server, weil COMPOSE_FILE auf prod.yml zeigt. Der Einstiegspunkt fuer Etappe 2 ist bewusst nicht der groesste Bereich, sondern ldap: dort sitzt der gefaehrlichste Loeschzweig, und die Wirkung ist dort am besten pruefbar. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU
36 lines
3.5 KiB
JSON
36 lines
3.5 KiB
JSON
{
|
|
"version": "1.0",
|
|
"timestamp": "2026-09-09T09:16:11.548Z",
|
|
"phase": null,
|
|
"phase_name": "Mandantentrennung wirksam machen (Etappenarbeit ausserhalb der Phasen, ueber Quick-Tasks)",
|
|
"phase_dir": null,
|
|
"plan": null,
|
|
"task": null,
|
|
"total_tasks": 4,
|
|
"status": "paused",
|
|
"completed_tasks": [
|
|
{"id": 1, "name": "Etappe 1 / forTenant() auf eine Verbindung zwingen, live nachgewiesen", "status": "done", "commit": "bbf1795"},
|
|
{"id": 2, "name": "Etappe 1 / Anmeldeweg ueber drei SECURITY-DEFINER-Funktionen", "status": "done", "commit": "de50297"},
|
|
{"id": 3, "name": "Etappe 1 / alle 227 Zugriffe klassifiziert, maschinell abgesichert", "status": "done", "commit": "5f3a39c"},
|
|
{"id": 4, "name": "Etappe 1 / Browser-Gegenprobe der Anmeldung (lokal)", "status": "done", "commit": "da0ac04"}
|
|
],
|
|
"remaining_tasks": [
|
|
{"id": 5, "name": "Etappe 2: 31 Einheiten vollstaendig + 9 teilweise auf forTenant umstellen, nach Bereichen gebuendelt (tenders 62, groups 37, ldap 21, dkv 21, user 17, module-registry 17, dashboard 13, calendar 12, tenant 8, favorites 7, settings 4)", "status": "not_started"},
|
|
{"id": 6, "name": "Etappe 3: Systemkontext fuer Hintergrundlaeufe plus WINDOWS #19 (nullable tenantId bei SearchProvider und TenderRssFeedSource)", "status": "not_started"},
|
|
{"id": 7, "name": "Etappe 4: Scharfschalten (DATABASE_URL auf tessera_app) mit Vorabpruefung und dokumentiertem Rueckweg", "status": "not_started"}
|
|
],
|
|
"blockers": [
|
|
{"description": "Etappe 4 darf erst nach Etappe 2 und 3 laufen. Wird vorher scharf geschaltet, liefern die noch nicht umgestellten Abfragen null Zeilen statt zu vieler.", "type": "technical", "workaround": "Reihenfolge einhalten; rls-preflight.mjs vor dem Umschalten laufen lassen"}
|
|
],
|
|
"async_jobs": [],
|
|
"human_actions_pending": [],
|
|
"decisions": [
|
|
{"decision": "Anmeldeweg ueber SECURITY-DEFINER-Funktionen statt Policy oder zweiter Rolle", "rationale": "Eine Policy ist ein Zeilenpraedikat und haette zwangslaeufig die ganze Benutzertabelle freigegeben. Die Funktion pinnt die Ausnahme auf feste Spaltenliste, Gleichheitsbedingung und LIMIT 1.", "phase": "Etappe 1"},
|
|
{"decision": "Benanntes Volume fuer user-files statt Bind-Mount", "rationale": "Das Image uebereignet /app/user-files an uid 1001; ein frisch angelegtes Host-Verzeichnis gehoert root und haette aus dem Datenverlust einen kaputten Upload gemacht.", "phase": "Quick 260909-cx0"},
|
|
{"decision": "Datenverlust in der Datenbank ist derzeit hinnehmbar", "rationale": "Ausdrueckliche Aussage des Users am 2026-09-09: nichts laeuft produktiv. Erlaubt beim Scharfschalten den direkten Weg. Gilt nur, solange das so bleibt.", "phase": "Etappe 4 (Vorgriff)"}
|
|
],
|
|
"uncommitted_files": [],
|
|
"next_action": "Etappe 2 beginnen: docs/mandantentrennung-zugriffsklassifikation.md lesen und den ersten Bereich buendeln. Sinnvoller Einstieg ist NICHT der groesste Bereich, sondern ldap (21 Zugriffe, 9 davon bereits mandantengebunden) — dort sitzt der gefaehrlichste Loeschzweig, und die Wirkung ist dort am besten pruefbar.",
|
|
"context_notes": "Die Sitzung lief ueber Quick-Tasks, nicht ueber Phasen; es gibt daher kein aktives Phasenverzeichnis. Der entscheidende Fund war, dass forTenant() selbst kaputt war (Kontext auf einer Verbindung, Abfrage auf einer anderen) — die Mandantentrennung hat nie funktioniert. Das ist behoben und live belegt. Wichtig fuer die Fortsetzung: erst pruefen, ob das Fundament traegt, bevor darauf gebaut wird; genau das hat hier einen stillen Datenverlust verhindert. Der Arbeitsbaum ist sauber, alles ist gepusht, die CI ist gruen."
|
|
}
|