TabHub

Lokaler Tab-Manager für mehrere Chromium-Browser mit REST-, MCP- und Weboberfläche. Der Server lauscht nur auf 127.0.0.1.

Anforderungen

• Windows 10/11

• Node.js 22+

• Corepack (corepack enable)

Start

corepack pnpm install
Copy-Item .env.example .env
corepack pnpm dev

Lokale Fähigkeit für persönlichen Kontext

Die erstklassigen Kontextrouten sind fail-closed hinter TABHUB_FEATURE_CONTEXT=true geschaltet. Die Produktionsnavigation von /app erhält eine opake lokale Sitzung mit HttpOnly; SameSite=Strict. Während der Vite-Entwicklung setzen Sie ein zufälliges, nur für den Server bestimmtes TABHUB_DEV_PROXY_SECRET; der Vite-Proxy muss POST /api/local/session/bootstrap aufrufen und den passenden x-tabhub-dev-proxy-secret-Header einfügen. Verwenden Sie für diesen Wert niemals eine VITE_-Variable und legen Sie ihn niemals im Browser-Code offen. Das Bootstrap-Geheimnis, Bearer-Anmeldedaten, Pairing-Codes, Kontextkörper, rohe Suchanfragen und Idempotenzschlüssel sind von Anforderungsprotokollen ausgeschlossen.

Der Befehl baut zuerst die Weboberfläche und startet dann den Server. Öffnen Sie http://127.0.0.1:7717/app/.

Die Weboberfläche ist auf Englisch und Russisch verfügbar. Die Sprache kann in der Kopfzeile der Anwendung gewählt werden; die Auswahl wird im Browser gespeichert. Popup und Erweiterungseinstellungen verwenden automatisch die Sprache der Browseroberfläche, sofern diese Englisch oder Russisch ist.

Serverprüfung:

Invoke-RestMethod http://127.0.0.1:7717/api/health

Aktuell erwartete Antwort:

{"status":"ok","database":"ok","schemaVersion":26}

Die Standarddatenbank wird in data/tabhub.sqlite relativ zum Repository-Stammverzeichnis erstellt. Der Pfad kann über TABHUB_DB_PATH in der .env im Stammverzeichnis geändert werden.

TABHUB_FEATURE_LOGICAL_IMPORTANCE=false behält den bisherigen Wichtigkeitseditor für einen einzelnen physischen Tab bei und deaktiviert die neuen logical-page-Endpunkte. Der Wert true aktiviert eine einzige kanonische Wichtigkeitseinstufung für alle Kopien einer URL-Seite. Starten Sie den Server nach dem Ändern des Flags neu. Für ein sicheres Zurücksetzen setzen Sie es wieder auf false: Gespeicherte kanonische Daten werden nicht gelöscht, aber die Legacy-Oberfläche liest und verändert sie nicht.

Für die UI-Entwicklung mit Hot Reload starten Sie Server und Vite mit einem einzigen Befehl und öffnen dann die Vite-Adresse aus der Konsole:

corepack pnpm dev:web

TABHUB_FEATURE_RESOURCES=true aktiviert das Resource-Backend und die REST-API: Ressourcenliste/-details/-seiten/Aktivität über alle Zeiten, Ressourcenkontext, Befehle, Benutzerbewertung und resource_id-Schnittmengen für Tab-/Instanzauswahlen. Die Resource-UI-Facette kommt in W30 und wird nicht allein durch dieses Server-Flag aktiviert. Setzen Sie das Flag für ein sicheres Zurücksetzen wieder auf false und starten Sie neu: Gespeicherte Zuordnungen, Kontext und Bewertungen bleiben isoliert und werden weder gelöscht noch über Ressourcenrouten offengelegt.

Die Erfassung exakter Kopien und der Drawer-Fluss für Kurz-/Tiefen-Seitenzusammenfassungen sind unabhängig voneinander fail-closed hinter TABHUB_FEATURE_PAGE_SUMMARY_CAPTURE=true geschaltet. Sie verwenden bewusst nicht das Resource-Research-Flag: Eine tiefe Seitenzusammenfassung analysiert weiterhin eine einzelne erfasste Seite, während Research eine eigene Korpus-, Evidenz-, Budget- und Zustimmungssemantik hat. Wenn dieses Flag deaktiviert ist (Standard), meldet /api/features pageSummaryCapture: false, der HTTP-Relay lehnt nur capture-tab-content vor der Erweiterungszustellung ab, und die Ingest-Route für exakte Instanzen fehlt. Gewöhnlicher Inhalts-Ingest, die vorhandene Library-Aktion für Kurzzusammenfassungen bereits erfasster Inhalte und Aktivierungs-, Schließ- und Arbeitsbereich-Relay-Befehle bleiben verfügbar. Starten Sie den Server nach dem Ändern des Flags neu; setzen Sie es für eine schema-kompatible Rollback-Oberfläche wieder auf false.

Nur auf erfasste Inhalte gestütztes Resource-/Seiten-Research ist unabhängig standardmäßig deaktiviert hinter TABHUB_FEATURE_RESEARCH=true. Schema 24 wird bedingungslos installiert, sodass vorhandener Research-Verlauf und Datenschutz-Schwärzung lesbar bleiben, wenn das Flag auf false zurückgesetzt wird; das deaktivierte Flag blockiert nur neue Preflight-, Run- und Research-Cancel-Mutationen. Die Ausführung erfordert zusätzlich ANTHROPIC_API_KEY. Ohne Anbieter bleiben Preflight, Verlauf, Auftragslesevorgänge und Datenschutz-Schwärzung verfügbar, während Run/Refine vor dem Schreiben mit 503 RESEARCH_PROVIDER_UNAVAILABLE fehlschlagen.

Der Anbieter verwendet ANTHROPIC_RESEARCH_MODEL, unveränderliche Startpreise aus ANTHROPIC_RESEARCH_INPUT_USD_PER_MTOK und ANTHROPIC_RESEARCH_OUTPUT_USD_PER_MTOK sowie eine optionale explizite ANTHROPIC_RESEARCH_PRICING_VERSION. Wenn die Version leer ist, leitet TabHub sie aus den effektiven Preisen ab. TABHUB_RESEARCH_MAX_OUTPUT_TOKENS ist auf 8192 begrenzt, und TABHUB_RESEARCH_TIMEOUT_MS begrenzt einen einzelnen Aufruf. Der Worker erlaubt einen gleichzeitigen Aufruf, zehn Versuche und eine Reservierung von USD 2 pro UTC-Tag, während jeder Lauf außerdem in das vom Benutzer genehmigte Budget passen muss. Research verbraucht nur den erfassten genehmigten Korpus: Es ruft niemals eine URL ab, öffnet sie nicht und navigiert nicht zu ihr. Starten Sie den Server neu, nachdem Sie ein Research-Flag oder eine Anbietereinstellung geändert haben.

Die begrenzte Live-Akquisition von Schema 26 ist unabhängig standardmäßig deaktiviert hinter TABHUB_FEATURE_LIVE_ACQUISITION=true. Wenn sie aktiviert ist, stellt der akzeptierte C90b-Koordinator nur Resource-bezogene Preflight-/Start-/Statusflüsse bereit, verwendet den geschlossenen serverinternen SafePublicHttpClient, materialisiert begrenzte öffentliche Beweise und übergibt einen unveränderlichen erfassten/Live-Korpus an den vorhandenen Research-Workflow. Er stellt keinen generischen Fetch-Endpunkt bereit und verwendet niemals Browsernavigation, Erweiterungsabrufe, Weiterleitungen, Wiederholungen, Skripte, Unteranfragen oder Tab-/Fenstermutationen. Außerhalb eines ausdrücklich überprüften Rollouts lassen Sie das Flag auf false.

TABHUB_FEATURE_PRIVACY_PURGE=true ermöglicht die Erstellung neuer dauerhafter Datenschutzbereinigungen. Der vorhandene Schema-26-Bereinigungsstatus sowie Wiederholung/Wiederherstellung bleiben verfügbar, wenn das Flag deaktiviert ist, sodass das Deaktivieren neuer Arbeiten nicht dazu führen kann, dass eine aktive Bereinigung hängen bleibt.

Die tägliche Aktivität wird durch zwei unabhängige, fail-closed Flags gesteuert. Setzen Sie TABHUB_FEATURE_ACTIVITY_DAILY_WRITER=true, um akzeptierte Aktivität in tägliche UTC-Buckets zu sammeln und Metriken zu Lücken, Duplikaten und Außer-Reihenfolge-Ereignissen zu aktualisieren. Setzen Sie TABHUB_FEATURE_ACTIVITY_WINDOWS=true zusammen mit TABHUB_FEATURE_ACTIVITY_DAILY_WRITER=true und TABHUB_FEATURE_RESOURCES=true, um 7-Tage/30-Tage-Seiten-/Ressourcenfenster und Aktivitätsmetriken für UI/Adapter anzukündigen und bereitzustellen. Beide Aktivitätsflags sind standardmäßig false. Der reine Lesemodus fällt fail-closed auf die G3-Gesamtaktivität zurück, weil die Tagesabdeckung unvollständig wäre; der reine Schreibmodus sammelt Buckets, ohne die neuen Leser bereitzustellen, und ist für ein gestuftes Rollout gültig.

Die unveränderliche Migrationsverfügbarkeits-Epoche zeichnet auf, wann die tägliche Nachverfolgung verfügbar wurde. Eine separate, persistierte Lebenszyklus-Epoche des Writers zeichnet nur den aktuellen kontinuierlichen Zeitraum auf, in dem der serverseitige Tages-Writer aktiviert war. Sie behauptet nicht, dass die Browsererweiterung jede mögliche Beobachtung geliefert hat; Lücken und Zustellungszustand bleiben getrennte Telemetrieaspekte. Das Deaktivieren und erneute Aktivieren des Writers startet eine neue kontinuierliche Epoche, und zeitlich begrenzte Leser bleiben nicht verfügbar, es sei denn, beide Aktivitätsflags sind derzeit aktiviert.

Das Rollout der Prioritätsbewertung verwendet drei unabhängige, standardmäßig deaktivierte Flags: TABHUB_FEATURE_PRIORITY_ASSESSMENT_WRITER erlaubt gestufte Bewertungsschreibvorgänge, TABHUB_FEATURE_PRIORITY_READERS erlaubt Schema-22-Leser, und TABHUB_FEATURE_PRIORITY_SHADOW erlaubt die Schattenpräsentation nur, wenn Leser ebenfalls aktiviert sind. C50 deklariert und validiert diese Flags nur; es startet keine Sammlung und stellt keine Prioritätsrouten bereit. Ein Writer kann ohne Leser oder Schatten bereitgestellt werden, während jede angeforderte Fähigkeit auf einer Datenbank älter als Schema 22 fail-closed ausfällt.

Autostart unter Windows

Für den dauerhaften lokalen Start bauen Sie zuerst die Produktionsartefakte und prüfen Sie diese manuell:

corepack pnpm install --frozen-lockfile
corepack pnpm build
corepack pnpm start

Der Server akzeptiert weiterhin Verbindungen nur auf 127.0.0.1; ein anderer Wert für TABHUB_HOST wird abgelehnt, weil es in v1 keine Autorisierung gibt. Für den Autostart öffnen Sie Taskplaner → Aufgabe erstellen und legen Sie Folgendes fest:

• Trigger Bei Anmeldung;

• Wählen Sie auf der Registerkarte Allgemein „Nur ausführen, wenn der Benutzer angemeldet ist“, da das Umschalten des Fokus zwischen Browserfenstern einen interaktiven Desktop erfordert;

• Aktion Programm starten;

• Programm: den absoluten Pfad aus (Get-Command node).Source;

• Argumente: den absoluten Pfad aus (Resolve-Path packages/server/dist/main.js).Path, in Anführungszeichen gesetzt;

• Arbeitsordner: den Pfad aus (Resolve-Path .).Path.

• Deaktivieren Sie auf der Registerkarte Einstellungen „Aufgabe beenden, wenn sie länger als 3 Tage ausgeführt wird“ und aktivieren Sie den Neustart bei Fehler, z. B. nach 1 Minute bis zu 3 Mal.

Speichern Sie die Aufgabe, führen Sie sie dann manuell aus und prüfen Sie Invoke-RestMethod http://127.0.0.1:7717/api/health. Führen Sie nach einem TabHub-Update erneut corepack pnpm install --frozen-lockfile und corepack pnpm build aus, starten Sie dann den laufenden Server (oder die Aufgabe im Taskplaner) neu, damit die neuen Migrationen angewendet werden, und stellen Sie sicher, dass der Health-Endpunkt schemaVersion: 26 anzeigt. Laden Sie TabHub auf der Erweiterungsseite des Browsers neu und aktualisieren Sie die Anwendungsseite, um einen frischen Snapshot zu senden; die Aufgabe muss nicht neu erstellt werden.

Chromium-Erweiterung

Erstellen Sie einen einzigen Manifest-V3-Build:

corepack pnpm --filter @tabhub/extension build

Öffnen Sie in jedem Browser die Erweiterungsseite, aktivieren Sie den Entwicklermodus und laden Sie den entpackten Ordner packages/extension/.output/chrome-mv3 hoch:

• Chrome: chrome://extensions

• Edge: edge://extensions

• Yandex Browser: browser://extensions

Öffnen Sie die TabHub-Einstellungen und wählen Sie separat den Namen des aktuellen Browsers aus. Das ist zwingend erforderlich: Die Chromium-API kann Chrome nicht zuverlässig von Yandex Browser unterscheiden. Daher sind automatisches und manuelles Senden von Tabs deaktiviert, bis eine explizite Auswahl getroffen wurde. Nach einem Update von einer älteren Version muss der Browser erneut ausgewählt werden; das verhindert, dass der bisherige automatische Wert chrome fälschlicherweise Edge oder Yandex markiert. Beim Ändern eines bereits konfigurierten Werts schließt die Erweiterung zuerst den alten Snapshot und sendet dann einen vollständigen Snapshot mit der neuen Identität. Jede Installation der Erweiterung speichert eine eigene UUID, und für die aktuell geladene Erweiterungssitzung im Browser gibt es eine separate Sitzungs-UUID; zusätzlich wird die native tabId übermittelt. Dadurch werden zwei Profile desselben Browsers und zwei physische Tabs mit derselben URL nicht mehr verwechselt, und eine veraltete tabId wird nach einem Neustart oder Neuladen der Erweiterung nicht zum Umschalten verwendet.

Im Popup sind die Prüfung des lokalen Servers, die Anzahl nicht synchronisierter physischer Tabs und Operationen, ein manueller Snapshot und das Erfassen des Inhalts des aktuellen oder aller verfügbaren HTTP(S)-Tabs verfügbar. Ein vollständiger Snapshot ohne feste Begrenzung der Tab-Anzahl wird außerdem beim Start, nach Änderungen an Tabs mit Debounce und alle fünf Minuten über chrome.alarms gesendet; der Transport prüft nur die tatsächliche Payload-Größe. Wenn der Server ausgeschaltet ist, werden ausstehende Daten in chrome.storage.local gespeichert: ersetzte Snapshots und wiederholter Inhalt werden kompaktiert, und die Warteschlange ist nur durch die sichere Größe von 32 MiB begrenzt, ohne Begrenzung der Anzahl der Operationen. Dauerhafte HTTP-4xx-Fehler außer 408/425/429 werden in ein begrenztes Protokoll mit 50 Einträgen verschoben und blockieren die folgenden Elemente nicht; vorübergehende Fehler behalten die Reihenfolge bei und werden automatisch wiederholt.

Die Weboberfläche öffnet standardmäßig Library, und Graph bleibt eine alternative Visualisierung derselben kanonischen Seiten. Es gibt keinen separaten Haupt-Tab Open tabs mehr. Library behält die ursprüngliche Reihenfolge des Auftretens der Seiten und die feste Browserreihenfolge Chrome → Yandex → Edge → Other bei; Tags, Summary und Verknüpfungen werden nicht zwischen physischen Kopien dupliziert. In der Spalte Tab hat eine geschlossene Seite kein physisches Ziel, eine offene Kopie wird als kompakter exakter Browser-Tab angezeigt, und zwei oder mehr Kopien werden zu einer Liste mit Fenster, Position und nativer tabId aufgeklappt. Navigation und Schließen aus dieser Liste adressieren die vollständige Identität browser / installation / browserSession / browserTabId, sodass TabHub den ausgewählten Tab in seinem eigenen Chrome, Yandex Browser, Edge oder einem anderen Chromium-Profil fokussiert oder schließt und kein URL-Duplikat öffnet. Der Filter Multiple open copies behält nur kanonische Zeilen mit openInstanceCount > 1; er wird auf dem Server vor der Zählung und Paginierung angewendet und unterscheidet sich bewusst von der Exact-Duplicate-Prüfung der Raw-URL. Ein Fragment (#...) gehört zur Identität der kanonischen Seite, und groß-/kleinschreibungsunabhängige utm_*-Parameter werden weiterhin als Tracking-Parameter entfernt.

Im Normalzustand markieren die Library-Checkboxen kanonische Seiten für das Ändern von Status und Themen. Eine separate Schaltfläche Manage browser tabs / Tabs verwalten aktiviert die Massenauswahl physischer Instanzen: Die Checkbox der übergeordneten Zeile wählt alle geöffneten Kopfen dieser Zeile aus, während eine aufgeklappte Liste das Behalten nur bestimmter Kopien erlaubt. Die physische Auswahl bleibt über Seitenwechsel hinweg gespeichert, wird jedoch beim Wechsel der Library-Filter, beim Deaktivieren der Verwaltung oder beim Wechsel zu Graph gelöscht; der Wechsel zu Graph bringt die Ansicht auch wieder in den normalen Seitenmodus. Der vollständige gefilterte Satz physischer Tabs wird einer separaten, nicht paginierte Abfrage ohne das SQLite-Limit von 999 Bind-Parameter aufgelöst. In diesem Modus stehen Move, Close, Pin/Unpin, Mute/Unmute, Sleep, Reload, Workspaces und der Export von URL/Markdown/JSON sowie die Voreinstellungen Extra exact copies, exaktem Hostname und Alter zur Verfügung. Ein gewöhnlicher Live-Befehl kann ist nur auf eine einzige bestimmt browser/install/session; gemischte, veraltete oder Offline-Auswahl wird vollständig blockiert. Eine separate, explizite Aktion Close all matching duplicates bündelt nur sichere Überzählige exakte Raw-URL-Kopien über alle verbundenen Profile, behört in jeder Gruppe den Keeper, führt für jedes Profil eine strikte Live-Vorschau aus und zeigt vor der Gesamtbestätigung ausgeschlossenen Profile. Massgenschließen weist pro Profil eine Bestätigung und den verfügbaren Reopen closed tabs vor; unbekannte Ergebnisse werden nicht automatisch wiederholt. Ein Mittelklick auf ein Library-Zeile schließt ohne einen modalen Fragezeichen nur die eine physischen Kopie; bei mehrere Kopien muss zuerst die genaue Zeile in der ausgeklappten Liste ausgewählt werden. Ein TabHub-Tab bleibt geschützt, und Live-Befehle haben keine geheime Targetbegrenzung.

Inside the Library there are personal collections Zur Prüfung und Papierkorb. In „Zur Prüfung“ fallen nur vermeintliche Empfehlungen von Seiten aus dem Inbox mit Significance Null: Die Benutzeroberfläche zeigt immer die Begründung und Warnhinweise, löscht aber nie automatisch etwas. Für jede Seite – unabhängig von der Website oder dem Themen – kann man explizit Behalten, Später oder Schließen und vergessen wird. Die letzte Aktion verlangt eine Bestätigung, richtet sich an jede bekannte physische Kopie in deren eigenen Browser, erfordert ein vollständiges exakt schließendes Ergebnis und blendet die kanonische Seite erst davon aus der normalen Library aus. Wenn eine Kopie offline, verändert oder nicht adressierbar ist, wird die Seite nicht vergessen; passiert der Fehler bereits beim Schließen von mehreren Browsern, meldet das Ergebnis die Zahl der bereits geschlossenen Kopien, und the Eintrag bleibt für eine sichere Wiederholung in der Library. Eine vergessene Seite wartet sieben Tage im reversiblen Papierkorb; das erneute Öffnung oder beaugliche Wiederherstellung hebt die Löschung auf, und abgelaufene geschlossene Einträge werden vom Server im Hintergrund bereinigt.

In der Spalte Activity der Library summiertTabHub zwei historische Kennzahlen für die kanonische Seite über alle aufgezeichneten Browser-Sitzungen. Diese Werte bleiben nach dem Schließen der physischen Tab und nach der Browser-Neustarts bestehen. Bei der Navigation beziehen sich die Intervalle auf die URL, für das erfasst wurden, Integrationen werden daher nicht vermischt. Selbst wenn ein kurzer Wechsel vor der debounced Aufnahme endet, erzeugt das akzeptierte Aktivitätsintervall selbst einen library-Eintrag der geschlossen wurde, und bei der folgenden Snapshot wird er geöffnet und bereichert, ohne Duplikat. On screen zählt nur die Zeit, in der der Tab ausgewählt ist, sein Fenster im Vordergrund steht und de Rechner nicht im Leerlauf oder gesperrt ist. Active use ist eine Unter reactionary Aktion innerhalb dieser Zeit: 60 Sekunden nach einer bestätigen Bewegungsauslösung per Maus, Tastatur, Scrollen oder Touch. Ein Drawer zeigt separat die historische Page activity / Seitenaktivität und die Metrik Open copies / Offene Kopien für die konkreten physischen Tabs der jeweiligen Browser-Sitzs. Die Erweiterung speichert nur Intervalle und Summen, keine Zeigerkoordinaten, gedrückte Tasten und keine Text. In den geschützten Browser-Seiten, in denen kein Content-Script verfügbar ist, wird nur On screen gezählt. Nach einem vollständigen Neustart des Browsers beginnen die Zähler der physischen Tabs mit einer neuen Sitzung, damit eine wiederverwendete Chromium tabId nicht erhalten, aber die historische Seitenaktivität weiter sich aus. Der genaue historische Aggregat beginnt mit Schema 15: alten physischen Summen ohne gespeicherte URL werden bewusst nicht einfach kopiert; Schema 16 materialgen die genauen URL-IDs, die Likes, die man nicht sehen kann.

Workspaces speichert ihr einen benannten Snapshot aller ausgewählter physischen Instanzen in SQLite, mit den Live-URLs, in der aktuellen Serverreihenfolge von Browser/window/index. Die Abfrage mit kompakten IDs enthält; nach einem Live-Befehl synchronisiert die Erweiterung zuerst den neuen Reihenfolge- und Flaggen; damit speichert Direkt nach Move/Pin/Mute nicht den alten Zustand. Save & close speichert erstens bestätigt den Snapshot und öffnet daraufhin die Vorschau des Schließens. Der ganze gespeicherte Satz kann im aktuellen oder im neuen Fenster neu geöffnet, umbenannt oder gelöscht werden; beim Wiederherstellen wird jedes gespeicherte Element nacheinander geöffnet, ohne versteckte Kürzung. Während der Wiederherstellung wird ein doppelter Auslöser blockiert; bei unbekanntem Ergebnis sieht keine Beobwarnung zurück, aber die UI fragt zuerst, ob der Browser geprüft soll. Die ausgewählten Tabs auch als die URL-Liste, Markdown or JSON erstellt.

Der Inhalt wird nur auf Befehl extrahiert: Readability liefert den Haupttext und den HTML-Artikel der Seite; für Seiten ohne passenden Artikel wird document.body.innerText verwendet. In v1 wird dieTabs nicht automatisch durch, es gibt kein automatisches Erkennen.

Nach mehreren Browser-Aufnahmen erscheinen die Einträge in der gemeinsamen Tabelle mit einer Browser-Spalte. Ein erneuter Snapshot aktualisiert die vorhandene normalisierte Referenz; eine nicht mehr vorhandene Tab bleibt mit isOpen=false in der Datenbank.

REST-Prüfung ohne Erweiterung

$body = @{
  browser = 'chrome'
  tabs = @(@{
    url = 'https://example.com/?utm_source=test#section'
    title = 'Example'
    windowId = 1
    index = 0
  })
} | ConvertTo-Json -Depth 4

Invoke-RestMethod -Method Post -Uri http://127.0.0.1:7717/api/ingest/snapshot -ContentType application/json -Body $body
Invoke-RestMethod http://127.0.0.1:7717/api/tabs

GET /api/tabs unterstützt die globale Sortierung vor der Paginierung: sort_by akzeptiert title, topics, browser, activity, status, importance, state oder age, und sort_direction akzeptiert asc oder desc. Die Sortierung nach Spalten nicht mit search_mode=semantic und similar_to kombinierbar; dort wird die Reihenfolge durch Relation bestimmt.

Volltextsuche

Die Suche funktioniert über den Titel und die vollständige URL noch vor der Erfassung des Inhalts, einschließlich des Titels und der Ausgangs-URL jeder physischen Tab, die mit der kanonischen Seite verbunden sind; nach der Erfassung berücksichtigt sie auch den für bereitete Text und Zusammenfassungen. Teilweise eingegebene Wörter werden per Präfix geteilt, und direkte Fragmente aus Titel und URL als Unicode-Substring der Groß- und Kleinschreibung; Satzzeichen in der Suchanfrage werden nicht als FTS-Syntax behandelt:

Invoke-RestMethod 'http://127.0.0.1:7717/api/tabs?q=local-first'

In der Webschnittstelle ist derselbe Parameter in Suchfeld über der Tabelle verfügbar.

Semantische Suche und Inbox-Cluster

Embeddings werden nur nach einem Kommentar erstellt. Standardmäßig verwendet TabHub das lokale Ollama unter http://127.0.0.1:11434; bevor das erste Indizierung erfolgt, installiere das Modell:

ollama pull nomic-embed-text

Für Voyage setzen Sie EMBEDDING_PROVIDER=voyage, VOYAGE_API_KEY und optional in VOYAGE_EMBEDDING_MODEL in .env. EMBEDDING_PROVIDER=disabled schaltet den Provider ganz ab. Beide Varianten speichern 512-dimensionale Vektoren in der lokalen sqlite-vec-Tabelle; erfasster Text wird vor dem Senden zum Provider auf 32.000 Zeichen beschränkt und in Paketen à 100 Tabs verarbeitet.

Invoke-RestMethod -Method Post `
  -Uri http://127.0.0.1:7717/api/embeddings/reindex `
  -ContentType application/json `
  -Body '{"limit":100}'

Invoke-RestMethod 'http://127.0.0.1:7717/api/tabs?q=compiler&search_mode=semantic'
Invoke-RestMethod 'http://127.0.0.1:7717/api/tabs?similar_to=1'

Invoke-RestMethod -Method Post `
  -Uri http://127.0.0.1:7717/api/clusters/inbox `
  -ContentType application/json `
  -Body '{"maxClusters":8}'

Die erneute Erfassung des Textes entfernt den veralteten Vektor. cluster_inbox indexiert nur noch nicht indizierte Tabs mit Status inbox und schlägt dann deterministisch benannte Cluster vor; es erstellt keine Tags und ändert keine Markierung.

Zusammenfassung auf Anfrage

TabHub fasst Tabs nie automatisch zusammen. Um manuelle Anfragen über die UI oder MCP zu erfassen, in .env ANTHROPIC_API_KEY setzen und den Server neu starten. Standardmäßig verwendet der kurze Modus claude-haiku-4-5-20251001, der i die claude-sonnet-5; Modelle und berechnete Preise können über die ANTHROPIC_*-Variablen von .env.example überschrieben werden.

Anfragen erzeugen eine zuverlässige Task in SQLite, und ein Hintergrund-Arbeiter führt höchstens einen Anthropic-Aufruf gleichzeitig aus element. Temporäre Fehler werden mit Backoff, ausgeführte Aufgaben werden nach dem Restart wiederhergestellt, ein veraltetes Ergebnis nicht über neu erwerberten Inhalt zu vergessen. TABHUB_DAILY_SUMMARY_LIMIT begrenzt einmal genau die Anzahl Versuche des Providers pro UTC-Tag; der Token-Verbrauch und die berechneten Kosten werden für jeden Versuch gespeichert und in das Protokoll des Erfolgsjobs geschrieben.

$job = Invoke-RestMethod -Method Post `
  -Uri http://127.0.0.1:7717/api/tabs/1/summarize `
  -ContentType application/json `
  -Body '{"depth":"short"}'

Invoke-RestMethod "http://127.0.0.1:7717/api/jobs/$($job.jobId)"

Wenn der Key nicht gesetzt ist, gibt der Endpunkt 503 SUMMARY_PROVIDER_UNAVAILABLE zurück und erstellt keinen Auftrag. In der UI-Tabelle ist die Short Summary für jeden Tab mit erfasstem Text erstellbar oder aktualisierbar; der Wartestatus und Fehler werden neben der Aktion angezeigt.

Tabellenorganisation

Die Tabelle unterstützt die Auswahl von Zeilen und das massenweise Ändern des Status oder die Zuordnung eines thematischen Pfads, z. B. Research/AI/Agents. In der Massen-Panel und Tab-Karte schlägt das Themen-Feld Pfaden mit Suche vor, bleibt aber wiederum für neue Pfaden edierbar; Die systemische Thema Без темы steht nicht in den Versteck-Hinweisen. Die Zeilen der aktuellen Seite werden mit dynamischer Spaltgröße virtualisiert, sodass aufgeklappte Details korrekt bleiben, ohne die gesamte Seite in DOM zu laden. Die Themen-Border zeigt eine Baumstruktur mit Hilfe mit Hilfe mit Hilfe, mit Hilfe: Man kann Stamm- und Unterthemen erstelle, umbenennen und verschieben, Farbe zuordnen und diese nach Bestätigung löschen. Ein Filter auf einer Oberthemen-Pfad je alle Unterthemen. Der Klick öffnet eine Tab-Karte mit Inhalt, Zusammenfassung, Themen, gerichteten Relationen, Wichtigkeit und benutzerdefinierten Feldern.

Die geschützte systemische Thema Без темы enthält automatisch all Tabs ohne benutzerdefiniertes Thema. Beim erste benutzerdefinierte Thema wird der „untenung erhalten sein“. Hat man dann zu einem Themas gespeichert, wird das Thema wiederholt. Без темы kann als Filter in Library und Graph verwendet werden, ansonsten kann sie nicht umbenannt, umbenannt, gelöscht oder manuell zugewiesen sein. Im Graphen wird das Systemthema selbst und seine strukturellen Verknüpfungen nicht angezeigt: Nach dem Filter sehen die Tabs wie normale, ohne Themenkategorie ebene Tabs aus.

PATCH /api/tabs/:id akzeptiert jede nichtleere Kombination aus status, importance und customFields. Ein Textwert erstellt oder lässt die Feld, null entfernt es. Die Massen-Wichtig ist unter PATCH /api/tabs/importance möglich. CRUD Vorgänge für Themen liegen unter /api/tags, die Pfadaten-Zuordnung ist POST /api/tags/assign. Benutzerdefinierte Verbindungen zwischen Tab-Tab, Tab-Thema und Thema-Thema liegen unter /api/relations; das bisherige /api/links ist als kompatible Projekt beat Connections zwischen Tabs verfügbar. Benutzerdefinierte Änderungen als user gespeichert, MCP-Änderungen als agent.

Beziehungsgraph

Der Abschnitt Graph öffnet einen 3D-WebGL-Graphen, in dem Tabs und Themen als eigene Knotentypen dargestellt werden. Mit der Maus lässt sich die Szene drehen, horizontal bewegen und zoomen. Ein Klick wählt einen Knoten aus, zieht eine Kamera zu ihm und öffnet einen Inspektor mit Metadaten, der Sprung zu einem bestehende Browser-Tab oder zum aktuell markierten Library-Thema.

Für den ausgewählten Knoten wird die Fokus Tiefe von eins bis fünf Schritten eingestellt: Alle Knoten und Kanten in dieser unabhängigen Umgebung bleiben hell, der Rest der Szene wird transparent. Bei kreativem oder aktivem Filter ist die harte Unterdrückung für Direktverbindungen über die Themagrenze hinaus zu haben, und die tieferen Nachbarschaften des ausgewählten Knoten wird über eine beabsichtigte Tast nachgeladen – das globale Full-Graph ist nicht erforderlich. Im Inspektor kann man eine gerichtete semantische Beziehung zu einem sichtbaren Knoten, der Typ angegeben oder vorhanden.

Der Filter im Themenbaum lädt nur eine gewählte Unterbaum. Für dichte Graphen verkürzt die UI die Simulationszeit, vereinfacht die Geometrie und schaltet das teure Ziehen einzelner Knoten ab; der 3D-Code selbst wird als eigenen Lazy-Chunk geladen.

Invoke-RestMethod http://127.0.0.1:7717/api/graph/v2
Invoke-RestMethod 'http://127.0.0.1:7717/api/graph/v2?root_topic_id=1'
Invoke-RestMethod 'http://127.0.0.1:7717/api/graph/v2?root_topic_id=1&focus_node_type=topic&focus_node_id=2&focus_depth=3'
Invoke-RestMethod http://127.0.0.1:7717/api/relations
Invoke-RestMethod http://127.0.0.1:7717/api/graph

MCP für Claude Desktop und Codex

Zuerst bauen Sie den stdio-MCP-Server und lassen Sie den Haupt-TabHub-Server auf 127.0.0.1:7717 laufen:

corepack pnpm --filter @tabhub/mcp build
corepack pnpm dev

Der MCP-Prozess verwendet TABHUB_API_URL und bleibt ein dünner Adapter über der REST-API. Er stellt die Tools list_tabs, get_tab, search_tabs, summarize_tab, cluster_inbox, set_status, set_importance, tag_tabs, link_tabs, list_tags, get_stats, review_disposable_pages, set_page_retention, close_and_forget_page, list_retention_trash, restore_retention_page und die Ressource tabhub://tab/{id} bereit. list_tabs akzeptiert dieselben Filter wie die REST-Liste, einschließlich q, search_mode und similar_to; search_tabs unterstützt die Modi fulltext und semantic. cluster_inbox indiziert explizit unverarbeitete Tabs und gibt Vorschläge mit Titeln, Schlüsselwörtern und Tab-IDs zurück. Das veraltete Tool set_importance liest zuerst /api/features: Bei aktiviertem Logical Importance erfasst der Server einen Agenteneintrag on_behalf_of_user; bei deaktiviertem Flag oder altem schema-17-Server wird der bisherige skalare Eintrag nur für ausgewählte Tabs verwendet. Ein ungültiger Feature-Contract führt zu keinem Eintrag. review_disposable_pages zeigt nur persönliche Vorschläge und Warnungen; set_page_retention speichert Entscheidungen „behalten“ oder „später“. Das destruktive close_and_forget_page erfordert confirmed=true, schließt alle bekannten physischen Instanzen nur bei genau bestätigtem Ergebnis und verschiebt die Seite anschließend in den siebentägigen Papierkorb; sie kann über list_retention_trash und restore_retention_page eingesehen und rückgängig gemacht werden. summarize_tab markiert die Anfrage als Agentenanfrage, stellt sie in dieselbe SQLite-Warteschlange und wartet bis zu 55 Sekunden auf den Abschluss; wenn die Arbeit noch nicht beendet ist, wartet ein erneuter Aufruf weiter auf dieselbe aktive Aufgabe. Der Inhalt von MCP-Antworten ist auf etwa 20 000 Zeichen begrenzt.

Claude Desktop

Öffnen Sie Settings → Developer → Edit Config, fügen Sie den Server in %APPDATA%\Claude\claude_desktop_config.json hinzu und starten Sie Claude Desktop vollständig neu:

{
  "mcpServers": {
    "tabhub": {
      "command": "C:\\Program Files\\nodejs\\node.exe",
      "args": ["D:\\VibeCoding\\TabHub\\packages\\mcp\\dist\\main.js"],
      "env": {
        "TABHUB_API_URL": "http://127.0.0.1:7717"
      }
    }
  }
}

Wenn sich Node.js oder das Repository an einem anderen Ort befinden, ermitteln Sie die absoluten Pfade mit den Befehlen (Get-Command node).Source und (Resolve-Path packages/mcp/dist/main.js).Path und ersetzen Sie die obigen Werte.

Codex

Fügen Sie den Server über die CLI hinzu:

codex mcp add tabhub --env TABHUB_API_URL=http://127.0.0.1:7717 -- 'C:\Program Files\nodejs\node.exe' 'D:\VibeCoding\TabHub\packages\mcp\dist\main.js'
codex mcp list

Die äquivalente manuelle Konfiguration in %USERPROFILE%\.codex\config.toml:

[mcp_servers.tabhub]
command = 'C:\Program Files\nodejs\node.exe'
args = ['D:\VibeCoding\TabHub\packages\mcp\dist\main.js']
cwd = 'D:\VibeCoding\TabHub'
startup_timeout_sec = 10
tool_timeout_sec = 60

[mcp_servers.tabhub.env]
TABHUB_API_URL = "http://127.0.0.1:7717"

Öffnen Sie nach der Verbindung /mcp in Codex und stellen Sie sicher, dass tabhub und alle oben genannten Tools verfügbar sind.

Prüfungen

corepack pnpm test
corepack pnpm typecheck
corepack pnpm build

Sicherungskopie

Das SQLite-Online-Backup wird bei gestopptem oder laufendem Server mit folgendem Befehl erstellt:

corepack pnpm backup

Die Datei erscheint im Wurzelordner backups/.

Implementierungsstatus

• Phase 0: Monorepo-Gerüst, gemeinsame Schemata, SQLite-Migration und Healthcheck — fertig.

• Phase 1: Snapshots aus Chromium-Browsern, zuverlässige Erweiterungs-Warteschlange, REST-Ingest, Deduplizierung und gemeinsame Tabelle — fertig.

• Phase 2: manuelle Erfassung von Readability-Inhalten, FTS5 und Suche in der UI — fertig.

• Phase 3: REST-Verwaltungsoperationen, hierarchische Tags, Statistiken und MCP-Tools für Claude Desktop/Codex — fertig.

• Phase 4: explizite Zusammenfassung über eine zuverlässige SQLite-Warteschlange, sequenzieller Anthropic-Worker, UI und MCP — fertig.

• Phase 5: Themenbaum, Tab-Karte, Verknüpfungen, Wichtigkeit, benutzerdefinierte Felder und Massenoperationen in UI/MCP — fertig.

• Phase 6: sqlite-vec, explizite Indizierung über Ollama/Voyage, semantische Suche, ähnliche Tabs und benannte Inbox-Cluster in REST/MCP — fertig.

• Phase 7: typisierter 3D-Graph von Tabs und Themen mit WebGL-Navigation, beliebigen Querverbindungen, Inspektor und Fokus auf der Umgebung mit einer Tiefe von 1–5 Schritten — fertig.