cie — el único grafo de código que sabe qué tareas y pruebas implementan realmente tu código.

Code Insight Engine. Ninguna otra herramienta de grafo de código evaluada puede responder "¿qué archivos implementan esta tarea y están probados?" como una sola consulta: todas son de recuperación pura. cie sí puede, porque la trazabilidad de tareas/QA vive en el mismo grafo que el código. También se extiende a lenguajes sin LSP y sin gramática de tree-sitter (probado en Nirdosha, un lenguaje creado desde cero, mediante nada más que el volcado AST del propio compilador).

Cada línea de arria es un comando real contra un clon real de psf/requests (más de 52k estrellas, no el código de este proyecto) — cie index ., y luego un cliente real de MCP por stdio llamando a callers("close") en un servidor cie-mcp --embedded en ejecución. Reproúcelo tú mismo: scripts/record_demo.sh. La metodología completa, incluido dónde esta consulta exacta sub-resuelve (3 de 6 sitios de llamada reales, una brecha real que no se oculta aquí) está en docs/benchmarks-requests.md.

Un número real, medido contra una base de código real de 36 archivos (metodología completa en docs/benchmarks.md, incluido un caso en el que no ayudó): resolver todos los llamantes reales de un nombre de función ambiguo llevó 1 llamada de herramienta de cie (callers(), correcta por construcción en todos los resultados que devuelve) frente a 3 para solo grep (1 grep

• 2 lecturas para desambiguar, aún sin garantía de corrección). No toda tarea favorece un grafo — el mismo documento informa de un empate y una pérdida real, honestamente, no solo las victorias — y re-ejecutado en un segundo repositorio público independiente (psf/requests, no el código propio de este proyecto) en docs/benchmarks-requests.md, el patrón se mantiene en una victoria real (un archivo de 1.184 líneas se reduce al 43% de su tamaño bruto) y también saca a la luz un fallo real (la misma consulta de llamante ambigüo resuelvió solo 3 de 6 sitios de llamada reales en ese repositorio) — publicado porque es cierto, no ajustado para parecer mejor.

Un segundo gancho, también medido, no afirmado: cie inclye ~121 herramientas invocables por LLM — no una superficie genérica de "ejecutar código arbitrario" de la que el modelo tenga que improvisar una solución, sino herramientas específicas (callers, file_skeleton, traceability_orphans...) que le permiten expresar la intención direcamente. La preocupación obvia es que más herramientas significa más oportunidads de elegir la equivocada — lo probé en lugar de asumirlo: un agente nuevo, con la lista real de herramientas de cie más 14 tareas seleccionadas a propósito para ser confundibles (cie tiene 5 herramientas con "coverge" en el nombre), eligió la herramienta exactamente correcta 14/14 contra la superficie completa de 81 herramientas — el mismo 14/14 que obtuvo contra un subconjunto de 14 herramientas. Una sola ejecución, advertencias reales en el documiento enlacado — pero la preocupación de "más herramientas, mäs margen para equiocarse" no se sostuvo al comprobarlo de verdad.

Pruébalo con dos comandos, sin servidor, sin registrro: indexa un proyecto en un archivo SQLite local y sírvelo a Claude Code, Cursor o cualquiera cliente MCP, con trazabilidad de tareas/QA incluida. Apúntalo a Neo4j en su lugar para una configuración real de equipo/multiproyecto (consulta Inicio rápido a continuación para ver qué incluye cada modo).

Consulta docs/competitive-landscape.md para la comparación completa contra CodeGraph, CodeGraphContext, Serena y otros, incluido dónde cie está honestamente por detrás.

Inicio rápido (configuración cero, sin Neo4j)

pip install "cie[mcp]"
cie index /path/to/your/project
cie-mcp /path/to/your/project --embedded

Eso es un servidor MCP por stdio: añádelo a Claude Code / Cursor / Codex / cualquier cliente MCP como añadirías cualquier otro servidor MCP local, y puede llamar a search_symbol, callers, callees, file_skeleton, path_between y todo lo demás en cie.tools.ToolService contra el grafo de llamadas real de tu proyecto, indexado localmente en .cie/graph.db.

--policy inspector (solo lectura) está disponible si quieres que el cliente conectado solo vea herramientas de lectura — consulta cie/tool_policy.py. El seguimiento de tareas/QA también funciona aquí, respaldado por un segundo archivo SQLite local (.cie/tasks.db, a través de cie.embedded_task_repository.EmbeddedTaskRepository) — pasa --no-task-tracking a cie-mcp si prefieres omitir su creación.

Consulta "Qué es — tres capas" a continuación para el desglose completo (extracción estructural, ~121 herramientas, la capa de tareas/QA).

Related MCP server: AtlasMemory

Instalación

pip install cie             # core: graph, tools, task/hierarchy layer over Neo4j
pip install "cie[mcp]"      # + the MCP server (cie-mcp) — what most people want
pip install "cie[http]"     # + the HTTP tool-mount / mock server (cie/routes.py)

Dependencias principales (pyproject.toml): driver de Neo4j, Pydantic v2, tree-sitter (+ gramáticas de Pythón/JS/TS/Java/Go/Rust), watchd og, Click, Rich. Requiere Pythón ≥3.10. Solo routes.py / mock_server.py incorpo ran FastAPI/uvicorn (el extra [htp]); solo mcp_server.py incorpo ra el SDK de MCP (el extra [mtp]). El motor de consultas, la extracción, los repositorios de tareas/jerarquías y el propio ToolService no tienen ninguna dependencia HTTP en absoluto.

Qué es — tres capas

• Un grafo de código genérico. Extracción estructural (símbolos, grafo de llamadas, importaciones, herecia, enlaces de pruebas) mediante LanguageAdapters conectables: incluye soporte de tree-sitter para Pythón / JavaScript / TypeScript / Java / Go / Rust listo para usar (Go/Rust: extracción de funciones+métodos, firmas y resolución de llamadas por receptor/método de implementación; la extracción de aristas de importación y los docstrings son una brecha documentada para estos dos — consulta el docstring del módulo cie/extract.py); añade tu propio adaptador para cualquier otro lenguaje (envolviendo el volcado AST del propio compilador, un servidor LSP o una gramática de tree-sitter) mediante cie.lang_adapter.register_adapter o el grupo de puntos de entrada cie.language_adapters, sin necesidad de cambiar el código de este paquete.

• ~121 herramientas invocables por LLM (cie.tools.ToolService, expuestas 1:1 como herramientas MCP y endpoints POST /tools/{tool}) — búsqueda de símbolos, recorrido del grafo de llamadas, detección de clones/comunidad/deriva, informes de calidad, inteligencia de pruebas, trazabilidad, puntuación de confianza, descomposición, APM y un sistema de archivos virtual aislado (view_file/write_file/edit_file/delete_file/write_files_atomic), todo autodescriptivo (ToolService.describe()), exponible como definiciones de herramientas JSON-Schema tipadas (cie.tool_schema) con autorización por tipo de agente (cie.tool_policy), y servible a través del Model Context Protocol real (cie.mcp_server, cie-mcp).

• Una capa de tareas / jerarquía de PRD (cie.task_repository, cie.hierarchy) para rastrear tareas atómicas de desarrollo/QA y (opcionalmente) el árbol de descomposición de PRD de un proyecto. CRUD y trazabilidad de tareas/QA (cie.task_repository.TaskRepository — push/list/status, recorrido de dependencias, validación de cobertura/ciclos/contrato de API) funciona sin configuración también, mediante cie.embedded_task_repository.EmbeddedTaskRepository (SQLite, .cie/tasks.db; pasa task_tracking=False a build_tool_service_embedded, o --no-task-tracking a cie-mcp, para el comportamiento de fallo rápido de cie.embedded_repository.NullTaskRepository en su lugar). El árbol separado de descomposición de PRD (cie.hierarchy, prd_coverage/prd_orphans/prd_traceability_chain) es solo Neo4j — esas tres herramientas llaman a cie.factory.get_hierarchy_repo directamente, independientemente de qué backend haya construido el ToolService.

Capacidades (fundamentadas en el código)

El paquete cie/ tiene ~28k líneas en ~60 módulos. La superficie de capacidades se corresponde claramente con las secciones de la especificación que el propio código documenta en los docstrings de sus módulos. Nada de lo siguiente es aspiracional: cada viñeta es un módulo real y (donde se indica) una herramienta real en ToolService / la CLI / las rutas HTTP.

Extracción y carga del grafo de código en dos pasadas (extract.py, callgraph.py, testlink.py)

• Pasada 1 (extract.py): análisis tree-sitter de cada archivo soportado en Nodes de archivo/clase/función/método con signature, line_start/ line_end, docstring, más las entradas brutas para la pasada 2 — imports y call_sites. Pura: sin efectos secundarios en BD/SF.

• Pasada 2 (callgraph.py): resuelve los sitios de llamada en aristas calls etiquetadas con confianza — EXTRACTED (definición en el mismo archivo o mapa de importación resuelto), INFERRED (heurística de tipo de receptor), o AMBIGUOUS (exactamente un símbolo con el mismo nombre en todo el proyecto). También resuelve aristas inheritance/extends y sintetiza nodos stub external:: para clases base no resueltas.

• testlink.py: una tercera pasada que emite aristas TESTS desde los símbolos de prueba a los símbolos de implementación que prueban, mediante tres heurísticas — convención de nombres (test_foo → foo), mejora de confianza cuando una coincidencia de nombres está respaldada por una arista calls real, y resolución de decoradores @patch(...)/@mock.patch(...).

Modelo de datos central (models.py, repository.py, neo4j_repository.py, in_memory_repository.py, embedded_repository.py)

• NodeKind cubre los tipos estructurales (FILE/CLASS/FUNC/METHOD/SYMBOL) y cada tipo de resultado de análisis — CloneCluster, AntiPattern, DriftFinding, MetricSnapshot, CommunitySummary, Type, Package, Document, Contract, TestSkeleton, StateMachine, State, Transition, AgentVerdict, ConfidenceReport, JustificationTrace, InvariantViolation, SemanticDiffFinding, RuntimeErrorTrace, Page, ImpliedPage, InteractiveElement, DerivedTaskHint, TestExecution, MockEndpoint, MockCall, ContractViolation, ApmMetric, PerformanceBaseline, PerformanceRegression, CoverageGap. Los nodos de análisis nunca los produce extract.py — solo los pases bajo demanda, escritos mediante replace_analysis_nodes.

• Confianza de Edge: EXTRACTED / INFERRED / AMBIGUOUS, sellada con procedencia IN-08 (extracted_at, extractor_version, source_ref).

• Tres backends de Repository tras un único Protocol: Neo4jRepository (Cypher, namespacing por proyecto, índice vectorial, timeouts de consulta/escritura/esquema), InMemoryRepository (el doble de prueba de referencia contra el que se verifican ambos backends) y EmbeddedRepository (SQLite, dos tablas, grafo completo re-persistido por llamada — simple, de un solo proyecto, local-first).

• QueryEngine (query.py): orquestación ligera e independiente del backend — búsqueda, recorrido, vecinos, comunidad, nodos dios, estadísticas, camino más corto, firmas, methods-of-class, listado de archivos, descubrimiento de características, búsqueda semántica (requiere embeddings escritos en tiempo de carga).

Backends de almacenamiento y configuración (config.py, factory.py)

• Neo4jConfig.from_env() — lee NEO4J_* (o el override legacy CIE_NEO4J_*) más timeouts por operación (CIE_NEO4J_QUERY_TIMEOUT_S, ..._WRITE_TIMEOUT_S, ..._SCHEMA_TIMEOUT_S). Los límites a nivel de driver por sí solos no detienen un cuelgue por espera de bloqueo; cie.timeouts impone presupuestos independientes de tiempo de pared alrededor de cada ida y vuelta de consulta.

• CieConfig — un objeto de arranque explícito para un llamador externo (raíz del proyecto, nombre del proyecto, configuración de Neo4j, raíz permitida, límite de tamaño de archivo, adaptadores de lenguaje). No hay un interruptor de «desactivar la jaula» — las herramientas de archivo aplican la jaula incondicionalmente (cie.tools.view._jail).

• factory.py construye ToolService de tres maneras: build_tool_service (Neo4j, motores/repos de tareas cacheados por proyecto que comparten un único driver), build_tool_service_from_config (de una sola llamada, sin variables de entorno) y build_tool_service_embedded (grafo SQLite + EmbeddedTaskRepository por defecto, NullTaskRepository opt-in mediante task_tracking=False).

Superficie de herramientas — ToolService (cie/tools/__init__.py, ~121 métodos)

Cada método devuelve el sobre estándar de SPEC §0 (ok/tool/results/ truncated/total/hint/elapsed_ms, cie.envelope); los errores llevan un hint obligatorio. Agrupados por capacidad (todos también expuestos vía MCP y POST /tools/{tool}):

Navegación principal del grafo — search_symbol, resolve_import, semantic_search, callers, callees, file_skeleton, path_between, failing_context, affected_by, class_hierarchy, test_map, actual_callers, dead_code_confirm, hybrid_search (léxico + vector denso + centralidad de grafo, con puntuaciones por componente), entity_context, view_file (con ventanas, numerado por líneas, unido con el índice de símbolos).

GraphRAG Q&A — qa (cie.graphrag): un pipeline real — query_plan.classify elige una estrategia de recuperación, hybrid_search recupera, rerank reordena según un juicio de relevancia del LLM, entity_context expande el vecindario, y una llamada final al LLM responde con citas ensambladas por separado a partir del grafo (el LLM nunca emite citas por sí mismo).

Sección 13 — Inteligencia de Código (pases de análisis bajo demanda escritos como nodos de análisis):

• Detección de clones (clone_detect.py, CI-01..05): tres señales fusionadas — Jaccard de tokens (copiar-pegar), Jaccard de forma AST (clones renombrados), coseno de embeddings (clones semánticos) → nodos CloneCluster. Herramientas: clone_detect_run, clone_clusters, clone_find.

• Análisis de rendimiento (perf_analyze.py, CI-06..08): estimación de Big-O (anidamiento de bucles + recursión) escrita en nodos FUNC/METHOD, más detección de antipatrones (consultas N+1, bucles anidados, E/S síncrona en un bucle, crecimiento sin límite). Herramientas: performance_analyze_run, performance_profile, antipattern_scan.

• Detección de deriva (drift_detect.py, CI-10..12): brechas de requisitos (file_path de tarea vs nodos FILE indexados), deriva de contratos de API (reutiliza la extracción de api_routes), deriva arquitectónica. Herramientas: drift_detect_run, drift_report, architecture_check.

• Métricas (metrics.py, CI-19..21): integra clon/deriva/deuda técnica en MetricSnapshots de solo añadidura (tendencia consultable desde el historial). Herramientas: metrics, tech_debt_report, metric_trend.

• Comunidades (community_detect.py, RQ-04/AI-03): detección por propagación de etiquetas (la ruta de escritura real detrás de Node.community — anteriormente de solo lectura sin nada que la poblara) + nodos CommunitySummary temáticos por LLM que llevan embeddings. Herramientas: community_detect_run, community_summarize_run, community_search.

• Gobernanza de calidad: accuracy_check, freshness_report, comprehensiveness_report, salience_report.

Sección 0 — Población y sincronización en tiempo real (sync.py): un modelo de dos grafos (especulativo vs canónico), una puerta de calidad GateRunner de 4 etapas, confianza por niveles, delta AST a nivel de símbolo + detección de movimientos, soft-delete al revertir, población por lotes idempotente vinculada a commits, clasificación de eventos de sincronización. Herramientas: sync_quality_gate, sync_promote, sync_revert, sync_ast_delta, sync_evict_speculative, sync_load_commit, configure_layer_rules, get_layer_rules, install_git_hook.

Sección 1 — Extensiones del modelo de datos central (data_model.py): export_rdf, related_edges, validate_property_constraints, resolución de flujo de tipos (type_flow_run/type_flow), grafo de dependencias (dependency_graph_run/dependency_graph), grafo de documentación desde markdown (doc_graph_run/doc_search).

Sección 14 — Marco de confianza (aseguramiento especificación-vs-código):

• Contratos (contracts.py, CF-01..03): contratos en forma de python_assert, vinculación best-effort por nombre al alcance del PRD, validación de tipo de dominio por nombre de parámetro, inject_assertions/strip_assertions. Herramientas: contracts_run, contracts, validate_types, inject_assertions, strip_assertions.

• Síntesis de pruebas (test_synthesis.py, CF-04/05): esqueletos generados por plantilla en seis tipos de prueba, vinculados al código mediante las mismas aristas TESTS que usa DM-14. Herramientas: test_skeletons_run, test_skeletons, test_coverage.

• Máquinas de estado (state_machine.py, CF-06/07): extracción de FSM, detección de estados muertos/inalcanzables (algoritmos de grafo reales), comprobación estructural código-vs-FSM. Herramientas: state_machine_run, state_machine, fsm_validate.

• Trazabilidad (traceability.py, CF-08/09): cobertura/huérfanos/ cadena mediante recorrido de grafo en el lado del código y en el lado de la jerarquía del PRD. Herramientas: traceability_coverage, traceability_orphans, traceability_chain, prd_traceability_coverage, prd_traceability_orphans, prd_traceability_chain.

• Diff semántico (semantic_diff.py, CF-10/11): comprobación especificación-vs-código por coincidencia de patrones (deliberadamente conservadora, alto falso-negativo por diseño). Herramienta: semantic_diff.

• Consenso multi-agente (consensus.py, CF-12/14): almacenamiento y consulta de veredictos (un bus duradero de exactamente-una-vez explícitamente no se construye aquí). Herramientas: record_verdict, agent_verdicts.

• Puntuación de confianza (confidence.py, CF-15/16): composición pura sobre señales de contrato/prueba/consenso; capas de generación/ejecución reportadas como None. Herramientas: confidence_report, justification (CF-17/18).

• Invariantes y retroalimentación de telemetría (invariants.py, CF-19..21): evaluación segura de expresiones de contrato contra una instantánea de estado + registro de violaciones; recorrido de grafo desde un nodo de código de vuelta a sus contratos/pruebas. Herramientas: check_invariant, invariant_violations, telemetry_to_spec.

Sección 15 — Motor de descomposición (decompose.py): reutiliza el walker HTML existente + el detector de elementos interactivos para descomponer páginas en nodos Page/ImpliedPage/InteractiveElement/ DerivedTaskHint. Herramientas: decompose_page, page_tree, promote_hint_to_task, element_coverage, implied_pages_run, implied_pages.

Sección 16 — Ejecución de pruebas y APM (test_orchestration.py, mocking.py, mock_server.py, apm.py): generación de planes de prueba sobre elementos interactivos / contratos / transiciones / endpoints de API / escenarios de error del PRD, ejecución de pruebas, reporte de brechas de cobertura, pruebas de rincones y recovecos, reportes de cobertura unificados; orquestación de mocks de terceros con un servidor mock FastAPI realmente ejecutable (override explícito de base-URL, no intercepción de red); ingesta de métricas APM incl. recopilación automática de tiempos de pytest --junitxml, líneas base, detección de regresiones. Herramientas: test_plan, run_tests, record_test_result, test_results, coverage_gaps, nook_and_corner_test, unified_coverage_report, mock_registry_run, mock_registry, mock_coverage, start_mock_server, stop_mock_server, mock_violations, record_apm_metric, apm_metrics, performance_baseline, performance_regressions.

Sección 17 — Inteligencia de sistema (subsystems.py): un registro estático de cada subsistema realmente construido en este codebase, con consultas de población (repo, project) -> int (invocables, no Cypher crudo, de modo que la misma prueba pasa tanto contra Neo4j como contra el doble en memoria). Herramientas: subsystem_health, subsystem_gaps, subsystem_dependency_graph, subsystem_dependency_graph_run, population_path.

Ingesta de telemetría en tiempo de ejecución (telemetry.py, CI-15..17): ingesta real de spans de OpenTelemetry sobre OTLP/HTTP con codificación JSON (recibida en POST /telemetry/otlp), distinta del APM en tiempo de prueba. La decodificación cruda de protobuf se evita deliberadamente.

Sistema de archivos virtual y sandbox (cie/tools/view.py, edit.py, runner.py, blame.py): view_file enjaulado (numerado por líneas, con un índice de símbolos unido al grafo, límite de tamaño configurable), write_file, write_files_atomic, edit_file, delete_file, run (subproceso + jaula de cwd + timeout duro — CIE_RUN_ROOT amplía la jaula), blame_history (historial de git unido con artefactos del grafo de tareas). Cada escritura mantiene el índice de símbolos heurístico en proceso incrementalmente fresco y vuelve a resolver los llamantes de archivos sin cambios.

Respaldo heurístico (cie/tools/index.py, heuristic.py): cuando una llamada al grafo falla o devuelve vacío, ToolService construye perezosamente un SymbolIndex en memoria recorriendo+parseando el árbol del proyecto, de modo que search_symbol/file_skeleton/view_file siguen funcionando contra un árbol no indexado o parcialmente indexado — el mismo camino de código que da forma a los resultados que el camino respaldado por grafo.

Capa de tareas y jerarquía de PRD (tasks.py, task_repository.py, embedded_task_repository.py, hierarchy.py)

• AtomicTask / AtomicTaskBatch (pydantic, con versión de esquema en la ingesta), con escritura de estado/intentos, artefactos, eventos de reparación, validación de ciclos de dependencias, validación de cobertura, validación de contratos de API.

• Neo4jTaskRepository (caché de entidades real write-behind, cie.graph_cache) o EmbeddedTaskRepository (SQLite, cero configuración — mismo protocolo TaskRepository, mismo código de validación plan_push, sin Neo4j) — NullTaskRepository sigue disponible como opt-out explícito.

• hierarchy.py: almacena/recorre un árbol de PRD (Module → Feature → Workflow → UseCase → UserStory → REALIZED_BY AtomicTask), Cypher sin APOC — solo Neo4j, aún no portado al backend embebido (sus tres herramientas — prd_coverage/prd_orphans/prd_traceability_chain — llaman a cie.factory.get_hierarchy_repo directamente). CLI: hierarchy:push, hierarchy:children, hierarchy:lineage.

Tres front-ends, un sobre

• MCP (cie.mcp_server / cie-mcp): verdadero Model Context Protocol sobre stdio (o sse / streamable-http), construido con el SDK oficial mcp. El JSON Schema de cada herramienta proviene de la introspección del SDK del método vinculado — una única fuente de verdad. Las herramientas denegadas por política nunca se registran, no solo se rechazan. Políticas: forge/orchestrator (lectura+escritura), miner/inspector (solo lectura).

• HTTP (cie.routes.py): router montado en la aplicación FastAPI anfitriona (no un proceso separado). POST /tools/{tool} (kwargs en el cuerpo), GET /tools, GET /health, GET /schema-version, además de POST /tasks, GET /tasks/{name}, GET /tasks/pending, POST /hierarchy, POST /telemetry/otlp, etc.

• CLI (cie.cli, 49 comandos): tablas Rich legibles por humanos por defecto; cada comando respeta --json (a nivel de grupo, antes del subcomando) emitiendo el mismo sobre SPEC §0 que la superficie HTTP, de modo que un agente puede manejar cie enteramente a través de JSON. Los comandos reflejan las herramientas anteriores (search, node, neighbors, community, communities, god, stats, search-symbol, view-file, callers, callees, skeleton, failing-context, affected-by, blame, run, reindex, watch, tasks:*, hierarchy:*, coverage:*, validate:*, schema-version, schema:dump, …).

Notas de seguridad y determinismo (del código)

• Las herramientas de archivo se encierran incondicionalmente bajo la raíz del proyecto (cie.tools.view._jail); CIE_RUN_ROOT solo puede ampliar el encierro de run. No existe la opción de "desactivar el encierro".

• Cada arista lleva procedencia (extracted_at/extractor_version/ source_ref); la confianza se sella en el momento de la escritura, nunca la inventa el extractor puro.

• Los tiempos de espera de reloj de pared por operación (cie.timeouts) acotan los cuelgues por espera de bloqueo que los propios tiempos de espera del controlador no acotan — una lección directa de un incidente real de bloqueo de esquema de Aura el 2026-08-04 documentado en cie.timeouts.

• Las citas en GraphRAG se ensamblan a partir del grafo, nunca las emite el LLM, por lo que no pueden fabricarse a mitad de generación.

Dos niveles

cie tiene dos niveles, y la división es deliberada — se dirigen a dos públicos diferentes:

Nivel de adquisición — configuración cero, integrado. Un único archivo SQLite local, sin servidor, nada que configurar (ver Quickstart). El grafo de código completo (búsqueda, recorrido, grafo de llamadas, esqueleto de archivos, el sistema de archivos virtual, el respaldo heurístico, GraphRAG Q&A) + ~121 herramientas sobre MCP/HTTP/CLI. Sin seguimiento de tareas/QA, sin capa de gobernanza de calidad (detección de clones/deriva, confianza, contratos). Este es el nivel que prueba un desarrollador en solitario o un visitante por primera vez — el gancho afilado que consigue la primera estrella.

Nivel de retención — respaldado por Neo4j. Todas las capacidades, el espacio de nombres multiproyecto, y las cosas que un equipo sigue consultando a diario (no un "wow" de una sola vez): trazabilidad de tareas/QA (qué tareas y pruebas implementan qué código), gobernanza de calidad continua, la jerarquía de PRD y tendencias de cobertura. Este es el nivel que hace que valga la pena mantener cie instalado después de la primera semana — la historia que ningún grafo de código puro tiene.

from pathlib import Path
from cie.config import CieConfig, Neo4jConfig
from cie.factory import build_tool_service_from_config

config = CieConfig(
    project_root=Path("/path/to/your/project"),
    project="my-project",
    neo4j=Neo4jConfig(uri="bolt://localhost:7687", user="neo4j", password="password"),
)
service = build_tool_service_from_config(config)

service.reindex()
print(service.search_symbol("main"))

O mediante MCP: cie-mcp /path/to/your/project (sin --embedded) — lee las variables de entorno CIE_NEO4J_*/NEO4J_*, o pasa --neo4j-uri/--neo4j-user/ --neo4j-password explícitamente.

Documentación

• Panorama competitivo — los competidores más cercanos (CodeGraphContext, CodeGraph, Serena y otros), en qué se diferencia cie y en qué está honestamente por detrás.

• Benchmarks — psf/requests — la misma metodología re-ejecutada en un repositorio público conocido que este proyecto no escribió, no un caso de prueba autorreferencial; una victoria real y una brecha real de recall, ambas reportadas.

• Precisión de selección de herramientas — ¿tener 81+ herramientas en lugar de ~14 le cuesta a un agente la precisión de selección? Medido, no afirmado: 14/14 correctas en ambas condiciones, una ejecución — la hipótesis de que la amplitud cuesta precisión no se sostuvo aquí.

• Benchmarks — mediciones reales de tamaño de llamada de herramienta/respuesta contra un código base real, publicadas honestamente (incluyendo donde no ganó).

• Benchmarks de competidores — el mismo código base real indexado y consultado con CodeGraphContext y Serena realmente instalados y ejecutados (no estimados), incluyendo un error real de resolución de nombres ambiguos que esta indagación descubrió, diagnosticó con precisión y corrigió.

• Añadir un lenguaje — un LanguageAdapter completo y verificado para un lenguaje que cie nunca ha visto, sin gramática de tree-sitter ni LSP involucrados.

Estructura del proyecto

cie/
  models.py            # NodeKind/Edge/Confidence + all result dataclasses (one source of truth)
  repository.py        # Repository Protocol
  neo4j_repository.py  # Neo4j (Cypher) backend
  in_memory_repository.py  # reference test double + embedded query/traversal logic
  embedded_repository.py   # zero-config SQLite backend
  query.py             # QueryEngine (backend-agnostic orchestration)
  extract.py           # tree-sitter extraction (Python/JS/TS/Java/Go/Rust)
  callgraph.py         # pass-2 calls/inheritance edge resolution
  testlink.py          # TESTS edge resolution
  lang_adapter.py      # pluggable language-adapter registry + entry points
  config.py factory.py # bootstrap (Neo4jConfig / CieConfig / build_tool_service*)
  tools/               # ToolService (~121 tools) + jailed fs/run/blame helpers
  mcp_server.py        # real MCP server (cie-mcp)
  routes.py            # FastAPI router (mounted into host app)
  cli.py               # 49-command CLI (Rich tables + --json envelope)
  tool_schema.py tool_policy.py  # typed JSON-Schema + per-agent authorization
  # analysis passes (on-demand, write analysis nodes):
  clone_detect.py perf_analyze.py drift_detect.py metrics.py
  community_detect.py graphrag.py query_plan.py graph_diff.py
  contracts.py test_synthesis.py state_machine.py traceability.py
  semantic_diff.py consensus.py confidence.py justification.py
  invariants.py telemetry.py decompose.py subsystems.py
  sync.py data_model.py api_routes.py source_analysis.py
  test_orchestration.py mocking.py mock_server.py apm.py
  tasks.py task_repository.py hierarchy.py   # task / PRD-hierarchy layer
  envelope.py embed.py graph_cache.py timeouts.py telemetry.py
tests/                # test_standalone_smoke / test_mcp_server / test_embedded_repository

Licencia

cie se publica bajo la Licencia MIT.

Al contribuir, aceptas que tus contribuciones se licencian bajo la misma licencia MIT — consulta CONTRIBUTING.md.