Pindoc

Memoria de equipo vinculada al código para el desarrollo asistido por IA. Los agentes escriben el registro duradero; los humanos revisan, discuten y dirigen.

Pindoc es un sistema de memoria de proyectos autohospedado para equipos que trabajan con agentes de programación IA. Convierte los descubrimientos útiles de los agentes en artefactos tipados: decisiones, rutas de depuración, cierres de tareas, notas de verificación y análisis vinculados al código. Cada artefacto se delimita a un área del proyecto y se vincula a commits, archivos, URLs, recursos o artefactos de Pindoc relacionados.

Sigue siendo la wiki en la que nunca escribes, pero el objetivo no es la automatización por sí misma. Pindoc conserva las partes del trabajo del agente que los compañeros de equipo y los futuros agentes pueden reutilizar.

Por qué existe

Las sesiones de programación con IA son productivas, pero el contexto del equipo sigue perdiéndose:

• una ruta de depuración muere con la sesión de terminal,

• la misma decisión se vuelve a explicar a cada nuevo agente,

• el análisis útil se queda en el chat de un solo operador en lugar de convertirse en conocimiento del equipo,

• se acumulan documentos duplicados en wikis, gestores de incidencias, PRs y mensajes de commit,

• en entornos de proyectos reales, la persona que encuentra un problema no siempre puede cambiar el código inmediatamente; la evidencia estructurada ayuda al equipo a discutir y decidir.

Pindoc convierte el trabajo del agente que merece la pena conservar en una memoria de equipo buscable y vinculada al código. El siguiente compañero de equipo o agente de programación puede preguntar a Pindoc qué es importante antes de realizar cambios.

Qué hace diferente a Pindoc

• Capa de memoria colaborativa: los artefactos se escriben para compañeros de equipo y futuros agentes, no como resúmenes de chat privados.

• Superficie de escritura solo para agentes: la interfaz de usuario de lectura es para leer y revisar; las escrituras duraderas pasan a través de los agentes.

• Flujo de trabajo nativo MCP: herramientas como pindoc.context_for_task, pindoc.artifact.propose y pindoc.task.queue regulan el comportamiento del agente en lugar de actuar como una API CRUD simple.

• Artefactos tipados: Decision, Analysis, Debug, Flow, Task, TC, Glossary y tipos de paquete de dominio.

• Memoria vinculada al código: los artefactos pueden apuntar a commits, archivos, rangos de líneas, recursos, URLs y artefactos relacionados.

• Diseñado para ser registrado: Pindoc evita archivos de chat sin procesar y solo conserva decisiones, análisis, rutas de depuración, verificación y contexto de tareas con valor futuro.

• Daemon multi-proyecto: un punto final /mcp puede servir a múltiples proyectos; cada llamada de herramienta lleva project_slug.

• Primero autohospedado: Docker Compose levanta Postgres, pgvector, el daemon de Pindoc y la SPA de lectura.

Demo pública

Una demo pública de solo lectura es una vía de seguimiento y no forma parte de este lanzamiento de código abierto. Hasta que se publique, el README, docs/ y un clon autohospedado son la prueba principal. Los operadores que deseen evaluar Pindoc de principio a fin pueden ejecutar docker compose up -d --build e inspeccionar sus propios artefactos.

El plan de demo de seguimiento se mantiene en Plan de Demo Pública para cuando una instancia alojada sea apropiada.

Inicio rápido

Requisitos previos:

• Docker 27+

• Se recomiendan 2 núcleos de CPU y 4 GB de RAM para uso local o equipos pequeños

• Se recomiendan 5 GB de disco libre para imágenes de Docker, datos de Postgres y la caché de incrustaciones; 2 GB es el mínimo para un clon nuevo y ligero

• HTTPS de salida en la primera ejecución para que el modelo EmbeddingGemma incluido y el tiempo de ejecución puedan ser cacheados

• Go 1.25+ solo para desarrollo nativo en el host

• Node 20.15+ y pnpm 10+ solo para desarrollo web fuera de Docker

La ruta predeterminada de Docker incluye búsqueda semántica a través de un proveedor ONNX EmbeddingGemma incluido, por lo que no se requiere un sidecar de incrustación. Consulta Requisitos del sistema para perfiles de despliegue mínimos y opcionales.

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

Abre el lector:

http://localhost:5830/

En una instancia nueva, / redirige al asistente del primer proyecto. Para abrir ese asistente directamente:

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

Conectar un cliente MCP

El daemon de Docker expone un punto final MCP a nivel de cuenta:

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

El alcance del proyecto no está codificado en la URL. Los agentes pasan project_slug en las llamadas de herramientas con alcance de proyecto. Los espacios de trabajo generados por pindoc.harness.install almacenan ese slug en el frontmatter de PINDOC.md.

Flujos de trabajo comunes

Pide a un agente que comience a trabajar con el contexto del proyecto:

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

Bucle MCP típico:

1. pindoc.workspace.detect

2. pindoc.task.queue

3. pindoc.context_for_task

4. trabajo de código o documentación

5. pindoc.artifact.propose

6. actualizar el estado de aceptación y cierre de la tarea

Configuración

La ruta predeterminada de Docker es de usuario único y solo loopback:

No expongas un daemon escribible a la internet pública sin un proveedor de identidad. Para una demo pública de solo lectura, mantén /mcp y las rutas HTTP de mutación bloqueadas en el proxy inverso; consulta SECURITY.md y docs/22-public-demo.md.

Para una instancia pública escribible o entre dispositivos, sigue docs/oauth-setup.md. Cubre la configuración de la GitHub OAuth App, la regla de callback ${PINDOC_PUBLIC_BASE_URL}/auth/github/callback, el registro del cliente MCP en tiempo de ejecución y el QA de OAuth local con PINDOC_FORCE_OAUTH_LOCAL.

Desarrollo

# 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 .

Para probar la ruta bearer de OAuth localmente mientras te conectas a través de 127.0.0.1, establece PINDOC_FORCE_OAUTH_LOCAL=true; el daemon avisará al arrancar y requerirá tokens Bearer para las llamadas /mcp de loopback.

En hosts Windows sin una cadena de herramientas C local, ejecuta las pruebas de Go a través de Docker:

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

Documentación

• Centro de documentación

• Plan de Demo Pública

• Ruta de la historia de la Demo Pública

• Política de artefactos dignos de registro

• Lista de verificación para lanzamiento público

• Contribución

• Seguridad

• Notas de diseño

Estado

Pindoc está en fase de uso interno activo. La ruta de autohospedaje local, la interfaz de lectura, el modelo de proyecto/área, el flujo de propuesta de artefactos, la cola de tareas, el historial de revisiones, los resúmenes y la ruta real del proveedor de incrustaciones están implementados. La vía de lanzamiento de código abierto se centra en la fiabilidad de la primera ejecución, una demo de uso interno de solo lectura, CI, documentos de seguridad y un posicionamiento colaborativo más claro.

Licencia

Licencia Apache 2.0. Consulta LICENSE.