KIglove – Projekt- und Operationssystem

1. Ziel

KIglove ist ein selbst-dokumentierendes, KI-gesteuertes System zur sicheren Organisation und Ausführung von Datei- und Datenbankoperationen über eine versionierte JSON-REST-API.

Die zentrale Leitidee lautet:

> Keine Mutation ohne Projektkontext, existierenden Task, benanntes Ziel, Begründung, Regelprüfung, Sicherung und Protokolleintrag.

2. Aufgabe

KIglove organisiert:

• Projekte und deren technische Verbindungen, zum Beispiel SSH und Docker.
• Tasks als verpflichtende Änderungsfreigabe.
• zentrale Regeln mit Kontext, Guidelines und deterministischen Contracts.
• Datei- und Datenbankoperationen.
• projektbezogene History-Sicherungen.
• ein zentrales API-Transaktionsprotokoll.
• regelbasiertes, projektbezogenes PII-Tokenizing.
• automatisch erzeugte und versionierte Endpoint-Dokumentation.

3. URL-Struktur

• /kiglove/ – diese Übersicht.
• /kiglove/ziel-scope – Ziel, Scope und Abgrenzung.
• /kiglove/projekte – Projekte und Verbindungen.
• /kiglove/api-sicherheit – Bearer, IP-Allowlist und Rate-Limit.
• /kiglove/task-mutation – harte Task-Pflicht für Mutationen.
• /kiglove/regelwerk – Regeln, Kontext, Guideline und Contract.
• /kiglove/history – Sicherungen vor Datei-/DB-Änderungen.
• /kiglove/pii – PII-Tokenizing und Rückauflösung.
• /kiglove/endpoints – Endpoint-Registry und Versionierung.

4. Harte Systemregeln

1. Jede Mutation hat einen project_id.

2. Jede Mutation hat eine existierende task_id.

3. Jede Mutation benennt target_type und target_path beziehungsweise das konkrete DB-Objekt.

4. Jede Mutation enthält eine Begründung mit mindestens zehn Wörtern.

5. Vor jeder Mutation wird eine projektbezogene History-Sicherung erzeugt.

6. Jede API-Transaktion wird in protokoll gespeichert.

7. Regeln werden vor der Operation deterministisch ausgewertet; ein Contract-Verstoß beendet die Operation.

8. DELETE für Tasks ist verboten.

9. Bearer-Token, Secrets und unmaskierte PII werden nie in Logs oder History gespeichert.

5. Zielarchitektur

KI / Client
  -> Bearer + IP-Allowlist + Rate-Limit
  -> Endpoint-Contract und Version
  -> Projektauflösung
  -> Task-/Ziel-/Begründungsprüfung
  -> Regelauflösung und deterministische Contract-Prüfung
  -> PII-Encode
  -> History-Sicherung
  -> Datei- oder Datenbankoperation
  -> PII-Decode für berechtigte Antwort
  -> Protokollierung

6. Minimales Datenmodell

Bereits vorhanden:

• tasks: Task-ID, Titel, Enum-Status und Detail/Begründung.
• protokoll: ID, Zeitstempel und JSON-Details.

Für KIglove zusätzlich erforderlich:

• projects: Projekt-ID, Schlüssel, Name, Status und Metadaten.
• project_connections: Projektbezug, Typ (ssh, docker, postgres, ...), Ziel, Secret-Referenz und Konfiguration.
• project_rules: Projektbezug, Scope-Pfad, Kontext, Guideline, Contract, Priorität und Aktivstatus.
• project_history: Projekt, Task, Ziel, Operation, Snapshot-Referenz, Hash und Zeitstempel.
• pii_rules und pii_tokens: Klassifikation, Tokenformat, verschlüsselte Rückauflösung und Cache-Metadaten.
• api_endpoints: Version, Verb, Pfad, Contract, Operation und Aktivstatus.

Secret-Werte werden ausschließlich über Secret-Referenzen bezogen; niemals als Klartext in projects oder project_connections.

7. Aktueller Stand versus Ziel

Bereits aktiv im WSW-MVP:

• Datei-API mit Sandbox.
• Tasks erstellen, lesen und aktualisieren, ohne DELETE.
• harte task_id-Pflicht für Datei-Mutationen.
• zentrale Protokollierung.
• PostgreSQL-Datenbank wsw.
• Darstellung unter /adm/tasks und /protokoll.

Noch Zielanforderung für KIglove:

• Bearer-Token, IP-Allowlist und Rate-Limit.
• Projekt- und Verbindungsverwaltung.
• Regel-/Contract-Engine.
• History-Sicherung vor jeder Datei- und DB-Mutation.
• PII-Modul.
• automatische Endpoint-Registry und Code-/Dokumentationsgenerierung.

Die Zielanforderungen dürfen nicht als bereits produktiv aktiv angenommen werden.

8. Nicht im Scope

• unkontrollierter Zugriff auf das Betriebssystem.
• Speicherung von SSH-, Docker- oder DB-Secrets im Klartext.
• stilles Überspringen von Regeln, Tasks, History oder Protokollierung.
• autonome Schemaänderungen ohne versionierte Migration.
• unversionierte, nicht dokumentierte Endpoints.