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)
Phase 2: Oracle-GC Integration (Week 3-4)
Phase 3: Auto-Summary Engine (Week 5-6)
Phase 4: CLI & UX (Week 7-8)
📊 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:
- Das komplette Hash-Chain-Schema designen (mit Go-Types)?
- Den Oracle-GC-Algorithmus im Detail implementieren?
- Die Auto-Summary-Prompts entwickeln (für strukturierte Metadaten)?
- 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).
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:
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:
🏗️ Architektur
🔥 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:
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:
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)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:
5. Session-Diff mit IBD-Integration
sin session diff <id1> <id2>nutzt nicht nur Text-Diffs, sondern das IBD-Subsystem für semantische Vergleiche:📁 Verzeichnisstruktur
🛠️ CLI-Commands
🚀 Implementierungsplan
Phase 1: Foundation (Week 1-2)
sin session writer).sin/archive/)Phase 2: Oracle-GC Integration (Week 3-4)
sin session auditCommandPhase 3: Auto-Summary Engine (Week 5-6)
Phase 4: CLI & UX (Week 7-8)
📊 Vergleich mit anderen Tools
🎯 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:
...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:
Labels:
feat,session-management,oracle,sckg,ibd,adw,poc,rtkBereit zum Posten? Dann erstelle ich danach direkt den Code für Phase 1 (Hash-Chain Writer + SQLite-Integration).