managarten/docs/TECHNOLOGY_AUDIT_2026_03.md

Technology Audit - ManaCore Monorepo

Datum: 27. Maerz 2026 Status: Noch nichts live - vollstaendiger Umbau moeglich Scope: Gesamtes Repository - Architektur, Services, Frontend, Infrastruktur, Testing, Deployment

---

Zusammenfassung

Bereich	Bewertung	Handlungsbedarf
Architektur-Vision (Local-first)	Stark	Kein Umbau noetig
Backend-Proliferation	Kritisch	19 NestJS + 1 Go + 1 Hono = 21 Backends
Frontend (SvelteKit)	Gut	Versionen konsistent, Svelte 5 durchgaengig
Mobile (Expo)	Mittel	Version-Divergenz (SDK 52/54/55)
Shared Packages	Zu granular	55 Packages, viele konsolidierbar
Infrastructure	Ambitioniert	67 Container auf einem Mac Mini
Testing	Kritisch	~162 Testdateien fuer 24 Apps + 16 Services
Services-Mix	Problematisch	4 Sprachen (TS, Python, Go, Bun)
CI/CD	Funktional	Change-Detection gut, kein Staging
Datenbank	Grundsolide	PostgreSQL 16 + Drizzle ORM

---

Inhaltsverzeichnis

1. Groesstes Problem: 19 identische NestJS-Backends
2. NestJS vs. Alternativen
3. Sprachen-Wildwuchs
4. Mobile Apps: Expo-Version-Divergenz
5. Frontend: Svelte 5 + SvelteKit
6. Local-First Architektur
7. Infrastruktur & Deployment
8. Datenbank
9. Testing
10. Shared Packages
11. CI/CD Pipeline
12. Frontend Store-Duplikation
13. Services-Analyse
14. Sicherheit & fehlende Stuecke
15. Was nicht geaendert werden sollte
16. Priorisierte Empfehlungen

---

1. Groesstes Problem: 19 identische NestJS-Backends

Das ist mit Abstand das dringendste Thema. Es gibt 19 separate NestJS-Backends, die alle quasi identisch aufgebaut sind:

ConfigModule + DatabaseModule + HealthModule + MetricsModule + AdminModule + CRUD-Module

Jeder einzelne Backend-Service:

• Ist ein eigener Docker-Container (~50 MB node_modules)
• Braucht seinen eigenen Port (3007, 3031, 3032, 3033, 3034...)
• Hat eigene Health-Checks, Metrics, Auth-Integration
• Wird separat gebaut, deployed, ueberwacht
• Dupliziert ~300-400 Zeilen identischen Boilerplate

Backend-Komplexitaets-Analyse

Kategorie	Backends	Source Files	Empfehlung
Komplex (behalten)	Chat, Todo, Calendar, Contacts, Storage, Mukke	60-89 pro Backend	Eigenstaendige Services
AI-spezialisiert (behalten)	Picture, Planta, NutriPhi	30-50 pro Backend	Eigene AI-Pipelines
Triviales CRUD (konsolidieren)	Zitare (20!), Clock (31), Presi, CityCorners, Questions, Context	20-35 pro Backend	-> 1 Content Service
Eliminieren	Photos (mana-media Proxy), Skilltree (Frontend-only)	minimal	Backend loeschen

Beispiel: Zitare Backend

Das Zitare Backend hat 20 TypeScript-Dateien und genau zwei Features:

// app.module.ts - Das ist der gesamte Service:
@Module({
  imports: [
    ConfigModule.forRoot({ isGlobal: true }),
    DatabaseModule,
    FavoriteModule,    // CRUD fuer Favoriten
    ListModule,        // CRUD fuer Listen
    HealthModule.forRoot({ serviceName: 'quote-backend' }),
    MetricsModule.register({ prefix: 'zitare_' }),
    AdminModule,
  ],
})
export class AppModule {}

Dafuer laeuft ein eigener Docker-Container mit eigenem Port, eigener Health-Check, eigenem Prometheus-Scrape-Target.

Empfehlung: Konsolidierung auf 2-4 Backends

Da bereits mana-sync (Go) als zentraler Sync-Server existiert und local-first das Paradigma ist, brauchen die meisten NestJS-Backends nicht mehr zu existieren. Die Daten leben in IndexedDB und synchen ueber mana-sync nach PostgreSQL.

Service	Zweck	Ersetzt
mana-sync (Go)	Sync, CRUD, Echtzeit	7+ CRUD-only Backends
mana-core-auth (NestJS)	Auth, Credits, Billing, Admin	Bleibt
mana-compute (Hono/Bun)	App-spezifische Logik (RRULE, Reminders, AI-Pipelines)	Todo-Server-Pattern fuer alle
mana-chat (NestJS)	AI Chat (Streaming, Azure OpenAI)	Chat-Backend

Geschaetzte Einsparung: ~5.500 Zeilen duplizierter Code, 7-8 Docker-Container weniger, ~1 GB RAM.

Duplizierten Boilerplate pro Backend

Pattern	Zeilen pro Backend	Total (19x)	Einsparbar
app.module.ts	40	760	~70%
main.ts bootstrap	10	190	~80%
database.module.ts	35	665	~90%
CRUD Controllers (Durchschnitt)	60	1.140	~65%
CRUD Services (Durchschnitt)	80	1.520	~70%
Entity Schemas (Durchschnitt)	25	475	auto-generierbar
Gesamt	~290	~5.500	~85%

---

2. NestJS vs. Alternativen

Problem mit NestJS fuer CRUD-Backends

• Schwer (~50 MB node_modules pro Backend)
• Viel Boilerplate (Module, Controller, Service, DTO fuer jede Entity)
• Overkill fuer simple CRUD-Operationen
• NestJS Version-Drift: 18 Backends auf ^10.4.x, ManaDeck auf ^11.0.1

Empfehlung

Technologie	Wann verwenden
Hono + Bun	Leichte Compute-Server (wie der Todo-Server)
Go (mana-sync)	Performance-kritisch, Echtzeit, WebSocket
NestJS	Nur fuer mana-core-auth (komplex, viele Module, 174 Source Files)

Der Todo Hono/Bun Server ist ein gutes Pattern:

{
  "dependencies": {
    "drizzle-orm": "^0.45.1",
    "hono": "^4.7.0",
    "postgres": "^3.4.5",
    "rrule": "^2.8.1"
  }
}

Leicht, schnell, genau die Abhaengigkeiten die er braucht.

---

3. Sprachen-Wildwuchs: 4 Runtime-Umgebungen

Aktuell im Einsatz:

Sprache	Services	Berechtigung
TypeScript/Node.js (NestJS)	19 Backends + Auth + 5 Infra-Services	Historisch, aber zu viel
Python (FastAPI)	mana-llm, mana-stt, mana-tts, mana-voice-bot, mana-image-gen	Berechtigt (ML/AI Libraries)
Go	mana-sync, mana-matrix-bot, mana-api-gateway-go	Berechtigt (Performance)
Bun (Hono)	Todo Server	Gutes Pattern

Problem: Drei angefangene Go-Rewrites

Service	Go-Version Status	NestJS-Version Status
mana-api-gateway-go	~35% fertig	Funktional
mana-search-go	<10%, kaum Code	Funktional
mana-matrix-bot	Fertig (21 Services -> 1 Go Binary)	Entfernt

Empfehlung

Entscheidet euch:

• Option A: Go fuer alle Infrastruktur-Services (sync, gateway, search), TypeScript nur fuer Auth
• Option B: Alles bei TypeScript lassen, aber NestJS durch Hono/Bun ersetzen

Mischt nicht beides halbfertig. Die angefangenen Go-Rewrites (api-gateway-go, search-go) entweder fertigstellen oder loeschen.

---

4. Mobile Apps: Expo-Version-Divergenz

App	Expo SDK	React Native	NativeWind
context, chat	52	0.76	^3.4.0
picture, manadeck, manacore	54	0.81	^4.2.1
matrix	55	0.83	latest

Empfehlung

Alle auf Expo SDK 55 (neueste) bringen. Bei 7 Mobile-Apps ist das noch machbar. Expo hat gute Upgrade-Guides. Zusaetzlich:

• NativeWind Version vereinheitlichen (v3 vs v4 ist ein Breaking Change)
• Navigation-Timing-Workarounds fixen (requestAnimationFrame-Hacks in Picture Mobile)

---

5. Frontend: Svelte 5 + SvelteKit

Bewertung: Gut

• Alle 22 Web-Apps auf Svelte 5.41.0 und SvelteKit 2.47.1 (konsistent)
• Runes-Mode durchgaengig (korrekt: $state, $derived, $effect)
• Shared packages gut extrahiert (shared-auth, shared-ui, shared-theme)
• Tailwind CSS 4 durchgaengig
• TypeScript strict mode ueberall

Probleme

• 2 Apps skippen type-check (picture/web, chat/web) wegen shared-ui Type-Errors
• Store-Pattern wird manuell kopiert statt shared (siehe Abschnitt 12)

Kein Handlungsbedarf bei der Technologie-Wahl. Svelte 5 war die richtige Wahl.

---

6. Local-First (Dexie + mana-sync)

Bewertung: Stark

Der Local-first Stack (Dexie.js IndexedDB + Go Sync-Server + WebSocket Push) ist architektonisch solid:

Guest:      App -> IndexedDB (Dexie.js) -> UI            (kein Sync)
Logged in:  App -> IndexedDB -> UI -> SyncEngine -> mana-sync (Go) -> PostgreSQL
                                    <- WebSocket push <-

• 19/22 Apps bereits migriert
• Guest-Mode funktioniert
• Offline-CRUD moeglich
• Field-level LWW Conflict Resolution

ABER: mana-sync braucht dringend Haertung

Metrik	Wert	Bewertung
Go-Quellcode	426 Zeilen	Zu wenig fuer die kritischste Komponente
Tests	0	Kritisch
Dokumentation	Minimal	Kein CLAUDE.md
Error Handling	Unklar	Nicht dokumentiert

mana-sync ist der Single Point of Failure des gesamten Stacks. Wenn der Sync-Server Daten verliert oder falsch merged, betrifft das alle 19 Apps.

Empfehlung

Investiert hier sofort:

1. Go Tests (table-driven tests fuer Sync-Logik, Conflict Resolution)
2. Dokumentation (CLAUDE.md, Sync-Protokoll, Conflict-Resolution-Strategie)
3. Error Handling und Recovery
4. Monitoring/Alerting (Sync-Failures, Latenz, Connection-Counts)
5. Horizontal Scaling Strategie (aktuell: Single Instance)

---

7. Infrastruktur & Deployment

67 Docker-Container auf einem Mac Mini

Tier	Container	Anzahl
Infra	Postgres, Redis, MinIO, Nginx, Backup	5
Core	Auth, API Gateway, Search, SearXNG, Media, Landing Builder	6
App Backends	19x NestJS	19
App Frontends	19x SvelteKit	19
Matrix	Synapse, Element, Bot	3
AI/ML	mana-llm, Ollama, STT, TTS, Image-Gen	5+
Monitoring	Grafana, VictoriaMetrics, Alertmanager, cAdvisor, Exporters, Loki, GlitchTip	11
Misc	Watchtower, Games	2+
Gesamt		~67

Empfehlung

Mit Backend-Konsolidierung (Abschnitt 1) und Frontend-Konsolidierung:

1. Backend-Konsolidierung: 19 NestJS -> 4-6 Services = -13 Container
2. SvelteKit-Apps konsolidieren: Statt 19 separate Node-Container, ein Nginx-Reverse-Proxy der alle statischen Builds served = -18 Container
3. Monitoring vereinfachen: Node-Exporter, cAdvisor, Redis-Exporter, Postgres-Exporter sind fuer einen Mac Mini Overkill = -4 Container

Ziel: ~30 Container statt 67.

Production-Compose ist gut aufgesetzt

Positiv:

• PostgreSQL mit tuning (shared_buffers=512MB, WAL config)
• Automatisches Backup (hourly pg_dumpall + daily pg_basebackup)
• Health-Checks auf allen Services
• Deploy-Metrics werden in PostgreSQL getrackt
• Matrix-Notifications bei Deploy-Failures
• Cloudflare Tunnel fuer Zugang

Negativ:

• Kein Staging-Environment
• Kein Blue-Green Deployment
• Kein automatischer Rollback bei Health-Check Failure
• Mac Mini ist Single Point of Failure

---

8. Datenbank

Bewertung: Grundsolide

• PostgreSQL 16 mit guter Konfiguration
• Drizzle ORM ueberall konsistent (Code-first Schemas, Type-safe)
• Backup-Strategie vorhanden
• Schema-Isolation pro Service

Aktuelle Situation

• 23 separate Datenbanken in einer PostgreSQL-Instanz
• Jeder Service hat eigenes Drizzle-Schema
• db:push fuer Schema-Aenderungen (kein manuelles SQL)
• db:studio fuer Daten-Inspektion

Empfehlung

• Drizzle ist perfekt hier. Bleibt dabei.
• Ueberlegt ob Konsolidierung auf weniger DBs mit Schema-Isolation (PostgreSQL Schemas statt separate DBs) sinnvoll ist
• Drizzle-Kit Version vereinheitlichen (aktuell Mix aus ^0.30.2 und ^0.38.3)

---

9. Testing

Bewertung: Kritisch

Bereich	Test-Dateien	Abdeckung
Apps (24 Stueck)	~162 (inkl. node_modules-Artefakte)	Duenn
Services (16 Stueck)	~23	11 von 16 Services haben 0 Tests
mana-core-auth	Gut (5 E2E Specs)	Einziger Service mit guter Abdeckung
mana-sync	0 Tests	Kritischster Service ohne Tests
mana-llm	Vorhanden (Python)	Unit Tests

Services ohne Tests (kritisch)

• mana-sync (Sync-Engine - Datenverlust-Risiko!)
• mana-search
• mana-crawler
• mana-notify
• mana-media
• mana-api-gateway
• mana-image-gen
• mana-stt
• mana-tts
• mana-voice-bot
• mana-landing-builder

Empfehlung (Prioritaet vor Go-Live)

1. mana-sync: Integration Tests fuer Sync-Logik und Conflict Resolution (Go)
2. mana-core-auth: Weiter ausbauen (bereits gut)
3. @manacore/local-store: Unit Tests fuer SyncEngine und Conflict Resolution
4. E2E Tests: Fuer die wichtigsten User-Flows (Auth -> CRUD -> Sync -> Multi-Device)

---

10. Shared Packages

Bewertung: Zu viele (55 Stueck)

Sinnvolle Packages:

• @manacore/local-store - Kern der Local-first Architektur
• @manacore/shared-auth - Auth-Abstraktion
• @manacore/shared-nestjs-auth - NestJS JWT Guards
• @manacore/shared-ui - UI-Komponenten (hat aber Type-Errors)
• @manacore/shared-tailwind - Tailwind Config
• @manacore/shared-vite-config - Vite Config

Zu granulare Packages (Konsolidierungskandidaten):

Aktuell (einzeln)	Konsolidiert zu
shared-credit-service, shared-credit-ui, credit-operations	@manacore/credits
shared-feedback-service, shared-feedback-types, shared-feedback-ui	@manacore/feedback
shared-help-content, shared-help-mobile, shared-help-types, shared-help-ui	@manacore/help
shared-subscription-types, shared-subscription-ui	@manacore/subscriptions
shared-nestjs-health, shared-nestjs-metrics, shared-nestjs-setup	@manacore/nestjs-bootstrap
manadeck-database, nutriphi-database, spiral-db	Zurueck in die jeweiligen Apps

Ziel: ~25-30 Packages statt 55

---

11. CI/CD Pipeline

Bewertung: Funktional

CI (ci.yml):

• Laeuft auf PRs und Push zu main/dev
• Change-Detection: Nur geaenderte Services werden gebaut
• Type-Check, Lint, Format, Tests
• Docker-Image-Builds selektiv

CD (cd-macmini.yml):

• Self-hosted Runner auf Mac Mini
• Erkennt geaenderte Services automatisch
• Baut Base-Images (nestjs-base, sveltekit-base) wenn noetig
• Health-Checks nach Deploy
• Deploy-Metrics in PostgreSQL
• Matrix-Notifications bei Failures

Root package.json: 294 Scripts

Das ist nicht mehr wartbar. Jede neue App fuegt ~15 Scripts hinzu.

Fehlend

• Kein Staging-Environment - dev und main Branches only
• Kein automatischer Rollback - Bei Deploy-Failure manuelles Recovery
• Kein Blue-Green Deployment - Alle User bekommen Update sofort
• Keine automatische Deployment-Trigger - workflow_dispatch ist manuell

---

12. Frontend Store-Duplikation

Ueber 15 SvelteKit-Apps haben identische Kopien der gleichen Store-Dateien:

apps/*/apps/web/src/lib/stores/auth.svelte.ts      # ~80 Zeilen, 15x kopiert
apps/*/apps/web/src/lib/stores/user-settings.svelte.ts  # ~60 Zeilen, 15x kopiert
apps/*/apps/web/src/lib/stores/theme.svelte.ts      # ~40 Zeilen, 15x kopiert

Geschaetzte Duplikation: ~500+ Zeilen ueber 15 Apps

Das Package @manacore/shared-stores existiert bereits, wird aber nicht voll genutzt. Diese Stores sollten dort zentralisiert werden.

---

13. Services-Analyse (Detail)

Services Maturity Matrix

Service	Tech	Tests	Error Handling	Config	Completeness
mana-core-auth	NestJS/TS	Gut (E2E + Integration)	Gut	Env-driven	95%
mana-llm	Python/FastAPI	Unit Tests	Implizit	Pydantic	80%
mana-api-gateway	NestJS/TS	Keine	Gut	Env-driven	75%
mana-search	NestJS/TS	Keine	Maessig	Env-driven	70%
mana-crawler	NestJS/TS	Keine	Minimal	Env-driven	75%
mana-media	NestJS/TS	Keine	Minimal	Env-driven	70%
mana-notify	NestJS/TS	Keine	Minimal	Env-driven	75%
mana-stt	Python/FastAPI	Keine	Keine	Env	55%
mana-tts	Python/FastAPI	Keine	Keine	Env	55%
mana-image-gen	Python/FastAPI	Keine	Keine	Env	50%
mana-voice-bot	Python/FastAPI	Keine	Keine	Basic	40%
mana-sync	Go	Keine	Unklar	Minimal	40%
mana-matrix-bot	Go	Keine	Unklar	Minimal	50%
mana-api-gateway-go	Go	Keine	Unklar	Minimal	35%
mana-landing-builder	NestJS/TS	Keine	Minimal	Env-driven	60%
mana-search-go	Go	Keine	Keine	Keine	10%

Port-Konflikte

Port	Beansprucht von	Problem
3025	mana-llm UND mana-image-gen	Koennen nicht parallel laufen
3030	mana-api-gateway UND mana-landing-builder UND mana-api-gateway-go	Dreifach-Konflikt

---

14. Sicherheit & fehlende Stuecke

Sicherheit

Thema	Status
JWT (EdDSA)	Gut - Better Auth + jose Library
CORS	Konfiguriert, aber 20+ Domains hardcoded in docker-compose
Passkeys/WebAuthn	Implementiert
SMTP (Brevo)	Konfiguriert
Secrets	Env-basiert, aber Default-Passwoerter in dev compose
Rate Limiting	Vorhanden (Redis-based)

Fehlende Stuecke

Luecke	Risiko	Aufwand
Kein Distributed Tracing (OpenTelemetry)	Debugging in Prod unmoeglich	2-3 Tage
Kein Staging-Environment	Bugs erst in Prod sichtbar	1 Tag
shared-ui Type-Errors	2 Apps skippen type-check	2-3 Tage
Kein API-Dokumentation (OpenAPI/Swagger)	Nur mana-core-auth hat Swagger	1 Woche
Logging nicht standardisiert	Winston vs NestJS Logger vs FastAPI vs Go	3-5 Tage
Keine Correlation IDs	Requests nicht ueber Services verfolgbar	2 Tage

---

15. Was NICHT geaendert werden sollte

Diese Technologie-Entscheidungen sind gut und sollten beibehalten werden:

Technologie	Grund
Svelte 5 + SvelteKit	Modern, performant, gut umgesetzt
Local-first Architektur	Zukunftssicher, Guest-Mode, Offline-CRUD
Dexie.js	Solide IndexedDB-Abstraktion
PostgreSQL + Drizzle ORM	Type-safe, bewaehrtes Duo
Better Auth	Self-hosted, EdDSA JWT, Passkeys
MinIO	S3-kompatibel, self-hosted
Python fuer ML/AI	Einzige sinnvolle Wahl (STT, TTS, LLM, Image-Gen)
Go fuer mana-sync	Performance-kritisch, kleine Binary
Turborepo	Funktioniert gut fuer Monorepo-Orchestrierung
Cloudflare Tunnel	Einfaches Routing ohne oeffentliche IP
Astro fuer Landing Pages	Perfekt fuer statische Marketing-Seiten

---

16. Priorisierte Empfehlungen

Phase 1: Vor Go-Live (Kritisch)

#	Massnahme	Aufwand	Impact
1	mana-sync hardenen - Tests, Docs, Error Handling	1 Woche	Datensicherheit
2	7 triviale Backends eliminieren/konsolidieren (Zitare, Clock, Presi, CityCorners, Questions, Context, Photos)	1 Woche	-7 Container, -3.500 LOC
3	Port-Konflikte loesen (3025, 3030)	1 Stunde	Services laufen parallel
4	shared-ui Type-Errors fixen	2-3 Tage	Alle Apps type-checken wieder
5	Expo-Versionen alignen (alle auf SDK 55)	3-5 Tage	Konsistenz, Security

Phase 2: Kurzfristig

#	Massnahme	Aufwand	Impact
6	Go-Rewrites entscheiden (api-gateway-go, search-go: fertig oder loeschen)	Entscheidung	Klarheit
7	Store-Duplikation fixen (shared-stores richtig nutzen)	2-3 Tage	-500 LOC Duplikation
8	Shared Packages konsolidieren (55 -> ~30)	1 Woche	Einfacheres Dependency-Management
9	SvelteKit-Container konsolidieren (Nginx statt 19 Node-Container)	3-5 Tage	-18 Container
10	Staging-Environment einrichten	1 Tag	Bugs vor Prod fangen

Phase 3: Mittelfristig

#	Massnahme	Aufwand	Impact
11	OpenTelemetry Tracing einfuehren	3-5 Tage	Debugging in Prod
12	Structured Logging (JSON, Correlation IDs)	3-5 Tage	Log-Aggregation funktioniert
13	Test-Coverage aufbauen (Fokus: Sync, Auth, CRUD-Pfade)	Fortlaufend	Qualitaet
14	NestJS-Version alignen (alle auf 10.4 oder 11.0)	2-3 Tage	Konsistenz
15	Monitoring vereinfachen (weniger Exporters, mehr App-Level Metrics)	2-3 Tage	-4 Container

Phase 4: Langfristig

#	Massnahme	Aufwand	Impact
16	Root package.json Scripts aufraemen (294 -> CLI Tool)	1 Woche	Developer Experience
17	Mac-Mini Scripts konsolidieren (31 Shell Scripts -> 1 CLI)	1 Woche	Wartbarkeit
18	API-Dokumentation (OpenAPI/Swagger fuer alle Services)	2 Wochen	Developer Experience
19	Blue-Green Deployment	1 Woche	Zero-Downtime Deploys
20	Mobile Platform-Paritaet - fehlende Apps implementieren oder entfernen	Fortlaufend	Klarheit

---

Anhang: Bestandsaufnahme

Apps (24)

calendar, chat, citycorners, clock, contacts, context, docs, inventar, manacore, manadeck, matrix, mukke, nutriphi, photos, picture, planta, playground, presi, questions, skilltree, storage, todo, traces, zitare

Services (17)

it-landing, mana-api-gateway, mana-api-gateway-go, mana-core-auth, mana-crawler, mana-image-gen, mana-landing-builder, mana-llm, mana-matrix-bot, mana-media, mana-notify, mana-search, mana-stt, mana-sync, mana-tts, mana-voice-bot, ollama-metrics-proxy

Shared Packages (55)

credit-operations, eslint-config, local-store, mana-core-nestjs-integration, manadeck-database, notify-client, nutriphi-database, qr-export, shared-api-client, shared-app-onboarding, shared-auth, shared-auth-stores, shared-auth-ui, shared-branding, shared-config, shared-credit-service, shared-credit-ui, shared-drizzle-config, shared-error-tracking, shared-errors, shared-feedback-service, shared-feedback-types, shared-feedback-ui, shared-gpu, shared-help-content, shared-help-mobile, shared-help-types, shared-help-ui, shared-i18n, shared-icons, shared-landing-ui, shared-llm, shared-logger, shared-nestjs-auth, shared-nestjs-health, shared-nestjs-metrics, shared-nestjs-setup, shared-profile-ui, shared-pwa, shared-splitscreen, shared-storage, shared-stores, shared-subscription-types, shared-subscription-ui, shared-tags, shared-tailwind, shared-theme, shared-theme-ui, shared-tsconfig, shared-types, shared-ui, shared-utils, shared-vite-config, spiral-db, test-config, wallpaper-generator

Games (3)

voxelava, whopixels, worldream

Archivierte Apps (apps-archived/)

bauntown, memoro, news, nutriphi, reader, uload, wisekeep