Claude Code plugin · MCP · agent toolkit

livespec

Inteligencia de código local-first para agentes: call graph, impacto, y trazabilidad Spec ↔ código — con OpenSpec como único dialecto.

public beta · v0.31.0 9 lenguajes OpenSpec slugs group_db cross-repo sin API keys

← → · espacio · End = cierre (antes del anexo) · Shift+End = última ficha

01 · Qué es

Un producto agent-shaped

Capa universal

Code intelligence

Índice SQLite local (.mcp-docs/docs.db)
Call graph + PageRank
Impact / dead code / endpoints
Search FTS5 + grep indexado

Diferenciador

Spec ↔ código

FR / ADR / NFR bajo una taxonomía
IDs = slugs OpenSpec (auth-user-login)
sync / validate / export OpenSpec
Auditoría de cobertura

No es un IDE para humanos. Es señal que otros agentes consumen para orientarse más rápido en código ajeno.

02 · Qué responde

Las preguntas que un agente hace de verdad

Pregunta	Tool
¿Qué es este repo?	index_project → get_project_overview
¿Quién llama a X?	who_calls / quick_orient
¿Qué se rompe si cambio X?	analyze_impact / git_diff_impact
¿Qué código implementa auth-user-login?	get_spec_implementation
¿Qué Specs tocan este archivo?	analyze_impact(target_type=file)
¿Qué flujos HTTP parecen muertos?	find_legacy_flows
¿Hay dead code / tests huérfanos?	find_dead_code / find_orphan_tests

03 · Cómo funciona

Pipeline local, sin nube

walk repo→ extract (ast / tree-sitter)→ resolve edges→ SQLite + NetworkX→ MCP tools

1. Index

index_project hashea contenido, re-extrae solo lo cambiado, resuelve refs con INSERT OR IGNORE.

2. Graph

Grafo cacheado. Callers / callees / blast radius en µs tras el primer hit.

3. Specs

Árbol openspec/, anotaciones @spec:, links bulk. Explorer opcional (plugin docs).

Contrato: cada tool exige workspace=/abs/path/al/repo. Sin env fallback. Un repo por vez — o group_db compartido.

04 · Nomenclatura

Un solo dialecto: OpenSpec

Authoring

Escribir bajo openspec/specs/
### Requirement: + #### Scenario:
IDs = slugs del heading (auth-user-login)
Colisión → auth-login-2

Código ↔ Spec

Anotar @spec:auth-user-login
La spec existe en el store antes de anotar
sync_openspec / validate_openspec
Marker  fija el id ante renames

OpenSpec escribe el itinerario. livespec enciende el radar: qué código implementa cada requirement y qué se rompe si lo tocás. Sin catálogo nativo ## SPEC-NNN — hard cut en beta.

05 · Superficie

44 tools en tres tiers

~27 core

Siempre visibles: code intel, Spec agentic, OpenSpec read, search, legacy flows.

12 Spec plugin

CRUD, links, scenarios, scans, apply/archive change. Gate por Specs o LIVESPEC_PLUGINS.

5 Docs plugin

generate/list/export docs + Spec Explorer / Flow Explorer.

Lenguajes: Python, Go, Java, JS/TS, Rust, Ruby, PHP
Frameworks: Flask, FastAPI, Django, Spring, Express/Hono, Angular, Next…
Cross-repo: [workspace] group_db — hops HTTP entre servicios

06 · Cross-repo

group_db: el flujo entre servicios

Qué une

who_does_this_call → invokes_endpoints
who_calls → route_callers
find_symbol group-wide + project_root
find_legacy_flows
export_flow_explorer

Qué significa en la práctica

Un agente en el BFF puede preguntar qué SA atiende un path, o qué clientes llaman un endpoint del SA, sin abrir 10 repos a mano.

Orphans ≠ basura: casi siempre un SA que falta en el group o un cliente third-party fuera del índice.

07 · Comparativa

OpenSpec · livespec · Graphify

OpenSpec no compite: autoría. Graphify sí se solapa (grafo local + MCP). Se diferencian en la pregunta que responden.

	OpenSpec	livespec	Graphify
Qué es	SDD / authoring de requirements	Code intel + Spec↔código	Knowledge graph del repo
Pregunta	¿Qué debemos construir?	¿Qué código implementa / qué rompe?	¿Cómo está organizado y qué lo atraviesa?
Artefacto	openspec/ markdown	SQLite + call graph + Specs	graph.json + HTML / Obsidian / Neo4j
Fuerte en	Gates, proposals, changes	Spec↔código, group_db, endpoints, PR impact	Comunidades Leiden, god nodes, multimodal
LLM	No (markdown humano)	Nunca — 100% determinista	No para código; sí para docs/medios
Lenguajes	—	9 con tests de extractor	36 declarados
Cuándo	Escribir y gobernar Specs	Orientar, impact, coverage, polyrepo HTTP	Repo sin Specs, mucha doc, mapa rápido

OpenSpec ⊂ proceso livespec ⊂ grafo + Specs Graphify ⊂ mapa / multimodal Conviven: dos MCP en el mismo agente

08 · Competencia directa

livespec frente a Graphify

Overlap real

tree-sitter → call / import graph
Persistencia local (sin nube)
Postura anti-vector (“grafo > embeddings”)
Skill + MCP para agentes

Wedge de livespec

Spec ↔ código + OpenSpec interop
Polyrepo HTTP vía group_db
Endpoints framework-aware
Ops de agente: dead code, legacy flows, orphan tests

No clonamos Leiden ni multimodal: diluyen el diferenciador y pelean con el core FTS-only / zero-LLM. Ver docs/COMPETITIVE_GRAPHIFY.md.

09 · Limitaciones

Lo que livespec no es

No es tráfico real

Dead / legacy = evidencia de grafo. Confirmá con APM antes de borrar.

No es omnisciente

DI, reflection, string dispatch → falsos positivos honestos.

Índice = verdad

Sin index_project fresco, impacto y grep mienten.

FTS, no vectores

Search es keyword. Semántica profunda no es el producto.

Spring ≠ beans

find_endpoints lista mappings HTTP — no @Bean/@Service.

Dead ≠ tests

Por defecto excluye src/test / *.test.ts. Opt-in: include_tests.

Acción: usalo para orientar y anclar Specs — no como juez final de “borrá esto”.

10 · Cómo leer el barrido

Cuatro palabras, un significado

Dead

Símbolo de prod sin callers. Tests excluidos por defecto — no “basura confirmada”.

Endpoint

Ruta HTTP/CLI (o UI si pedís Angular). Spring: mappings — no @Bean/@Config.

Spec ligada

Requisito con ≥1 símbolo anclado. Si no: la Spec “flota” (escrita, no trazada).

Módulo huérfano

Módulo sin ninguna Spec. Hay grafo, no hay pregunta “qué implementa X”.

Acción: dead por defecto es prod (tests fuera). Endpoints Spring ≠ beans DI.

11 · Victoria del hard-cut

Qué salió bien · en una frase

23

Repos medidos

13 en un group_db + 10 solos. Tools read-only + re-index.

23/23

OpenSpec válido

Ningún árbol falló validate estricto tras slugs-only.

13/13

livespec self

Todas nuestras Specs ancladas. 1 dead. Así se ve el objetivo.

2→1

Hop cross-repo

2 clientes del composer llegan a 1 endpoint JPR en el grafo.

Acción: el hard-cut no rompió el radar — el gap ahora es ligar Specs, no inventar dialectos.

12 · Cross-repo en una imagen

¿Se ven llamadas entre servicios?

sm-hotel-composercliente · listByChunk*

→

HTTPhop en el grafo

→

api-search-hotel-jprgetHotelList

24 / 19

Con pareja

Servers/clients con al menos un hop indexado.

2 / 36

Sin pareja

Puede ser ruta muerta o SA faltante. Mirar APM.

Acción: el group_db sirve cuando cliente y server están indexados juntos.

13 · Arquetipo A · Composer

Specs de adorno

“El código está, las Specs también… pero casi no se tocan.”

2 / 9

Specs con código

Ej. flight-hotel, insurance, transport. ~7 Specs flotando.

32–70

Dead típico

flight-v2 llega a 70. Mucho interno sin callers.

flight-hotel flight-v2 insurance transport sm-hotel-composer 4/11

Acción: ligar o archivar Specs flotantes — hoy son ruido para el agente.

14 · Arquetipo B · SA Java

Grafo sano · Specs flojas

“Casi no hay dead… pero igual no podés preguntar qué implementa X.”

0–4

Dead (prod)

blue-ribbon 0 · availability/lleego 1 · HTX 4. Tests ya no inflan.

2–3 / 9

Specs ligadas

El hueco es trazabilidad, no basura.

blue-ribbon 0 dead · 11 eps availability 1 dead · 11 eps lleego / HTX Specs 2/9

Acción: anotar @spec: en handlers — el grafo ya está listo.

15 · Arquetipo C · Bien anclado

Así se ve el objetivo

“Casi todas las Specs tienen código. El agente puede cerrar el loop.”

8 / 10

search-manager

Mejor del group. Orquestador con Specs reales.

9 / 10

SPA results

Bien anclado; UI vía framework=angular; 222 orphan tests.

13 / 13

livespec self

Referencia: slugs + links + validate green.

15 / 15

Mensis

Specs OK; 21 dead son UI/helpers sin callers.

Acción: copiá este patrón a composers/SAs — Specs sin link no sirven al agente.

16 · Cuándo usarlo · audiencia: devs

Fit / no-fit

Usar (devs)

Cold-open de repo desconocido
Impact antes de un refactor
PR → Specs / callers
Polyrepo HTTP (group_db)
Adopción OpenSpec brownfield

No usar solo

“Borrá lo no usado” sin APM
Búsqueda semántica profunda
Debug runtime / K8s / logs
Indexar la carpeta padre multi-repo

17 · Playbook

Cómo sacarle el máximo

Un dialecto OpenSpec
Slugs bajo openspec/.
Anclar Spec → código
@spec:auth-user-login (la spec existe antes).
Impact en el PR
analyze_impact / git_diff_impact.
Coverage de gate
audit_coverage — Specs sin código y viceversa.

# cold open
index_project(workspace=REPO)
get_project_overview(workspace=REPO)
sync_openspec(workspace=REPO)
get_spec_implementation(
  workspace=REPO,
  spec_id="auth-user-login")

18 · Cierre

Una frase

OpenSpec define el viaje. livespec muestra el radar: conexiones, impacto y cobertura Spec ↔ código — sin inventar tráfico.

Qué

Call graph + Spec↔código local

Vs Graphify

Ellos mapean; nosotros anclamos Specs y polyrepo

Límite

Grafo ≠ prod · índice fresco

github.com/Rixmerz/livespec · PyPI livespec · v0.31.0
Comparativa Graphify: docs/COMPETITIVE_GRAPHIFY.md

Anexo

Detalle por repo del group_db

Las 13 fichas siguientes son opcionales. El talk termina en la diapo 18.

Tip: End / flechas — saltá si el público ya entendió los arquetipos.

Anexo A1/13 · detalle

api-composer-flight-hotel

Composer Node · 114 símbolos · 51 archivos

32

Candidatos a dead

Funciones sin callers en el grafo (de 114). Revisar; no borrar a ciegas.

5

Endpoints HTTP

Rutas detectadas. Universo distinto al dead (no son el mismo conteo).

2 / 9

Specs con código

9 Specs en store; solo 2 ligadas. 7 Specs sin implementación.

35

Módulos sin Spec

Módulos huérfanos: sin ninguna Spec anclada.

Anexo A2/13 · detalle

api-composer-flight-v2

Composer Node · 314 símbolos · 105 archivos

70

Candidatos a dead

Alto: ~22% de los símbolos sin callers en el grafo.

9

Endpoints HTTP

Pocas rutas vs mucho código interno sin uso aparente.

3 / 10

Specs con código

10 Specs; 3 ligadas; 7 sin impl. Specs “flotan”.

56

Módulos sin Spec

Más módulos huérfanos que Specs ligadas.

Anexo A3/13 · detalle

api-composer-insurance

Composer Node · 66 símbolos · repo chico

17

Candidatos a dead

~¼ del grafo sin callers.

5

Endpoints HTTP

Superficie HTTP chica y clara.

2 / 9

Specs con código

Mismo patrón composers: Specs existen, casi no anclan.

14

Módulos sin Spec

14 módulos sin trazabilidad Spec.

Anexo A4/13 · detalle

api-composer-transport

Composer Node · 62 símbolos · grafo fino (23 edges)

15

Candidatos a dead

Poco grafo → muchos símbolos parecen aislados.

3

Endpoints HTTP

Solo 3 rutas indexadas.

2 / 9

Specs con código

7 Specs sin implementación.

22

Módulos sin Spec

Más huérfanos que símbolos totales casi.

Anexo A5/13 · detalle

api-sa-availability-jpr

SA Java · 213 símbolos · 198 edges

1

Candidatos a dead

Casi limpio: el grafo conecta casi todo.

11

Endpoints HTTP

Mappings Spring (sin beans DI).

3 / 9

Specs con código

Código vivo; Specs aún flojas (6 sin impl).

6

Módulos sin Spec

Pocos huérfanos — mejor que composers.

Anexo A6/13 · detalle

api-sa-blue-ribbon-bags-insurance

SA Java · 707 símbolos · 1135 edges

0

Candidatos a dead

Ningún símbolo sin callers. Grafo denso y sano.

11

Endpoints HTTP

Mappings HTTP; beans DI fuera del listado.

2 / 9

Specs con código

Código OK, trazabilidad Spec no: 7 sin impl.

16

Módulos sin Spec

Hueco = Specs, no dead code.

Anexo A7/13 · detalle

api-sa-flight-search-lleego

SA Java · 611 símbolos · 766 edges

1

Candidatos a dead

Prod casi limpio (tests ya no cuentan como dead).

7

Endpoints HTTP

Mappings Spring reales.

2 / 9

Specs con código

7 Specs sin código. Specs flotando pese a API viva.

7

Tests huérfanos

Archivos/tests sin símbolo de producción claro.

Anexo A8/13 · detalle

api-search-hotel-jpr

Server del join cross-repo · 989 símbolos

6

Candidatos a dead

De 989 símbolos; tests fuera. Revisar Redis/logs/helpers.

12

Endpoints HTTP

Incluye getHotelList — target del hop desde SM.

3 / 9

Specs con código

6 Specs sin impl. Server clave, Specs flojas.

27

Módulos sin Spec

Hueco de trazabilidad en el server del grupo.

Anexo A9/13 · detalle

api-search-manager

Orquestador · 104 símbolos · mejor Spec link del grupo

16

Candidatos a dead

Dead moderado en un repo chico.

4

Endpoints HTTP

Pocas rutas; rol = orquestar, no exponer API ancha.

8 / 10

Specs con código

Así se ve bien: casi todas las Specs anclan código.

32

Módulos sin Spec

Aún hay módulos huérfanos; Specs sí están ligadas.

Anexo A10/13 · detalle

hsd-api

339 símbolos · ¿por qué dead (61) > endpoints (60)?

61

Candidatos a dead

Símbolos sin callers entre los 339. Helpers, utils, métodos internos.

60

Endpoints HTTP

Rutas. No es un subconjunto del dead: un endpoint puede tener callers y un helper no.

2 / 9

Specs con código

7 Specs sin impl. API ancha, Specs flojas.

23

Módulos sin Spec

Dead y Specs sin código conviven — dos problemas distintos.

Anexo A11/13 · detalle

results (SPA)

Front · 2330 símbolos · 6047 edges

44

Candidatos a dead

Poco % del total; el ruido fuerte es otra métrica.

143

Entry points UI

framework=angular. Default HTTP ≈ 0–1.

9 / 10

Specs con código

Casi todas ligadas — buen ancla Spec↔código.

222

Tests huérfanos

El hallazgo dominante: tests sin símbolo de prod claro.

Anexo A12/13 · detalle

sa-holiday-taxis

SA Java · 1233 símbolos · Specs flojas, dead bajo

4

Candidatos a dead

Prod; tests excluidos por defecto.

13

Endpoints HTTP

Mappings Spring (sin @Bean/@Config).

2 / 9

Specs con código

7 Specs sin impl.

17

Tests huérfanos

También hay tests sin ancla clara.

Anexo A13/13 · detalle

sm-hotel-composer

Home del smoke cross-repo · 234 símbolos

46

Candidatos a dead

~20% del repo sin callers en grafo.

7

Endpoints HTTP

Pocas rutas; desde acá sale el hop a JPR.

4 / 11

Specs con código

7 sin impl (incluye probe de audit). Specs flojas.

2

Clientes → JPR

listByChunk* llaman getHotelList en api-search-hotel-jpr.