Celmis

Inteligencia de código autoalojada: interroga tus bases de código, revisa pull requests y genera la evidencia que pide un auditor

celmis-labs.github.io · Documentación · Inicio rápido · Resultados

Celmis lee tus repositorios una sola vez y mantiene un grafo de símbolos de ellos. Todo lo demás —preguntas, revisiones, auditorías de dependencias, documentación generada— es otra forma de leer ese grafo. Se ejecuta en una sola máquina con docker compose, con el proveedor de modelos que elijas detrás, y nada sale de tu red salvo las llamadas que configures.

En el relato más antiguo, Kelmis era el fundidor —uno de los tres Dáctilos Ideos, junto con Damnameneus el martillo y Acmon el yunque, a quienes se atribuía el trabajo del hierro. Aquí el índice hace la reducción; las superficies son las que trabajan el resultado.

Lo que te aporta y que una herramienta basada solo en el diff no puede

Haz una pregunta que abarque dos repositorios y la respuesta cita a ambos:

Eso no es un resultado de búsqueda. La pasarela y el servicio de pagos son repositorios separados sin código compartido, y la respuesta traza la cadena de llamadas entre ellos —y luego observa, sin que se lo pidan, que el nombre del topic de Kafka está incrustado en ambos y que cambiar uno rompe silenciosamente el otro.

Un revisor que solo lee el diff de forma estructural no puede decir eso. Nunca tuvo abierto el otro repositorio.

Related MCP server: OpenCodeHub MCP Server

Siete cosas que la gente hace con ella

Las tres primeras son las que una herramienta de revisión de código no hace en absoluto, y son la razón por la que esto es una plataforma y no un revisor: indexa una vez y luego lee ese índice desde el lado del trabajo en el que estés.

Tres números

Ese último número es deliberadamente poco favorecedor, y se queda. Mide una de las superficies de abajo —la revisión de pull requests en PRs aislados de un solo repositorio— y ese conjunto no tiene un servicio hermano en el que un símbolo pueda tener consumidores, así que aquello sobre lo que se construye este producto no está en el número en absoluto. La tabla, la auditoría de cada hallazgo que puntuó como falso y el comando que reproduce ambos están en Resultados.

Tabla de contenidos

• Lo que te aporta y que una herramienta basada solo en el diff no puede

• Siete cosas que la gente hace con ella

• Tres números

• Inicio rápido

• Primer usuario y administración

• Conectar un repositorio

• Pregunta al código

• Revisión de pull requests

• Dependencias, SBOM y el paquete de evidencias

• Arrégralo desde aquí

• Quién puede ver qué

• Lenguajes y formatos

• Comprobaciones deterministas — sin modelo, sin falsos positivos

• Conecta Claude Code y otros clientes MCP

• Resultados

• Auditoría de los falsos positivos

• Repositorios de prueba

• Configuración

• Operaciones

• Desarrollo local

• Referencia de la CLI

• Arquitectura

• Solución de problemas

• Estructura del proyecto

• Procedencia y derechos

Inicio rápido

Qué necesitas

Postgres y Qdrant están incluidos — no hay ningún clúster externo que aprovisionar. No es necesario instalar Python ni Node.js para el flujo con Docker.

Ponlo en marcha

git clone <your-fork-url> celmis
cd celmis

# Generates .env and fills every secret in the format each one needs.
# Idempotent: run it again after a pull and it fills only the new blanks.
./scripts/init-env.sh

docker compose --env-file .env up -d

# Wait for healthy — first boot pulls three images and applies migrations
docker compose ps

Abre http://localhost.

Aquí no se compila nada. Las tres imágenes se descargan del registro que indica CELMIS_REGISTRY con la etiqueta de CELMIS_TAG, para linux/amd64 y linux/arm64 — tanto Apple Silicon como un servidor ARM reciben una imagen nativa. Compilarlas en la máquina que las ejecuta se midió en 485 segundos y 4.2 GB de disco solo para api, que es por lo que instalar ya no significa compilar.

El puerto 80, no el 3000: un proxy inverso coloca la aplicación y su API en un mismo origen y sirve la API bajo /backend. Eso no es una preferencia de despliegue — el bundle del navegador pide una ruta relativa, que es la única manera de que una imagen publicada sirva a todas las instalaciones en lugar de solo a aquella sobre la que se construyó.

Para trabajar SOBRE Celmis en lugar de solo ejecutarlo, añade el overlay de desarrollo y recuperas las compilaciones locales:

docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

init-env.sh --check informa de lo que sigue vacío sin escribir nada.

Eso es un render de la sesión capturada, no una grabación de pantalla — las cifras que contiene son las que produjo la ejecución del 26 de agosto de 2026, y la salida de compose es textual de logs/03-up.log del informe de instalación. Está dibujado en lugar de fotografiado porque no se puede levantar una segunda pila junto a una en marcha: docker-compose.yml fija container_name, así que los nombres chocan.

Detenerlo

docker compose down       # stop, keep your data
docker compose down -v    # stop and DELETE every volume

Primer usuario y administrador

El formulario de registro en /login funciona en cuanto la pila está sana. Esa cuenta es un usuario normal — registrarse no concede derechos de administración, ni siquiera a la primera persona que entre.

La administración global viene del entorno: inicia sesión con CELMIS_MASTER_EMAIL y CELMIS_MASTER_KEY (como contraseña), ambas en .env. Quien administra la máquina es el administrador, que es el modelo que quiere una instalación autoalojada en lugar de quien haya llegado primero al formulario. La ruta no existe salvo que ambas variables estén definidas, y cada uso que se hace de ella queda escrito en el registro de auditoría.

Para elevar una cuenta normal:

docker compose exec api analyzer auth make-admin you@example.com

Conectar un repositorio

1. Ajustes → Configuración del LLM — pega una clave del proveedor. Se cifra con CREDENTIAL_MASTER_KEY antes de tocar la base de datos, y la interfaz solo vuelve a mostrarte los primeros y los últimos cuatro caracteres.

2. Conexiones — añade un token de GitHub, GitLab o Bitbucket. Usa una cuenta de máquina, no la tuya: un token personal alcanza todos los repositorios que puedes ver, y los tokens acaban en copias de seguridad, registros y capturas de pantalla.

3. Repositorios → Añadir — elige repositorios del proveedor o pega una URL de clonación. La indexación se pone en cola; el trabajo aparece en la misma página.

La indexación construye dos cosas a partir del mismo checkout: un grafo de símbolos (definiciones, llamadas, imports — sobre lo que razonan los agentes de revisión) y embeddings en Qdrant (lo que recupera Q&A). Un repositorio de 120k símbolos tarda aproximadamente un minuto en cuatro núcleos.

Veintitrés lenguajes se analizan en el grafo. Un archivo en un lenguaje sin parser se indica explícitamente en lugar de omitirse en silencio — analyzer graph-stats enumera lo que se leyó y lo que no.

Pregunta al código

Una pregunta en un chat, respondida con citas file:line de tantos repositorios como le señales. Las respuestas se transmiten a medida que se escriben.

Agrupa repositorios en un proyecto, y la pregunta se hace al grupo:

Las respuestas citan código real, y solo el código que quien pregunta tiene permitido ver — que es lo que hace seguro entregar la pregunta a alguien ajeno al equipo que es dueño del repositorio. Ver Quién puede ver qué.

Revisión de pull requests

Agents read the diff and post findings to GitHub, GitLab or Bitbucket. Rather than show that in a screenshot of this interface, the reviews are left where they were posted — fifty pull requests on real projects, with the comments still attached to the lines they were written about. They are listed under Repositorios de prueba, and the output there is unedited, including the findings the audit below marks wrong.

Where the graph is built, the review also carries what the diff does not show: who else calls the symbol being changed, including from another repository. Where it is not built, the review still runs — it just answers the narrower question, which is what the benchmark measured.

Every finding the benchmark scored false was opened in the source and published with a verdict. Thirty-three of seventy-nine turned out to be real defects the gold set does not contain. That work is in Auditoría de los falsos positivos, with the code and a permalink for each, so you can disagree with any of them.

Dependencies, SBOM and the evidence pack

The dependency audit is deterministic: native auditors where the tool is installed, OSV everywhere else, no model involved. A language model, if you give it a key, writes the summary — it does not decide what is vulnerable.

Two files come out of every audit, and neither needs an LLM key:

• SBOM — a CycloneDX inventory of every dependency, its version, package URL and the vulnerabilities known against it. This is the file people mean when they say «mándenos su SBOM».

• Evidence pack — the audit as a filing: every SBOM, every finding, the timeline of past runs, and a sha256 of each file, so a third party can check nothing was edited afterwards without having to trust us. A folder whose contents can be changed later proves nothing; the manifest is what makes it evidence.

Alongside them, the generated technical documentation — module PRDs, feature documents and integration guides written from the code — which is yours to keep and keeps working after any subscription ends.

Why this exists now. From 11 September 2026 the EU Cyber Resilience Act requires a manufacturer to report an actively exploited vulnerability to ENISA within 24 hours. The formal SBOM mandate lands in December 2027, but you cannot answer the 24-hour question without component-level visibility first — to report what is affected, you have to know what is inside.

Celmis does not claim compliance, and will not. It produces the artefacts a filing needs. Whether a filing is adequate is a lawyer's judgement, and a tool that implies otherwise is selling a false sense of safety.

One more thing the audit page says out loud, because it is the failure nobody looks for: an ecosystem nobody scanned reports zero vulnerabilities exactly like a clean one. Coverage is shown next to the findings — which auditor produced each result, and, more usefully, what went unchecked and why.

Corregir desde aquí

Finding something is half a loop. An embedded Claude Code session runs inside the installation, edits the checkout, and the runner commits, pushes a branch and opens a pull request.

A vulnerability in the dependency audit carries a Corregir con Claude button. It does not open an empty chat — it hands the session the repository, the package, both versions and the boundaries of the job, already written:

Here is one such loop, end to end, on a real finding — lodash 4.17.11 with a known vulnerability against it. 220 seconds from Iniciar la sesión to an open pull request, in five turns:

Read package.json
  → "Only package.json has lodash; no requirements.txt/pyproject/go.mod exist here."
Edit package.json: "lodash": "4.17.11" → "4.18.0"
mcp__exec__run: cat package.json | grep -A2 lodash; ls
  → "Confirmed no other manifest files exist, so no other changes were needed."

The branch it pushed, and the pull request it opened, on GitHub:

Look at what is not in that diff. axios 0.21.1, minimist 1.2.0, node-fetch 2.6.0 sit on the lines directly above and below — all outdated, all flagged in the same audit — and all untouched. The task said manifests only, and an agent that tidied three more on the way past would have been a worse result to review, not a better one.

It is a live pull request, not a screenshot: celmis-demo-gateway#6 — branch celmis-agent/b8960e01, one commit, +1/-1.

Two details in that transcript are worth more than the diff. The agent did not assume there were no other manifests — it ran a command in the sandbox to check. And the task said «solo manifiestos, no tocar dependencias no relacionadas», so the change is exactly one line.

Lo que el runner permite, y lo que no

This is decided by the runner, not by the prompt — which is the part worth reading before you grant an agent anything:

• Sin shell propio. Bash, WebFetch, WebSearch y la edición de notebooks están deshabilitados. Los comandos se ejecutan a través del contenedor sandbox, que es un servicio separado con su propio uid y un sistema de archivos raíz de solo lectura.

• Git es trabajo del runner. El agente nunca hace commit ni push. Cuando el trabajo está hecho — o cuando se pulsa Finalizar y subir — el runner crea el commit, sube la rama y abre el PR. Nunca a la rama por defecto.

• Un límite del proveedor es una pausa, no una pérdida. El primer intento de la ejecución anterior alcanzó un límite semanal de la cuenta a mitad de sesión. La sesión no murió: pasó a paused, mantuvo su trabajo reanudable durante catorce días y mostró el mensaje del propio proveedor en lugar de un fallo genérico. Una segunda clave la terminó.

• La sesión se puede ver en vivo. La salida se transmite por SSE con reproducción, de modo que una reconexión retoma donde se quedó en lugar de empezar en blanco.

Connection is a setup token, held per user or per workspace. The API never returns it once saved — only whether it is there and whether it still works.

Quién puede ver qué

Access is resolved per repository, per team, and it governs every surface at once — Q&A, graph, search, MCP:

This is what makes the neighbouring-team case work rather than being a promise: load the repository, grant the other team the right to ask, and deny the paths that must not be read. They get answers; those files are refused at the source, not filtered out of a response that already contained them.

Lenguajes y formatos

Seventeen graph modules, plus a generic path through tree-sitter tag queries for languages without one:

Código — Python, TypeScript, JavaScript, Go, Java, C#, C++, PHP, Vue y más a través de la vía genérica.

Infraestructura — Dockerfile, docker-compose, Helm, manifiestos de Kubernetes, Terraform y flujos de trabajo de CI. Esta es la parte que la mayoría de las herramientas de inteligencia de código omiten, y es la razón por la que una pregunta puede cruzar de una función a la definición del servicio que la ejecuta.

Comprobaciones deterministas — sin modelo, sin falsos positivos

Every check below is decided by reading files. No language model takes part in deciding that something is wrong, so the false-positive rate is zero by construction rather than by tuning.

That distinction is the whole point. Around twenty percent false positives is where developers stop reading a tool's comments at all — one costs seconds of attention, a thousand costs you a team that has learned to skip everything the tool says. A model is used here to explain and to prioritise, never to detect.

Ordinary CVE scanning is deliberately not on that list. OSV-Scanner already does it, it is free, and it is the de-facto standard — Celmis runs it (plus each ecosystem's own auditor: pip-audit, npm audit, govulncheck, cargo audit) and treats the result as an input rather than as a feature.

Sobre el cumplimiento. Celmis produce los artefactos que pide una auditoría: un SBOM CycloneDX, un inventario de dependencias, un historial de hallazgos con marcas de tiempo y la evidencia en la que se apoya cada hallazgo. No afirma que su expediente sea adecuado, y ninguna herramienta puede hacerlo honestamente: lo que un auditor acepta depende de su sector, su jurisdicción y sus propios controles. Produzca los artefactos; deje que quienes tienen la tarea de evaluarlos lo hagan.

Conectar Claude Code y otros clientes MCP

Celmis exposes its index over MCP, so an agent can search symbols, read API surfaces and find consumers instead of grepping a checkout it does not have.

Por HTTP (la pila en ejecución lo sirve en /mcp/):

# Mint a token (or issue one from Settings → MCP in the UI)
docker compose exec api analyzer mcp issue-token \
  --scopes "read:graph read:groups" --duration 86400

// ~/.claude.json  (or .mcp.json in a project)
{
  "mcpServers": {
    "celmis": {
      "type": "http",
      "url": "http://localhost:8000/mcp/",
      "headers": { "Authorization": "Bearer <the token you just minted>" }
    }
  }
}

Por stdio, sin el salto por HTTP:

{
  "mcpServers": {
    "celmis": {
      "command": "docker",
      "args": ["compose", "exec", "-T", "api", "analyzer", "mcp", "serve"]
    }
  }
}

Qué puede preguntar un agente

The HTTP mount serves 18 tools. They answer the questions a grep cannot:

Los dos transportes no son el mismo conjunto. analyzer mcp serve a través de stdio sirve 13 herramientas más antiguas con forma de grafo (find_symbol, find_callers, query_graph); el montaje HTTP sirve las 18 anteriores. Ninguno es subconjunto del otro: elige el transporte para las herramientas que quieras.

Una guía paso a paso, con los ámbitos que necesita cada herramienta y los modos de fallo, está en .claude/skills/celmis-mcp/SKILL.md. Claude Code la detecta automáticamente cuando este repositorio está abierto.

Lo que el agente puede solicitar

Una sola llamada a search_symbols, un símbolo de contrato, y la respuesta llega desde dos repositorios en dos idiomas — para un cliente que no ha hecho checkout de ninguno. La frontera que un diff nunca cruza es la que esto vuelve ordinaria.

Dieciocho herramientas, servidas a través de Streamable HTTP en /mcp/ y autenticadas con el mismo token Bearer que /api/:

cross_repo_edges es la que vale la pena entender, porque es la razón por la que este producto lleva un grafo de símbolos en primer lugar. Un revisor que solo ve diffs — cada herramienta de la tabla del benchmark anterior, incluida esta cuando el grafo está vacío — puede decirte que la firma de una función cambió. No puede decirte que un servicio en un repositorio distinto todavía llama a la forma antigua, porque nunca tuvo ese repositorio abierto. Agrupa los repositorios una vez, y esa pregunta se puede responder:

> which services outside this repo call PaymentGateway.charge?

Esto también es por lo que nuestro puesto en el benchmark subestima el producto en lugar de describirlo: el conjunto del benchmark son pull requests aisladas de un solo repositorio, así que no hay un repositorio hermano para que una arista cruce. La capacidad es real y el benchmark no puede verla — lo cual es una afirmación sobre el benchmark, no una declaración que debas aceptar a ciegas. Apunta un cliente MCP a tu propio grupo y compruébalo.

Resultados

Celmis se ejecutó sobre el conjunto offline del Martian Code Review Bench: 50 pull requests seleccionadas, 173 comentarios de referencia escritos por humanos, puntuados contra el conjunto de referencia por un juez LLM. Medido en e0db376 con gemini-3.6-flash a temperatura 0.1, sin tokens de razonamiento.

El F1 varía 4.8 puntos según quién juzgue. El puesto no se mueve en absoluto: decimoséptimo bajo los tres. Por debajo de nosotros en cada uno de los tres: CodeRabbit (19/25/23), todas las versiones de Greptile (26–29), Kodus (21/23/21), Copilot, Claude Code, Gemini y CodeAnt.

Toda la ejecución costó $5.88 — $0.118 por pull request — y produjo 153 hallazgos, 3.06 por PR (defecto 114, seguridad 27, contrato 6, estructural 6).

Por qué esta comparación es justa. Martian incluye sus propias evaluaciones de 49 herramientas en el repositorio del benchmark, producidas por los mismos tres jueces sobre las mismas 50 PRs contra los mismos datos de referencia. No volvimos a puntuar a nadie: sus filas se toman tal como se publicaron y la nuestra se añade. Reproduce toda la tabla con:

python3 autoloop/offline_table.py anthropic_claude-sonnet-4-5-20250929

Offline no es la tabla pública. Martian ejecuta dos benchmarks. La tabla pública es la online: 200,000 pull requests reales puntuadas por lo que los desarrolladores realmente corrigieron. Esta tabla es la offline: 50 PRs seleccionadas puntuadas contra un conjunto de referencia. Miden cosas distintas y los números no son intercambiables. Las afirmaciones del tipo «la herramienta X es la #1 en Martian» suelen referirse a la tabla online, a una métrica distinta o a un juez distinto.

Lo que este número no contiene. El grafo estaba vacío en las 50 PRs (graph_status nulo, drift vacío en todas), porque el conjunto del benchmark son pull requests aisladas de un solo repositorio: no hay un servicio hermano en el que un símbolo pueda tener consumidores. El drift entre repositorios, aquello para lo que este producto lleva un grafo de símbolos, no contribuyó en nada a la puntuación anterior. No es medible aquí, y no lo estamos afirmando a partir de esta tabla. Consulta Repositorios de prueba para verlo funcionar con código real.

Auditoría de los falsos positivos

La puntuación del benchmark tiene un suelo estructural: el juez compara nuestro comentario con una lista finita de comentarios de referencia escritos por humanos, por lo que un hallazgo correcto que el anotador nunca escribió se cuenta como falso por construcción. Abrimos los 79 nuestros en el código fuente en el commit medido y asignamos un veredicto a cada uno.

De los 79 hallazgos puntuados como falsos positivos, 33 son defectos reales que el conjunto de referencia no contiene, 38 son genuinamente erróneos y 8 no pudieron resolverse a partir del código. Eso sitúa la precisión real de esta ejecución entre 69.7% y 75.0% en lugar del 48.0% medido — pero esa cifra corregida no puede compararse con nada de la tabla anterior, porque nadie ha auditado las demás herramientas de la misma manera y sus falsos positivos casi con seguridad contienen una proporción similar de defectos reales; para comparar con otras herramientas, el 48.0% medido es la cifra honesta, porque es el mismo método aplicado a todos.

Veinticuatro de los 38 hallazgos genuinamente erróneos comparten cuatro causas raíz, y ninguna de ellas es «el modelo es débil» — las cuatro tienen que ver con lo que se le mostró al modelo. La más frecuente es un identificador declarado en el mismo archivo pero fuera del fragmento que recibió el agente: un parámetro de método 26 líneas más arriba, un import en la línea 3, un attr_reader en la línea 18.

El informe completo ofrece la afirmación, el código en ese commit, el veredicto, el razonamiento y un enlace permanente para cada uno de los 79, de modo que cualquier veredicto puede discutirse con la misma evidencia delante de ti.

Repositorios de prueba

Cada revisión de la ejecución anterior sigue viva y pública. Son pull requests reales de proyectos reales, bifurcadas con su historial, con los comentarios en línea que escribió Celmis:

Merece la pena abrir primero:

• keycloak#17 — una desreferencia nula y una cuestión de indexación de códigos de recuperación en el proveedor de almacenamiento de pruebas de Keycloak

• grafana#16 — un fallo de Storage registrado contra la métrica Legacy, una de las tres instancias del mismo error en ese archivo

• cal.diy#11 — forEach con un callback asíncrono, de modo que los borrados son de disparar y olvidar y el try circundante no captura nada

• sentry#11 — siete comentarios en línea en una PR de consumidor de Kafka

Estás leyendo la salida sin editar, incluidos los hallazgos que la auditoría anterior marca como erróneos. Nada se eliminó después de la puntuación.

Configuración

./scripts/init-env.sh escribe .env a partir de .env.example y genera todos los secretos. El ejemplo incluye cada secreto vacío a propósito: una versión anterior ponía el comando de generación junto a la variable, los archivos dotenv no admiten comentarios en línea, y toda instalación que lo copió se ejecutó con una contraseña maestra impresa en el repositorio.

La configuración llega a los contenedores solo a través del bloque environment: en docker-compose.yml — la imagen no lleva ningún .env. Una variable que no aparece ahí toma el valor predeterminado del código, diga lo que diga tu .env. GET /healthz informa de los relojes de revisión tal como el proceso realmente los resolvió, que es como compruebas lo que llegó.

Los relojes están documentados como un conjunto en .env.example, con el invariante que los une:

REVIEW_LLM_TIMEOUT_SECONDS × (1 + RETRY_FACTOR)  ≤  REVIEW_TIMEOUT_SECONDS

Operaciones

docker compose logs -f api            # follow the API
docker compose exec api analyzer graph-stats <repo>   # what parsed, what did not
./scripts/backup.sh                   # Postgres + volumes
./scripts/restore.sh <archive>

Admin → Monitoring muestra la profundidad de la cola, el gasto por espacio de trabajo y la configuración de modelos por agente. Usage & cost desglosa el gasto por superficie, de modo que una compilación de documentación por lotes no se lea como chat.

Desplegar en un servidor se hace con ./scripts/deploy-on-server.sh v0.1.0, ejecutado en el servidor: descarga las imágenes publicadas, levanta la pila detrás de Caddy y sella la compilación a la que enlaza el pie de página de AGPL. Nada fuera de esa máquina necesita una credencial para ello. Consulta docs/ORACLE_CICD.md, o docs/HETZNER.md para una VM sencilla.

Desarrollo local

# Postgres and Qdrant from compose, everything else on the host
docker compose up -d postgres qdrant

python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"

alembic upgrade head
uvicorn src.api.main:app --reload --port 8000

cd web && npm install && npm run dev     # http://localhost:3000

pytest -q                # the suite
ruff check .             # lint, ratcheted at zero
cd web && npx tsc --noEmit

Referencia de CLI

analyzer se instala con pip install -e .; dentro de Docker usa docker compose exec api analyzer …. Todos los comandos aceptan --help.

Subcomandos agrupados: analyzer repo, analyzer group, analyzer auth, analyzer mcp, analyzer scip.

Arquitectura

                      ┌──────────────┐
   GitHub / GitLab ──▶│   webhook    │──┐
   Bitbucket          └──────────────┘  │
                                        ▼
   Browser ──▶ web (Next.js) ──▶ api (FastAPI) ──▶ Postgres   jobs, policies, audit
                                     │              Qdrant     embeddings
                                     │              sandbox    untrusted execution
                                     ▼
                              model provider
                       (direct, or via a LiteLLM gateway)

• Postgres contiene trabajos, políticas, historial de ejecuciones, gasto y el registro de auditoría. La cola de trabajos duradera es una tabla: desencolar es SELECT … FOR UPDATE SKIP LOCKED, y un trabajador renueva su concesión mientras trabaja, en lugar de adivinar una duración de antemano.

• Qdrant almacena los embeddings, una colección por instalación con aislamiento de espacios de trabajo aplicado en el filtro.

• sandbox ejecuta cualquier cosa no confiable — una suite de pruebas, una compilación — como su propio uid en su propia red, sin base de datos, sin claves y con una raíz de solo lectura.

• LiteLLM es opcional. Configura LITELLM_PROXY_URL y LITELLM_MASTER_KEY juntas y cada llamada se enruta a través de la puerta de enlace; si dejas cualquiera de ellas vacía, se usan directamente las claves del proveedor.

Solución de problemas

Un contenedor no arranca. docker compose logs <service>. La API indica al inicio qué funciones opcionales no están disponibles y por qué, en lugar de fallar silenciosamente.

Las revisiones no producen nada. Comprueba GET /healthz para ver los relojes resueltos y luego docker compose logs api | grep agent_. Cada agente registra su tiempo transcurrido, su modelo y su código de error.

Un tiempo de espera agotado, no una caída. local_timeout significa que el plazo propio de esta instalación expiró antes de que el proveedor respondiera: aumenta REVIEW_LLM_TIMEOUT_SECONDS. Deliberadamente no se informa como un fallo del proveedor.

Q&A no cita nada. Probablemente el repositorio no esté indexado, o esté indexado sin embeddings. Repositories muestra el estado de cada uno; analyzer graph-stats <repo> muestra lo que se parseó.

La sandbox está siempre ocupada. SANDBOX_SLOTS indica cuántos trabajos se ejecutan a la vez y es el parámetro que consume memoria. SANDBOX_SLOT_WAIT es cuánto tiempo espera un llamante en la cola antes de que se le diga que vuelva.

Estructura del proyecto

src/
  api/          FastAPI app, routers, schemas
  review/       PR review — agents, orchestrator, providers, policies
  indexing/     parsers, symbol graph, embeddings
  qa/           retrieval and answer composition
  generation/   documentation vault
  llm/          provider clients, error taxonomy, cost ledger
  sync/         git providers, the durable job queue, workers
  sandbox/      the isolated execution server
  mcp_server/   the MCP surface
  security/     redaction, patterns, log filtering
web/            Next.js UI (App Router, 16 locales)
tests/          5200+ tests
deploy/         Caddy overlay and the LiteLLM gateway config
docs/           deploy guides and the end-to-end walk-through
bench/          benchmark harness and results

Procedencia y derechos

Este repositorio tiene un único commit raíz de unas cien mil líneas — la forma que un volcado de código de origen incierto presenta ante un escáner de procedencia, y una que necesita una explicación en lugar de un encogimiento de hombros. La tiene: PROVENANCE.md declara la postura sobre la licencia y el origen del código: el desarrollo ocurrió en privado antes de este commit, y nada de ello es necesario para compilar, auditar o bifurcar lo que hay aquí.

Ese archivo es un registro de hechos, no la licencia. La licencia es AGPL-3.0, con una excepción: todo lo que esté bajo ee/, y cualquier archivo cuyo nombre contenga .ee., está cubierto por LICENSE_EE en su lugar. ee/ no contiene código de producto hoy: el límite se trazó antes de la primera etiqueta porque añadirlo después implica volver a preguntar a cada colaborador que ya ha enviado trabajo bajo una AGPL sin salvedades.

Todo lo que se distribuye aquí es AGPL, incluidas las partes que parecen comerciales: la consola de auditoría, el uso y el gasto, las comprobaciones de cumplimiento y las métricas de instalación. Los controles de seguridad nunca son exclusivos de empresa — el log de auditoría se escribe bajo AGPL y siempre lo será. Consulta CONTRIBUTING.md para saber dónde va el código nuevo.