@cachly-dev/mcp-server 0.10.49 → 0.10.56

package/src/tools.ts

@@ -1729,197 +1729,6 @@ const TOOLS = [
       required: ['instance_id', 'context'],
     },
   },
-
-  // ── Travel Chaos Organizer (TCO) ─────────────────────────────────────────
-  // Requires TCO_API_URL env var pointing to the TCO FastAPI backend.
-  // Auth is shared with Cachly via the same Keycloak realm (CACHLY_JWT forwarded).
-  {
-    name: 'tco_list_trips',
-    description:
-      'List all travel trips in Travel Chaos Organizer. ' +
-      'Returns trip name, id, and date range. Use tco_get_timeline to see items for a specific trip. ' +
-      'Requires TCO_API_URL to be configured.',
-    inputSchema: { type: 'object', properties: {}, required: [] },
-  },
-  {
-    name: 'tco_create_trip',
-    description:
-      'Create a new trip in Travel Chaos Organizer. ' +
-      'Dates are optional ISO strings (YYYY-MM-DD). ' +
-      'Returns the new trip id.',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        name: { type: 'string', description: 'Trip name, e.g. "Barcelona Sommer 2025"' },
-        description: { type: 'string', description: 'Optional trip description' },
-        start_date: { type: 'string', description: 'Start date (YYYY-MM-DD), optional' },
-        end_date: { type: 'string', description: 'End date (YYYY-MM-DD), optional' },
-      },
-      required: ['name'],
-    },
-  },
-  {
-    name: 'tco_get_timeline',
-    description:
-      'Get the full timeline (flights, hotels, trains, activities …) for a trip. ' +
-      'Use tco_list_trips first to get the trip_id. ' +
-      'Returns items sorted by event_at with type icon, time, provider, and booking reference.',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        trip_id: { type: 'string', description: 'UUID of the trip (from tco_list_trips)' },
-      },
-      required: ['trip_id'],
-    },
-  },
-  {
-    name: 'tco_delete_trip',
-    description: 'Permanently delete a trip and all its timeline items. This is irreversible.',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        trip_id: { type: 'string', description: 'UUID of the trip to delete' },
-      },
-      required: ['trip_id'],
-    },
-  },
-  {
-    name: 'tco_inbox_list',
-    description:
-      'List items in the Travel Chaos Organizer Chaos Inbox — unassigned documents, ' +
-      'emails, and PDFs that Ollama has parsed but not yet assigned to a trip. ' +
-      'Use tco_inbox_assign to move them to a trip or tco_inbox_reject to discard.',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        status: {
-          type: 'string',
-          enum: ['pending', 'assigned', 'rejected'],
-          description: 'Filter by status (default: pending)',
-        },
-      },
-      required: [],
-    },
-  },
-  {
-    name: 'tco_inbox_assign',
-    description:
-      'Assign a Chaos Inbox item to an existing trip, creating a timeline entry. ' +
-      'Use tco_inbox_list to discover inbox_id values and tco_list_trips for trip_ids.',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        inbox_id: { type: 'string', description: 'UUID of the inbox item' },
-        trip_id: { type: 'string', description: 'UUID of the target trip' },
-        type: {
-          type: 'string',
-          enum: ['flight', 'train', 'bus', 'hotel', 'rental_car', 'activity', 'transfer', 'document', 'other'],
-          description: 'Item type (default: other)',
-        },
-      },
-      required: ['inbox_id', 'trip_id'],
-    },
-  },
-  {
-    name: 'tco_inbox_reject',
-    description: 'Remove an item from the Chaos Inbox without assigning it to any trip.',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        inbox_id: { type: 'string', description: 'UUID of the inbox item to reject' },
-      },
-      required: ['inbox_id'],
-    },
-  },
-  {
-    name: 'tco_parse_url',
-    description:
-      'Fetch a public URL (booking confirmation page, airline URL) and parse it with Ollama AI, ' +
-      'saving the result directly to a trip timeline or the Chaos Inbox. ' +
-      'Useful for quickly importing online booking confirmations without uploading a file.',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        url: { type: 'string', description: 'Public URL to fetch and parse' },
-        trip_id: { type: 'string', description: 'Trip UUID to assign to directly (omit to send to Chaos Inbox)' },
-      },
-      required: ['url'],
-    },
-  },
-  {
-    name: 'tco_import_email',
-    description:
-      'Import a raw email (paste the full email text including headers) into Travel Chaos Organizer. ' +
-      'Ollama strips headers, parses travel data (flights, hotels, bookings), and saves to inbox or trip. ' +
-      'Ideal for forwarding booking confirmation emails directly through Claude.',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        raw_email: { type: 'string', description: 'Full email text including headers' },
-        trip_id: { type: 'string', description: 'Trip UUID to assign directly (omit to send to Chaos Inbox)' },
-      },
-      required: ['raw_email'],
-    },
-  },
-  {
-    name: 'tco_parse_text',
-    description:
-      'Parse raw text (booking confirmation, itinerary, travel note) with Ollama AI in Travel Chaos Organizer. ' +
-      'Extracts flight, hotel, train, activity and other travel data. ' +
-      'Results are cached in Cachly Redis — identical text returns instantly without a second AI call. ' +
-      'Saves to a specific trip timeline or to the Chaos Inbox if no trip_id is given.',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        text: { type: 'string', description: 'Raw text to parse (booking confirmation, itinerary, etc.)' },
-        trip_id: { type: 'string', description: 'Trip UUID to assign directly (omit to send to Chaos Inbox)' },
-      },
-      required: ['text'],
-    },
-  },
-  {
-    name: 'tco_cache_stats',
-    description:
-      'Get Cachly Redis cache statistics for the TCO backend. ' +
-      'Shows how many AI parse results are cached, the cache hit rate, and whether Cachly is connected. ' +
-      'Use this to verify the TCO ↔ Cachly integration is working or to report savings to the user.',
-    inputSchema: { type: 'object', properties: {}, required: [] },
-  },
-  {
-    name: 'tco_provision_cache',
-    description:
-      'Provision a free Cachly Redis instance for Travel Chaos Organizer and return the connection string. ' +
-      'Creates a "tco-cache" instance on cachly.dev (free tier, 25 MB — enough for thousands of parse results). ' +
-      'After provisioning, instruct the user to set CACHLY_REDIS_URL=<returned URL> in their TCO .env and redeploy. ' +
-      'This wires TCO to Cachly so every Ollama parse result is deduplicated automatically.',
-    inputSchema: { type: 'object', properties: {}, required: [] },
-  },
-  {
-    name: 'tco_telegram_status',
-    description:
-      'Check if the current user has linked their Telegram account in Travel Chaos Organizer. ' +
-      'Returns linked status, plan, and guidance to link if not yet connected. ' +
-      'Use before tco_telegram_send to confirm the user will actually receive the message.',
-    inputSchema: { type: 'object', properties: {}, required: [] },
-  },
-  {
-    name: 'tco_telegram_send',
-    description:
-      'Send a Telegram message directly to the current TCO user\'s linked Telegram chat. ' +
-      'Supports Markdown formatting. Use for: summaries, reminders, trip updates, parse results. ' +
-      'Requires the user to have linked Telegram (check with tco_telegram_status first). ' +
-      'Ideal for pushing trip information to the user outside the app.',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        message: {
-          type: 'string',
-          description: 'Message text to send. Markdown supported (bold **text**, code `value`).',
-        },
-      },
-      required: ['message'],
-    },
-  },
 ] as const;
 
 

package/tsconfig.json

@@ -4,13 +4,14 @@
     "module": "Node16",
     "moduleResolution": "Node16",
     "outDir": "./dist",
-    "rootDir": ".",
+    "rootDir": "./src",
     "strict": true,
     "esModuleInterop": true,
     "skipLibCheck": true,
     "declaration": true,
     "sourceMap": true
   },
-  "include": ["src/**/*", "packages/**/*.ts"],
+  "include": ["src/**/*"],
   "exclude": ["node_modules", "dist"]
 }
+

package/.github/workflows/eas-build-android.yml

@@ -1,58 +0,0 @@
-name: EAS Build — TCO Android Preview
-
-on:
-  workflow_dispatch:
-    inputs:
-      message:
-        description: 'Build reason'
-        default: 'manual build'
-
-jobs:
-  build:
-    name: Build Android preview APK
-    runs-on: ubuntu-latest
-    defaults:
-      run:
-        working-directory: apps/travel-chaos-organizer/frontend
-
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: '20'
-
-      - name: Install dependencies
-        run: npm install
-
-      - name: Convert SVG icons to PNG (EAS Build requires PNG)
-        run: |
-          sudo apt-get install -y --no-install-recommends librsvg2-bin
-          rsvg-convert -w 1024 -h 1024 assets/icon.svg        -o assets/icon.png
-          rsvg-convert -w 1024 -h 1024 assets/adaptive-icon.svg -o assets/adaptive-icon.png
-          rsvg-convert -w 2048 -h 2048 assets/splash.svg        -o assets/splash.png
-          echo "Icons converted:"
-          ls -lh assets/*.png
-
-      - name: Setup EAS
-        uses: expo/expo-github-action@v8
-        with:
-          eas-version: latest
-          token: ${{ secrets.EXPO_TOKEN }}
-
-      - name: Create .env with production variables
-        run: |
-          echo "EXPO_PUBLIC_API_URL=${{ secrets.EXPO_PUBLIC_API_URL }}" >> .env
-          echo "EXPO_PUBLIC_KEYCLOAK_URL=${{ secrets.EXPO_PUBLIC_KEYCLOAK_URL }}" >> .env
-          echo "EXPO_PUBLIC_KEYCLOAK_REALM=${{ secrets.EXPO_PUBLIC_KEYCLOAK_REALM || 'travel-chaos' }}" >> .env
-          echo "EXPO_PUBLIC_KEYCLOAK_CLIENT_ID=${{ secrets.EXPO_PUBLIC_KEYCLOAK_CLIENT_ID || 'tco-mobile' }}" >> .env
-
-      - name: Build Android (preview — internal distribution)
-        run: |
-          eas build \
-            --profile preview \
-            --platform android \
-            --non-interactive \
-            --no-wait
-        # --no-wait: EAS build runs in the cloud asynchronously.
-        # Download the APK from expo.dev → your project → Builds when done (~10-15 min).

package/.github/workflows/eas-update.yml

@@ -1,55 +0,0 @@
-name: EAS Update — TCO Production
-
-on:
-  push:
-    branches: [main]
-    paths:
-      - 'apps/travel-chaos-organizer/frontend/**'
-  workflow_dispatch:
-    inputs:
-      message:
-        description: 'Update message'
-        default: 'OTA update'
-
-jobs:
-  update:
-    name: Publish EAS Update to production
-    runs-on: ubuntu-latest
-    defaults:
-      run:
-        working-directory: apps/travel-chaos-organizer/frontend
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: '20'
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: TypeScript typecheck
-        run: npx tsc --noEmit
-
-      - name: Create .env with production variables
-        run: |
-          echo "EXPO_PUBLIC_API_URL=${{ secrets.EXPO_PUBLIC_API_URL }}" >> .env
-          echo "EXPO_PUBLIC_KEYCLOAK_URL=${{ secrets.EXPO_PUBLIC_KEYCLOAK_URL }}" >> .env
-          echo "EXPO_PUBLIC_KEYCLOAK_REALM=${{ secrets.EXPO_PUBLIC_KEYCLOAK_REALM || 'travel-chaos' }}" >> .env
-          echo "EXPO_PUBLIC_KEYCLOAK_CLIENT_ID=${{ secrets.EXPO_PUBLIC_KEYCLOAK_CLIENT_ID || 'tco-mobile' }}" >> .env
-
-      - name: Publish EAS Update
-        env:
-          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}
-        run: |
-          MESSAGE="${{ github.event.inputs.message || github.event.head_commit.message }}"
-          MESSAGE="${MESSAGE:0:100}"
-          # Publish to both channels so preview and production builds both get the update
-          npx eas-cli update \
-            --branch production \
-            --message "$MESSAGE" \
-            --non-interactive
-          npx eas-cli update \
-            --branch preview \
-            --message "$MESSAGE" \
-            --non-interactive

package/STRATEGY.md

@@ -1,209 +0,0 @@
-# Cachly vs. Anthropic Memory — Ehrliche Standortbestimmung & 10x/100x-Roadmap
-
-> Stand: 29. Mai 2026 · Verfasst als interne, schonungslose Bestandsaufnahme.
-> Ziel: Wo stehen wir wirklich, was ist der Graben den Anthropic uns gräbt, und
-> was braucht es konkret, damit Cachly für die nächsten Jahre 10–100x besser,
-> stabiler, intelligenter und nutzerfreundlicher dasteht.
-
----
-
-## 0. TL;DR (für die Eiligen)
-
-- **Die Lücke, die wir füllen wollten, schließt Anthropic gerade selbst** — aber
-  nur für den Solo-Claude-Nutzer. Das Memory Tool, Managed-Agents-Memory,
-  Chat-Memory und "Dreaming" decken den **Single-User-, Single-Vendor-Fall**
-  zunehmend gut ab.
-- **Unser echter, verteidigbarer Graben liegt woanders**: *team-/org-weites,
-  strukturiertes, vendor- und tool-unabhängiges Wissen mit Governance.* Genau das
-  kann Anthropic strukturell **nicht** liefern, ohne ihr eigenes Lock-in-Modell zu
-  untergraben.
-- **Brutale Wahrheit**: Heute gewinnen wir diesen Graben *nicht* überzeugend.
-  Onboarding hat zu viel Reibung, die Recall-Qualität ist nicht nachweisbar besser
-  als "Claude liest seine eigenen Files", und wir hatten zuletzt zu viele Bugs für
-  ein Produkt, das gegen ein First-Party-Feature antritt.
-- **Der Weg zu 10x/100x** ist kein Feature-Wettrennen mit Anthropic. Es ist:
-  (1) **Recall-Qualität messbar überlegen machen**, (2) **Onboarding auf
-  Null-Reibung** bringen, (3) **Team-Wissensgraph zum Moat ausbauen**,
-  (4) **vendor-/tool-agnostisch** bleiben, (5) **Stabilität auf First-Party-Niveau**.
-
----
-
-## 1. Was Anthropic heute hat (der ehrliche Blick auf den Gegner)
-
-| Feature | Was es ist | Reichweite | Schwäche für uns nutzbar? |
-|---|---|---|---|
-| **Memory Tool** (`memory_20250818`) | Client-seitige Datei-Ops im `/memories`-Verzeichnis, 6 Commands (view/create/str_replace/insert/delete/rename) | Nur Anthropic-API, nur Claude-Modelle | **Ja** — unstrukturiert (flache Files), kein semantisches Retrieval, per-Agent |
-| **Managed Agents Memory** (Public Beta, Apr 2026) | Anthropic-gehostete Files, via API/Console exportierbar | Anthropic-Plattform | **Ja** — kein Team-Sharing-Modell, kein Wissensgraph |
-| **Chat Memory** (März 2026) | Auto-Destillation von Chats ~alle 24h in ein Memory-Profil | Consumer (Free/Pro/Max) | **Ja** — Consumer-only, nicht für Dev-Workflows/CI/Teams |
-| **Dreaming** (Research Preview) | Background-Prozess: Muster aus Sessions extrahieren, Memory kuratieren | Claude-intern | ⚠️ **Gefährlich** — das ist konzeptionell *unser* Crystallize/Belief-Update |
-| **Opus 4.8 Context** | 1M Token default, "infinite conversations" via Summarization, Suche über alte Chats | Claude | ⚠️ Reduziert den *Bedarf* an externem Memory für Solo-User |
-
-### Die unbequeme Erkenntnis
-Anthropics Memory ist **gratis, null Setup, first-party, und wird monatlich besser.**
-Für einen einzelnen Entwickler, der ausschließlich Claude nutzt, ist die Frage
-"Warum Cachly statt dem eingebauten Memory?" heute **nicht trivial zu beantworten.**
-
----
-
-## 2. Wo Cachly strukturell gewinnen kann (der echte Graben)
-
-Diese vier Punkte kann Anthropic nicht ohne Selbst-Sabotage angreifen:
-
-### 2.1 Vendor- & Tool-Unabhängigkeit
-- Anthropic-Memory lebt **in Anthropics Filesystem, gebunden an Claude über die
-  Anthropic-API.** Wechselst du zu GPT, Gemini, einem lokalen Modell oder nutzt
-  Cursor/Windsurf/Zed parallel — **dein Memory ist weg oder fragmentiert.**
-- Cachly spricht **MCP** → funktioniert mit *jedem* MCP-Client und ist
-  modell-agnostisch. **Dein Org-Wissen überlebt jeden Modellwechsel.**
-- *Das ist die Positionierung, die nie veraltet:* "Switzerland für AI-Memory."
-
-### 2.2 Team-/Org-weites Wissen
-- Anthropic-Memory ist **per-User / per-Agent.** Es gibt kein "Kollege A lernt
-  etwas, Kollege B profitiert beim nächsten `session_start`."
-- `team_learn` + geteilte Brain-Instanz ist **genau das** — und es ist der
-  Use-Case mit dem höchsten ökonomischen Wert (verhindert, dass 10 Entwickler
-  denselben Fehler 10x machen).
-
-### 2.3 Strukturiertes, kuratiertes Wissen statt flacher Files
-- Anthropic = Claude liest linear Textdateien.
-- Cachly = strukturierte Lessons (`topic`, `outcome`, `severity`, `tags`,
-  `depends_on`), Contradiction-Detection, Causal Knowledge Graph (CKG),
-  Belief-Update-Engine (BUE). **ABER:** dieser Vorteil ist heute *behauptet, nicht
-  bewiesen.* Siehe §3.
-
-### 2.4 Governance, Compliance, Self-Hosting
-- Self-hosted Valkey, BYOK, Audit-Trails, DSGVO-Löschung, SOC-2-Pfad.
-- Enterprises **dürfen** ihr Wissen oft nicht in Anthropics Managed Memory legen.
-  Das ist ein Verkaufsargument, das mit der Zeit *stärker* wird, nicht schwächer.
-
----
-
-## 3. Wo wir heute ehrlich schwach sind
-
-Kein Schönreden:
-
-1. **Recall-Qualität ist nicht gemessen.** Wir behaupten "strukturiert > flache
-   Files", haben aber **kein Benchmark**, das zeigt: Cachly-Recall führt zu
-   weniger Wiederholungsfehlern / besseren Antworten als das eingebaute Memory.
-   *Ohne diesen Beweis ist unser Hauptargument Marketing.*
-2. **Onboarding-Reibung.** Anthropic: 0 Setup. Cachly: Instanz provisionieren,
-   Device-Flow, MCP-Config, JWT-Persistenz, Instance-ID. Jede dieser Stufen ist
-   ein Drop-off-Punkt — und mehrere waren zuletzt **kaputt** (JWT nur im RAM,
-   Redis NOAUTH, Provisioning-Timeouts).
-3. **Stabilität.** Wir haben in den letzten Tagen viele kritische Bugs gefunden und
-   gefixt (Telemetrie-Zähler bei 0, NOAUTH, PKCE komplett kaputt, doppelte Drip-
-   Mails, Admin-Bypass). Ein Produkt, das gegen ein First-Party-Feature antritt,
-   **darf solche Bugs nicht haben.** Vertrauen ist hier asymmetrisch.
-4. **Wertnachweis fehlt dem User.** Der Nutzer sieht nicht, *dass* Cachly ihm
-   gerade einen Fehler erspart hat. Anthropics Memory ist unsichtbar-bequem;
-   unseres ist sichtbar-umständlich. Das muss sich umkehren.
-5. **"Dreaming" ist eine direkte Bedrohung** für unser Crystallize/BUE-
-   Alleinstellungsmerkmal. Wenn das Modell selbst Muster extrahiert, müssen wir
-   beim *Team-übergreifenden* und *strukturierten* Teil uneinholbar sein.
-
----
-
-## 4. Die 10x/100x-Roadmap (konkret, priorisiert)
-
-> Leitsatz: **Wir gewinnen nicht, indem wir Anthropics Memory kopieren. Wir
-> gewinnen, indem wir das werden, was Anthropic strukturell nicht sein darf:
-> der neutrale, team-weite, beweisbar-bessere Wissens-Layer über allen Modellen.**
-
-### Phase 1 — Stabilität & Null-Reibung (die Eintrittskarte) · *0–3 Monate*
-Ohne das ist alles andere wertlos.
-
-- **[10x Stabilität]** Vollständige Test-Suite für die Brain-Tools (Recall, Learn,
-  Dedup, Contradiction). Heute faktisch ungetestet. Ziel: jede Tool-Antwort hat
-  einen Vertragstest.
-- **[10x Onboarding]** "Ein-Befehl-Setup": `npx @cachly-dev/init` → Auto-Provision,
-  Device-Flow, MCP-Config-Write, erster `brain_from_git`-Seed, alles in <60s,
-  idempotent, mit klarem Fortschritt. Jeder bisherige Drop-off-Punkt eliminiert.
-- **[Reibung]** Graceful Degradation: Wenn Redis/Netz weg ist, darf das Tool
-  **nie** den ganzen Agent-Call blockieren. Timeouts + Circuit-Breaker überall.
-- **[Vertrauen]** Self-Healing-Auth: JWT/Instance-ID persistent, automatische
-  Re-Provisionierung bei verlorenem State, kein "0 Recalls weil RAM-only" mehr.
-
-### Phase 2 — Beweisbar bessere Recall-Qualität (der Moat-Beweis) · *3–9 Monate*
-Das ist der Punkt, an dem wir *verdienen*, gegen First-Party anzutreten.
-
-- **[100x Intelligenz]** Echtes hybrides Retrieval: semantische Embeddings +
-  Reranking + CKG-Traversierung, nicht Keyword-Match. Messbar gegen das
-  eingebaute Memory.
-- **[Beweis]** **Cachly-Bench**: ein offener Benchmark, der zeigt, dass ein Agent
-  *mit* Cachly weniger Wiederholungsfehler macht / schneller zur Lösung kommt als
-  mit Claude-Memory allein. Das ist unsere wichtigste Marketing- *und* Produkt-
-  Investition. Ohne Zahl keine Story.
-- **[Intelligenz]** Contradiction-Resolution, die *wirklich* funktioniert: wenn
-  zwei Lessons sich widersprechen, automatisch via MADC/Voting auflösen und das
-  Ergebnis persistent machen (heute teilweise berechnet, aber nicht gespeichert).
-- **[Wertsichtbarkeit]** "Brain saved you here"-Signal: wenn ein Recall einen
-  bekannten Fehler verhindert, sichtbar machen (im Tool-Output + Dashboard-Metrik).
-
-### Phase 3 — Team-Wissensgraph als uneinholbarer Moat · *9–18 Monate*
-Hier ist Anthropic strukturell raus.
-
-- **[100x Team]** Org-weiter Wissensgraph: Lessons, Personen, Dateien, Services als
-  Knoten; Recall berücksichtigt *wer* was gelernt hat und *wo* es relevant ist.
-- **[Virality]** Jeder gelöste Fehler eines Entwicklers wird automatisch zur
-  Org-Lesson — mit Attribution. `team_learn` als Default, nicht als Opt-in.
-- **[Governance]** Rollen, Sichtbarkeits-Scopes, Audit-Trails, "Wissens-Reviews"
-  (ein Senior bestätigt eine Lesson → höheres Vertrauen im Recall-Ranking).
-- **[Enterprise]** Self-Hosted-Tier mit SOC-2/ISO, BYOK by default, Daten bleiben
-  im Kunden-VPC. Das ist der Umsatz, den Anthropic-Memory nicht abgreifen kann.
-
-### Phase 4 — Der neutrale Layer über allen Modellen · *18+ Monate*
-- **[100x Reichweite]** First-class-Support für jeden großen MCP-Client und jedes
-  Modell. Cachly = "bring your own model, keep your brain."
-- **[Ökosystem]** Öffentliche/teilbare Brains (kuratierte Domänen-Wissensbasen:
-  "React-Best-Practices-Brain", "Kubernetes-Incident-Brain"), als Marktplatz.
-- **[Moat-Vertiefung]** Je mehr Org-Wissen akkumuliert, desto höher die
-  Wechselkosten *weg* von Cachly — aber **null** Lock-in beim *Modell*. Das ist
-  die einzige gesunde Form von Lock-in.
-
----
-
-## 5. Was wir explizit NICHT tun sollten
-
-- **Nicht** versuchen, Anthropics Single-User-Memory zu schlagen. Das verlieren wir.
-  Unser Nutzer ist das **Team** und die **Org**, nicht der Solo-Hobbyist.
-- **Nicht** Feature-für-Feature mit "Dreaming" konkurrieren. Stattdessen den
-  *strukturierten, geteilten, beweisbar-besseren* Teil besitzen.
-- **Nicht** weiter Features stapeln (wir haben ~89 Tools), solange Recall-Qualität
-  und Stabilität nicht bewiesen sind. **Tiefe vor Breite.**
-- **Nicht** vendor-Lock-in beim Modell aufbauen — das ist unser einziger
-  glaubwürdiger Vorteil gegenüber First-Party.
-
----
-
-## 6. Die drei Metriken, die alles entscheiden
-
-Wenn wir nur drei Zahlen tracken dürften:
-
-1. **Time-to-first-recall** (Onboarding-Reibung): vom `npx`-Befehl bis zum ersten
-   erfolgreichen, wertvollen Recall. Ziel: <2 Minuten.
-2. **Recall-Lift** (Moat-Beweis): % weniger Wiederholungsfehler / schnellere
-   Lösung *mit* Cachly vs. ohne, gemessen über Cachly-Bench. Ziel: messbar >0,
-   dann skalieren.
-3. **Team-Knowledge-Reuse** (Virality/Moat): wie oft wird die Lesson eines
-   Entwicklers von *einem anderen* erfolgreich recallt. Das ist der Wert, den nur
-   wir liefern.
-
----
-
-## 7. Fazit (schonungslos)
-
-Anthropic hat die **Single-User-Memory-Lücke** weitgehend geschlossen. Hätten wir
-nur darauf gewettet, wären wir in Schwierigkeiten.
-
-Aber die **eigentlich wertvolle Lücke** — *team-weites, strukturiertes,
-vendor-neutrales, governance-fähiges Wissen mit beweisbarem Recall-Vorteil* — ist
-**offen, und Anthropic kann sie aus strukturellen Gründen nicht schließen.**
-
-Heute besetzen wir diese Lücke **noch nicht überzeugend**: zu viel Reibung, zu
-wenig Beweis, zu viele Bugs. Der Weg zu 10x/100x ist deshalb unspektakulär und
-unerbittlich:
-
-> **Erst stabil & reibungslos. Dann beweisbar schlauer. Dann team-weit
-> uneinholbar. Immer modell-neutral.**
-
-In dieser Reihenfolge. Nicht andersrum.

package/apps/travel-chaos-organizer/.env.example

@@ -1,49 +0,0 @@
-# Travel Chaos Organizer — Environment Variables
-# Copy to .env and fill in your values
-
-# App
-DEBUG=false
-UPLOAD_DIR=/data/uploads
-
-# Database (overridden by docker-compose for containerized runs)
-DATABASE_URL=postgresql+asyncpg://tco:tco@localhost:5432/tco
-
-# Keycloak
-KEYCLOAK_URL=http://localhost:8080
-KEYCLOAK_REALM=travel-chaos
-KEYCLOAK_CLIENT_ID=tco-backend
-
-# Ollama — point to your self-hosted instance
-OLLAMA_URL=http://your-server:11434
-OLLAMA_MODEL=llama3.2-vision
-OLLAMA_TIMEOUT=120
-
-# Cachly Redis — caches Ollama parse results to avoid duplicate AI calls.
-# docker-compose sets this automatically (local Redis).
-# In production, replace with your Cachly instance URL:
-#   cachly.dev → Instances → Connection String
-# Same document uploaded twice? Instant response from cache, no second AI call.
-CACHLY_REDIS_URL=redis://localhost:6379/0
-# CACHLY_REDIS_URL=redis://:<password>@<host>.cachly.dev:6380/0
-
-# Telegram Notifier (optional) — get token from @BotFather
-# TELEGRAM_BOT_TOKEN=...
-# TCO_TELEGRAM_CHAT_ID=...   # chat or channel ID for TCO events
-
-# Email — Resend (optional, https://resend.com)
-# RESEND_API_KEY=re_...
-# RESEND_FROM=noreply@yourdomain.com
-
-# Admin dashboard (change before going live!)
-ADMIN_USER=admin
-ADMIN_PASSWORD=changeme
-
-# CORS — comma-separated origins, or * for all
-CORS_ORIGINS=*
-
-# Stripe
-# STRIPE_SECRET_KEY=sk_live_...
-# STRIPE_WEBHOOK_SECRET=whsec_...
-# STRIPE_PRO_PRICE_ID=price_...
-STRIPE_SUCCESS_URL=https://YOUR_DOMAIN/upgrade/success
-STRIPE_CANCEL_URL=https://YOUR_DOMAIN/upgrade/cancel