cie

cie — o único grafo de código que sabe quais tarefas e testes realmente implementam seu código.

Code Insight Engine. Nenhuma outra ferramenta de grafo de código pesquisada consegue responder "quais arquivos implementam esta tarefa, e eles estão testados?" como uma única consulta — todas são puramente de recuperação. cie consegue, porque a rastreabilidade tarefa/QA vive no mesmo grafo que o código. Ele também se estende a linguagens sem LSP e sem gramática tree-sitter (comprovado em Nirdosha, uma linguagem criada do zero, usando nada além do próprio dump de AST do compilador).

Cada linha acima é um comando real contra um clone real de psf/requests (52k+ estrelas, não o código deste próprio projeto) — cie index ., depois um cliente MCP stdio real chamando callers("close") em um servidor cie-mcp --embedded em execução. Reproduza você mesmo: scripts/record_demo.sh. Metodologia completa, incluindo onde esta consulta exata sub-resolve (3 de 6 locais de chamada reais, uma lacuna real não escondida aqui) está em docs/benchmarks-requests.md.

Um número real, medido contra uma base de código real de 36 arquivos (metodologia completa em docs/benchmarks.md, incluindo um caso onde não ajudou): resolver cada chamador real de um nome de função ambíguo levou 1 chamada de ferramenta cie (callers(), correto-por- construção em todos os resultados que retorna) vs. 3 para apenas grep (1 grep

• 2 leituras para desambiguar, ainda assim sem garantia de correção). Nem toda tarefa favorece um grafo — o mesmo documento relata um empate e uma perda real, honestamente, não apenas as vitórias — e re-executado em um segundo repositório público independente (psf/requests, não o código deste próprio projeto) em docs/benchmarks-requests.md, o padrão se mantém em uma vitória real (um arquivo de 1.184 linhas é esqueletizado para 43% do seu tamanho bruto) e também revela uma falha real (a mesma consulta de chamador ambíguo resolveu apenas 3 de 6 locais de chamada reais naquele repositório) — publicado porque é verdadeiro, não ajustado para parecer melhor.

Um segundo gancho, também medido, não apenas afirmado: cie envia ~121 ferramentas chamáveis por LLM — não uma superfície genérica de "executar código arbitrário" da qual o modelo precisa improvisar uma solução alternativa, mas específicas (callers, file_skeleton, traceability_orphans...) que permitem expressar intenção diretamente. A preocupação óbvia é que mais ferramentas significa mais chances de escolher a errada — testei em vez de assumir: um agente novo, com a lista real de ferramentas do cie mais 14 tarefas escolhidas a dedo para serem confundíveis (cie tem 5 ferramentas diferentes com nome "coverage" sozinho), escolheu a ferramenta exatamente correta 14/14 contra a superfície completa de 81 ferramentas — os mesmos 14/14 que obteve contra um subconjunto de 14 ferramentas. Uma execução, ressalvas reais no documento vinculado — mas a preocupação "mais ferramentas, mais espaço para errar" não se sustentou quando realmente verificada.

Experimente em dois comandos, sem servidor, sem cadastro — indexe um projeto em um arquivo SQLite local e sirva-o para Claude Code, Cursor ou qualquer cliente MCP, com rastreabilidade de tarefa/QA incluída. Aponte-o para Neo4j para uma configuração real de equipe/multiprojeto (veja Quickstart abaixo para o que há em cada modo).

Veja docs/competitive-landscape.md para a comparação completa contra CodeGraph, CodeGraphContext, Serena e outros, incluindo onde cie está honestamente atrás.

Quickstart (zero-configuração, sem Neo4j)

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

Isso é um servidor MCP sobre stdio — adicione-o ao Claude Code / Cursor / Codex / qualquer cliente MCP da mesma forma que adicionaria qualquer outro servidor MCP local, e ele pode chamar search_symbol, callers, callees, file_skeleton, path_between e tudo mais em cie.tools.ToolService contra o grafo de chamadas real do seu projeto, indexado localmente em .cie/graph.db.

--policy inspector (somente leitura) está disponível se você quiser que o cliente conectado veja apenas ferramentas de leitura — veja cie/tool_policy.py. O rastreamento de tarefa/QA também funciona aqui, apoiado por um segundo arquivo SQLite local (.cie/tasks.db, via cie.embedded_task_repository.EmbeddedTaskRepository) — passe --no-task-tracking para cie-mcp se preferir pular sua criação.

Veja "O que é — três camadas" abaixo para o detalhamento completo (extração estrutural, ~121 ferramentas, a camada de tarefa/QA).

Instalação

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)

Dependências principais (pyproject.toml): driver Neo4j, Pydantic v2, tree-sitter (+ gramáticas Python/JS/TS/Java/Go/Rust), watchdog, Click, Rich. Requer Python ≥ 3.10. Apenas routes.py / mock_server.py trazem FastAPI/uvicorn (o extra [http]); apenas mcp_server.py traz o SDK MCP (o extra [mcp]). O mecanismo de consulta, extração, repositórios de tarefa/hierarquia e o próprio ToolService não têm dependência HTTP alguma.

---

O que é — três camadas

• Um grafo de código genérico. Extração estrutural (símbolos, grafo de chamadas, importações, herança, links de teste) via LanguageAdapters plugáveis — acompanha suporte tree-sitter para Python / JavaScript / TypeScript / Java / Go / Rust pronto para uso (Go/Rust: extração de função+método, assinaturas e resolução de chamadas de receptor/método de implementação; extração de arestas de importação e docstrings são uma lacuna documentada para estes dois — veja o docstring do módulo de cie/extract.py); adicione seu próprio adaptador para qualquer outra linguagem (envolvendo o próprio dump de AST de um compilador, um servidor LSP ou uma gramática tree-sitter) via cie.lang_adapter.register_adapter ou o grupo de ponto de entrada cie.language_adapters, sem mudança de código neste pacote necessária.
• ~121 ferramentas chamáveis por LLM (cie.tools.ToolService, expostas 1:1 como ferramentas MCP e endpoints POST /tools/{tool}) — busca de símbolos, travessia de grafo de chamadas, detecção de clone/comunidade/deriva, relatórios de qualidade, inteligência de teste, rastreabilidade, pontuação de confiança, decomposição, APM e um sistema de arquivos virtual isolado (view_file/write_file/edit_file/delete_file/write_files_atomic), todos autodescritivos (ToolService.describe()), expostos como definições de ferramentas JSON-Schema tipadas (cie.tool_schema) com autorização por tipo de agente (cie.tool_policy) e servíveis sobre o Protocolo de Contexto de Modelo real (cie.mcp_server, cie-mcp).
• Uma camada de tarefa / hierarquia de PRD (cie.task_repository, cie.hierarchy) para rastrear tarefas atômicas de dev/QA e (opcionalmente) uma árvore de decomposição de PRD do projeto. CRUD de tarefa/QA e rastreabilidade (cie.task_repository.TaskRepository — push/list/status, travessia de dependências, validação de cobertura/ciclo/contrato de API) funciona com zero configuração também, via cie.embedded_task_repository.EmbeddedTaskRepository (SQLite, .cie/tasks.db; passe task_tracking=False para build_tool_service_embedded, ou --no-task-tracking para cie-mcp, para o comportamento fail-fast de cie.embedded_repository.NullTaskRepository em vez disso). A árvore separada de decomposição de PRD (cie.hierarchy, prd_coverage/prd_orphans/prd_traceability_chain) é ainda somente Neo4j — essas três ferramentas chamam cie.factory.get_hierarchy_repo diretamente independentemente de qual backend construiu o ToolService.

Capacidades (fundamentadas no código)

O pacote cie/ tem ~28k linhas em ~60 módulos. A superfície de capacidades mapeia-se claramente nas seções de especificação que o próprio código documenta em seus docstrings de módulo. Nada abaixo é aspiracional — cada marcador é um módulo real e (onde indicado) uma ferramenta real em ToolService / na CLI / nas rotas HTTP.

Extração e carregamento de grafo de código em duas passadas (extract.py, callgraph.py, testlink.py)

• Passada 1 (extract.py): análise tree-sitter de cada arquivo suportado em Nodes de arquivo/classe/função/método com signature, line_start/ line_end, docstring, mais as entradas brutas para a passada 2 — imports e call_sites. Pura: sem efeitos colaterais de DB/FS.
• Passada 2 (callgraph.py): resolve locais de chamada em arestas calls com etiqueta de confiança — EXTRACTED (def no mesmo arquivo ou resolvido por mapa de importação), INFERRED (heurística de tipo de receptor) ou AMBIGUOUS (exatamente um símbolo com o mesmo nome em todo o projeto). Também resolve arestas inheritance/extends e sintetiza nós stub external:: para classes base não resolvidas.
• testlink.py: uma terceira passada que emite arestas TESTS de símbolos de teste para os símbolos de implementação que testam, via três heurísticas — convenção de nomenclatura (test_foo → foo), upgrade de confiança quando uma correspondência de nomenclatura é apoiada por uma aresta calls real, e resolução de decoradores @patch(...)/@mock.patch(...).
• Carregadores: cie load <dirs> --project <name> (Neo4j, substituição completa dos nós de um projeto) e cie index <path> (SQLite embutido, zero-configuração). reindex / reindex_file para atualização incremental de arquivo único após um patch; watch para reindexação automática orientada por sistema de arquivos (watchdog).

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

• NodeKind cobre os tipos estruturais (FILE/CLASS/FUNC/METHOD/SYMBOL) e todos os tipos de resultado de análise — 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. Nós de análise nunca são produzidos por extract.py — apenas por passadas sob demanda, escritos via replace_analysis_nodes.
• Confiança Edge: EXTRACTED / INFERRED / AMBIGUOUS, carimbada com proveniência IN-08 (extracted_at, extractor_version, source_ref).
• Três backends Repository atrás de um Protocol: Neo4jRepository (Cypher, namespacing por projeto, índice vetorial, timeouts de consulta/escrita/esquema), InMemoryRepository (o test double de referência contra o qual ambos os backends são verificados) e EmbeddedRepository (SQLite, duas tabelas, grafo completo re-persistido por chamada — simples, monoprojeto, local-first).
• QueryEngine (query.py): orquestração fina, agnóstica de backend — busca, travessia, vizinhos, comunidade, nós god, estatísticas, caminho mais curto, assinaturas, métodos-de-classe, listagem de arquivos, descoberta de recursos, busca semântica (requer embeddings escritos no momento do carregamento).

Backends de armazenamento e configuração (config.py, factory.py)

• Neo4jConfig.from_env() — lê NEO4J_* (ou override legado CIE_NEO4J_*) mais timeouts por operação (CIE_NEO4J_QUERY_TIMEOUT_S, ..._WRITE_TIMEOUT_S, ..._SCHEMA_TIMEOUT_S). Limites no nível do driver sozinhos não impedem um travamento por espera de lock; cie.timeouts impõe orçamentos de tempo de parede independentes em torno de cada ida e volta de consulta.
• CieConfig — um objeto de bootstrap explícito para um chamador externo (raiz do projeto, nome do projeto, configuração Neo4j, raiz permitida, teto de tamanho de arquivo, adaptadores de linguagem). Sem alternância de "desativar o jail" — as ferramentas de arquivo fazem jail incondicionalmente (cie.tools.view._jail).
• factory.py constrói ToolService de três maneiras: build_tool_service (Neo4j, engines/task-repos em cache por projeto compartilhando um driver), build_tool_service_from_config (uma chamada, sem variáveis de ambiente) e build_tool_service_embedded (grafo SQLite + EmbeddedTaskRepository por padrão, NullTaskRepository opt-in via task_tracking=False).

Superfície de ferramentas — ToolService (cie/tools/__init__.py, ~121 métodos)

Todo método retorna o envelope padrão da SPEC §0 (ok/tool/results/ truncated/total/hint/elapsed_ms, cie.envelope); erros carregam um hint obrigatório. Agrupados por capacidade (todos também expostos via MCP e POST /tools/{tool}):

Navegação central do 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 (lexical + vetor denso

• centralidade de grafo, com pontuações por componente), entity_context, view_file (em janelas, com números de linha, unido ao índice de símbolos).

GraphRAG Q&A — qa (cie.graphrag): um pipeline real — query_plan.classify escolhe uma estratégia de recuperação, hybrid_search recupera, rerank reordena por um julgamento de relevância do LLM, entity_context expande a vizinhança, e uma chamada final ao LLM responde com citações montadas separadamente a partir do grafo (o LLM nunca emite citações por conta própria).

Seção 13 — Inteligência de Código (passagens de análise sob demanda escritas como nós de análise):

• Detecção de clones (clone_detect.py, CI-01..05): três sinais fundidos — Jaccard de tokens (copiar-colar), Jaccard de forma AST (clones renomeados), cosseno de embeddings (clones semânticos) → nós CloneCluster. Ferramentas: clone_detect_run, clone_clusters, clone_find.
• Análise de desempenho (perf_analyze.py, CI-06..08): estimativa de Big-O (aninhamento de loops + recursão) gravada em nós FUNC/METHOD, além de detecção de anti-padrões (consultas N+1, loops aninhados, I/O síncrono em loop, crescimento ilimitado). Ferramentas: performance_analyze_run, performance_profile, antipattern_scan.
• Detecção de desvios (drift_detect.py, CI-10..12): lacunas de requisitos (task file_path vs nós FILE indexados), desvio de contrato de API (reutiliza extração api_routes), desvio arquitetural. Ferramentas: drift_detect_run, drift_report, architecture_check.
• Métricas (metrics.py, CI-19..21): consolida clone/desvio/dívida técnica em MetricSnapshots somente-anexação (tendência respondível a partir do histórico). Ferramentas: metrics, tech_debt_report, metric_trend.
• Comunidades (community_detect.py, RQ-04/AI-03): detecção por propagação de rótulos (o caminho real de escrita por trás de Node.community — anteriormente somente-leitura, sem nada populando-o) + nós CommunitySummary temáticos via LLM carregando embeddings. Ferramentas: community_detect_run, community_summarize_run, community_search.
• Governança de qualidade: accuracy_check, freshness_report, comprehensiveness_report, salience_report.

Seção 0 — População e Sincronização em Tempo Real (sync.py): um modelo de dois grafos (especulativo vs canônico), um portão de qualidade GateRunner em 4 estágios, confiança em camadas, delta de AST em nível de símbolo + detecção de movimentação, exclusão-suave-em- reversão, população em lote idempotente vinculada a commits, classificação de eventos de sincronização. Ferramentas: 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.

Seção 1 — Extensões do Modelo de Dados Principal (data_model.py): export_rdf, related_edges, validate_property_constraints, resolução de fluxo de tipos (type_flow_run/type_flow), grafo de dependências (dependency_graph_run/ dependency_graph), grafo de documentação a partir de markdown (doc_graph_run/ doc_search).

Seção 14 — Estrutura de Confiança (garantia spec-vs-código):

• Contratos (contracts.py, CF-01..03): contratos em formato python_assert, vinculação best-effort por nome ao escopo do PRD, validação de tipo de domínio de nomes de parâmetros, inject_assertions/strip_assertions. Ferramentas: contracts_run, contracts, validate_types, inject_assertions, strip_assertions.
• Síntese de testes (test_synthesis.py, CF-04/05): esqueletos gerados por template em seis tipos de teste, vinculados ao código via as mesmas arestas TESTS que o DM-14 usa. Ferramentas: test_skeletons_run, test_skeletons, test_coverage.
• Máquinas de estado (state_machine.py, CF-06/07): extração de FSM, detecção de estados mortos/inalcançáveis (algoritmos reais de grafo), verificação estrutural código-vs-FSM. Ferramentas: state_machine_run, state_machine, fsm_validate.
• Rastreabilidade (traceability.py, CF-08/09): cobertura/órfãos/cadeia via travessia de grafo no lado do código e no lado da hierarquia do PRD. Ferramentas: traceability_coverage, traceability_orphans, traceability_chain, prd_traceability_coverage, prd_traceability_orphans, prd_traceability_chain.
• Diff semântico (semantic_diff.py, CF-10/11): verificação spec-vs-código por correspondência de padrões (deliberadamente conservadora, alta taxa de falso-negativo por design). Ferramenta: semantic_diff.
• Consenso multi-agente (consensus.py, CF-12/14): armazenamento + consulta de veredictos (um barramento durável exactly-once é explicitamente não construído aqui). Ferramentas: record_verdict, agent_verdicts.
• Pontuação de confiança (confidence.py, CF-15/16): composição pura sobre sinais de contrato/teste/consenso; camadas de geração/execução reportadas como None. Ferramentas: confidence_report, justification (CF-17/18).
• Invariantes e retorno de telemetria (invariants.py, CF-19..21): avaliação segura de expressões de contrato contra um snapshot de estado + registro de violações; travessia de grafo de um nó de código de volta aos seus contratos/testes. Ferramentas: check_invariant, invariant_violations, telemetry_to_spec.

Seção 15 — Motor de Decomposição (decompose.py): reutiliza o walker HTML existente + detector de elementos interativos para decompor páginas em nós Page/ImpliedPage/InteractiveElement/DerivedTaskHint. Ferramentas: decompose_page, page_tree, promote_hint_to_task, element_coverage, implied_pages_run, implied_pages.

Seção 16 — Execução de Testes e APM (test_orchestration.py, mocking.py, mock_server.py, apm.py): geração de planos de teste sobre elementos interativos / contratos / transições / endpoints de API / cenários de erro do PRD, execução de testes, relatório de lacunas de cobertura, testes de cantos e frestas, relatórios unificados de cobertura; orquestração de mocks de terceiros com um servidor mock FastAPI realmente executável (override explícito de base-URL, não interceptação de rede); ingestão de métricas APM incl. coleta automática de tempo de --junitxml do pytest, baselines, detecção de regressão. Ferramentas: 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.

Seção 17 — Inteligência do Sistema (subsystems.py): um registro estático de cada subsistema realmente construído neste codebase, com consultas de população (repo, project) -> int (chamáveis, não Cypher bruto, para que o mesmo teste passe tanto contra Neo4j quanto contra o double em memória). Ferramentas: subsystem_health, subsystem_gaps, subsystem_dependency_graph, subsystem_dependency_graph_run, population_path.

Ingestão de telemetria em tempo de execução (telemetry.py, CI-15..17): ingestão real de spans OpenTelemetry via OTLP/HTTP com codificação JSON (recebidos em POST /telemetry/otlp), distinta do APM em tempo de teste. Decodificação bruta de protobuf é deliberadamente não tentada.

Sistema de arquivos virtual e sandbox (cie/tools/view.py, edit.py, runner.py, blame.py): view_file isolado (com números de linha, com um índice de símbolos unido ao grafo, teto de tamanho configurável), write_file, write_files_atomic, edit_file, delete_file, run (subprocesso + jail de cwd + timeout rígido — CIE_RUN_ROOT amplia o jail), blame_history (histórico git unido a artefatos do grafo de tarefas). Cada escrita mantém o índice heurístico de símbolos em processo incrementalmente fresco e re-resolve chamadores de arquivos inalterados.

Fallback heurístico (cie/tools/index.py, heuristic.py): quando uma chamada de grafo falha ou retorna vazio, ToolService constrói lazy um SymbolIndex em memória percorrendo+parseando a árvore do projeto, para que search_symbol/file_skeleton/view_file continuem funcionando contra uma árvore não indexada ou parcialmente indexada — mesmo caminho de código de modelagem de resultado que o caminho apoiado por grafo.

Camada de tarefas e hierarquia de PRD (tasks.py, task_repository.py, embedded_task_repository.py, hierarchy.py)

• AtomicTask / AtomicTaskBatch (pydantic, com versão de schema na ingestão), com write-back de status/tentativas, artefatos, eventos de reparo, validação de ciclos de dependência, validação de cobertura, validação de contrato de API.
• Neo4jTaskRepository (cache de entidades real com write-behind, cie.graph_cache) ou EmbeddedTaskRepository (SQLite, zero-configuração — mesmo protocolo TaskRepository, mesmo código de validação plan_push, sem Neo4j) — NullTaskRepository permanece disponível como opt-out explícito.
• hierarchy.py: armazena/percorre uma árvore de PRD (Module → Feature → Workflow → UseCase → UserStory → REALIZED_BY AtomicTask), Cypher sem APOC — somente Neo4j, ainda não portado para o backend embutido (suas três ferramentas — prd_coverage/prd_orphans/prd_traceability_chain — chamam cie.factory.get_hierarchy_repo diretamente). CLI: hierarchy:push, hierarchy:children, hierarchy:lineage.

Três front-ends, um envelope

• MCP (cie.mcp_server / cie-mcp): Model Context Protocol real via stdio (ou sse / streamable-http), construído com o SDK oficial mcp. O JSON Schema de cada ferramenta vem da introspecção do SDK do método vinculado — uma única fonte de verdade. Ferramentas negadas por política nunca são registradas, não apenas recusadas. Políticas: forge/orchestrator (leitura+escrita), miner/inspector (somente-leitura).
• HTTP (cie.routes.py): router montado no app FastAPI host (não um processo separado). POST /tools/{tool} (kwargs no corpo), GET /tools, GET /health, GET /schema-version, além de POST /tasks, GET /tasks/{name}, GET /tasks/pending, POST /hierarchy, POST /telemetry/otlp, etc. dedicados.
• CLI (cie.cli, 49 comandos): tabelas Rich legíveis por humanos por padrão; todo comando honra --json (em nível de grupo, antes do subcomando) emitindo o mesmo envelope SPEC §0 que a superfície HTTP, para que um agente possa dirigir cie inteiramente via JSON. Comandos espelham as ferramentas acima (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 segurança e determinismo (do código)

• Ferramentas de arquivo fazem jail incondicionalmente sob a raiz do projeto (cie.tools.view._jail); CIE_RUN_ROOT pode ampliar o jail run apenas. Não existe opção de "desabilitar o jail".
• Cada aresta carrega proveniência (extracted_at/extractor_version/ source_ref); confiança é carimbada no momento da escrita, nunca inventada pelo extrator puro.
• Timeouts de wall-clock por operação (cie.timeouts) limitam travamentos de espera de lock que os timeouts do driver não cobrem — uma lição direta de um incidente real de schema-lock no Aura em 2026-08-04 documentado em cie.timeouts.
• Citações no GraphRAG são montadas a partir do grafo, nunca emitidas pelo LLM, então não podem ser fabricadas no meio da geração.

Dois níveis

cie tem dois níveis, e a divisão é deliberada — eles visam dois públicos diferentes:

Camada de aquisição — zero configuração, embutida. Um único arquivo SQLite local, sem servidor, nada para configurar (veja Quickstart). O grafo de código completo (busca, travessia, grafo de chamadas, esqueleto de arquivos, o sistema de arquivos virtual, o fallback heurístico, Q&A com GraphRAG) + ~121 ferramentas via MCP/HTTP/CLI. Sem rastreamento de tarefas/QA, sem camada de governança de qualidade (detecção de clone/deriva, confiança, contratos). Esta é a camada que um dev solo ou um visitante de primeira vez experimenta — o gancho afiado que conquista a primeira estrela.

Camada de retenção — com suporte a Neo4j. Todas as capacidades, namespacing multi-projeto e as coisas que um time consulta todos os dias (não um "uau" de uma vez só): rastreabilidade de tarefas/QA (quais tarefas e testes implementam qual código), governança contínua de qualidade, a hierarquia de PRDs e tendências de cobertura. Esta é a camada que faz valer a pena manter o cie instalado após a primeira semana — a história que nenhum grafo de código puro tem.

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"))

Ou via MCP: cie-mcp /path/to/your/project (sem --embedded) — lê as variáveis de ambiente CIE_NEO4J_*/NEO4J_*, ou passe --neo4j-uri/--neo4j-user/ --neo4j-password explicitamente.

Documentação

• Panorama competitivo — concorrentes mais próximos (CodeGraphContext, CodeGraph, Serena e outros), onde o cie difere e onde está honestamente atrás.
• Benchmarks — psf/requests — a mesma metodologia reexecutada em um repositório público conhecido que este projeto não escreveu, não um caso de prova autorreferencial; uma vitória real e uma lacuna real de recall, ambas reportadas.
• Precisão na seleção de ferramentas — ter 81+ ferramentas em vez de ~14 custa precisão de seleção para um agente? Medido, não afirmado: 14/14 corretas em ambas as condições, uma execução — a hipótese de que amplitude custa precisão não se sustentou aqui.
• Benchmarks — medições reais de chamadas de ferramenta/tamanho de resposta contra uma base de código real, publicadas honestamente (incluindo onde não venceu).
• Benchmarks de concorrentes — a mesma base de código real indexada e consultada com CodeGraphContext e Serena realmente instalados e executados (não estimados), incluindo um bug real de resolução de nomes ambíguos que essa investigação descobriu, diagnosticou com precisão e corrigiu.
• Adicionando uma linguagem — um LanguageAdapter completo e verificado para uma linguagem que o cie nunca viu, sem gramática tree-sitter ou LSP envolvidos.

Estrutura do projeto

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

Licença

O cie é distribuído sob a Licença MIT.

Ao contribuir, você concorda que suas contribuições são licenciadas sob a mesma licença MIT — veja CONTRIBUTING.md.