Deklarix war eine Pre-Publish-Kennzeichnungsprüfung für Werbe-Content
(UWG/MStV). Dieser Scope wird komplett verworfen und durch eine
KI-Antragsprüfung ersetzt: Mitarbeitende beschreiben ein KI-Vorhaben,
das System leitet Datenklasse und KI-VO-Einstufung ab, gleicht sie
gegen einen Werkzeugkatalog ab und erzeugt einen Entscheidungsvorschlag
mit Herleitung — ein Mensch entscheidet, das System bereitet nur vor.
BREAKING CHANGE: Migration 0008 droppt alle werberechtsspezifischen
Tabellen (submission, finding, extraction, evidence_package,
participant, platform_connection, asset). account/app_user/session/
audit_log bleiben (Mandantentrennung, Login, Protokollierung sind
produktunabhängig) — app_user.role wechselt von
creator/agentur/marke/kanzlei/admin zu den fünf neuen Rollen
mitarbeiter/verantwortlicher/pruefer/admin/betreiber (vier
Mandanten-Rollen + eine plattformweite, siehe CLAUDE.md).
Entfernt: internal/extract, internal/dossier, internal/evidence,
internal/socialconnect, alte rules/*.yaml (UWG-Regeln), testdata/golden
— alles ausschließlich für das alte Produkt.
Neu, Phase 1 der Baureihenfolge ("Datenmodell, Regelwerk als YAML,
Katalogstruktur"):
- Store: abteilung (Stammdaten), werkzeug + werkzeug_sperre (der
eigentliche Wert des Produkts — zentral gepflegter Katalog mit
mandantenspezifischen Ergänzungen/Sperrungen, Pflichtfelder
letzte_pruefung/quelle für jede Zusicherung), antrag (Fragebogen-
Grundgerüst, Antworten als JSONB für den adaptiven Fragebogen aus
Phase 2).
- internal/rules komplett neu: lädt und validiert drei YAML-
Regelwerke (Datenklasse-Ableitung, KI-VO-Einstufung, Anforderungs-
profil) aus rules/*.yaml — noch ohne Auswertungslogik gegen echte
Fragebogen-Antworten (das ist Phase 3, bewusst erst nach dem
Fragebogen aus Phase 2, der die exakten Fakten-Feldnamen festlegt).
Offene fachliche Annahmen (Rangfolge der Datenklassen, Fragebogen-
Lücke für die "verboten"-Varianten) explizit in rules/OPEN.md
dokumentiert statt geraten.
- Web-Layer auf Minimalgerüst reduziert, das kompiliert und die neue
Rollenwelt trägt: Firma-Registrierung (Ebene 1, erster Nutzer wird
admin), Login/Logout, Plattform-Bereich (Ebene 5, nur betreiber:
Dashboard, Accounts-Übersicht, Audit-Log) — Fragebogen (Ebene 2) und
Fachebene (Ebene 3) folgen in den nächsten Phasen.
- CLAUDE.md komplett neu geschrieben: Produktbeschreibung, Fünf-Ebenen-
Rollenmodell, Fragebogen-Spezifikation, Ableitungstabellen,
Werkzeugkatalog, Bewertungslogik (geplant), Onboarding, offene
Punkte (u. a. Postgres-RLS-Frage aus der Frontend-Spezifikation
noch nicht entschieden, "Admin und Verantwortlicher gleichzeitig"
beim Onboarding noch nicht datenmodelliert).
Volle Testsuite inkl. echter Postgres-Tests grün. End-to-End gegen
einen laufenden Server verifiziert: Firma-Registrierung legt Account +
admin-Nutzer an, Betreiber-Login leitet zu /betreiber, mandanten-
übergreifende Accounts-Liste sichtbar für betreiber, 404 für
mitarbeiter auf /betreiber, 303 zu /login ohne Sitzung.
136 lines
4.4 KiB
Go
136 lines
4.4 KiB
Go
package store
|
|
|
|
import (
|
|
"context"
|
|
"errors"
|
|
"fmt"
|
|
"time"
|
|
|
|
"github.com/jackc/pgx/v5"
|
|
)
|
|
|
|
// Antrag ist ein Vorhaben aus dem Fragebogen (Abschnitt A) mit den
|
|
// vollständigen Antworten aus B/C/D als JSON — der Fragebogen ist
|
|
// adaptiv (Folgefragen hängen von vorherigen Antworten ab), ein starres
|
|
// Spaltenschema könnte das nicht abbilden. Antworten ist bewusst
|
|
// []byte (rohes JSON), nicht ein aufgelöster Go-Typ — die Struktur der
|
|
// Antworten ist Sache von internal/rules (Stufe 2), store speichert nur.
|
|
type Antrag struct {
|
|
ID string
|
|
AccountID string
|
|
ErstellerUserID string
|
|
AbteilungID *string
|
|
Titel string
|
|
Beschreibung string
|
|
Ergebnis string
|
|
Haeufigkeit string
|
|
Antworten []byte
|
|
Status string
|
|
CreatedAt time.Time
|
|
UpdatedAt time.Time
|
|
}
|
|
|
|
const antragColumns = `id, account_id, ersteller_user_id, abteilung_id, titel, beschreibung,
|
|
ergebnis, haeufigkeit, antworten, status, created_at, updated_at`
|
|
|
|
func scanAntrag(row interface {
|
|
Scan(dest ...any) error
|
|
}) (Antrag, error) {
|
|
var a Antrag
|
|
err := row.Scan(
|
|
&a.ID, &a.AccountID, &a.ErstellerUserID, &a.AbteilungID, &a.Titel, &a.Beschreibung,
|
|
&a.Ergebnis, &a.Haeufigkeit, &a.Antworten, &a.Status, &a.CreatedAt, &a.UpdatedAt,
|
|
)
|
|
return a, err
|
|
}
|
|
|
|
// CreateAntrag legt einen neuen Antrag im Status "entwurf" an.
|
|
func (s *Store) CreateAntrag(ctx context.Context, accountID, erstellerUserID string, abteilungID *string, titel string) (Antrag, error) {
|
|
row := s.Pool.QueryRow(ctx, `
|
|
INSERT INTO antrag (account_id, ersteller_user_id, abteilung_id, titel)
|
|
VALUES ($1, $2, $3, $4)
|
|
RETURNING `+antragColumns,
|
|
accountID, erstellerUserID, abteilungID, titel,
|
|
)
|
|
a, err := scanAntrag(row)
|
|
if err != nil {
|
|
return Antrag{}, fmt.Errorf("store: create antrag: %w", err)
|
|
}
|
|
return a, nil
|
|
}
|
|
|
|
// GetAntrag liest einen Antrag anhand seiner ID — ohne Mandanten-Prüfung,
|
|
// das ist Sache des Aufrufers (siehe Antrag.AccountID).
|
|
func (s *Store) GetAntrag(ctx context.Context, id string) (Antrag, error) {
|
|
row := s.Pool.QueryRow(ctx, `SELECT `+antragColumns+` FROM antrag WHERE id = $1`, id)
|
|
a, err := scanAntrag(row)
|
|
if errors.Is(err, pgx.ErrNoRows) {
|
|
return Antrag{}, ErrNotFound
|
|
}
|
|
if err != nil {
|
|
return Antrag{}, fmt.Errorf("store: get antrag: %w", err)
|
|
}
|
|
return a, nil
|
|
}
|
|
|
|
// UpdateAntragFelder aktualisiert die Fragebogen-Felder eines Antrags —
|
|
// solange er im Entwurf ist, kann der Fragebogen adaptiv weiter
|
|
// ausgefüllt werden (Sache der Anwendungsschicht, store erzwingt den
|
|
// Status hier nicht).
|
|
func (s *Store) UpdateAntragFelder(ctx context.Context, id, titel, beschreibung, ergebnis, haeufigkeit string, antworten []byte) (Antrag, error) {
|
|
row := s.Pool.QueryRow(ctx, `
|
|
UPDATE antrag SET
|
|
titel = $2, beschreibung = $3, ergebnis = $4, haeufigkeit = $5, antworten = $6, updated_at = now()
|
|
WHERE id = $1
|
|
RETURNING `+antragColumns,
|
|
id, titel, beschreibung, ergebnis, haeufigkeit, antworten,
|
|
)
|
|
a, err := scanAntrag(row)
|
|
if errors.Is(err, pgx.ErrNoRows) {
|
|
return Antrag{}, ErrNotFound
|
|
}
|
|
if err != nil {
|
|
return Antrag{}, fmt.Errorf("store: update antrag felder: %w", err)
|
|
}
|
|
return a, nil
|
|
}
|
|
|
|
// SetAntragStatus setzt den Status eines Antrags (entwurf -> eingereicht
|
|
// -> entschieden). Antrag ist, anders als bewertung/entscheidung, NICHT
|
|
// append-only — der Lebenszyklus ist eine normale Zustandsänderung.
|
|
func (s *Store) SetAntragStatus(ctx context.Context, id, status string) error {
|
|
tag, err := s.Pool.Exec(ctx, `UPDATE antrag SET status = $2, updated_at = now() WHERE id = $1`, id, status)
|
|
if err != nil {
|
|
return fmt.Errorf("store: set antrag status: %w", err)
|
|
}
|
|
if tag.RowsAffected() == 0 {
|
|
return ErrNotFound
|
|
}
|
|
return nil
|
|
}
|
|
|
|
// ListAntraegeForAccount liefert alle Anträge eines Mandanten, neueste
|
|
// zuerst.
|
|
func (s *Store) ListAntraegeForAccount(ctx context.Context, accountID string) ([]Antrag, error) {
|
|
rows, err := s.Pool.Query(ctx, `
|
|
SELECT `+antragColumns+` FROM antrag WHERE account_id = $1 ORDER BY created_at DESC
|
|
`, accountID)
|
|
if err != nil {
|
|
return nil, fmt.Errorf("store: list antraege for account: %w", err)
|
|
}
|
|
defer rows.Close()
|
|
|
|
var out []Antrag
|
|
for rows.Next() {
|
|
a, err := scanAntrag(rows)
|
|
if err != nil {
|
|
return nil, fmt.Errorf("store: scan antrag: %w", err)
|
|
}
|
|
out = append(out, a)
|
|
}
|
|
if err := rows.Err(); err != nil {
|
|
return nil, fmt.Errorf("store: list antraege for account: %w", err)
|
|
}
|
|
return out, nil
|
|
}
|