recludOS Legacy - Museumsstück

Status: 🏛️ DEPRECATED / LEGACY Version: 3.3.0 (Final) Archiviert: 2026-02-21 Nachfolger: BACH v1.1

---

⚠️ WICHTIGER HINWEIS

Dies ist ein ARCHIVIERTES SYSTEM. recludOS wurde vollstaendig durch BACH ersetzt (aktuell v3.7+).

Warum archiviert?

• Fragmentierung: Dateien ueber viele Ordner verstreut, keine zentrale Struktur
• Flache Ordnerstruktur: Alles auf einer Ebene, keine klare Hierarchie
• JSONs nicht zentralisiert: 50+ JSON-Dateien an verschiedenen Orten statt an einem Ort
• Wartbarkeit: Mit wachsendem Umfang wurde das System schwer navigierbar
• BACH bietet bessere Strukturierung, DB-Integration und Memory-Modelle

Dieses Repository dient als:

• Historische Referenz
• Lern-Ressource fuer innovative Konzepte
• Museumsstueck (ausfuehrbar aber nicht produktiv)

---

📋 Inhaltsverzeichnis

1. Was war recludOS?
2. Architektur-Ueberblick
3. Kern-Konzepte
4. Verzeichnis-Struktur
5. Demo starten
6. Innovative Features
7. Warum migriert zu BACH?
8. Weiterführende Dokumentation
9. Lizenz

---

Was war recludOS?

recludOS (Recursive Claude Operating System) war ein experimentelles Verwaltungssystem für Claude-basierte AI-Agenten mit folgenden Zielen:

• Autonomie: Claude sollte sich selbst verwalten und verbessern koennen
• Lernen: Evolution-Learning mit Mutation + Selektion
• Delegation: Automatische Verteilung von Tasks auf 6 Actor-Kategorien
• Budget-Aware: Token-bewusste Steuerung mit 4 Zonen (GREEN/YELLOW/ORANGE/RED)
• Tool Discovery: Automatische Erkennung neuer Python-Tools

Zeitlinie

Datum	Version	Meilenstein
2025-11	1.0.0	Erstes Proof-of-Concept
2025-12-22	2.0.0	MAJOR REFACTORING - Neue Hauptstruktur
2025-12-25	3.0.0	Pfad-Heilung, Directory Watcher, Connections
2025-12-29	3.1.0	Akteure-Modell v2.0 (6 Kategorien)
2026-01	3.3.0	Distribution & Identity System (Final)
2026-02	-	Migration zu BACH v1.1

---

Architektur-Ueberblick

System-Komponenten

recludOS/
├── main/
│   ├── system/
│   │   ├── boot/          ⭐ Kern-System (Entry Point)
│   │   ├── act/           Aktionen (code, communicate, delegate, ...)
│   │   └── controll/      Steuerung (manage/, registry/, SystemCenter/)
│   ├── tools/             Tools & Agents
│   ├── connections/       Multi-LLM Kommunikation
│   ├── storage/           Projekte, Reports, Snapshots
│   └── gui/               Control Center, Dashboards
├── User/
│   ├── MessageBox/        User ↔ Claude Interface
│   └── Tools/             User-Tools
└── Workspace/             Temporaerer Arbeitsbereich

Boot-Sequenz (5 Phasen)

1. Phase 0: Pre-Boot - System-Zeit, Directory Scan
2. Phase 1: Version Check - Lokale vs. Kontext, Pfad-Heilung
3. Phase 2: Meta-Systeme - Task Manager, Memory, Registries
4. Phase 3: Optional - Bootstrap Integration, Tool Discovery
5. Phase 4: Micro-Routines - 14 Pre-Checks + 6 Post-Actions

---

Kern-Konzepte

1. Akteure-Modell (6 Kategorien)

recludOS orchestrierte 6 unterschiedliche "Akteure":

Akteur	Staerken	Kosten	Delegation-Trigger
User	Entscheidungen, Kreativitaet	Zeit	Komplexe Fragen
Claude	Reasoning, Orchestrierung	Tokens (teuer!)	Nur Komplexes
Scripts	Batch, Automatisierung	CPU (billig)	Bulk-Operationen
Local AI (Ollama)	RAG, Bulk-Text	GPU (lokal)	Zusammenfassungen
Online Tools	Spezial-Services	API-Calls	Format-Konvertierung
Queue	Async-Processing	Wartezeit	Non-Critical Tasks

2. Token Budget Zones

Zone	Budget	Claude-Modus	Delegation
🟢 GREEN	<50%	Normal	Keine
🟡 YELLOW	50-80%	Normal + Hints	Batch→Scripts, Text→Ollama
🟠 ORANGE	80-95%	Nur Komplex	Aggressiv
🔴 RED	>95%	Nur Kritisch	Alles→MessageBox

3. Micro-Routines

14 Pre-Prompt Checks:

• check-001: MessageBox Scan
• check-002: Load Last Snapshot
• check-003: Task Status Update
• check-004: Token Budget Check
• check-005: Daily Initialization
• ... (siehe boot/micro-routines.json)

6 Post-Response Actions:

• action-001: Create Snapshot
• action-002: Update Task Manager
• action-003: Log Lesson Learned
• ... (siehe boot/micro-routines.json)

4. Evolution Learning (Konzept — nie produktiv eingesetzt)

Das System sah vor, dass Skills sich automatisch verbessern koennen:

• Mutation: Kontrollierte Code-Aenderungen (max 50% Token-Anstieg)
• Fitness: (token_eff * 0.3) + (user_feedback * 0.4) + (error_rate * 0.2) + (completion * 0.1)
• Selektion: Schlechte Mutationen → Rollback, Gute → Behalten
• Immune System: Max 3 Fehler → Quarantaene

Hinweis: Dieses System wurde entworfen und codiert, aber nie produktiv getestet. Es blieb ein theoretisches Konzept.

5. Unified Tool System

Tool Registry mit automatischer Erkennung:

Problem erkannt → Pattern-Matching → Tool vorgeschlagen → Ausfuehrung → Lesson Learned

Tool Discovery (tool-watcher):

• Scannt User/, Tools/, Workspace/ nach .py Dateien
• Analysiert Capabilities
• Registriert automatisch in Transfer-Queue
• Kategorisiert (user-only, claude-only, shared)

Duplicate Detector:

• Similarity-Scoring (60% Threshold)
• Warnung vor redundanten Tools
• Gap-Analysis (fehlende Kategorien)

---

Verzeichnis-Struktur (dieses Legacy-Repo)

recludOS_legacy/
├── README.md              Dieses Dokument (Deutsch)
├── README_EN.md           Englische Version
├── DEPRECATED.md          Warum archiviert, Migration
│
├── boot/                  ⭐ Vollstaendiger Boot-Sektor
│   ├── SKILL.md           Haupt-Dokumentation
│   ├── *.py               Python-Module (bootstrap, micro_routines, ...)
│   ├── *.json             Konfigurationen (19 Dateien)
│   ├── *.md               Dokumentation (ACTORS_MODEL, BOOT_VARIANTS, ...)
│   └── archive/           Aeltere Versionen
│
├── demo/                  🎬 Ausfuehrbares Demo
│   └── mini_boot.py       Vereinfachte Boot-Demonstration
│
├── docs/                  📚 Dokumentation
│   ├── recludOS_entscheidung.md
│   ├── recludOS_in_BACH_synopse.md
│   └── selbstheilungskraefte_in_recludOS.md
│
└── original_analyses/     🔬 Analysen
    ├── recludOS_bootsektor.md  (743 Zeilen - vollstaendige Analyse)
    └── ANALYSE_Lernsysteme_BACH_vs_recludOS.md  (472 Zeilen - Vergleich)

---

Demo starten

Voraussetzungen

• Python 3.8+
• Keine weiteren Dependencies (Demo ist standalone)

Ausfuehrung

cd demo/
python mini_boot.py

Das Demo-Script zeigt:

• Multi-Phasen Boot-Sequenz
• Micro-Routines Checks
• Token Budget Zones
• Actor-Modell
• Shutdown-Protokoll

WICHTIG: Dies ist eine vereinfachte Demonstration! Das vollstaendige System liegt in boot/.

---

Innovative Features

Was recludOS gut konnte (und BACH uebernommen hat)

Feature	Beschreibung	Status in BACH
Directory Watcher	Automatische Pfad-Heilung bei Umbenennungen	✅ Uebernommen
Tool Auto-Discovery	Neue .py Dateien automatisch erkennen	✅ Uebernommen (teilweise)
Token-bewusste Delegation	Budget-Zonen mit automatischer Delegation	❌ Noch nicht
Actor Profiles	Datengetriebene Staerken/Schwaechen	❌ Noch nicht
Micro-Routines	Pre/Post Checks	✅ Uebernommen (vereinfacht)
Terminal Chat	Textual TUI mit Ollama-Integration	❌ Noch nicht

Was recludOS NICHT gut konnte (und BACH besser macht)

Problem in recludOS	Loesung in BACH
Fragmentierte Struktur, JSONs verstreut	SQLite mit Relationen, zentral
Kein Memory-Decay	5-Schicht-Memory mit Decay/Boost
Flache Ordnerstruktur	Klare Hierarchie (skills/docs/wiki/)
Keine zentrale Wissensbasis	skills/docs/docs/docs/help/ + wiki/ Hierarchie
Komplexe Boot-Sequenz (10s+)	Schneller Start (<2s)

---

Warum migriert zu BACH?

Die Entscheidung (Januar 2026)

recludOS war innovativ, aber nicht wartbar:

1. Fragmentierung

   • Dateien ueber viele Ordner verstreut, keine zentrale Struktur
   • 50+ JSON-Dateien an verschiedenen Orten statt zentralisiert
   • Flache Ordnerstruktur ohne klare Hierarchie
   • → Navigation und Wartung schwierig

2. Zu viele Moving Parts

   • 19 JSON-Dateien nur fuer Boot
   • 8+ Python-Module fuer Bootstrap
   • Micro-Routines mit 20 Checks/Actions
   • → Fehler schwer zu debuggen

3. Fehlende Zentralisierung

   • Keine Datenbank (nur lose JSON-Dateien)
   • Keine Relationen zwischen Registries
   • Wissen verstreut statt an einem Ort
   • → Dateninkonsistenzen

4. Fehlende Integration

   • Kein Knowledge Digest
   • Kein Shared Memory Client
   • Kein BACH API
   • → Isolation

Was von recludOS ueberlebt hat

• Konzept der dynamischen Injektoren → BACH Task INJ_001
• Directory Watcher / Pfad-Heilung → BACH tools/
• MessageBox-Konzept → BACH User-Interface
• Shutdown-Protokoll → BACH Konsolidierung

Siehe: DEPRECATED.md fuer Details zur Migration

---

Weiterfuehrende Dokumentation

In diesem Repository

• boot/SKILL.md (862 Zeilen) - Haupt-Dokumentation, vollstaendige Boot-Sequenz
• boot/ACTORS_MODEL.md - 6 Akteur-Kategorien im Detail
• boot/BOOT_VARIANTS.md - Mini/Normal/Full Boot-Varianten
• boot/README_Unified_Tool_System.md - Tool-Registry-System
• original_analyses/recludOS_bootsektor.md - 743 Zeilen vollstaendige Analyse
• original_analyses/ANALYSE_Lernsysteme_BACH_vs_recludOS.md - Lernsystem-Vergleich

Python-Module (boot/)

Modul	Zeilen	Beschreibung
bootstrap_integration.py	146	System-Bootstrap
micro_routines_executor.py	615	Pre/Post Checks
unified_tool_system.py	312	Master Tool Integration
tool_registry.py	442	Tool Registry Management
tool_discovery.py	261	Problem-Pattern Matching
duplicate_detector.py	359	Similarity Scoring
terminal-chat.py	369	Textual TUI Chat

JSON-Konfigurationen (boot/)

19 JSON-Dateien fuer Boot, Registry, Micro-Routines, Shutdown, etc.

---

Lizenz

Experimentell / Educational Use Only

Dieser Code ist:

• ❌ NICHT produktiv nutzbar
• ✅ Frei studierbar fuer Lernzwecke
• ✅ Konzepte koennen in eigenen Projekten verwendet werden
• ⚠️ Keine Garantien, keine Haftung

Hinweis: recludOS wurde entwickelt von Lukas Geiger (github.com/lukisch) und Claude (Anthropic). Dieses Repo gehoert zur ellmos-ai Organisation.

---

Danksagungen

recludOS war ein mutiges Experiment. Es hat gezeigt:

• Was moeglich ist: Autonome Verwaltungssysteme, Multi-Actor-Orchestrierung, Token-bewusste Delegation
• Was noetig ist: Solide DB-Grundlagen, klare Schnittstellen, einfache Architekturen
• Was bleibt: Innovative Konzepte die in BACH weiterleben

RIP recludOS (2025-11 bis 2026-02) 🏛️

Nachfolger: BACH (aktuell v3.7+)

---

Stand: 2026-02-21 Archiviert von: Claude Code Kontakt: github.com/lukisch | ellmos-ai