Forzar máximo 2 steps en plan: 1 coder + 1 reviewer opcional
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>
This commit is contained in:
@@ -4,11 +4,15 @@
|
||||
|
||||
| Tool | Categoría | Acción |
|
||||
|------|-----------|--------|
|
||||
| `create_module` | Módulos | (Legacy) Alternativa para crear módulo — preferir acai_write |
|
||||
| `compile_module` | Módulos | Compila módulo tras editar index-base.tpl |
|
||||
| `compile_module` | Módulos | Recompilación manual de rescate cuando necesitas forzar la compilación sin editar el archivo |
|
||||
| `check_module` | Módulos | Preview de cómo renderiza un módulo |
|
||||
| `check_module_usage` | Módulos | Qué páginas usan un módulo |
|
||||
| `set_module_example_data` | Módulos | Datos de ejemplo para editor visual |
|
||||
| `acai-view` | Archivos | Lee un archivo del proyecto por tramos |
|
||||
| `acai-glob` | Archivos | Busca rutas de archivos por patrón |
|
||||
| `acai-grep` | Archivos | Busca texto en archivos del proyecto |
|
||||
| `acai-line-replace` | Archivos | Reemplaza un bloque concreto en un archivo existente |
|
||||
| `acai-write` | Archivos | Crea o reescribe un archivo completo. Antes de usarlo, lee la doc correspondiente según el tipo de archivo (`module-creation-guide`, `builder-fields`, `css-js-conventions`, `hooks-and-api`) |
|
||||
| `acai-delete` | Archivos | Borra un archivo del proyecto |
|
||||
| `list_page_modules` | Registros | Lista módulos de una página |
|
||||
| `add_module_to_record` | Registros | Añade módulo a una página |
|
||||
| `remove_module_from_record` | Registros | Elimina módulo de una página |
|
||||
@@ -30,29 +34,43 @@
|
||||
| `refresh_acai_token` | Auth | Renovar token JWT expirado |
|
||||
| `navigate_browser` | Navegación | Navegar el browser del frontend a una URL |
|
||||
| `save_project_styles` | Proyecto | Guardar resumen de estilos en docs/project-styles.md |
|
||||
| `orchestrate_task` | Orquestador | Guía paso a paso para tareas complejas |
|
||||
| `rollback_git` | Git | Recuperar cambios de git remoto |
|
||||
|
||||
## Flujos de trabajo
|
||||
|
||||
### Crear un módulo nuevo desde cero
|
||||
|
||||
1. `acai_write` — Escribe `index-base.tpl` en `template/estandar/modulos/NOMBRE/`. El server crea la carpeta si no existe, compila y genera todos los archivos derivados (index-twig.tpl, index.tpl, builder.json, screenshots)
|
||||
2. `add_module_to_record` — Añade el módulo a una página (tabla padre, ej: `apartados`)
|
||||
3. `set_module_config_vars` — Rellena las variables con contenido (textos, colores, opciones). **OBLIGATORIO** — sin esto el módulo no muestra nada. Devuelve:
|
||||
1. `acai-write` — Crea `index-base.tpl`, `style.css`, `script.js` y cualquier hook necesario con rutas relativas al proyecto
|
||||
2. `acai-write` o `acai-line-replace` compilan automáticamente al tocar `index-base.tpl`
|
||||
3. `add_module_to_record` — Añade el módulo a una página (tabla padre, ej: `apartados`)
|
||||
4. `set_module_config_vars` — Rellena las variables con contenido (textos, colores, opciones). **OBLIGATORIO** — sin esto el módulo no muestra nada. Devuelve:
|
||||
- `configVars`: mapa de variables → recordNums
|
||||
- `uploadFields`: mapa de variables upload → `{ fieldName, recordNum }` — **usa estos directamente** para subir imágenes sin necesidad de leer builder.json
|
||||
- Para vars multi con uploads: `uploadFields["varName.subVarName"]` es un array con `[{ index, fieldName, recordNum }]`
|
||||
4. Para imágenes: `generate_image` o `upload_record_image` usando el `recordNum` y `fieldName` del `uploadFields` devuelto en el paso 3
|
||||
5. Verificar con `check_module` o recargando la página
|
||||
|
||||
> **Nota:** `create_module` es una alternativa legacy que hace lo mismo pero con menos control sobre el contenido del template.
|
||||
5. Para imágenes: `generate_image` o `upload_record_image` usando el `recordNum` y `fieldName` del `uploadFields` devuelto en el paso 4
|
||||
6. Verificar con `check_module` o recargando la página
|
||||
|
||||
### Editar un módulo existente
|
||||
|
||||
1. `get_module_config_vars` — Leer el estado actual del módulo (variables, recordNums)
|
||||
2. Editar `index-base.tpl` con `acai_write` o `acai_line_replace` — el server compila automáticamente al guardar
|
||||
3. Si cambias variables: `set_module_config_vars` para actualizar valores
|
||||
2. `acai-view` — Leer solo el tramo de `index-base.tpl` que se va a modificar
|
||||
3. `acai-line-replace` — Editar el bloque concreto. Usa `acai-write` solo si el archivo es nuevo o el cambio es masivo
|
||||
4. La compilación es automática tras cada edición de `index-base.tpl`
|
||||
5. Si cambias variables: `set_module_config_vars` para actualizar valores
|
||||
|
||||
### Editar archivos del proyecto con bajo consumo de tokens
|
||||
|
||||
1. `acai-view` — Leer el archivo o un rango de líneas
|
||||
2. `acai-glob` — Encontrar archivos relevantes por ruta cuando no conoces el path exacto
|
||||
3. `acai-grep` — Buscar texto o atributos concretos dentro de archivos del proyecto
|
||||
4. `acai-line-replace` — Reemplazar el bloque exacto en archivos existentes
|
||||
5. `acai-write` — Crear archivos nuevos o reescribirlos por completo si es necesario
|
||||
6. `acai-delete` — Borrar archivos solo cuando sea explícitamente necesario
|
||||
|
||||
Reglas:
|
||||
- Usa siempre rutas relativas al proyecto
|
||||
- No edites `index.tpl`, `index-twig.tpl` ni `builder.json` — son auto-generados
|
||||
- Tras editar cualquier `index-base.tpl` con las file tools, la compilación se ejecuta automáticamente
|
||||
|
||||
### Añadir/modificar imágenes de un módulo
|
||||
|
||||
@@ -68,13 +86,13 @@
|
||||
- `tableName`: `"builder_custom"` (siempre sin cms_)
|
||||
- `recordId`: el recordNum del paso 1
|
||||
- `fieldName`: el campo de relations del builder.json (ej: `image1`)
|
||||
- `imageUrl`: URL accesible desde Docker (ej: `http://localhost/cms/uploads/...`)
|
||||
- `imageUrl`: usa la URL recomendada por la tool que generó/subió la imagen. En Forge, si `generate_image` devuelve `uploadUrl` o `fullUrl`, priorízala frente a `dockerUrl`
|
||||
|
||||
### Generar imagen con IA
|
||||
|
||||
1. `generate_image` con prompt descriptivo + style (photographic, digital-art, minimalist...)
|
||||
2. La imagen se guarda en `cms/uploads/generated/` y devuelve `dockerUrl`
|
||||
3. Usar esa `dockerUrl` con `upload_record_image` para asignarla a un módulo
|
||||
2. La imagen se guarda en `cms/uploads/generated/` y devuelve una URL local de preview (`dockerUrl`) y, cuando aplica, una URL recomendada para subida (`uploadUrl` / `fullUrl`)
|
||||
3. Para `upload_record_image`, usa la URL recomendada por la tool. En Forge, prioriza `uploadUrl` o `fullUrl` si están presentes
|
||||
|
||||
### Gestionar registros de una tabla
|
||||
|
||||
@@ -85,10 +103,9 @@
|
||||
|
||||
### Explorar el sitio
|
||||
|
||||
1. `orchestrate_task` con workflow `explore_site` — Guía para entender la estructura
|
||||
2. `list_page_modules` — Ver qué módulos tiene cada página
|
||||
3. `get_module_config_vars` — Ver los datos de cada módulo
|
||||
4. `check_module` — Preview de cómo renderiza
|
||||
1. `list_page_modules` — Ver qué módulos tiene cada página
|
||||
2. `get_module_config_vars` — Ver los datos de cada módulo
|
||||
3. `check_module` — Preview de cómo renderiza
|
||||
|
||||
## Reglas importantes para todas las tools
|
||||
|
||||
|
||||
Reference in New Issue
Block a user