El MCP server creaba archivos con UID 1000 que el server Python
(UID 1001) no podía modificar ni borrar. Ahora ambos containers
usan UID 1001, eliminando conflictos de permisos en volúmenes compartidos.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Nueva variable AGENTIC_OPENAI_BASE_URL para proveedores compatibles
con OpenAI API (MiniMax, DeepInfra, Together, etc.).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El modelo repetía tareas anteriores porque el historial se
reconstruía como mensajes user/assistant que parecían peticiones
nuevas. Ahora el historial va como un bloque de contexto marcado
explícitamente con [HISTORIAL — NO ejecutar de nuevo].
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- role=tool → role=user con tool_result blocks
- assistant con tool_calls → assistant con tool_use blocks
- Merge mensajes consecutivos del mismo role (Claude requiere alternancia)
- Capturar input_tokens del evento message_start
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El endpoint /context-debug ahora devuelve full_context con el
system_prompt y messages exactos enviados al modelo.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Extraída lógica de carga a _load_knowledge_from_dir() reutilizable.
Se llama automáticamente en el lifespan después de set_dependencies().
Si falla, solo loguea warning — no bloquea el arranque.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El sistema multi-agente (planner → coder → reviewer) añadía
complejidad y causaba problemas (sobreplanificaci��n, repetición
de tareas, pérdida de contexto entre steps).
Ahora: mensaje → coder → respuesta. Como Claude Code.
- El coder decide si responder directamente o usar tools
- Sin plan intermedio, sin reviewer, sin steps
- Un solo execute() con conversación real completa
- Historial compactado con key_data al finalizar
- System prompt actualizado: asistente de desarrollo, no agente
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
GPT-5.4 ignora las convenciones del knowledge base (42K tokens).
Las reglas más críticas se duplican en el system prompt del coder:
- script.js y style.css son ESTÁTICOS (sin Twig)
- Valores dinámicos via data-* attributes
- CmsApi.hook() en vez de fetch
- querySelectorAll con clase raíz en vez de getElementById
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El planner generaba 3+ steps para tareas simples causando que el
coder repitiera acciones en cada step (creaba el módulo varias veces).
Ahora el engine fusiona los steps en 1 coder con descripción combinada.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El plan del planner se emite como tool_use(name="plan") + tool_result
con los steps formateados. El frontend lo renderiza como un bloque
colapsable de herramienta con el plan de ejecución.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Budget de 15K dejaba fuera docs críticos (css-js-conventions,
hooks-and-api). Con 42K tokens totales y 128K de contexto,
incluir todo es la mejor estrategia.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El planner generaba 6+ steps para tareas simples como crear un módulo,
causando que el coder repitiera acciones o creara el módulo dos veces.
- Reglas explícitas: máximo 2-3 steps
- Crear módulo = 1 step coder (archivos + add + config)
- Explorar = 1 step coder
- Reviewer solo para tareas complejas
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El agenticSystem ahora es conversacional — recuerda lo dicho en
mensajes anteriores de la misma sesión.
- engine.py: direct_response guarda en task_history con formato
"User: X → Agent: Y"
- context/engine.py: _build_messages() reconstruye el task_history
como pares user/assistant reales en el array de messages, antes
del mensaje actual. El modelo ve una conversación completa.
- base.py: planner/reviewer no emiten AGENT_DELTA al frontend
(su output es interno, no para el usuario)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El planner genera JSON interno que no debe mostrarse al usuario.
Solo coder y collector emiten AGENT_DELTA al stream.
Para direct_response, el engine emite como agent=coder para que
el ClaudeFormatEmitter lo procese correctamente.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El planner ahora puede devolver direct_response en vez de un plan
cuando el mensaje no requiere herramientas (saludos, preguntas
generales, conversación casual).
- planner.py: prompt actualizado con formato direct_response
- engine.py: si planner devuelve string, emitir como texto y
completar sin ejecutar steps
"hola" → "¡Hola! ¿En qué puedo ayudarte hoy?" (0 steps, 0 tools)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Nuevo ClaudeFormatEmitter traduce eventos nativos al formato exacto
que produce Claude Code CLI: content_block_start/delta/stop, tool_result,
assistant snapshots, result con usage/cost, done.
- streaming/claude_format.py: ClaudeFormatEmitter + DualEmitter
- base.py: enriquecer eventos con tool_call_id, raw_output, tool_arguments
- engine.py: usage/cost en EXECUTION_COMPLETED
- routes.py: ?format=claude en /sessions/{id}/stream
- main.py: DualEmitter wiring (emite a ambos formatos)
El frontend puede consumir el stream sin cambios — mismos event types
que Claude Code CLI. El formato nativo sigue disponible para el dashboard.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Config: COST_PER_1M_INPUT y COST_PER_1M_OUTPUT configurables via .env
- OpenAI adapter: stream_options include_usage para capturar tokens reales
- base.py: acumula input/output tokens de cada iteración del agente
- planner.py: devuelve usage junto con el plan
- engine.py: suma tokens de planner + steps + review, calcula coste USD
- Response incluye usage{input_tokens, output_tokens} y total_cost_usd
Formato compatible con el bridge de Claude Code CLI para integración
con el frontend y reporting a Acai webservice.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El server compila automáticamente al guardar index-base.tpl via
acai_write — no necesita create_module ni compile_module manual.
- mcp-tools-reference.md: flujo actualizado, create_module marcado legacy
- module-creation-guide.md: paso 2 usa acai_write
- ACAI-CLAUDE.md: key workflows actualizados
- coder.py: system prompt alineado
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1. Task history preserva key_data estructurado (recordNums, sectionIds,
moduleIds, pages) extraído de las tool executions reales — el modelo
retiene contexto entre tasks sin re-consultar.
2. Coder system prompt mejorado: instrucciones explícitas sobre qué tool
usar para cada operación (create_module vs create_or_update_record),
consultar knowledge base antes de actuar, y reutilizar key_data del
historial.
3. Eliminado artifact_memory y working_context del coder context_sections
— ya no son necesarios con conversación real. Reduce acumulación de
artifacts en el context.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El MCP acai-code usa HTTP al server Python para operaciones de
ficheros (write, view, delete). En Docker, el server Python está
en el container app:9091, no en localhost:29871 (legacy local).
- mcp.json: env LOCAL_SERVER_URL=http://app:9091 para acai-code
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
