asistente-2.spec.ts: usa waitForThreadReplyViaSdk en lugar de sendThreadMessage + waitForThreadReply (que dependian del panel UI). Elimina la importacion de sendThreadMessage. Agrega test.setTimeout(120_000) al test de threads para dar tiempo suficiente al ciclo completo.
login.spec.ts: ampliar locators de room tiles con .mx_RoomTile para mayor compatibilidad con Element Web moderno que no siempre usa role=treeitem.
element-auth.ts: ampliar locator de roomsTree con .mx_RoomList, .mx_LeftPanel_roomListContainer, .mx_RoomTile para detectar sesion existente de forma mas robusta, tanto en loginToElement como en waitForLoginResult.
goToRoom: implementa estrategia doble — primero intenta click directo en el sidebar (mas robusto), luego usa Ctrl+K como fallback. Evita el click en el boton Search que a veces es bloqueado por toasts.
startThreadOnLastMessage: en headless Chromium la hover action bar de Element no se renderiza (es React onMouseEnter, no CSS :hover). Ahora usa el Matrix SDK expuesto en window.mxMatrixClientPeg para enviar el mensaje threaded directamente via API, evitando la dependencia del panel UI.
Nueva funcion waitForThreadReplyViaSdk: consulta el timeline del SDK en lugar de depender del panel de thread UI. Busca eventos con m.relates_to.rel_type === 'm.thread' y filtra por sender si se especifica.
Nueva funcion interna waitForRoomLoaded: espera header del room o el composer como fallback, desacoplando la verificacion de la navegacion.
Mueve la logica de cierre de toasts a un modulo compartido (element-utils.ts) para evitar duplicacion. persistent-context.ts importa dismissAllToasts desde ahi y la invoca despues de verificar el sidebar. Se mejora tambien la deteccion del sidebar usando multiples locators alternativos (mx_RoomList, mx_LeftPanel_roomListContainer, mx_RoomTile) para mayor compatibilidad con distintas versiones de Element Web.
Migra los tests E2E de storageState a persistent browser context para
preservar IndexedDB (crypto keys E2EE). Añade reintentos de login,
screenshots de debug, logging detallado, y helpers de threads.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
global-setup.ts:
- Usa launchPersistentContext en vez de browser.newContext()
- Reemplaza storageState por marker file para cache de sesion
- Captura logs de consola del browser para debug
- Screenshots y HTML dump en caso de error
playwright.config.ts:
- Elimina storageState (ahora via persistent context fixture)
- Screenshots siempre activas, video y trace en failures
Tests (login, assistant-bot, asistente-2):
- Importan test/expect desde persistent-context fixture
- Usan handleElementDialogs() en vez de espera manual de rooms
- Nuevo test de threads en asistente-2: verifica que el bot
responde dentro del thread cuando se le habla por thread
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
element-auth.ts:
- Reintentos con backoff para M_LIMIT_EXCEEDED (max 3 intentos)
- Screenshots de debug en cada paso del login
- Deteccion de sesion activa (skip login si ya logueado)
- Manejo robusto de cross-signing con fallback si no hay Done button
- waitForLoginResult() detecta errores, rate limits y exito
matrix-room.ts:
- Logging detallado en goToRoom, sendMessage, waitForBotReply
- Screenshots automaticas en errores y timeouts
- Dump del timeline en timeout para diagnóstico
- Nuevos helpers: startThreadOnLastMessage, sendThreadMessage,
waitForThreadReply, assertBotDidNotReplyInMainTimeline
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Nuevo fixture que crea un worker-scoped persistent browser context
compartido entre tests. A diferencia de storageState, preserva IndexedDB
donde Element Web guarda las crypto keys de E2EE.
Incluye handleElementDialogs() que maneja:
- "Element is open in another window" → click Continue
- "Missing session data" → error informativo
- Espera rooms sidebar como señal de sesion cargada
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Nueva pantalla Tests en el menu principal del dashboard para ejecutar
Go tests, E2E tests (headless/headed) y todos secuencialmente.
Reemplaza el "Run Tests" del menu Server por navegacion a la nueva pantalla.
Tests para TestMenuOptions, updateTestsScreen (navegacion, seleccion,
generacion de intents), viewTests (render, cursor, last run),
testKindLabel, testKindIntent, y navegacion desde main/server menus.
Issue: 0023
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Nueva seccion "Tests" en el menu principal del dashboard que permite
ejecutar Go tests, E2E tests (headless y headed), y todos secuencialmente.
- ScreenTests con menu de seleccion de tipo de test
- TestKind enum para identificar el tipo de test ejecutado
- Nuevos intents: IntentRunGoTests, IntentRunE2ETests, IntentRunE2EHeadTests, IntentRunAllTests
- LastTestKind en Model para re-ejecucion con "r"
- runGoTests, runE2ETests, runAllTests en adapter
- "Run Tests" en Server menu reemplazado por navegacion a ScreenTests
- Test output muestra tipo de test en titulo y vuelve a ScreenTests con "0"
Issue: 0023
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Completa el sistema E2E con Playwright (cierra issue 0022 completo):
- Tests para assistant-bot y asistente-2
- Script run.sh de orquestacion completa
- Documentacion en e2e/README.md
- Seccion E2E en CLAUDE.md
Cierra 0022c (tests de agentes + docs) y el issue padre 0022
(Tests E2E con Playwright) ya que todos los sub-issues estan completados:
- 0022a: infraestructura base
- 0022b: auth fixtures y helpers
- 0022c: tests de agentes, run.sh, documentacion
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- e2e/README.md: guia completa de instalacion, configuracion,
ejecucion y debug de tests E2E
- .gitignore: agrega e2e/playwright-report/
- CLAUDE.md: agrega seccion E2E tests y dev-scripts/e2e en estructura
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Completa el placeholder de 0022a con el flujo completo:
1. Verifica agentes corriendo (via ps.sh)
2. Levanta Element Web si no esta activo
3. Ejecuta npx playwright test
4. Genera reporte HTML en caso de fallos
5. Teardown de Element Web
6. Retorna exit code de Playwright
Soporte --headed para debug local con DISPLAY.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Tests de cada agente via Element Web + Playwright:
- assistant-bot: saludo DM, pregunta, !help, !ping, E2EE check
- asistente-2: saludo, !tools, tool use (que hora es?), !help, E2EE check
Assertions flexibles para respuestas LLM (no-deterministicas),
estrictas para commands deterministicos (!help, !ping).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Integra fixtures de autenticacion para Element Web (login + cross-signing
con recovery key), helpers de interaccion con rooms Matrix (goToRoom,
sendMessage, waitForBotReply, assertNoDecryptionErrors) y smoke tests
de validacion de sesion E2EE.
Implementa el issue 0022b — fixtures de Playwright para
autenticacion en Element Web y helpers de interaccion con rooms.
- element-auth.ts: flujo completo de login + cross-signing con
recovery key, preparado para cachear sesion via storageState
- global-setup.ts: ejecuta login una vez antes de todos los tests,
reutiliza sesion cacheada si tiene menos de 12 horas
- matrix-room.ts: helpers goToRoom, sendMessage, waitForBotReply,
getLastMessage, assertNoDecryptionErrors (detecta "Unable to decrypt")
- login.spec.ts: 3 smoke tests validando sesion, E2EE y navegacion
- playwright.config.ts: configurado storageState para inyectar sesion
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Proyecto Node.js independiente en e2e/ con Playwright + Chromium headless.
Incluye setup-element.sh para descargar y servir Element Web localmente
(puerto 8090 por defecto, 8080 ocupado por Docker).
Scripts de instalacion y placeholder para ejecucion de tests.
Cierra issue 0022a.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Issue multi-issue desglosado en 3 sub-issues:
- 0022a: infraestructura base (Docker, Playwright config, CI)
- 0022b: auth fixtures y helpers (login, E2EE, utilidades Matrix)
- 0022c: tests de agentes + documentacion
Incluye actualizacion del README con issue 21 (completado) y todos
los sub-issues de 0022 registrados como pendientes.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Nuevo comando slash que automatiza la creacion de issues en dev/issues/.
Sigue estrictamente la regla create_issue.md, evalua el tamaño del issue
para desglosar en sub-issues con feature flags si es necesario, y registra
todo en el README automaticamente.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Dos problemas corregidos:
1. Detección de threads con E2EE: después de desencriptar un evento,
evt.Content.Raw puede no contener m.relates_to. Se añade fallback
usando el contenido tipado (evt.Content.Parsed) que es más robusto
tras la desencriptación de mautrix.
2. Notificaciones de tools fuera del thread: la notificación "🔨 tool"
se enviaba con SendMarkdown directo a la sala, ignorando el contexto
de thread. Ahora usa sendReply que respeta ThreadID.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Añadir tipo de rama quick/<slug> a los comandos /git-branch y /git-push
para cambios pequeños que no están asociados a un issue existente.
Antes, /git-push en master siempre inventaba un número de issue inexistente.
Ahora pregunta al usuario si el cambio tiene issue asociado o no.
No se modifican los flujos de ramas issue/ ni feature flags.
Actualiza el template de new-agent.sh para que agentes nuevos se creen
con matrix.threads.enabled: true por defecto. Tambien documenta la
seccion threads en create_agent.md para que la guia de creacion
incluya la configuracion de threads como opcion personalizable.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Añade la seccion matrix.threads con enabled: true a los 3 agentes
existentes (assistant-bot, asistente-2, meteorologo). Esto activa
el soporte de threads implementado en issue 0012, permitiendo que
los bots respondan dentro de threads cuando reciben mensajes en uno.
auto_thread queda en false para no cambiar el comportamiento actual.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Tests unitarios:
- runner_test.go: verifica ruteo correcto de ReplyAction segun
ThreadID (plain markdown, reply, thread, thread sin fallback, nil reply)
- thread_test.go: extraccion de ThreadID desde m.relates_to raw
(thread, reply sin thread, plain, m.replace, thread sin event_id)
- thread_relates_test.go: estructura JSON de RelatesTo.SetThread
cumple la spec de Matrix (rel_type, event_id, is_falling_back, m.in_reply_to)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Implementa el soporte completo de threads de Matrix:
- Listener extrae ThreadID de m.relates_to con rel_type=m.thread
- Client.SendThreadMarkdown envia mensajes como parte de un thread
usando SetThread de mautrix con fallback m.in_reply_to
- Runner detecta ThreadID en ReplyAction y rutea a SendThreadMarkdown
- MatrixSender interfaz actualizada con SendThreadMarkdown
- runtime.go propaga ThreadID en todas las respuestas (comandos, LLM, RBAC)
- sendReply helper centraliza la logica de envio con/sin thread
- Auto-thread: si matrix.threads.auto_thread=true, crea thread nuevo
para cada conversacion que no esta ya en un thread
- Memoria por thread: usa ThreadID como clave de window cuando el mensaje
esta en un thread, permitiendo conversaciones paralelas independientes
- Config: matrix.threads.enabled y matrix.threads.auto_thread en ThreadsCfg
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Todas las tareas del issue implementadas: default seguro con tmpdir,
configuracion de agentes existentes, tests unitarios y documentacion.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- docs/security.md: nueva seccion 6 sobre aislamiento del provider
claude-code, comportamiento del working_dir y checklist actualizado
- CLAUDE.md: añadir claude_code.working_dir a la seccion de seguridad
- create_agent.md: recomendar siempre configurar working_dir cuando
se usa el provider claude-code
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Extraer la logica de resolucion de working_dir a una funcion
resolveWorkDir() separada para hacerla testeable. Tres tests cubren:
- WorkingDir vacio → crea tmpdir con prefijo claude-agent-*
- WorkingDir configurado → crea el directorio y lo usa
- WorkingDir ya existente → lo usa sin error
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Setear working_dir a /tmp/claude-agents/<agent-id> en assistant-bot
y asistente-2, evitando que claude -p herede el CWD del launcher
(raiz del repo). El directorio se crea automaticamente al arrancar
gracias al MkdirAll añadido en el commit anterior.
Se mantiene bypassPermissions ya que el aislamiento real viene del
working_dir — sin acceso al repo, el bypass no expone codigo fuente.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cuando WorkingDir esta vacio, se crea un directorio temporal aislado
en lugar de heredar el CWD del launcher (raiz del repo). Esto evita
que el subproceso claude -p tenga acceso de lectura/escritura al
codigo fuente del proyecto.
Si WorkingDir tiene valor, se asegura que el directorio exista
creandolo con MkdirAll. Se loguea WARN cuando se usa el tmpdir
para que el operador lo note y configure explicitamente.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Issue para evitar que el subproceso claude -p tenga acceso al repositorio
del proyecto. Incluye default seguro con tmpdir, configuracion de agentes
existentes, tests y documentacion.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Completa el issue 0019 (prompt injection hardening) con:
- storage.base_path configurable para aislar datos de runtime
- Seccion de seguridad anti-injection en todos los system prompts
- Template reutilizable en .claude/templates/security-prompt.md
- Documentacion completa en docs/security.md
- Actualizacion de CLAUDE.md, create_agent.md y create_tool.md
- Feature flag prompt-injection-hardening activado
- Issue 0019 cerrado y movido a completed
Todas las fases del issue 0019 (prompt injection hardening) completadas
a traves de 4 sub-issues (0019a, 0019b, 0019c, 0019d).
- Activa feature flag prompt-injection-hardening en feature_flags.json
- Mueve issue a dev/issues/completed/
- Actualiza README con estado completado
- Marca todas las tareas pendientes como completadas en el issue
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cambios en documentacion para completar fase 7 del issue 0019:
- CLAUDE.md: nueva seccion Seguridad con resumen de protecciones
- create_agent.md: requisito obligatorio de seccion anti-injection en
system prompts + item en checklist de verificacion
- create_tool.md: nueva seccion Seguridad con requisitos para tools
que hacen I/O (deny-by-default, path traversal, SSRF, command
injection, rate limiting)
- docs/security.md: documentacion completa de las 5 capas de defensa
(sanitizacion, prompt hardening, tool validation, rate limiting,
filesystem isolation) con ejemplos de configuracion
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Crea template reutilizable en .claude/templates/security-prompt.md y
aplica seccion de seguridad obligatoria a todos los system prompts:
- assistant-bot/prompts/assistant-system.md
- asistente-2/prompts/system.md
- meteorologo/prompts/system.md
Las instrucciones cubren:
- Rechazo de acciones fuera del rol
- Proteccion del system prompt (no revelar)
- Rechazo de comandos destructivos
- Validacion de coherencia contextual de tool calls
- Resistencia a redefinicion de identidad
- Prohibicion de generar contenido para ataques
Tareas 3.1, 3.2, 3.3 del issue 0019.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Añade BasePath a StorageCfg y resolveDataBase() en runtime.go para
centralizar la resolucion del directorio base de datos del agente.
Prioridad: config storage.base_path > $AGENTS_DATA_DIR/<id> > agents/<id>/data
Esto permite mover los datos de runtime fuera del arbol del proyecto,
evitando que herramientas de desarrollo lean bases de datos, logs o
crypto stores por accidente.
Los paths de memory.db y knowledge.db ahora usan el base resuelto.
Los configs existentes no se rompen (fallback al path original).
Tareas 1.1 y 1.2 del issue 0019.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Rate limiting de tool calls por room usando sliding window en el registry.
Config via security.tool_rate_limit en YAML. Loguea tool_rate_limited
al exceder el limite. Tests unitarios y de integracion incluidos.
Sub-issue 0019c del hardening contra prompt injection.
egutierrez