Agentic Activity Dashboard

Dashboard local que grafica tu actividad con Claude Code por proyecto: cuánto consumes del plan, en qué modelos, con qué skills y subagentes, y cuándo trabajan tus agentes.

Lee los transcripts que Claude Code ya escribe en ~/.claude/projects/**/*.jsonl. Nada sale de tu máquina: no hay servicios externos, no hay API keys, no hay build.

Correrlo (30 segundos)

Para tu equipo — sin clonar nada:

npx @timekast/agentic-dashboard --open

Hasta que el paquete exista en npm (falta el primer publish del owner de la org; ver Publicar una versión), la vía que funciona para el equipo es la del repo, con acceso por ssh a GitHub. Clona en cada corrida y da lo último de main:

npx github:TimeKast/agentic-dashboard --open

Desde un checkout:

node cli.js --open   # o: node server.js

Dentro de la carpeta del repo no uses npx @timekast/agentic-dashboard: npx ve que el directorio actual es ese paquete, usa la copia local y busca el ejecutable en ./node_modules/.bin, que no existe → sh: agentic-dashboard: command not found. Ahí va node cli.js; npx es para cualquier otra carpeta.

El navegador se abre solo cuando lo arrancas desde una terminal (http://localhost:4571). Si prefieres que no, --no-open o AGENTIC_NO_OPEN=1. Ya está — no hay npm install porque no hay dependencias.

Si ya está corriendo y solo quieres verlo, esto lo abre (y lo levanta si hace falta):

agentic-dashboard open

Requisitos: Node ≥ 18 y haber usado Claude Code en esta máquina. El primer escaneo tarda ~2.5 s con 436 transcripts y ~30 s con 3 100; los siguientes ~80 ms gracias al cache incremental. La página se re-escanea sola cada vez que le das foco.

El paquete se distribuye por npm bajo la org (requiere el primer publish a mano del owner; ver Publicar una versión), así que npm sirve un tarball ya armado y cacheado en vez de clonar el repo en cada corrida — arranca más rápido y no necesitas acceso al repo para usarlo. Como tiene versión de verdad, puedes fijarla o regresarte:

npx @timekast/[email protected]     # una versión exacta
npx @timekast/agentic-dashboard@latest    # la última publicada

npx github:TimeKast/agentic-dashboard sigue funcionando (es el mismo repo) pero ya no es la vía recomendada: clona en cada corrida y siempre te da lo último de main.

Cada quien ve su propia data: se leen los transcripts de tu ~/.claude/projects. No hay nada que configurar y no hay cuenta que crear.

--port <n>       otro puerto (o PORT=n)
--export <dev>   escribe tu resumen de equipo y sale
--no-open        no abrir el navegador (abrirlo es el default desde una terminal)
open             ábrelo en el navegador; lo levanta si no está corriendo
doctor           revisa que todo esté bien (Node, transcripts, cache, puerto, versión)
update           trae la última versión (git pull en checkout; limpia el cache de npx)
service …        córrelo en segundo plano (macOS/launchd) — ver más abajo
shortcut …       crea el acceso directo en ~/Applications
--help

El estado (cache) vive en ~/.agentic-dashboard/, no junto al código — se puede mover con AGENTIC_HOME. Los transcripts se leen de ~/.claude/projects; AGENTIC_PROJECTS_DIR los redirige (datos de demostración, pruebas).

Si usas la Browser pane de Claude Code, ya hay un launch.json en el workspace padre: arranca la config agentic-dashboard.

Correrlo como servicio (macOS) — sin terminal abierta

El dashboard tiene que correr en tu máquina (lee tus transcripts y lanza claude/codex con tu sesión), pero no necesita una terminal de desarrollo levantada. Con service queda como LaunchAgent de launchd: arranca al iniciar sesión, launchd lo relevanta si muere, y tú solo abres la URL. En reposo no cuesta nada (sin timers ni polling).

npm i -g @timekast/agentic-dashboard        # ruta estable (desde npx se borra al limpiar cache)
agentic-dashboard service install           # o --port 8080
agentic-dashboard service status            # ¿corre? ¿en qué puerto? ¿dónde está el log?
agentic-dashboard service restart           # tras un update, para cargar el código nuevo
agentic-dashboard service uninstall

service install deja además un acceso directo: la app Agentic Dashboard en ~/Applications, con su icono, que aparece en Launchpad y Spotlight (⌘+espacio). Abrirla abre el dashboard en el navegador y, si no está corriendo, lo levanta primero. Para tenerlo en el Dock: ábrela una vez, clic derecho en su icono → Opciones → Mantener en el Dock. Se puede instalar suelto con agentic-dashboard shortcut install (y quitar con uninstall).

El plist queda en ~/Library/LaunchAgents/mx.timekast.agentic-dashboard.plist y captura el PATH de tu shell, para que el runner de pruebas encuentre claude y codex (launchd arranca con un PATH mínimo). El log va a ~/.agentic-dashboard/service.log. update reinicia el servicio solo si está instalado. Desde un checkout de git también funciona: apunta al cli.js del repo, así que git pull + service restart basta.

Las caras

| Ruta | Qué es | |---|---| | / · /terminal | Informe — 3 esquemas (RESUMEN/DEV/PRO), tema claro/oscuro, hallazgos con handoff, equipo, todas las sesiones con filtros | | /benchmark | Benchmark v2 — agentes ejecutando, verificados por máquina, comparados por configuración |

/classic (el dashboard anterior) se retiró: lo único que tenía y el Informe no —la matriz proyecto × persona y el "vs periodo previo"— vive ahora en el Informe. La URL redirige a /.

Qué muestra — la cara Informe

El Informe es un espejo de cómo trabaja cada quien con el agente: cuánto, cuándo, con qué (skills, commands, subagentes, Plan Mode), qué falló, qué mejorar y qué se puede automatizar. La cuota y el costo acompañan, no mandan. Secciones, en orden (v2.2, tras un council de 3 lentes: ojo de diseño, un dev del equipo y producto):

| # | Sección | Pregunta que responde | |---|---|---| | 01 | Ahora | ¿Cuánta cuota me queda? Ventana de 5 h y semana, con hora de reinicio y edad de la lectura. El titular resume cómo trabajaste en el rango. | | 02 | Cómo trabajaste | ¿Cómo trabajo? Ritmo (horas activas, sesiones, prompts por sesión, turnos por prompt, Plan Mode, fluidas, código), con qué (skills que se cargaron, slash commands, subagentes, herramientas), cuándo (hora × día) y qué automatizar: peticiones que repites (candidatas a command o skill) y comandos que el agente corre en cada sesión (candidatos a hook, script o CI). | | 03 | Qué mejorar | ¿Qué falló y qué cambio? Señales fuera de rango con su consejo, señales en rango colapsadas a una línea, y los hallazgos con handoff (incluidos los automatizables) en todos los esquemas. | | 04 | Hoy | ¿En qué se me fue hoy? Tokens por hora y por modelo, reparto por modelo y por proyecto, sesiones del día de la que más cuota se llevó a la que menos, cuánto subió la semana hoy y el botón Cerrar el día. | | 05 | Proyectos | ¿Cuánto trabajo se llevó cada proyecto? Horas, tokens y sesiones por proyecto; después, la parte de la suscripción (≈ MX$) y el $ API-equivalente, con la comparación API vs suscripción prorrateada al rango (por default Max 20×, US$200/mes, editable en PRO; en ALL se prorratea a los días que cubre el histórico local). Un modelo sin fila en PRICING aparece como chip ⚠ sin precio. | | 06 | Sesiones | ¿Qué hice y cómo? Las 10 más recientes del rango: primer prompt, veredicto, modelo dominante (+N subagentes), duración y cuota. Ver todas · filtros abre el histórico completo en un panel con filtros por rango, quién (tuyas / de máquina / todas), veredicto, modelo, proyecto y texto, en páginas de 50, y dice cuántos días cubre el histórico local (Claude Code borra transcripts de más de ~30 días). La ficha trae skills, commands, subagentes, Plan Mode y la línea de tiempo de la sesión (prompts, herramientas, commands, frenadas y errores, paso a paso). | | 07 | Equipo | ¿Cómo trabaja cada quien? Aparece cuando hay dos o más exports en team/: por persona, horas, fluidas, prompts por sesión, Plan Mode (con frenadas y permisos negados), subagentes, su cuota (puntos de semana de su propia bitácora, no tu tarifa), su Salud y su Fricción de flujo (las mismas señales y umbrales que las tuyas, sobre sus sesiones), reparto por modelo, skills, commands, proyectos, la causa que más se repite y su última nota; debajo, la matriz quién trabaja en qué (horas por proyecto y persona). Es para aprender y para capacidad, no un ranking. | | 08 | Bitácora | ¿Cómo voy contra días anteriores? Los días cerrados, acumulados: cuánto subió la semana, sesiones, modelo, causa y nota, con el resumen esta semana vs la pasada. |

El selector de esquema dosifica lo demás: DEV agrega consumo por día (por hora en el rango HOY), veredictos, tokens/cache, código y herramientas; PRO agrega totales, skills, subagentes, higiene y las vistas exploratorias (treemap, radar). Tema claro/oscuro; esquema, rango y tema persisten.

Piezas clave, en cualquier esquema:

• El mapa está en el header: la tesis del producto en una frase y la lista numerada de secciones (// 01 AHORA … // 06 BITÁCORA), que también son los kickers de cada bloque.

• Todo lo que termina en › abre su ficha en el panel lateral: definición, fórmula, dónde se concentra y a qué está conectado. Es la única convención de clic; funciona con teclado (Tab, Enter, Esc). De una señal de salud llegas a la ficha del proyecto que la dispara y de ahí a la sesión concreta con su mini-waterfall.

• Qué automatizar sale de dos señales nuevas del escaneo: el inicio normalizado de cada petición humana (${B}promptStarts${B}, 4 palabras) y la forma de cada comando que corre el agente (${B}bashCmds${B}: ${B}pnpm test${B}, ${B}git status${B}…, sin inspección de archivos ni intérpretes sueltos). Tres peticiones iguales o un comando repetido en cada sesión generan un hallazgo con la petición lista para pedirle a Claude el command, el skill o el hook.

• Rango HOY además de 7D / 30D / 90D / ALL: todo el informe se filtra al día en curso y la gráfica de consumo pasa a ser por hora.

• Estados honestos: con menos de 3 sesiones las señales de salud dicen "sin veredicto" en vez de 100%; con pocos datos las gráficas dicen que faltan datos en vez de dibujar un pico.

• Salud accionable: cada señal fuera de rango trae 1-2 líneas de qué hacer, con tus datos ("tu fricción se concentra en X (7 sesiones): ábrelas y busca el patrón").

• La unidad es tu cuota, no los pesos. Todo lo que consumió algo (un día, una sesión, un modelo, un proyecto) se muestra en puntos de tu semana: la subida real entre dos lecturas de cuota del mismo día, repartida a prorrata del peso de cada consumo. Si el día no tuvo dos lecturas, se muestra el porcentaje del consumo del día. El ≈ MX$ acompaña como dato secundario para cuando quieras saber cuánto costó.

• ≈ Plan MX$ — tu parte del plan: el precio mensual (editable en PRO, igual que el tipo de cambio) se reparte según el peso de cada consumo, y el peso pondera por modelo y por cache como hace la cuota real (un token de Fable pesa más que uno de Sonnet; uno leído de cache casi nada). El proxy del peso son los precios de API — Anthropic no publica el factor exacto. Antes se repartía por tokens crudos, y eso no podía explicar un consumo de Fable. El COST $ API-equivalente sigue ahí como comparador, en su toggle (DEV/PRO).

• Subagentes en su sesión: los transcripts anidados (<sesión>/subagents/*.jsonl) suman su costo y su reparto por modelo a la sesión que los lanzó. Una sesión de 40 minutos con cinco subagentes en Fable ya no aparece barata.

• Hallazgos y handoff (PRO): el informe genera hallazgos desde tus transcripts — fricción concentrada, errores de API, sesiones que no producen cambios, skills muertos, loops y skills de la factory instalados y sin usar, interrupciones sin Plan Mode, subagentes en foreground — cada uno con evidencia, hipótesis marcada como tal, pasos y criterio de cierre. Los seleccionas y los copias en el formato que sirva: PROMPT (se pega en Claude Code), CLAUDE.MD (reglas para el repo) o ISSUES (para el backlog).

• Límite semanal real: el porcentaje de tu cuota de 7 días (y de la ventana de 5 h) sale del rate_limit_event que Claude Code recibe con cada respuesta de la API, el mismo número que muestra /usage. El dashboard lo lee con una llamada mínima a haiku desde ~/.agentic-dashboard/probe (excluida del informe) — cuesta ~$0.05, no fracciones de centavo, porque claude -p carga tu configuración global aunque el prompt sea una palabra — y lo cachea 60 minutos en ~/.agentic-dashboard/quota.json; en el panel hay Actualizar ahora. Antes se estimaba por horas activas contra una referencia publicada, y quedaba muy por debajo de la realidad (8% estimado contra 52% real en una máquina con muchas sesiones en paralelo): las horas cuentan una sola vez las sesiones simultáneas y la cuota cobra tokens. Si claude no está en el PATH, se muestra la estimación por horas y se dice que es estimación.

Todo respeta el selector de rango (HOY / 7D / 30D / 90D / ALL) excepto la cuota (siempre la ventana en curso, la que define Anthropic), la sección Hoy (siempre el día de hoy), la bitácora (todo lo cerrado) y la higiene de skills (siempre todo el histórico — un skill que usaste hace tres meses no es "sin usar").

Hoy, cerrar el día y la bitácora

La cuota real solo se puede leer como foto (utilización de 5 h y 7 días en el momento de la lectura). Desde v2.2 cada lectura se guarda en ~/.agentic-dashboard/journal/quota-log.jsonl, y con eso el informe puede decir cuánto subió tu semana hoy: suma las subidas entre lecturas consecutivas del mismo día. Si la lectura anterior es de otro día (la noche, el fin de semana), esa subida ocurrió fuera de lo observado: se muestra aparte ("además subió +N pts desde la lectura anterior") y no se reparte entre las sesiones de hoy. Una bajada es un reinicio de ventana: lo consumido desde el reinicio es la lectura nueva entera. Solo hay lecturas cuando el dashboard estuvo abierto: se lee al abrir, con Actualizar ahora, y una vez por hora mientras el informe esté abierto (cada /api/stats guarda una lectura si la anterior tiene más de 60 min). Sigue siendo una aproximación, y la pantalla dice con cuántas lecturas se calculó. El reparto por sesión, proyecto y modelo es una estimación por precio de API, no cuota medida por sesión.

Cerrar el día congela los números del día en journal/days/YYYY-MM-DD.json: cuota (delta de la semana y máximo de la ventana de 5 h), tokens y costo por proyecto y por modelo, sesiones con sus veredictos y la más cara, tiempo activo, más una causa (subagentes caros, sesión larga, loop de errores, refactor grande, investigación, día normal, otro) y una nota libre. Los días pasados se cierran solos con la primera lectura del informe del día siguiente; cerrar el día en curso deja un cierre parcial que se completa solo a medianoche conservando causa y nota. Nada es obligatorio: sin nota, la bitácora igual sirve. La bitácora es esa lista acumulada, con la causa que más se repite; cada día abre su ficha y desde ahí se edita la nota.

Endpoints: GET /api/journal (delta de hoy + días cerrados) y POST /api/journal ({day, note, cause}).

Benchmark v2 — /benchmark

Responde una pregunta distinta a la de la versión anterior: no qué modelo escribe mejor una respuesta, sino qué configuración hace el trabajo, con cuánta intervención tuya.

Tu primera prueba. Mientras no hay intentos, RESULTADOS abre con una guía de 5 pasos: qué es (y que se descuenta de tu misma ventana de 5 h, con el % actual), el caso sugerido (B2: tres cuartas partes del peso las verifica una máquina, el resto un juez) con su costo estimado antes de correr, el botón para correrlo con tu configuración y otro para correrlo con Sonnet, y la jerga en una línea cada una (harness, verificador, juez, rúbrica congelada, esfuerzo, confirmar). El Informe manda aquí desde la ficha de cualquier sesión y desde el hallazgo "X concentra tu cuota" (/benchmark?desde=informe&modelo=Fable), que prellena la configuración Sonnet para la comparación.

La diferencia es que aquí el agente ejecuta: trabaja en un repositorio de prueba, y una máquina comprueba los hechos antes de que opine nadie. Un modelo ya no puede aprobar describiendo bien un arreglo que nunca funcionó.

Cómo se decide un criterio. Cada criterio de rúbrica declara quién lo decide:

| Quién | Cómo | Ejemplo | |---|---|---| | La máquina | Verificadores deterministas | El test que escribió falla con el código original y pasa con su arreglo (redGreen); los tests ocultos que nunca vio pasan; el JSON cumple el esquema y el grafo no tiene ciclos | | El juez | Dos juicios independientes que deben coincidir | Si la causa raíz está bien argumentada, si el cambio fue quirúrgico | | Tú | Confirmas o corriges antes de que cuente | Nada entra al marcador sin tu confirmación |

Hoy la mitad del peso de las rúbricas lo decide una máquina. Un criterio con verificador no puede darse por bueno por opinión del juez, y si el verificador no pudo correr, el criterio no se da por cumplido: la evaluación queda incompleta (no se llama al juez, no se puntúa y no se puede confirmar hasta arreglar el verificador y recalificar). Si toda la rúbrica la decide la máquina, no se llama a ningún juez. Y tu confirmación no sobreescribe un hecho de máquina: un crítico que el verificador dio por fallado sigue fallado aunque lo marques; lo que marcaste queda registrado aparte (humanAccepted, machineHeld) y nunca entra a la tasa de éxito verificado.

Criterios críticos. Autorización, seguridad y evidencia inventada bloquean la aprobación aunque el puntaje alcance. Antes se podía perder el RBAC completo y aprobar con 85.

Cada intento es reproducible. Guarda un manifiesto inmutable: caso y versión con su hash (que incluye los verificadores completos y el contenido de la semilla y del material), prompt, rúbrica, trampas y verificadores congelados (recalificar usa esos, no los del catálogo actual; el juez también recibe la rúbrica congelada), modelo pedido y modelo confirmado, harness (su versión va como metadato, no parte la identidad), esfuerzo, skills por contenido (se copian a .claude/skills del workspace y se hashean sus archivos; una que no exista impide el lanzamiento), instrucciones (van al CLAUDE.md / AGENTS.md / GEMINI.md del workspace), herramientas, permisos, presupuesto y timeout, más lo que de verdad se aplicó (applied), artefactos, log, los cambios respecto de la semilla (diff.md, que el juez lee para opinar sobre alcance y cirugía), verificación y evaluación. La unidad de comparación es modelo + configuración, no el modelo suelto: dos corridas con distinto esfuerzo o distintas skills no son comparables. Lo que un harness no puede aplicar (network: off, presupuesto en Codex, skills en Gemini/Grok) se rechaza antes de lanzar.

Campañas. Eliges casos, configuraciones, repeticiones y presupuesto. Antes de arrancar ves cuántas ejecuciones y evaluaciones habrá y cuánto se estima que cuesten. La cola alterna el orden de las configuraciones entre repeticiones, sobrevive a un reinicio y se reanuda sin repetir lo hecho. El presupuesto actúa de dos formas: antes de cada intento (no se lanza si lo gastado más el siguiente intento con sus dos jueces rebasa el tope) y dentro de cada intento (Claude Code recibe --max-budget-usd con lo que queda). Si un intento termina sin reportar costo, la campaña se pausa: sin ese dato no hay forma de vigilar nada. Para harnesses sin tope por intento ni reporte de costo el presupuesto es orientativo, y el plan lo dice.

Recomendación honesta. Solo se comparan configuraciones sobre los casos comunes con la misma versión del examen (id + hash); cada configuración necesita 3 corridas confirmadas en cada caso común; costo o minutos sin registrar no son cero, son incertidumbre (y con incertidumbre en las dos primeras no hay ganador); los fallos operativos entran a la tasa (reliableSuccess): un harness que revienta la mitad de las veces no gana por lo que sí terminó.

Los doce casos. Los cinco de la Factory (descubrimiento, diseño, backlog, implementación, QA/release), cinco de comportamiento (autonomía y cierre, preservar tu trabajo, corrección a mitad de tarea, recuperación ante fallos, y honestidad y límites) y los tres lotes de /implement que forman el primer benchmark real de la Factory: B2 (corrección pequeña sin tocar trabajo ajeno), I2 (feature convencional siguiendo el contrato del kit: errores tipados, códigos con nombre, validación y paginación compartidas) e I3 (cambio entre módulos manteniendo el contrato público, la compatibilidad hacia atrás y un consumidor lejano que es fácil olvidar). En I2 e I3 el 80 % del peso lo decide la máquina; cada lote trae en material/solucion/ la solución de referencia con la que sus tests ocultos pasan, y npm test comprueba que con la semilla fallan y con la solución pasan. Agregar un caso requiere su material y sus verificadores; no se toca el runner.

El piloto. La pregunta concreta es si Sonnet 5 puede hacer el /implement rutinario por menos cuota sin subir fallos ni tu trabajo. La campaña Piloto /implement · Sonnet 5 vs Opus 5.5 (B2, I2, I3 × las dos configuraciones × 1 repetición, orden alternado por caso, tope US$30) queda creada en CAMPAÑAS sin lanzar; arrancarla gasta cuota. Seis corridas validan el circuito, no declaran un ganador (hacen falta 3 confirmadas por celda): se repiten solo las comparaciones inconclusas. Lo que salga se consume en el Informe: el hallazgo "X concentra tu cuota" trae la línea del benchmark para implementar (/api/bench/recommendation) y su ficha abre el Benchmark con el modelo prellenado.

Lo que ves al final. Por configuración: éxito verificado, fallos críticos, intervención humana (los minutos los capturas tú, no se inventan del transcript), duración del agente, consumo con el costo del juez aparte, consistencia entre repeticiones y cobertura. La recomendación es por tarea, y dice sin comparación, evidencia insuficiente o sin ganador claro cuando la evidencia no alcanza.

Qué sale de tu máquina. El análisis del informe es local. Ejecutar agentes, leer tu cuota y usar el juez son llamadas a proveedores, con el material del caso. Cada intento corre en una carpeta desechable (bench/work/<id>), en otro árbol que el material del evaluador (bench/attempts/<id>/material), con las credenciales de tus proyectos quitadas del entorno por patrón (API_KEY, TOKEN, SECRET, PRIVATE_KEY…), y los verificadores corren código del candidato con un entorno mínimo (PATH y un HOME desechable: sin ~/.npmrc, ~/.aws ni config de gh).

Esto no es un sandbox. En modo workspace el agente corre con bypassPermissions y puede leer cualquier ruta del disco si la adivina; la aplicación no puede impedirlo. Lo que sí hace: el material no está a un ls .. de distancia, y al terminar se revisa el log del intento buscando accesos al material (attempts/, material/, rubrica.md, tests ocultos…). Un hallazgo queda en el manifiesto (leak), bloquea la evaluación y la confirmación, y cuenta en el reporte. El aislamiento real (otro usuario, contenedor) es trabajo del sistema, no de este código.

Histórico v1

Antes del benchmark v2 había una pestaña PRUEBAS IA en el Informe, con cinco pruebas de un turno calificadas a mano o por un juez de una sola pasada. Se retiró: hacía la misma promesa con menos rigor, y tener dos entradas parecidas en el menú solo confundía.

Las corridas que ya existían no se borran: viven en la pestaña Histórico dentro del benchmark, en solo lectura. No entran en ninguna comparación, porque se calificaron sin verificadores, sin criterios que bloquearan la aprobación y con un juez que aceptaba la cadena "false" como un sí. Están ahí como evidencia de lo que se probó, no como resultado comparable. Quien llegue a la URL vieja /#pruebas va al benchmark.

Costo de tenerlo abierto: cero

Con el tab abierto y quieto no corre nada: sin timers, sin animaciones infinitas, sin polling. La página se re-escanea al recuperar foco o visibilidad (throttle de 5 s), y el scan del server es incremental (~80 ms). El server en idle tampoco hace nada: solo escanea cuando alguien pide /api/stats.

Las señales de Salud y sus rangos

Un tropiezo es algo que te hizo perder tiempo o cuota en una sesión: frenar al agente a media respuesta, negarle un permiso, o que la API de Claude devuelva 5 o más errores. Con eso se deduce el veredicto de cada sesión (nadie lo etiqueta a mano): Fluida (escribió código sin tropiezos), Con tropiezos (escribió código pero hubo tropiezos), Sin cambios (tropiezos y ningún cambio detectado en disco) o Solo consulta (sin cambios detectados ni tropiezos). "Escribió código" = ediciones, archivos nuevos o commits, en la sesión o en sus subagentes; el veredicto dice si hubo cambios, no si el resultado sirvió.

| Señal | Meta | Qué mide | Qué hacer si sale de rango | |---|---|---|---| | Sesiones sin tropiezos | ≥ 75% | De las que escribieron código (Fluida + Con tropiezos), cuántas terminaron Fluidas | Peticiones con contexto (qué módulo, qué leer) y plan antes de ejecutar | | Sesiones sin cambios | ≤ 10% | Tropiezos y ningún cambio detectado en disco: tiempo sin producto visible | Regla de los 10 minutos: sin cambio en disco, sesión nueva con la petición reescrita | | Frenadas al agente | ≤ 0.30 / sesión | Veces que cortaste al agente a media respuesta | Plan Mode primero; achicar el alcance | | Permisos negados | ≤ 0.20 / sesión | Veces que le dijiste "no" a una acción que pidió (toolDenialKind: user-rejected; un bloqueo por regla o hook cuenta aparte) | Lo que niegas siempre, decláralo prohibido en settings o CLAUDE.md | | Errores del servicio | ≤ 1 / sesión | Incidentes de la API de Claude (saturación, red); los reintentos de un mismo incidente no suman | Con 5 seguidos, parar y reintentar después; partir trabajos largos | | Contexto reutilizado | ≥ 70% | De la entrada de tus sesiones (input + cache), qué parte ya estaba en cache | Una sesión por tarea, no una por pregunta; no re-pegar archivos ya leídos |

Todas piden 3 sesiones tuyas en el rango; con menos dicen "sin veredicto", no "en rango" ni "fuera". Las sesiones de máquina (entrypoint sdk-*) no entran en ninguna.

Los umbrales son heurísticos, no telemetría oficial. Están puestos donde los tropiezos dejan de ser ruido y empiezan a costar tiempo. Viven todos en signals() dentro de terminal.html, en un solo lugar, para que se puedan discutir y mover si tu equipo trabaja distinto. Cada señal trae en pantalla, en ese orden: qué significa en una frase, el consejo con tus datos, qué hacer, cómo verificar que funcionó, y solo al final la definición técnica y la fórmula. El botón Glosario del header abre los ~25 conceptos del informe (sesión, veredicto, tokens, cuota, skill, subagente, harness, juez IA…) en lenguaje de equipo.

Las señales de Fricción de flujo

Un segundo bloque, debajo de Salud, mide lo que tecleas de más y lo que el agente espera de más. Salud detecta tropiezos dentro de una sesión; Fricción de flujo detecta el trabajo de "pegamento" entre pasos que una automatización debería absorber. Mismo formato y mismo panel de detalle; los umbrales viven en flowSignals() de terminal.html y las expresiones que clasifican prompts en classifyPrompt() de scan.js.

| Señal | Meta | Qué mide | Qué hacer si sale de rango | |---|---|---|---| | Órdenes de subir | ≤ 10% de prompts | Prompts que solo piden commit, push, release o deploy | Un cierre que haga commit + push + CI + deploy y devuelva verde/rojo | | Corridas a mano | ≤ 0.2 / sesión | "Ya lo corrí", "ve la terminal"; aparte, bloqueos del clasificador de auto mode | Allowlist en .claude/settings.json del proyecto (/fewer-permission-prompts) | | Espera en polling | ≤ 1 min / sesión | Minutos del agente en bucles sleep/until/--watch (tope 30 min por llamada) | run_in_background + Monitor, o comandos con --watch/--wait | | Preguntas de estado | ≤ 0.15 / sesión | "Avísame cuando termine", "cómo va", "qué falta" | Notificación del sistema desde el hook Stop en sesiones largas | | Taps de aprobación | ≤ 5% de prompts | Prompts de ≤ 25 caracteres que solo dicen sí/ok/dale | Modo fluido: solo paran los checkpoints de alto riesgo | | Mensajes entre sesiones | ≤ 0.3 / sesión | Mensajes de otra sesión de Claude coordinándose | Una sesión por repo o un worktree por sesión; commits por pathspec | | Skills sin uso | ≤ 50% | Skills instaladas que no se cargaron en el rango | Archivar o fusionar las muertas (lista Higiene por skill en DEV) |

Los conteos de prompts salen de expresiones regulares en español, porque así trabaja el equipo: un prompt en inglés no cuenta, y eso es preferible a contar de más. La espera en polling suma el tiempo entre cada Bash con sleep/until/--watch y su resultado.

Datos de demostración

Para ver el Informe con 30 días de trabajo sin usar tus transcripts (o para enseñárselo al equipo), el repo trae un generador determinista con la forma exacta que escribe Claude Code:

node scripts/demo-data.js --out /tmp/agentic-demo
AGENTIC_PROJECTS_DIR=/tmp/agentic-demo/projects AGENTIC_HOME=/tmp/agentic-demo/home node cli.js --open

Cuatro proyectos, ~90 sesiones, skills, slash commands, subagentes anidados, frenadas, errores de la API, peticiones y comandos repetidos, y un historial de lecturas de cuota. Nada se mezcla con tu carpeta real: AGENTIC_PROJECTS_DIR redirige de dónde se leen los transcripts y AGENTIC_HOME dónde vive el cache, la cuota y la bitácora.

Pruebas

npm test corre las pruebas unitarias con node:test (sin dependencias): los helpers puros del escaneo (forma de comandos, inicio de prompts, unión de intervalos, precios) y la bitácora (delta de semana por lecturas, cierre automático y parcial) sobre un AGENTIC_HOME temporal. Los tests ocultos de bench/cases/*/material no son de este paquete: son los que el benchmark le aplica al agente.

Cómo funciona

~/.claude/projects/**/*.jsonl → scan.js → ~/.agentic-dashboard/cache.json → server.js → terminal.html
        (transcripts)          (agrega)          (incremental)               (:4571)     (Chart.js)

• cli.js es el punto de entrada (npx, --port, --export, --open).
• scan.js recorre los transcripts y agrega métricas por proyecto y por día. Cachea el resultado por archivo, con clave (mtime, size): sólo re-parsea lo que cambió. La constante SCHEMA invalida todo el cache cuando cambia la lógica de agregado. También inventaría los skills instalados para poder cruzarlos contra los que se cargan.
• server.js sirve las páginas y /api/stats (sólo http y fs).
• journal.js guarda el historial de lecturas de cuota y los cierres de día (~/.agentic-dashboard/journal/), y arma la bitácora.
• terminal.html es la UI (Informe); benchmark.html la del benchmark. Usan chart.umd.js (Chart.js 4.4.7) vendoreado al lado — cero CDN de librerías: el treemap del Informe se dibuja en DOM puro y el radar con el Chart.js local. Lo único remoto son las fuentes (Google Fonts); sin red caen a las del sistema (--sans/--mono con fallback real: monoespaciada del sistema, nunca serif).
• Estilo: tokens y clases en el <style> de cada cara (escala tipográfica de 7 pasos, espaciado en grid de 4, contraste AA en ambos temas, iconos Lucide inline). Motion mínimo y rápido (≤ 240 ms, curvas ease-out, sin animación al re-renderizar, prefers-reduced-motion respetado) — criterios del skill emil-design-eng de Emil Kowalski.

Decisiones no obvias (léelas antes de tocar el código)

1. Tiempo activo = unión de intervalos, nunca suma. Cada sesión emite intervalos [evento, min(siguiente, evento+5min)]; al agregar se unen. Sumar por archivo duplicaba las sesiones paralelas y producía días de 17 h.
2. Los transcripts anidados (subagents/, workflows/) cuentan tokens y tools, pero no tiempo, prompts ni sesiones: corren en paralelo al padre.
3. Una sesión = un archivo, atribuida a su día de inicio (si no, una sesión que cruza medianoche cuenta dos veces).
4. Prompts humanos se detectan por origin.kind === "human"; los <command-name> son slash-commands y se cuentan aparte; los prompts encolados llegan como type:"attachment".
5. El costo en $ es API-equivalente aproximado, no una factura. Con plan de suscripción sirve sólo para comparar proyectos entre sí. La tabla PRICING en scan.js hay que actualizarla cuando salgan modelos nuevos — si un modelo no matchea, la UI avisa con un chip "sin precio" en vez de subestimar en silencio. El cache read no es 0.1× para todos: Fable/Mythos cobran $0.25/M y Opus 5.5 $0.20/M (campo cr de la fila); como en una sesión de Claude Code casi todo es cache read, cobrarlo a 0.1× inflaba el peso de Fable ~4×.
6. Un mensaje se cuenta una vez, con su output completo. Claude Code escribe una línea por bloque de contenido con el mismo message.id, y output_tokens crece con el streaming: vale el mayor, no el primero. Y al reanudar o bifurcar una sesión copia el historial a un archivo nuevo con los mismos ids: el cache guarda quién es dueño de cada id (msgIndex), así que el archivo original cobra y la copia solo suma sus turnos nuevos (dupTurns).
7. Las sesiones de máquina (entrypoint sdk-*: claude -p, Agent SDK, el probe de cuota, el benchmark) aportan cuota y tokens al proyecto y al día, pero ni prompts, ni tiempo activo, ni herramientas, ni sesiones, ni fricción: el archivo conserva todo para su ficha, y al agregar se quitan esos campos (MACHINE_STRIP). En days[día] van como machineSessions.
8. El límite semanal real sale de quota.js (ver Límite semanal real arriba); en los transcripts el campo rateLimits siempre viene null. Cuando claude no está en el PATH, el selector ofrece Max 20× / Max 5× / Pro con los rangos publicados, o Auto = tu semana previa más alta, y la pantalla dice que es estimación.

Vista de equipo

Cada dev corre su propio dashboard; para compararse, cada quien exporta un resumen:

node cli.js --export tu-nombre
# o, sin clonar:  npx @timekast/agentic-dashboard --export tu-nombre

Eso escribe team/tu-nombre.json (~120 KB). Está gitignoreado a propósito: compartir tu actividad debe ser algo que decides, no el efecto secundario de un git add -A. Cuando quieras compartirlo:

git add -f team/tu-nombre.json && git commit -m "export: tu-nombre" && git push

Cuando la carpeta team/ tiene más de un archivo, el Informe muestra la sección Equipo: una tarjeta por persona (horas, fluidas, prompts por sesión, Plan Mode, subagentes, cuota de su bitácora, Salud y Fricción de flujo con las mismas señales que las tuyas, reparto por modelo, skills, commands, proyectos, causa más repetida y última nota) y la matriz quién trabaja en qué (horas activas por proyecto y persona en el rango). Las señales por persona omiten "Skills sin uso" (no sabemos qué tiene instalado cada quien) y dicen "sin veredicto" con menos de 3 sesiones, igual que las tuyas.

El export no lleva nada personal: sin extractos de prompts (tampoco los inicios que usa "qué automatizar"), sin rutas absolutas y sin nombres de archivo de transcript. Sí lleva la bitácora resumida (causa, delta de cuota, totales y la nota de cada día cerrado): la nota la escribes sabiendo que se comparte. Sólo agregados por día, por proyecto y por sesión. Verifícalo tú mismo — es un JSON plano.

Para qué sirve y para qué no. Esta vista es para capacidad y facturación: quién tiene ancho de banda, cuánto consumió un cliente, en qué se está yendo el tiempo del equipo. No es una métrica de desempeño individual. Más horas no es mejor trabajo, más líneas tampoco, y las sesiones de research no producen código a propósito. El dashboard lo dice en pantalla; no lo conviertas en un ranking.

Si un export tiene más de 7 días, la vista lo marca con ⚠ para que sepas que ese dato viene retrasado.

La vista de equipo necesita un checkout. Los exports no viajan en el paquete de npx — a propósito: correr el dashboard no debería repartirle a nadie los datos de los demás. Quien quiera comparar clona el repo; quien sólo quiera ver lo suyo usa npx y ya. Sin checkout, team/ se busca en ~/.agentic-dashboard/team.

Privacidad — importante para el equipo

• Todo corre en localhost. No hay telemetría ni llamadas salientes.
• cache.json contiene extractos de tus prompts (los primeros ~120 caracteres de cada sesión, para la tabla de sesiones recientes). Desde v1.0 vive en ~/.agentic-dashboard/, fuera del repo, justamente para que no se pueda commitear por accidente. La línea en .gitignore sigue ahí por los checkouts viejos.
• Si vas a mostrar el dashboard en pantalla compartida, cierra la tabla de "Sesiones recientes": muestra tus prompts.

Publicar una versión

El paquete se publica solo desde CI (.github/workflows/npm-publish.yml) con npm Trusted Publishing (OIDC): no hay token ni secret, npm confía en el workflow. Para sacar una versión nueva no necesitas cuenta de npm:

# 1. bump de version en package.json + entrada en CHANGELOG.md, commiteado en main
# 2. tag y push:
git tag v1.3.0 && git push origin v1.3.0

La primera vez es a mano (Trusted Publishing solo se puede configurar sobre un paquete que ya existe en el registro; hasta entonces el workflow falla con ENEEDAUTH). Lo hace el owner de la org @timekast en npm — la misma cuenta que mantiene @timekast/factory (npm view @timekast/factory maintainers) — una sola vez, desde un clone del repo en main. Nadie más del equipo necesita cuenta de npm, ni antes ni después:

git clone [email protected]:TimeKast/agentic-dashboard.git && cd agentic-dashboard
npm login                      # su cuenta, con acceso a la org @timekast
npm publish                    # publica la version del package.json (publishConfig.access=public)

Es el mismo camino que siguió @timekast/factory (su cli-publish.yml lo documenta): primer publish desde la máquina del owner, luego Trusted Publisher, y de ahí en adelante solo tags.

Después, en npmjs.com → paquete @timekast/agentic-dashboard → Settings → Trusted Publisher → repo TimeKast/agentic-dashboard, workflow npm-publish.yml (sin environment). A partir de ahí cada tag v* publica solo. Si un tag ya falló antes de ese setup, no lo re-cortes: publica esa versión a mano y sigue con el siguiente tag.

Para saber si el paquete ya está publicado: npm view @timekast/agentic-dashboard version (404 = todavía no); agentic-dashboard doctor también lo reporta.

El workflow rechaza el tag si no es alcanzable desde main, o si no coincide con la version del package.json — npm toma la versión de ahí, no del tag, y sin ese check un v2.0.0 mal cortado publicaría 1.2.0 en silencio.

Replicarlo / extenderlo

git clone <este-repo> && cd agentic-dashboard && node server.js

Funciona sin cambios en cualquier Mac/Linux con Claude Code. Para agregar una métrica:

1. En scan.js, agrégala dentro de days[día] (así respeta el filtro de rango) y súbele uno a SCHEMA.
2. El merge entre archivos usa mergeDay(), que suma números, fusiona objetos clave a clave y suma arrays posición a posición. No metas strings ahí — grita en consola a propósito.
3. En terminal.html, calcúlala en renderVals() y dibújala en view() (o en la ficha que corresponda: projDetail, sessionDetail…).

Ideas ya investigadas y priorizadas

docs/research/2026-08-12-ideas-de-la-comunidad.md compara este dashboard contra lo que hacen ccusage, ccflare, Claude-Code-Usage-Monitor, dash y la telemetría OTel oficial, y lista lo que falta verificado contra transcripts reales: líneas de código +/−, commits y PRs generados, errores de API e interrupciones (fricción), rechazos de permisos, y el effort por request.

Historia del diseño

• docs/refactor-2026-09-council.md — council de 3 lentes (diseño, dev del equipo, producto) que dio origen a v2.2: Hoy, bitácora, peso por modelo, convención de clic y guía de primera prueba.

docs/specs/ tiene el diseño original y el plan de mejoras que pasó por un council adversarial (4 lentes + refutadores) y dos rondas de revisión con Codex. El rediseño Informe (v1.1) tiene su propio rastro: docs/refactor-2026-08-council.md (el council que lo motivó, con sobrevivientes y refutados) y docs/refactor-2026-08-brief-claude-design.md (el brief que se llevó a Claude Design). Si vas a cambiar algo del agregado o de la UI, ahí está el porqué de cada decisión.

Estructura

cli.js         punto de entrada / npx (doctor, update, export)
scan.js        agregador + cache incremental + inventario de skills
server.js      http://localhost:4571 (+ /api/bench/* y /api/quota)
quota.js       lee tu cuota real del plan (ventanas de 5 h y 7 días)
benchmark.html cara "Benchmark v2" (/benchmark)
bench/         benchmark v2, un módulo por responsabilidad:
  schema.js      contratos: configuración, caso, intento, veredicto, hashes
  store.js       persistencia en disco: manifiestos, campañas, histórico v1
  harness.js     adaptadores claude/codex/gemini/grok: args, versión, parseo, entorno limpio
  verify.js      verificadores deterministas: redGreen, tests ocultos, json, graph, text, ui
  judge.js       juez estricto con consenso y calibración contra tus casos dorados
  run.js         ciclo de un intento: sembrar, lanzar, capturar, verificar, evaluar
  campaign.js    cola con presupuesto, alternancia de orden y reanudación
  report.js      métricas, cobertura y recomendación por tarea
  regression.js  de un fallo real a un borrador de caso, anonimizado
  cases/         un archivo por caso + su seed/ (lo que ve el agente) y material/ (lo que no)
terminal.html  UI del Informe  (/)
chart.umd.js   Chart.js 4.4.7 vendoreado
team/*.json    resúmenes que cada dev exporta y commitea
docs/specs/    diseño y plan de mejoras
docs/refactor-2026-08-*.md  council + brief del rediseño Informe (v1.1)
docs/research/ comparativa con la comunidad
CHANGELOG.md   qué cambió en cada versión

~/.agentic-dashboard/cache.json   generado, fuera del repo (extractos de prompts)
~/.agentic-dashboard/evals/runs/  corridas v1 (histórico), una carpeta por corrida
~/.agentic-dashboard/bench/       benchmark v2: attempts/ (manifiesto, workspace, material,
                                  artifacts, events), campaigns/, golden/, drafts/