cie

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 recuperación pura. cie 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 desde cero, mediante nada más que el volcado AST del propio compilador).

Cada línea anterior es un comando real contra un clon real de psf/requests (52k+ estrellas, no el código de este proyecto) — cie index ., luego un cliente MCP stdio real llamando a callers("close") en un servidor cie-mcp --embedded en ejecución. Reprodúcelo tú mismo: scripts/record_demo.sh. Metodología completa, incluyendo dónde esta consulta exacta sub-resuelve (3 de 6 sitios de llamada reales, una brecha real no 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, incluyendo un caso donde no ayudó): resolver cada llamador real de un nombre de función ambiguo tomó 1 llamada de herramienta cie (callers(), correcta por construcción en cada resultado que devuelve) vs. 3 para solo-grep (1 grep

• 2 lecturas para desambiguar, aún sin garantía de corrección). No cada tarea favorece un grafo — el mismo documento reporta 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 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 esqueletiza al 43% de su tamaño bruto) y también revela una falla real (la misma consulta de llamador ambiguo resolvió solo 3 de 6 sitios de llamada reales en ese repositorio) — publicado porque es verdad, no ajustado para verse mejor.

Un segundo gancho, también medido, no afirmado: cie incluye ~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 específicas (callers, file_skeleton, traceability_orphans...) que le permiten expresar intención directamente. La preocupación obvia es que más herramientas significa más oportunidades de elegir la incorrecta — lo probé en lugar de asumirlo: un agente nuevo, con la lista real de herramientas de cie más 14 tareas seleccionadas a mano para ser confusas (cie tiene 5 herramientas diferentes con nombre "coverage" solo), 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 ejecución, advertencias reales en el documento vinculado — pero la preocupación de "más herramientas, más margen para equivocarse" no se sostuvo cuando se verificó realmente.

Pruébalo en dos comandos, sin servidor, sin registro — indexa un proyecto en un archivo SQLite local y sírvelo a Claude Code, Cursor, o cualquier cliente MCP, con trazabilidad de tareas/QA incluida. Apúntalo a Neo4j en su lugar para una configuración real de equipo/multiproyecto (ver Quickstart abajo para lo que hay en cada modo).

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

Quickstart (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 sobre stdio — agrégalo a Claude Code / Cursor / Codex / cualquier cliente MCP como agregarí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, vía cie.embedded_task_repository.EmbeddedTaskRepository) — pasa --no-task-tracking a cie-mcp si prefieres omitir su creación.

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

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): controlador Neo4j, Pydantic v2, tree-sitter (+ gramáticas de Python/JS/TS/Java/Go/Rust), watchdog, Click, Rich. Requiere Python ≥ 3.10. Solo routes.py / mock_server.py incorporan FastAPI/uvicorn (el extra [http]); solo mcp_server.py incorpora el SDK de MCP (el extra [mcp]). El motor de consultas, la extracción, los repositorios de tareas/jerarquía, y ToolService mismo no tienen dependencia HTTP en absoluto.

---

Qué es — tres capas

• Un grafo de código genérico. Extracción estructural (símbolos, grafo de llamadas, importaciones, herencia, enlaces de pruebas) vía LanguageAdapters conectables — incluye soporte de tree-sitter para Python / JavaScript / TypeScript / Java / Go / Rust listo para usar (Go/Rust: extracción de funciones+métodos, firmas, y resolución de llamadas receptor/impl-método; extracción de bordes de importación y docstrings es una brecha documentada para estos dos — consulta el docstring del módulo de cie/extract.py); agrega tu propio adaptador para cualquier otro lenguaje (envolviendo el volcado AST del propio compilador, un servidor LSP, o una gramática de tree-sitter) vía cie.lang_adapter.register_adapter o el grupo de puntos de entrada cie.language_adapters, sin cambio de código en este paquete requerido.
• ~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()), expuesto como definiciones de herramientas JSON-Schema tipadas (cie.tool_schema) con autorización por tipo de agente (cie.tool_policy), y servible sobre el Protocolo de Contexto de Modelo 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 dev/QA y (opcionalmente) el árbol de descomposición de PRD de un proyecto. CRUD de tareas/QA y trazabilidad (cie.task_repository.TaskRepository — push/list/estado, recorrido de dependencias, validación de cobertura/ciclo/contrato-API) funciona con configuración cero también, vía 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 construyó el ToolService.

Capacidades (fundamentadas en el código)

El paquete cie/ tiene ~28k líneas en ~60 módulos. La superficie de capacidades se mapea limpiamente a las secciones de especificación que el propio código documenta en sus docstrings de módulo. Nada abajo 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 de 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 de DB/FS.
• Pasada 2 (callgraph.py): resuelve sitios de llamada en bordes calls etiquetados con confianza — EXTRACTED (definición en el mismo archivo o resuelta por mapa de importación), INFERRED (heurística de tipo receptor), o AMBIGUOUS (exactamente un símbolo con el mismo nombre en todo el proyecto). También resuelve bordes inheritance/extends y sintetiza nodos stub external:: para clases base no resueltas.
• testlink.py: una tercera pasada que emite bordes TESTS desde símbolos de prueba a los símbolos de implementación que prueban, vía tres heurísticas — convención de nombres (test_foo → foo), mejora de confianza cuando una coincidencia de nombres está respaldada por un borde calls real, y resolución de decoradores @patch(...)/@mock.patch(...).
• Cargadores: cie load <dirs> --project <name> (Neo4j, reemplazo completo de los nodos de un proyecto) y cie index <path> (SQLite embebido, configuración cero). reindex / reindex_file para actualización incremental de un solo archivo después de un parche; watch para reindexación automática impulsada por sistema de archivos (watchdog).

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 son producidos por extract.py — solo por pasadas bajo demanda, escritas vía replace_analysis_nodes.
• Confianza Edge: EXTRACTED / INFERRED / AMBIGUOUS, sellada con procedencia IN-08 (extracted_at, extractor_version, source_ref).
• Tres backends Repository detrás de un Protocol: Neo4jRepository (Cypher, espacios de nombres por proyecto, índice vectorial, tiempos de espera de consulta/escritura/esquema), InMemoryRepository (el doble de prueba de referencia contra el que ambos backends se verifican), y EmbeddedRepository (SQLite, dos tablas, grafo completo re-persistido por llamada — simple, de un solo proyecto, local-primero).
• QueryEngine (query.py): orquestación delgada, agnóstica al backend — búsqueda, recorrido, vecinos, comunidad, nodos dios, estadísticas, camino más corto, firmas, métodos-de-clase, listado de archivos, descubrimiento de características, búsqueda semántica (requiere embeddings escritos en el momento de la carga).

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

• Neo4jConfig.from_env() — lee NEO4J_* (o la anulación heredada CIE_NEO4J_*) más tiempos de espera por operación (CIE_NEO4J_QUERY_TIMEOUT_S, ..._WRITE_TIMEOUT_S, ..._SCHEMA_TIMEOUT_S). Los límites a nivel de controlador por sí solos no detienen un cuelgue de espera de bloqueo; cie.timeouts impone presupuestos de tiempo de pared independientes 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, techo de tamaño de archivo, adaptadores de lenguaje). Sin interruptor de "deshabilitar el aislamiento" — las herramientas de archivos aíslan incondicionalmente (cie.tools.view._jail).
• factory.py construye ToolService de tres maneras: build_tool_service (Neo4j, motores/repositorios de tareas en caché por proyecto compartiendo un controlador), build_tool_service_from_config (una llamada, sin variables de entorno), y build_tool_service_embedded (grafo SQLite + EmbeddedTaskRepository por defecto, NullTaskRepository opt-in vía task_tracking=False).

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

Cada método devuelve el sobre estándar de la 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 a través de MCP y POST /tools/{tool}):

Navegación central 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 ventana, numeración de líneas, unido al í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 la vecindad, y una llamada final al LLM responde con citas ensambladas por separado del grafo (el LLM nunca emite citas por sí mismo).

Sección 13 — Inteligencia de código (pasadas de análisis bajo demanda escritas 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 anti-patrones (consultas N+1, bucles anidados, E/S síncrona en un bucle, crecimiento ilimitado). Herramientas: performance_analyze_run, performance_profile, antipattern_scan.
• Detección de deriva (drift_detect.py, CI-10..12): brechas de requisitos (task file_path 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 anexión (tendencia respondible 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 — previamente de solo lectura sin nada que la poblara) + nodos CommunitySummary temáticos por LLM con 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 de 4 etapas GateRunner, confianza en niveles, delta de AST a nivel de símbolo + detección de movimientos, soft-delete-on- revert, 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 spec-vs-código):

• Contratos (contracts.py, CF-01..03): contratos en forma python_assert, vinculación best-effort por nombre al alcance del PRD, validación de tipos de dominio de nombres de parámetros, 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 plantillas en seis tipos de prueba, vinculados al código mediante los mismos bordes 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), verificación estructural código-vs-FSM. Herramientas: state_machine_run, state_machine, fsm_validate.
• Trazabilidad (traceability.py, CF-08/09): cobertura/huérfanos/cadena por 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): verificación spec-vs-código por coincidencia de patrones (deliberadamente conservadora, alta tasa de falsos negativos por diseño). Herramienta: semantic_diff.
• Consenso multi-agente (consensus.py, CF-12/14): almacenamiento y consulta de veredictos (un bus durable exactly-once 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 hasta 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 real y ejecutable (anulación explícita de la URL base, no intercepción de red); ingesta de métricas APM incl. recolección automática de tiempos --junitxml de pytest, 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 del sistema (subsystems.py): un registro estático de cada subsistema realmente construido en este código, con consultas de población (repo, project) -> int (invocables, no Cypher crudo, para que la misma prueba pase 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 a través de OTLP/HTTP con codificación JSON (recibidos 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 (con numeración de 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 + tiempo de espera estricto — CIE_RUN_ROOT amplía la jaula), blame_history (historial de git unido a artefactos del grafo de tareas). Cada escritura mantiene el índice de símbolos heurístico en proceso incrementalmente fresco y re-resuelve los llamadores 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 y analizando el árbol del proyecto, para que search_symbol/file_skeleton/view_file sigan funcionando contra un árbol no indexado o parcialmente indexado — el mismo camino de código de modelado de 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 con escritura diferida, cie.graph_cache) o EmbeddedTaskRepository (SQLite, cero configuración — el mismo protocolo TaskRepository, el mismo código de validación plan_push, sin Neo4j) — NullTaskRepository sigue disponible como exclusión explícita.
• 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): Protocolo de Contexto de Modelo real 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, más dedicados 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 honra --json (a nivel de grupo, antes del subcomando) emitiendo el mismo sobre de la SPEC §0 que la superficie HTTP, para que un agente pueda manejar cie enteramente sobre 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 archivos se enjaulan incondicionalmente bajo la raíz del proyecto (cie.tools.view._jail); CIE_RUN_ROOT solo puede ampliar la jaula run. No existe la opción de "deshabilitar la jaula".
• Cada borde lleva procedencia (extracted_at/extractor_version/ source_ref); la confianza se sella en el momento de la escritura, nunca se inventa por el extractor puro.
• Tiempos de espera de pared por operación (cie.timeouts) limitan los cuelgues de espera de bloqueo que los propios tiempos del driver no cubren — una lección directa de un incidente real de bloqueo de esquema Aura del 2026-08-04 documentado en cie.timeouts.
• Las citas en GraphRAG se ensamblan desde el 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 — apuntan a dos audiencias diferentes: Nivel de adquisición — configuración cero, integrado. Un único archivo SQLite local, sin servidor, nada que configurar (ver Inicio rápido). El grafo de código completo (búsqueda, recorrido, grafo de llamadas, esqueleto de archivos, el sistema de archivos virtual, el respaldo heurístico, Q&A con GraphRAG) + ~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. Cada capacidad, espacios de nombres multiproyecto, y las cosas que un equipo sigue consultando todos los días (no un "wow" de una sola vez): trazabilidad de tareas/QA (qué tareas y pruebas implementan qué código), gobernanza continua de calidad, 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 — competidores más cercanos (CodeGraphContext, CodeGraph, Serena y otros), dónde cie difiere y dónde honestamente va por detrás.
• Benchmarks — psf/requests — la misma metodología reejecutada 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 precisión de selección a un agente? 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 llamadas a herramientas/tamaño de 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 investigación descubrió, diagnosticó con precisión y corrigió.
• Añadir un lenguaje — una guía completa y verificada LanguageAdapter para un lenguaje que cie nunca ha visto, sin gramática 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 — ver CONTRIBUTING.md.