Skip to content

feat: Semantic Session Ledger mit Oracle-Verifizierung und Auto-Summaries #43

@Delqhi

Description

@Delqhi

Ich erstelle jetzt den Text für das neue GitHub Issue:

Hier ist der Text für das neue Issue:


feat: Semantic Session Ledger mit Oracle-Verifizierung und Auto-Summaries

🎯 Problem Statement

Aktuelle Coding-Agent CLIs (Claude Code, OpenCode, Aider, Codex) haben fundamentale Schwächen im Session-Management:

  • Agenten suchen ewig und finden nichts — irrelevante Tool-Calls, Web-Searches, gescheiterte Versuche füllen den Kontext
  • Kein automatischer Schrott-Filter — alles wird 1:1 geloggt, keine semantische Analyse
  • Kein Git-Commit-System — Sessions sind nur flache Dateien, nicht versioniert oder forensisch nachvollziehbar
  • Zusammenfassungen sind dürftig — nur LLM-Prosa ohne strukturierte Metadaten
  • Keine Integration mit Codebase-Knowledge — Sessions verstehen nicht, welche Module/Hot-Paths betroffen sind

Resultat: Sessions sind forensisch wertlos, schwer durchsuchbar und können nicht als strukturierte Assets des Repositories genutzt werden.

💡 Die SIN-Code Lösung: "Semantic Session Ledger & Oracle Verification"

Im Gegensatz zu generischen Lösungen (die nur Phi-4-mini oder Qwen-2.5-1.5B nutzen), nutzt SIN-Code die vollen Subsysteme des Stacks:

Subsystem Rolle im Session-Management
Oracle Unabhängige Verifikation: erkennt Schrott (Halluzinationen, repetitive Loops, PII-Leaks)
SCKG Semantic Codebase Knowledge Graph: mappt welche Module/Entry-Points/Hot-Paths betroffen sind
IBD Intent-Based Semantic Diffing: analysiert strukturelle Code-Änderungen (nicht nur Text-Diffs)
ADW Architectural Debt Watchdog: trackt technische Schulden pro Session
POC Proof of Correctness: verifiziert mathematisch/logisch korrekte Änderungen
RTK Token-Tracking: exakte Token-Kosten und Einsparungen pro Session

🏗️ Architektur

┌─────────────────────────────────────────────────────────────────┐
│                    SIN-CODE SESSION ENGINE                        │
└─────────────────────────────────────────────────────────────────┘

┌──────────────┐    ┌──────────────┐    ┌──────────────────────┐
│  User TUI    │───▶│  Agent-Core  │───▶│   Session Writer     │
│              │    │              │    │   (Hash-Chain)       │
└──────────────┘    └──────┬───────┘    └──────────┬───────────┘
                           │                       │
                           ▼                       ▼
                ┌──────────────────────┐    ┌──────────────────────┐
                │  Layer 1: Hash-Chain │    │  Layer 2: SQLite     │
                │  .sin/ledger/        │    │  .sin/sessions.db    │
                │  (kryptografisch)    │    │  (schnelle Queries)  │
                └──────────┬───────────┘    └──────────┬───────────┘
                           │                           │
                           ▼                           ▼
┌──────────────┐    ┌──────────────┐    ┌──────────────────────┐
│  Background  │◀───│   Oracle     │◀───│  Layer 3: Git        │
│  Oracle-GC   │    │  (Schrott-   │    │  .sin/archive/       │
│  (Verifizer) │    │   Filter)    │    │  (versioniert)       │
└──────┬───────┘    └──────────────┘    └──────────┬───────────┘
       │                                           │
       ▼                                           ▼
┌──────────────┐                        ┌──────────────────────┐
│  Redaction   │                        │  Auto-Summary-Engine │
│  Commits     │                        │  SESSION_SUMMARY.md  │
│  (Tombstone) │                        │  + summary.json      │
└──────────────┘                        └──────────────────────┘

🔥 Die 5 Killer-Features

1. Kryptografische Hash-Chain (statt nur JSONL)

Jedes Event (User-Prompt, LLM-Reasoning, Tool-Call, File-Edit) wird als Transaktion in eine Hash-Chain geschrieben:

{
  "event_hash": "sha256:a1b2c3...",
  "parent_hash": "sha256:f4e2a1...",
  "timestamp": "2026-06-08T10:23:14Z",
  "event_type": "tool_call",
  "git_state": {
    "branch": "main",
    "head": "f4e2a1",
    "dirty_files": [],
    "staged_changes": []
  },
  "event_data": {
    "tool": "Read",
    "input": {"file": "src/server.ts"},
    "output": "...",
    "tokens_used": 1240
  }
}

Vorteil: Nachträgliches Löschen eines einzelnen Records bricht die Integrität aller nachfolgenden Events (Avalanche-Effekt). Manipulationen sind sofort sichtbar.

2. Background Oracle: Schrott filtern & nachweislich löschen

Das Oracle-Subsystem (nicht nur ein billiges LLM) streamt das rohe Ledger und erkennt:

  • PII-Leaks (Secrets, Credentials)
  • Repetitive Tool-Loops (Endlos-Suchen)
  • Irrelevante Kontext-Generierung
  • Halluzinierte API-Calls

Verifiable Deletion (Nachweisliches Löschen):
Anstatt Daten stillschweigend zu überschreiben (was die Hash-Chain invalidieren würde), erstellt das Oracle einen "Redaction Commit" (Tombstone):

{
  "event_hash": "sha256:deadbeef...",
  "parent_hash": "sha256:a1b2c3...",
  "event_type": "oracle.redaction",
  "target_event_hash": "sha256:xyz123...",
  "reason": "PII-Leak: AWS_ACCESS_KEY in tool_result",
  "confidence": 0.98,
  "oracle_model": "claude-opus-4-5",
  "timestamp": "2026-06-08T10:25:47Z"
}

CLI-Command:

sin session audit sin-2026-06-08-xyz
# Zeigt: 3 Events wurden vom Oracle gelöscht (2x PII, 1x Halluzination)
# git log --grep="^oracle.redaction:" zeigt alle Löschungen

3. Auto-Generierte Semantische Session-Zusammenfassung

Während andere Tools nur Text zusammenfassen, generiert SIN-Code vollautomatisch und für den User unsichtbar eine SESSION_SUMMARY.md + summary.json:

SESSION_SUMMARY.md (Beispiel)

# Session Summary: sin-2026-06-08-xyz

## 🎯 Intent
Implementierung von JWT-Auth + Rate-Limiting für Express-Server

## 👤 Wer
- User: alice (developer)
- Agent-Model: claude-opus-4-5
- Oracle-Model: claude-opus-4-5

## ⏰ Wann
- Start: 2026-06-08T10:23:14Z
- Ende: 2026-06-08T11:47:32Z
- Dauer: 1h 24m 18s
- Aktive Turns: 47

## 📍 Wo — Dateien geändert (IBD-Analyse)
| Datei | Aktion | Semantic Changes | Structural Changes | Commit |
|-------|--------|------------------|--------------------|---------|
| src/auth/jwt.ts | created | +87 / -0 | +3 functions | a3f2e1 |
| src/server.ts | modified | +12 / -3 | +1 middleware | b7c4d2 |
| tests/auth.test.ts | created | +124 / -0 | +5 test cases | c9e5f3 |

## ❓ Warum — User Intent (Oracle-extrahiert)
1. JWT-Auth mit refresh-tokens implementieren
2. Rate-Limiting gegen DDoS hinzufügen
3. Tests schreiben

## ✅ Weshalb — Ergebnis
- ✅ JWT-Auth vollständig implementiert (POC-verifiziert)
- ✅ Rate-Limiting konfiguriert (100 req/15min)
- ⚠️ Tests für refresh-token flow fehlen noch (TODO)
- ❌ WebSocket-Auth abgebrochen (Out-of-Scope)

## 🏗️ SCKG Impact (Knowledge Graph Delta)
- Modules affected: `auth`, `server`
- Hot paths changed: `/api/login`, `/api/refresh`
- Knowledge graph: +3 nodes, +7 edges

## 💰 ADW Debt Delta
- Technical debt added: -2h (Refactoring verbessert)
- Technical debt removed: +5h (neue Features)
- Net debt change: -3h

## 🧮 RTK Token-Kosten
- Input: 128,400 tokens
- Output: 14,230 tokens
- GC-Overhead: 2,100 tokens (1.5%)
- Tokens saved via RTK: 45,000
- Kosten: $1.47

## 🔍 Oracle-GC Statistik
- Turns analysiert: 47
- Redacted (PII/Secrets): 3
- Redacted (Halluzinationen): 5
- Redacted (repetitive Loops): 6
- Keep-Rate: 70%

summary.json (Strukturiert)

{
  "sessionId": "sin-2026-06-08-xyz",
  "intent": {
    "original": "Implementiere JWT-Auth + Rate-Limiting",
    "extracted": ["JWT-Auth", "Rate-Limiting", "Tests"],
    "oracle_verified": true
  },
  "sckg_impact": {
    "modules_affected": ["auth", "server"],
    "hot_paths_changed": ["/api/login", "/api/refresh"],
    "knowledge_graph_delta": "+3 nodes, +7 edges"
  },
  "ibd_analysis": {
    "semantic_changes": 4,
    "structural_changes": 2,
    "intent_alignment": 0.87
  },
  "adw_debt_delta": {
    "technical_debt_added": "-2h",
    "technical_debt_removed": "+5h",
    "net_debt_change": "-3h"
  },
  "poc_verification": {
    "functions_verified": ["jwt.sign", "rateLimiter.configure"],
    "proof_status": "verified"
  },
  "rtk_token_tracking": {
    "input_tokens": 128400,
    "output_tokens": 14230,
    "gc_overhead_tokens": 2100,
    "tokens_saved_via_rtk": 45000,
    "cost_usd": 1.47
  },
  "oracle_redactions": [
    {
      "target_event_hash": "sha256:xyz123...",
      "reason": "PII-Leak: AWS_ACCESS_KEY",
      "confidence": 0.98
    }
  ]
}

4. Proaktive Compaction bei 70% Context (nicht erst bei 95% wie Claude Code)

Das Oracle überwacht das Context-Window und triggert automatisch:

  • 70% Context: Proaktive Compaction + Summary-Generierung
  • 85% Context: Aggressiver GC + Redaction Commits
  • 95% Context: Emergency Session-Split (neue Session mit Kontext-Transfer)

5. Session-Diff mit IBD-Integration

sin session diff <id1> <id2> nutzt nicht nur Text-Diffs, sondern das IBD-Subsystem für semantische Vergleiche:

  • Welche Intents wurden verfolgt?
  • Welche architektonischen Entscheidungen wurden getroffen?
  • Wie unterscheiden sich die Debt-Deltas?
  • Welche Module waren betroffen?

📁 Verzeichnisstruktur

.sin/
├── ledger/
│   ├── sin-2026-06-08-xyz.jsonl          # Hash-Chain (append-only)
│   └── ...
├── sessions.db                            # SQLite für Queries
├── summaries/
│   ├── sin-2026-06-08-xyz/
│   │   ├── SESSION_SUMMARY.md             # Auto-generiert
│   │   ├── summary.json                   # Strukturiert
│   │   ├── files-changed/                 # Snapshots
│   │   └── redactions/                    # Oracle-Löschungen
│   └── ...
└── archive/                               # Git-Repo mit allen Sessions
    ├── .git/
    ├── sessions/
    └── commits.jsonl                      # Commit-Metadaten

🛠️ CLI-Commands

sin session list                    # Alle Sessions auflisten
sin session show <session-id>       # Summary anzeigen
sin session audit <session-id>      # Oracle-Redactions anzeigen
sin session gc <session-id>         # Manueller GC-Lauf
sin session compact <session-id>    # Compaction erzwingen
sin session export <id> --json      # Export
sin session resume <session-id>     # Fortsetzen
sin session diff <id1> <id2>        # Sessions vergleichen (IBD)
sin gc stats                        # GC-Statistiken

🚀 Implementierungsplan

Phase 1: Foundation (Week 1-2)

  • Hash-Chain Writer (Go-Tool: sin session writer)
  • SQLite-Integration für schnelle Queries
  • Git-Archive Setup (.sin/archive/)

Phase 2: Oracle-GC Integration (Week 3-4)

  • Background Oracle Daemon (streamt Ledger)
  • Redaction Commit Logic (Tombstones)
  • sin session audit Command

Phase 3: Auto-Summary Engine (Week 5-6)

  • IBD-Integration für semantische Diffs
  • SCKG-Integration für Module/Hot-Paths
  • ADW-Integration für Debt-Tracking
  • POC-Integration für Verifikation
  • RTK-Integration für Token-Tracking

Phase 4: CLI & UX (Week 7-8)

  • Alle CLI-Commands implementieren
  • Proaktive Compaction (70%/85%/95%)
  • Session-Diff mit IBD
  • Dokumentation & Testing

📊 Vergleich mit anderen Tools

Feature Claude Code OpenCode Aider sin-code
Hash-Chain (kryptografisch) ❌ (nur JSONL) ❌ (SQLite) ❌ (MD)
DAG via parentUuid
Git-State Snapshot ✅ (einmalig) ✅ (pro Event)
Oracle-GC
Nachweisbare Löschung ✅ (Tombstones)
SCKG-Integration
IBD-Integration
ADW-Integration
POC-Integration
RTK-Integration
Strukturierte Summary ❌ (nur Prosa)
Token-Tracking pro Turn
Proaktive Compaction (70%) ❌ (95%)
Session-Diff (semantisch) ✅ (IBD)

🎯 Warum das den Markt dominiert

Tools wie Claude Code oder Aider sind im Grunde "Diktiergeräte" für Code. SIN-Code hingegen ist ein forensisches, semantisches Betriebssystem für KI-Agenten. Durch die Kombination aus:

  • Kryptografischer Hash-Chain
  • Oracle als unabhängigen Verifizierer
  • SCKG/IBD für semantisches Verständnis
  • ADW/POC/RTK für Debt/Verifikation/Kosten

...wird jede Session zu einem strukturierten, verifizierbaren und schuldenbewussten Asset des Repositories – komplett automatisch und ohne dass der User je einen Handgriff tun muss.

📝 Nächste Schritte

Soll ich jetzt:

  1. Das komplette Hash-Chain-Schema designen (mit Go-Types)?
  2. Den Oracle-GC-Algorithmus im Detail implementieren?
  3. Die Auto-Summary-Prompts entwickeln (für strukturierte Metadaten)?
  4. Einen funktionierenden Prototyp mit einer Session bauen?

Labels: feat, session-management, oracle, sckg, ibd, adw, poc, rtk


Bereit zum Posten? Dann erstelle ich danach direkt den Code für Phase 1 (Hash-Chain Writer + SQLite-Integration).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions