AGM Vertragsschicht — Entscheidungen

R-32 blockiert Schema Semantik

Bedeutet Marker 32692 die letzte fachliche Änderung oder den letzten Speichervorgang?

E nennt denselben Marker „Zuletzt gespeichert“, L1/L2 „Zuletzt geändert“. Ein expliziter Save und eine fachliche Änderung sind nicht zwingend dasselbe Ereignis.

A — Letzte fachliche Änderung Empfehlung Das API-Feld heißt updatedAt und ändert sich nur bei einer persistierten fachlichen Änderung. Keine zusätzliche Spalte; Labels und No-op-Saves müssen dieselbe Semantik einhalten. B — Letzter Speichervorgang Das Feld heißt savedAt und erfasst auch einen Save ohne fachliche Änderung. Die Listenbezeichnung „geändert“ wird ungenau; eine echte Änderungszeit fehlt. C — Zwei Zeitstempel updatedAt und savedAt werden getrennt geführt. Zusätzliche Spalte, Antwortfelder und Schreibregeln für jeden Save-Pfad. Später entscheiden

Warum A

A hält eine Wahrheit an einem Ort und passt zu Sortierung, Versionskonflikten und der Listenbezeichnung.

Marker 32692 in L1/L2 und E; Codex-Inventurabgleich 2026-08-22.

R-33 blockiert Schema R7

Wie wird das sichtbare Feld „Abmessungen“ R7-konform gespeichert?

Die Inventur beschreibt dimensions als Freitext. R7 verlangt Längen in Millimetern, Massen in Gramm und verbietet vorformatierte Präsentationswerte.

A — Strukturierte Messwerte Empfehlung Typisierte Messzeilen speichern kanonische Millimeter- beziehungsweise Grammwerte; die Anzeige wird daraus formatiert. Schema, API und spätere Oberfläche müssen mehrere Werte abbilden; Freitext braucht manuelle Migration. B — Feld vorerst weglassen dimensions bleibt bis zu einem Screen mit strukturierter Eingabe außerhalb des Vertrags. Der sichtbare Wert kann vorerst weder gespeichert noch ausgeliefert werden. Später entscheiden

Warum A

A erhält den Fachwert und erfüllt R7. Eine weitere Freitextspalte würde die Präsentationskopie nur umbenennen.

Marker 74925 in E; R7 des aktuellen Auftrags; bestehende Freitextentscheidung in VERTRAG.md.

R-38 blockiert Schema Löschen

Darf eine Mandantenlöschung alle zugehörigen Domänendaten kaskadierend löschen?

Sieben Tenant-FKs stehen derzeit auf CASCADE. Ein einzelnes DELETE würde Exponate, Räume, Ausstellungen, Konfiguration und Jobs entfernen; ein Purge-Screen fehlt.

A — RESTRICT bis Purge-Vertrag Empfehlung Alle Tenant-FKs verweigern Hard-Delete; ein späterer Purge-Vertrag regelt Sicherung, Reihenfolge und Nachweis. Mandantenlöschung ist bis dahin absichtlich nicht verfügbar. B — CASCADE vollständig Ein Tenant-DELETE löscht den gesamten Datenbaum in einer Transaktion. Kleinster Implementierungsaufwand, aber maximale und schwer prüfbare Schadenswirkung. C — Tenant jetzt soft-deleten Tenant erhält sofort einen Löschzeitpunkt und bleibt physisch bestehen. Neue Lifecycle-Regel und Filter auf allen Zugriffspfaden, obwohl der Screen fehlt. Später entscheiden

Warum A

A verhindert irreversible Massenlöschung ohne Vertrag und fügt keine tote Lifecycle-Spalte hinzu.

FK-Abgleich aller sieben Tenant-FKs; Codex 2026-08-22.

R-39 blockiert Schema Referenzen

Wie werden verwendete Hierarchie- und Referenzknoten gelöscht?

Raum, Taxonomien, Ausstellung und erlaubte Variantenschlüssel werden referenziert. Mehrere RESTRICT-Regeln stehen nur im Schema, nicht vollständig im Entscheidungsprotokoll.

A — Überall RESTRICT Empfehlung Parent- und verwendete Referenzknoten dürfen nicht hart gelöscht werden; zuerst werden Kinder und Zuordnungen aufgelöst. Pflegevorgänge brauchen sichtbare Fehlermeldungen und später gegebenenfalls Stilllegung. B — Stop-Referenzen SET NULL Beim Löschen verlieren betroffene Exponate ihre Zuordnung; Hierarchiekinder bleiben RESTRICT. Einfacher, aber fachlicher Kontext verschwindet still von vielen Exponaten. C — Referenzen kaskadieren Das Löschen eines Knotens entfernt auch abhängige Datensätze. Kann Exponate oder Varianten löschen und ist für Referenzdaten hochriskant. Später entscheiden

Warum A

A macht Datenverlust sichtbar und entspricht den bestätigten Regeln für Raum, Ausstellung und Standardtaxonomie.

FK 3, 5, 7, 10–13 und 18; R-06/O-5; Codex 2026-08-22.

R-40 blockiert Schema Job-Audit

Was bleibt von Jobzielen nach dem Löschen eines Exponats oder einer Textvariante?

Jobziele referenzieren Stop und optional TextVariant. Das aktuelle CASCADE löscht Zielzeilen und verändert nachträglich die Historie eines gelaufenen Jobs.

A — Zielhistorie erhalten Empfehlung Die FKs werden nullable mit SET NULL; Zielart und Ziel-UUID bleiben unveränderlich erhalten. Zusätzliche Snapshot-Felder und Nullfälle in Antwortschemas. B — Jobziele mitlöschen Das Löschen des Fachobjekts entfernt alle zugehörigen Jobziele. Einfach, aber Laufzahlen und Fehlerhistorie verlieren Belege. C — Fachobjekt-Löschung sperren Solange ein Jobziel existiert, wird das Löschen des Stops oder der Variante verweigert. Alte Jobs blockieren ohne Aufräumvertrag dauerhaft Löschvorgänge. Später entscheiden

Warum A

A trennt den Betriebsnachweis von der Lebensdauer des Fachobjekts, ohne Löschungen dauerhaft zu sperren.

FK 24/25 in jobs.ts; R-11/R-24; Codex 2026-08-22.

R-41 blockiert Schema R2

Wo liegt der eine Verarbeitungszustand eines Mehrziel-Jobs?

jobs.state und job_targets.state speichern heute dieselben vier Zustände. Ohne Ableitungsregel kann ein Job fertig sein, während noch ein Ziel läuft.

A — Zielzustände sind die Wahrheit Empfehlung Nur JobTarget speichert den Zustand; der Job-Gesamtzustand wird in einer PostgreSQL-View aggregiert. Abfragen brauchen Aggregation und eine Prioritätsregel für gemischte Zielzustände. B — Nur Jobzustand speichern Der Job trägt den einzigen Zustand; Ziele speichern nur Ergebnis oder Fehler. Per-Ziel-Fortschritt und gezielte Wiederholung werden schwächer. C — Zwei verschiedene Maschinen Orchestrierung und Zielausführung erhalten getrennte Namen, Übergangsmatrix und Constraints. Größter Modell- und Testaufwand; nur sinnvoll, wenn beide Fakten gebraucht werden. Später entscheiden

Warum A

A erfüllt R2 und erhält die für Massenläufe nötige Sicht je Ziel. Der Gesamtzustand bleibt DB-berechenbar.

jobs.ts und VERTRAG.md R-11/R-24; Codex-R2-Abgleich 2026-08-22.

R-42 blockiert Schema Identität

Welche Identität referenzieren createdBy und updatedBy?

R-13 verlangt Bearbeiterfelder, aber keine Inventur beschreibt Benutzerentität, Autorität oder Löschverhalten.

A — Externe Subject-ID Empfehlung Eine opaque, unveränderliche Subject-ID des Identity-Systems wird ohne lokalen FK gespeichert. Die DB kann die Benutzerexistenz nicht prüfen; Auflösung geschieht an der Identitätsgrenze. B — Lokale Identity-Tabelle Eine lokale Referenz verwendet RESTRICT und Stilllegung statt Löschen. Neue unvollständige Entität, Auth-Synchronisation und Lifecycle ohne Screen. C — Lokaler FK mit SET NULL Beim Löschen des Benutzers wird die Audit-Referenz entfernt. Lokale Integrität, aber die ausdrücklich geforderte Urheberschaft geht verloren. Später entscheiden

Warum A

A erfüllt die Auditentscheidung, ohne eine Benutzerentität mit unbekanntem Screen und Lifecycle zu erfinden.

VERTRAG.md R-13; unsichtbare Felder; Codex 2026-08-22.

R-43 blockiert Schema Anlage

Dürfen systemerzeugte Kindobjekte als leere Hüllen angelegt werden?

Text, Audio, Bilder, Dokumente und Medien entstehen über Aktionen. Eigene Anlage-Screens fehlen; Entwurfshüllen erzeugen zusätzliche unsichtbare Lebenszyklen.

A — Atomar vollständig anlegen Empfehlung Ein Kind entsteht erst mit Besitzer, natürlichem Schlüssel und bei Dateien vollständigen Metadaten; vorher existiert nur der Job. Fehler erzeugen kein halbes Fachobjekt und müssen vollständig am Job stehen. B — Entwurfshüllen erlauben Kindzeilen dürfen vor Inhalt oder Datei existieren und werden später vervollständigt. Zusätzliche Zustände, Aufräumregeln, Timeouts und Fehlerpfadtests je Entität. C — Nur Textentwürfe TextVariant darf leer existieren; dateibasierte Objekte entstehen atomar. Zwei Anlageprinzipien, aber Textbearbeitung kann vor Generierung beginnen. Später entscheiden

Warum A

A folgt R2 und R5: Verarbeitung bleibt am Job, und Ergebnisobjekte haben keinen halbfertigen Zustand.

Aktionen und Pflichtangaben in E; fehlende Entitätsscreens; Codex 2026-08-22.

R-44 blockiert Job-View R2

Welcher Gesamtzustand gilt bei gemischten Jobziel-Zuständen?

R-41 legt die Zielzustände als einzige gespeicherte Wahrheit fest. Für die abgeleitete Job-View fehlt noch die Priorität, wenn Ziele gleichzeitig warten, laufen, fehlschlagen oder fertig sind.

A — Aktivität vor Abschluss Empfehlung processing vor pending vor error vor done; ein Job ist erst terminal, wenn kein Ziel mehr läuft oder wartet. Eine fehlgeschlagene Teilmenge wird während restlicher Arbeit erst nach Abschluss als Gesamtfehler sichtbar; Zielzähler bleiben jederzeit sichtbar. B — Fehler hat immer Vorrang error vor processing vor pending vor done; der erste Fehler setzt den Gesamtzustand sofort auf Fehler. Noch laufende Ziele sind im Gesamtzustand nicht mehr erkennbar und brauchen zwingend zusätzliche Zähler. C — Teilfehler ergänzen Ein neuer Zustand partialError unterscheidet gemischte terminale Ergebnisse von einem vollständigen Fehler. Zusätzlicher Enumwert und zusätzliche Behandlung in jedem Verbraucher des Jobvertrags. Später entscheiden

Warum A

A bewahrt die Unterscheidung aktiv/terminal ohne einen neuen Zustand. Die View liefert zusätzlich Zielzähler, sodass Teilfehler nicht verschwinden.

Vor-Bau-Review 2026-08-22; R-41; Codex 2026-08-22.

R-34 R1

Welche Spalten der Exponatliste sind sortierbar und was ist die Standardsortierung?

Die Inventur sagt nur „nach Spalten“. Bild, Farbmarken, FP und Gesamtvollständigkeit besitzen keine fachliche Ordnung; Position und Navigation brauchen trotzdem eine stabile Sortierung.

A — Explizite Whitelist Empfehlung Sortierbar sind Titel, Inventarnummer, Kategorie, Raum, Rohmaterial-, Text- und Audio-Vollständigkeit sowie updatedAt; Standard ist updatedAt absteigend, ID aufsteigend. Eine feste Enum-Liste; sichtbare Spalten ohne Fachordnung bleiben unsortierbar. B — Kleine Kernmenge Nur Titel, Inventarnummer und updatedAt sind sortierbar. Geringster Queryaufwand, aber weniger Möglichkeiten als die Tabelle andeutet. C — Alle sichtbaren Spalten Auch Bild, Farbmarken, FP und zusammengesetzte Ampeln erhalten eine Ordnung. Für vier unklare Spalten müssten neue Regeln erfunden und DB-seitig gepflegt werden. Später entscheiden

Warum A

A deckt alle fachlich sinnvollen, in PostgreSQL berechenbaren Spalten ab, ohne künstliche Ordnungen.

L1/L2; Marker 22254 in E; Codex-R1-Abgleich 2026-08-22.

R-35 Sortierung

Wie werden alphanumerische Inventarnummern sortiert?

Museumsformate sind nicht beschrieben. Lexikalisch steht A-10 vor A-9; natürliche Sortierung braucht eine bestätigte PostgreSQL-Regel.

A — Vorläufig lexikalisch Empfehlung Unverändert nach gespeichertem Text sortieren und die Einschränkung dokumentieren. A-10 kann vor A-9 erscheinen; ein späterer Wechsel ändert Reihenfolgen, aber keine Daten. B — Natürliche DB-Sortierung Eine versionierte PostgreSQL-Funktion oder View zerlegt Ziffernblöcke. Mehr Query- und Testaufwand; Sonderformate können überraschen. C — Nummer strukturell zerlegen Präfix, laufende Nummer und Suffix werden getrennt gespeichert. Hohe Import- und Datenmigration; historische Nummern passen möglicherweise nicht. Später entscheiden

Warum A

A erfindet ohne Formatquelle keine Parsingregel. Ein späterer Wechsel zu B bleibt verlustfrei.

VERTRAG.md O-7; Listen-Inventur; Codex 2026-08-22.

R-36 Suche

Welche Menge und welche Felder durchsucht stopSearch?

Der Editor zeigt Suche, vorher/nachher und eine Listenposition. Unklar ist, ob der aktuelle Filter erhalten bleibt.

A — Aktueller Listenkontext Empfehlung Titel und Inventarnummer innerhalb desselben Mandanten-, Filter- und Sortierkontexts durchsuchen. Der Client muss den Listenkontext beim Öffnen des Editors mitführen. B — Mandantenweit Titel und Inventarnummer aller nicht archivierten Exponate durchsuchen; Filter entfallen. Einfacher, aber Suche und Position können verschiedene Mengen meinen. C — Volltext über Objektdaten Auch Künstler, Beschreibung, Provenienz und Rohmaterial durchsuchen. GIN-Index, Ranking und Sprachregeln werden ohne Screenbeleg Teil des Vertrags. Später entscheiden

Warum A

A hält Suche, Position und Navigation auf derselben Datenmenge.

Marker 74138, 22254, 25841, 74605 in E; Codex 2026-08-22.

R-37 Bulk

Ersetzt Bulk „Tags setzen“ die vollständige Farbmarkenmenge?

Die Inventur zeigt nur die Aktion. Der bestehende Vertrag nimmt Ersetzen an; diese Annahme wurde nie bestätigt.

A — Vollständig ersetzen Empfehlung Der Request sendet null bis drei Farbmarken und ersetzt den bisherigen Stand. Nicht mitgesendete Tags werden entfernt; Versionsprüfung muss Konkurrenz sichtbar machen. B — Nur hinzufügen Gewählte Tags werden ergänzt, vorhandene bleiben. Bulk-Entfernen braucht einen zweiten Vertrag; die Dreiergrenze kann Teilfehler erzeugen. C — Modus im Request Der Request trägt add, remove oder replace. Explizit und flexibel, aber größerer Vertrag und mehr Kombinationstests. Später entscheiden

Warum A

A ist der kleinste eindeutige Vertrag, passt zum Wort „setzen“ und zur bestehenden Annahme.

Marker 63185 in L1/L2; VERTRAG.md O-6; Codex 2026-08-22.

Offene Entscheidungen für den Exponat-Vertrag

Die neun Entscheidungen, die Schema oder Grundvertrag blockieren

Bedeutet Marker 32692 die letzte fachliche Änderung oder den letzten Speichervorgang?

Wie wird das sichtbare Feld „Abmessungen“ R7-konform gespeichert?

Darf eine Mandantenlöschung alle zugehörigen Domänendaten kaskadierend löschen?

Wie werden verwendete Hierarchie- und Referenzknoten gelöscht?

Was bleibt von Jobzielen nach dem Löschen eines Exponats oder einer Textvariante?

Wo liegt der eine Verarbeitungszustand eines Mehrziel-Jobs?

Welche Identität referenzieren createdBy und updatedBy?

Dürfen systemerzeugte Kindobjekte als leere Hüllen angelegt werden?

Welcher Gesamtzustand gilt bei gemischten Jobziel-Zuständen?

Die vier Entscheidungen für Listen- und Aktionsverträge

Welche Spalten der Exponatliste sind sortierbar und was ist die Standardsortierung?

Wie werden alphanumerische Inventarnummern sortiert?

Welche Menge und welche Felder durchsucht stopSearch?

Ersetzt Bulk „Tags setzen“ die vollständige Farbmarkenmenge?