Pindoc

Code-gepinnter Team-Speicher für KI-gestützte Entwicklung. Agenten schreiben die dauerhafte Aufzeichnung; Menschen überprüfen, diskutieren und steuern.

Pindoc ist ein selbst gehostetes Projektspeichersystem für Teams, die mit KI-Coding-Agenten arbeiten. Es verwandelt nützliche Erkenntnisse von Agenten in typisierte Artefakte: Entscheidungen, Debugging-Pfade, Aufgabenabschlüsse, Verifizierungsnotizen und codeverknüpfte Analysen. Jedes Artefakt ist auf einen Projektbereich begrenzt und an Commits, Dateien, URLs, Ressourcen oder verwandte Pindoc-Artefakte angeheftet.

Es ist immer noch das Wiki, in das man nie etwas eintippt, aber der Punkt ist nicht Automatisierung um ihrer selbst willen. Pindoc bewahrt die Teile der Agentenarbeit auf, die Teamkollegen und zukünftige Agenten wiederverwenden können.

Warum es existiert

KI-Coding-Sitzungen sind produktiv, aber der Team-Kontext geht oft verloren:

• ein Debugging-Pfad stirbt mit der Terminalsitzung,

• dieselbe Entscheidung wird jedem neuen Agenten erneut erklärt,

• nützliche Analysen bleiben im Chat eines einzelnen Bedieners, anstatt Teamwissen zu werden,

• doppelte Dokumente sammeln sich in Wikis, Issue-Trackern, PRs und Commit-Nachrichten an,

• in realen Projektumgebungen kann die Person, die ein Problem findet, den Code nicht immer sofort ändern; strukturierte Beweise helfen dem Team bei der Diskussion und Entscheidungsfindung.

Pindoc verwandelt Agentenarbeit, die es wert ist, behalten zu werden, in durchsuchbaren, code-gepinnter Team-Speicher. Der nächste Teamkollege oder Coding-Agent kann Pindoc fragen, was wichtig ist, bevor er Änderungen vornimmt.

Was Pindoc anders macht

• Kollaborative Speicherebene: Artefakte werden für Teamkollegen und zukünftige Agenten geschrieben, nicht als private Chat-Zusammenfassungen.

• Nur-Agenten-Schreiboberfläche: Die Reader-UI dient dem Lesen und der Überprüfung; dauerhafte Schreibvorgänge erfolgen durch Agenten.

• MCP-nativer Workflow: Tools wie pindoc.context_for_task, pindoc.artifact.propose und pindoc.task.queue regulieren das Agentenverhalten, anstatt nur als dünne CRUD-API zu fungieren.

• Typisierte Artefakte: Entscheidung, Analyse, Debug, Flow, Aufgabe, TC, Glossar und Domain-Pack-Typen.

• Code-gepinnter Speicher: Artefakte können auf Commits, Dateien, Zeilenbereiche, Ressourcen, URLs und verwandte Artefakte verweisen.

• Design für Aufzeichnungswürdigkeit: Pindoc vermeidet rohe Chat-Archive und behält nur Entscheidungen, Analysen, Debug-Pfade, Verifizierungen und Aufgabenkontexte mit zukünftigem Wert.

• Multi-Projekt-Daemon: Ein /mcp-Endpunkt kann mehrere Projekte bedienen; jeder Tool-Aufruf trägt project_slug.

• Self-Host-First: Docker Compose startet Postgres, pgvector, den Pindoc-Daemon und die Reader-SPA.

Öffentliche Demo

Eine schreibgeschützte öffentliche Demo ist ein geplanter Schritt und noch nicht Teil dieser OSS-Veröffentlichung. Bis zur Veröffentlichung sind die README, docs/ und ein selbst gehosteter Klon der primäre Beweis. Bediener, die Pindoc von Anfang bis Ende evaluieren möchten, führen docker compose up -d --build aus und untersuchen ihre eigenen Artefakte.

Der Plan für die Folgedemo befindet sich im Public Demo Plan für den Zeitpunkt, an dem eine gehostete Instanz angemessen ist.

Schnellstart

Voraussetzungen:

• Docker 27+

• 2 CPU-Kerne und 4 GB RAM empfohlen für lokales Dogfooding oder kleine Teams

• 5 GB freier Speicherplatz empfohlen für Docker-Images, Postgres-Daten und den Embedding-Cache; 2 GB ist das Minimum für einen frischen Klon

• Ausgehendes HTTPS beim ersten Start, damit das gebündelte EmbeddingGemma-Modell und die Laufzeit zwischengespeichert werden können

• Go 1.25+ nur für host-native Entwicklung

• Node 20.15+ und pnpm 10+ nur für Webentwicklung außerhalb von Docker

Der Standard-Docker-Pfad beinhaltet semantische Suche durch einen gebündelten EmbeddingGemma Q4 ONNX-Provider, daher ist kein Embedding-Sidecar erforderlich. Siehe Systemanforderungen für minimale und optionale Bereitstellungsprofile.

git clone https://github.com/var-gg/pindoc.git
cd pindoc
docker compose up -d --build

Öffnen Sie den Reader:

http://localhost:5830/

Bei einer frischen Instanz leitet / zum Assistenten für das erste Projekt weiter. Um diesen Assistenten direkt zu öffnen:

http://localhost:5830/projects/new?welcome=1

Verbinden eines MCP-Clients

Der Docker-Daemon stellt einen MCP-Endpunkt auf Kontoebene bereit:

{
  "mcpServers": {
    "pindoc": {
      "type": "http",
      "url": "http://127.0.0.1:5830/mcp"
    }
  }
}

Der Projektbereich ist nicht in der URL kodiert. Agenten übergeben project_slug bei projektbezogenen Tool-Aufrufen. Workspaces, die von pindoc.harness.install generiert wurden, speichern diesen Slug im PINDOC.md-Frontmatter.

Häufige Workflows

Bitten Sie einen Agenten, die Arbeit mit Projektkontext zu beginnen:

Use Pindoc context before editing. Find the current project, inspect assigned
Tasks, then implement the next acceptance item.

Typische MCP-Schleife:

1. pindoc.workspace.detect

2. pindoc.task.queue

3. pindoc.context_for_task

4. Code- oder Dokumentationsarbeit

5. pindoc.artifact.propose

6. Aktualisierung des Aufgabenakzeptanz- und Abschlussstatus

Konfiguration

Der Standard-Docker-Pfad ist für einen einzelnen Benutzer und nur für Loopback vorgesehen:

Setzen Sie einen beschreibbaren Daemon nicht ohne Identitätsanbieter dem öffentlichen Internet aus. Halten Sie für eine öffentliche, schreibgeschützte Demo /mcp und mutierende HTTP-Routen am Reverse-Proxy blockiert; siehe SECURITY.md und docs/22-public-demo.md.

Für eine beschreibbare öffentliche oder geräteübergreifende Instanz folgen Sie docs/oauth-setup.md. Es behandelt die Einrichtung der GitHub OAuth App, die Callback-Regel ${PINDOC_PUBLIC_BASE_URL}/auth/github/callback, die Registrierung des Laufzeit-MCP-Clients und lokales OAuth-QA mit PINDOC_FORCE_OAUTH_LOCAL.

Entwicklung

# Run Go tests. Integration tests that need Postgres are skipped unless
# PINDOC_TEST_DATABASE_URL is set.
go test ./...

# Web checks.
cd web
pnpm install --frozen-lockfile
pnpm typecheck
pnpm test:unit
pnpm build

# Full image build.
docker build -t pindoc-server:local .

Um den OAuth-Bearer-Pfad lokal zu testen, während die Verbindung weiterhin über 127.0.0.1 erfolgt, setzen Sie PINDOC_FORCE_OAUTH_LOCAL=true; der Daemon warnt beim Booten und erfordert Bearer-Token für Loopback /mcp-Aufrufe.

Auf Windows-Hosts ohne lokale C-Toolchain führen Sie Go-Tests über Docker aus:

docker run --rm -v "${PWD}:/work" -w /work golang:1.25 go test ./...

Dokumentation

• Dokumentations-Hub

• Public Demo Plan

• Public Demo Story Path

• Richtlinie für aufzeichnungswürdige Artefakte

• Checkliste für öffentliche Veröffentlichungen

• Mitwirken

• Sicherheit

• Design-Quellnotizen

Status

Pindoc befindet sich im aktiven Dogfooding. Der lokale Self-Host-Pfad, die Reader-UI, das Projekt-/Bereichsmodell, der Artefakt-Vorschlags-Workflow, die Aufgabenwarteschlange, die Revisionshistorie, Zusammenfassungen und der echte Embedding-Provider-Pfad sind implementiert. Der öffentliche OSS-Start konzentriert sich auf die Zuverlässigkeit beim ersten Start, eine schreibgeschützte Dogfood-Demo, CI, Sicherheitsdokumentationen und eine klarere kollaborative Positionierung.

Lizenz

Apache License 2.0. Siehe LICENSE.