xonecode 0.1.0

package/skills/xone-project-generator/references/flujo-de-generacion.md

@@ -0,0 +1,67 @@
+# El flujo de generación de un proyecto
+
+> Referencia de `xone-project-generator`. Sale del `SKILL.md` para que lo
+> esencial quepa en una lectura por omisión (100 líneas).
+
+## Flujo de Generación de Proyectos
+
+
+### Fase 1: Análisis de Requisitos
+
+1. **Comprender la descripción** — Que tipo de aplicación, cual es su proposito
+2. **Identificar colecciones** — Modelo de datos: entidades, campos, relaciones
+3. **Identificar pantallas y navegación** — Flujo de usuario: entrada, menu, listados, detalle, formularios
+4. **Identificar integraciones** — GPS, camara, firma digital (DR), escaner QR/barras
+5. **Definir paleta de colores y estilo visual** — Colores primarios, secundarios, fondos, textos
+
+### Fase 2: Estructura del Proyecto
+
+Consulta [references/fases-0-2-analisis-y-modelo-de-datos.md](references/fases-0-2-analisis-y-modelo-de-datos.md) para el flujo completo.
+
+```
+NombreProyecto/
+├── bd/              # [OBLIGATORIO] Base de datos SQLite
+├── icons/           # [OBLIGATORIO] Recursos graficos (solo PNG)
+├── files/           # [OBLIGATORIO] Archivos dinamicos (fotos, firmas, docs)
+├── fonts/           # [RECOMENDADO] Fuentes tipograficas (.ttf, .otf)
+├── scripts/         # [OPCIONAL] Scripts JS organizados por modulo
+├── lang/            # [OPCIONAL] Multiidioma (subcarpetas por ISO: en/, es/)
+├── certificates/    # [OPCIONAL] Certificados SSL/TLS
+└── splash.png       # [OPCIONAL] Imagen de splash de carga inicial (raíz del proyecto)
+                     # Acepta tambien splash.jpg/.gif/.webp/.apng/.mp4/.3gp
+                     # El framework lo carga automaticamente — NO es una <coll>
+```
+
+### Fase 3: Archivos de Configuración
+
+| Archivo | Descripción |
+|---------|-------------|
+| `app.xml` | Configuración de la app. Atributo `prefix="gen"` por defecto |
+| `app.ini` | Metadatos: Name, Title, Caption, Icon, IconFolder=icons, FilesFolder=files |
+| `mappings.xne` | SOLO colecciones Empresas y Usuarios, con los campos de la tabla de arriba. Encoding coherente con el resto del proyecto (regla en `xone-development`) |
+| `default.css` | Estilos globales con clases base |
+| `functions.js` | Funciones JavaScript globales |
+
+### Fase 4: Colecciones y Pantallas
+
+**Colecciones:**
+- Un archivo `.xne` por cada coleccion adicional. Encoding coherente con cómo se guarda (regla en `xone-development`)
+- `progid`: opcional salvo Empresas y Usuarios (regla en `xone-development`)
+- Usar macro `##PREF##` en queries SQL
+- Tipos de prop: solo los de la tabla de tipos de `xone-development`; no inventar otros
+
+**Pantallas:**
+- `EntradaApp.xne` — Pantalla de entrada **post-login** (bienvenida con botón "Entrar"). Obligatoria salvo que la app arranque directamente en `MenuPrincipal`. No es el splash (ver la regla de `xone-development` sobre la diferencia)
+- `MenuPrincipal.xne` — Menu principal
+- Pantallas de listado, detalle, formularios según requisitos
+- Inicializar con `<before-edit>` (regla en `xone-development`)
+- Splash de carga: fichero en la raíz del proyecto, no una pantalla `.xne` (misma regla)
+
+### Fase 5: Post-Generación
+
+Indicar al usuario que ejecute:
+1. Generar base de datos con `xone_db_generator`
+2. Insertar datos iniciales (Empresa + Usuario admin)
+3. Descargar iconos de Google Material Icons (PNG, JPG o SVG — todos validos)
+
+---

package/skills/xone-project-generator/references/plantillas-estandar.md

@@ -0,0 +1,98 @@
+# Las tres plantillas estándar
+
+> Referencia de `xone-project-generator`. Sale del `SKILL.md` para que lo
+> esencial quepa en una lectura por omisión (100 líneas).
+
+## Plantilla Estándar de Pantalla
+
+
+```xml
+<?xml version="1.0" encoding="iso-8859-15"?>
+<coll name="NombrePantalla" title="Título" special="true" notab="true" show-toolbar="false">
+
+    <!-- Inicializar la pantalla en before-edit, NUNCA en load -->
+    <before-edit refresh="false" show-wait-dialog="false">
+        <action name="runscript">
+            <script language="javascript">
+                // Inicializar campos y datos
+                self.MAP_TITULO = "Mi pantalla";
+            </script>
+        </action>
+    </before-edit>
+
+    <group name="grpPrincipal" id="1">
+        <frame name="frmHeader" width="100%" height="140p" bgcolor="#1565C0">
+            <!-- Logo, título, botones de navegacion -->
+        </frame>
+        <frame name="frmBody" width="100%" height="-2" scroll="true" bgcolor="#FFFFFF">
+            <!-- Contenido: campos, listas, botones -->
+        </frame>
+        <frame name="frmFooter" width="100%" height="100p" bgcolor="#F5F5F5">
+            <!-- Botones de acción, barra inferior -->
+        </frame>
+    </group>
+
+    <onback show-wait-dialog="false">
+        <action name="runscript">
+            <script language="javascript">
+                ui.getView(self).exit();
+            </script>
+        </action>
+    </onback>
+</coll>
+```
+
+## Plantilla Estándar de Coleccion de Datos
+
+
+```xml
+<?xml version="1.0" encoding="iso-8859-15"?>
+<coll name="MiColeccion"
+      progid="ASData.CASBasicDataObj"
+      sql="SELECT ID, NOMBRE FROM ##PREF##MiColeccion"
+      objname="MiColeccion"
+      updateobj="MiColeccion"
+      loadall="true">
+    <group name="General" id="1">
+        <!-- ID y ROWID los gestiona XOne: no hace falta declararlos (válido pero redundante). Solo ID se rescata en el SELECT. -->
+        <prop name="NOMBRE" type="T" visible="7" size="150" width="100%" />
+    </group>
+</coll>
+```
+
+## Plantilla mappings.xne
+
+
+```xml
+<?xml version="1.0" encoding="iso-8859-15"?>
+<xml>
+    <app prefix="gen" version="1.0.0" debug="true" default-language="javascript">
+        <style url="default.css" />
+    </app>
+    <collprops type="general">
+        <coll name="Empresas"
+              progid="ASGestion.CASEmpresa"
+              sql="SELECT ID, CODIGO, NOMBRE FROM ##PREF##Empresas"
+              objname="Empresas" updateobj="Empresas" loadall="true">
+            <group name="General" id="1">
+                <prop name="CODIGO" type="N" visible="7" />
+                <prop name="NOMBRE" type="T" visible="7" size="150" width="100%" />
+            </group>
+        </coll>
+        <coll name="Usuarios"
+              progid="ASGestion.CASUser"
+              sql="SELECT ID, CODIGO, NOMBRE, IDEMPRESA, LOGIN, PWD FROM ##PREF##Usuarios"
+              objname="Usuarios" updateobj="Usuarios" loadall="true">
+            <group name="General" id="1">
+                <prop name="CODIGO"     type="N" visible="7" />
+                <prop name="NOMBRE"     type="T" visible="7" size="100" width="100%" />
+                <prop name="IDEMPRESA"  type="N" visible="7" mapcol="Empresas" mapfld="ID" />
+                <prop name="LOGIN"      type="T" visible="7" size="50"  width="100%" />
+                <prop name="PWD"        type="X" visible="0" size="100" />
+            </group>
+        </coll>
+    </collprops>
+</xml>
+```
+
+---

package/skills/xone-project-generator/references/tamanos-canonicos.md

@@ -0,0 +1,49 @@
+# Tamaños canónicos (`width` / `height` / `fontsize`)
+
+> Referencia de `xone-project-generator`. Sale del `SKILL.md` para que lo
+> esencial quepa en una lectura por omisión (100 líneas).
+
+## Tamaños canónicos (`width` / `height` / `fontsize`)
+
+
+Antes de fijar cualquier `width` o `height`, consulta **[references/canonical-sizes.md](references/canonical-sizes.md)** — contiene tablas por tipo de elemento (frames, botones, inputs, listas, avatares, iconos, tipografía, áreas especiales, wearable) y los anti-patrones más frecuentes. **Todos los valores están calibrados para `resolution-width="1080"` / `resolution-height="1920"` (default XOne).**
+
+> **REGLA CRÍTICA:** En XOne **`p` ≠ `dp`**. 1p = 1px en el dispositivo de referencia. Material 56dp en 1080×1920 (xxhdpi, density 3×) = **~168p**, NO 56p. Aplicar valores Material directamente como `p` produce barras/botones ~3× más pequeños de lo necesario.
+
+### Heurísticas de decisión (memorizar)
+
+1. **Header / footer / toolbar / drawer fijos** → `height` en `Np` absoluto (típicos en 1080×1920: header `164p`, header completo con tabs `404p`, footer con botones `216p`–`288p`, bottom nav `168p`, drawer width `840p`–`960p`).
+2. **Frame body principal entre header y footer fijos** → `height="-2"` o `height="100%" scroll="true"`. NUNCA un `%` calculado a mano restando los fijos.
+3. **Contenido apilado verticalmente** → `height="-2"` (wrap content) y dejar que el contenido mande. Solo fijar `Np` si necesitas mínimo visual.
+4. **Imágenes, avatares, iconos** → `Np` fijos en **ambos** ejes para preservar aspecto. NUNCA `width="100%" height="100%"` en una imagen.
+5. **Botones** → `width` en `%`, `height` en `Np`, mínimo **144p** (touch target Material 48dp × 3 en xxhdpi). CTAs principales: `124p` (workflow pill).
+6. **Inputs** → `width="95%"`–`"100%"`, `height` en `Np` (típico `144p`).
+7. **Dos elementos en la misma fila** → anchos `%` que sumen ≤ 100%; el segundo no hereda el salto de línea por defecto (regla en `xone-development`).
+8. **Los `%` se refieren al padre directo**, no a la pantalla. Tres frames hermanos con `height="40%"` desbordan (suman 120%).
+9. **`<prop>` tiene 2 columnas internas (label + valor)**: si `labelwidth="50"` y `width="50%"`, el valor real queda con 25% de la fila. Bajar `labelwidth` a 20-30 o subir `width` a 95-100%.
+10. **`fontsize` usa escala XOne 1-12**, NO Material `sp`/`dp`. Texto estándar = `5`, título sección = `7`, topbar = `10`–`11`, nombre app = `12`.
+
+### Defaults seguros para 1080×1920 (cuando no estás seguro)
+
+| Nodo | width | height |
+|------|-------|--------|
+| `<frame>` cabecera | `100%` | `164p` |
+| `<frame>` cuerpo | `100%` | `-2` con `scroll="true"` |
+| `<frame>` pie con botones | `100%` | `216p` |
+| `<frame>` tarjeta | `95%` | `-2` |
+| `<prop type="T">` / `N` / `D` / `combo` | `100%` | `144p` |
+| `<prop type="B">` (botón) | `90%` | `124p` |
+| `<prop type="L">` (label) | `100%` | `-2` (o `96p`) |
+| `<prop type="NC">` (checkbox) | `100%` | `144p` |
+| `<prop type="IMG">` / `PH` / `DR` | `100%` | `600p`–`720p` |
+| `<prop type="Z">` (contenedor) | `100%` | `-2` o `100%` |
+| Icono `img-width` / `img-height` | `72p` (toolbar) o `104p` (botón cuadrado) | igual |
+| `tmargin` entre elementos del mismo bloque | — | `30p` |
+| `tmargin` entre bloques distintos | — | `50p` |
+| `fontsize` texto estándar | — | `5` |
+
+> **Si `resolution-width` ≠ 1080**, escalar con `valor_nuevo = valor_tabla × (resolution-width / 1080)`. Detalle en §14 de [references/canonical-sizes.md](references/canonical-sizes.md).
+
+> **Limitación honesta:** sin ver el render real es imposible afinar al píxel. Estos valores cubren el caso típico y evitan errores groseros (desborde, touch target insuficiente, distorsión de imagen), pero pueden requerir ajuste tras la primera compilación. Si el usuario aporta una captura o el dispositivo objetivo (móvil / tablet / wearable / kiosko), usar la sección §11 (wearable) o ajustar proporcionalmente.
+
+---

package/skills/xone-review/SKILL.md

@@ -0,0 +1,189 @@
+---
+name: xone-review
+description: "Validar, verificar y revisar proyectos XOne con el linter xone-simulator. Usar al validar un proyecto, validar una coll suelta, hacer smoke de una app, ejecutar un evento concreto, renderizar una coll o una pantalla tras el login, corregir iterativamente los errores del validador, o auditar un proyecto o un cambio antes de entregarlo: códigos del validador, checklist de entrega y priorización de hallazgos por severidad. También para inspeccionar la base de datos del proyecto con xone-db-tools: esquema de una tabla y consultas SQL sobre gestion.db. Las reglas y anti-patrones de cada capa viven en xone-development."
+---
+
+# XOne Review
+
+Verificación y revisión de proyectos XOne. Combina la validación automatizada con el CLI `xone-simulator` (paquete npm `xone-linter`), la validación de la BD con `xone-db-tools` y una revisión manual anclada a las reglas de `xone-development`.
+
+**El linter dice qué está mal, no cuál es la forma correcta.** Para eso lee `xone-development`. No reportes como hallazgo ni apliques como arreglo nada que no puedas anclar al validador o a esas reglas.
+
+## Precondiciones
+
+```bash
+command -v xone-simulator
+```
+
+Si no existe: `npm install -g xone-linter xone-db-tools`. Si está instalado pero el shell no lo encuentra, usa la ruta completa al binario global (comprueba `npm config get prefix`).
+
+En Claude Code, `/xone-validate [ruta]` ejecuta el flujo de validación y corrección completo.
+
+## Flujo
+
+1. Comprueba que `xone-simulator` existe; si no, indícalo al usuario y detente.
+2. `validate` y lee los issues. Prioriza `errors` sobre `warnings`.
+3. Si existe `bd/gestion.db`, ejecuta `xone-db-tools validate-db ./proyecto/bd/gestion.db --project ./proyecto --json`.
+4. Corrige **un tipo de error a la vez** y revalida tras cada tanda, para no introducir regresiones.
+5. `smoke` sobre la app completa cuando `validate` pase.
+6. Si `smoke` falla, aísla con `run` (evento concreto) y `render` (UI). Para una pantalla que está **detrás del login**, saca antes la sesión con `login --session` y pásasela a `render --session`.
+7. Revisión manual contra las reglas de `xone-development` (ver «Qué revisar en cada capa»).
+8. Prioriza los hallazgos y reporta con severidad, `archivo:línea` y causa raíz.
+
+No des por cerrado el trabajo hasta que `validate` pase sin `errors` y `smoke` devuelva exit 0, o hasta que los `failures` restantes estén justificados.
+
+**`validate-coll` queda fuera de este flujo, a propósito.** El flujo asume un proyecto completo; `validate-coll` es la entrada para cuando solo tienes un `.xne` suelto. Su veredicto es parcial por construcción, así que no cierra nada: en cuanto haya proyecto, se pasa `validate`.
+
+## Comandos
+
+Requieren `xone-linter >= 1.2.0` — `validate-coll`, `login` y `render --session` aparecieron en 1.1.0, y 1.2.0 es el suelo soportado. `describe-table` y `execute-sql` necesitan `xone-db-tools >= 0.2.0`.
+
+```bash
+xone-simulator validate      ./proyecto --json                 # verificación estática
+xone-simulator validate-coll ./Clientes.xne --json             # UNA coll suelta, sin app.xml
+xone-simulator smoke         ./proyecto --json                 # ciclo de vida completo
+xone-simulator run           ./proyecto --coll X --event before-edit --json
+xone-simulator render        ./proyecto --coll X               # coll a HTML
+xone-simulator login         ./proyecto --user u --pass p --session ./sesion.json
+xone-simulator render        ./proyecto --coll X --session ./sesion.json   # pantalla tras el login
+xone-db-tools validate-db     ./proyecto/bd/gestion.db --project ./proyecto --json
+xone-db-tools describe-table  ./proyecto/bd/gestion.db gen_clientes --json    # esquema de una tabla
+xone-db-tools execute-sql     ./proyecto/bd/gestion.db "SELECT …" --json      # datos (¡también escribe!)
+xone-db-tools execute-sql     ./proyecto/bd/gestion.db --file ./consulta.sql --json
+```
+
+**`validate`** comprueba XML bien formado y encoding, atributos obligatorios, unicidad de nombres, tipos de propiedad, `progid`, ficheros y estilos incluidos, sintaxis JS y referencias cruzadas (`mapcol`, `inherits`, `contents`, `openEditView`), más los anti-patrones documentados. Con `--json` devuelve `success`, `summary` e `issues` con severidad, fichero y mensaje.
+
+**`validate-coll`** valida **una coll suelta**, sin `app.xml` ni el resto del proyecto. Es para cuando solo tienes el `.xne` —una coll recién escrita, un fichero recibido aparte—, no un sustituto de `validate`.
+
+> **`"success": true` aquí NO significa que la coll esté bien.** Significa que no se halló nada
+> entre los chequeos que **sí** se ejecutaron.
+
+La respuesta trae un array **`skipped`** con lo que no se ha comprobado y por qué. **Léelo y
+repórtalo junto al veredicto.** Sin el proyecto quedan fuera, entre otros:
+
+- La sintaxis JS de los `<script>` de la coll (`JS_ASYNC_AWAIT` y compañía).
+- Las referencias a nodos de la propia coll (`REF_NODE_MISSING`).
+- Los handlers en ficheros `.js` (`REF_FUNC_MISSING`).
+- Las referencias entre colls: `mapcol`, `mapfld`, `linkedto`, `<contents src>`.
+- Los `<include>` y el `entry-point`.
+- La composición del layout: la coll se valida **sin el layout inyectado**, así que los props, frames y eventos que aportaría `<include-layout>` quedan invisibles para el validador.
+
+De los anti-patrones se ejecutan cinco de seis; solo se cae `ANTIPATTERN_VBSCRIPT`, que necesita
+`app.xml`.
+
+**`smoke`** dispara `create`/`before-edit`/`after-edit` más render con flow de todas las colls (o de `--coll X`). Con `--interact` además tapea los props con `onclick`/`method=ExecuteNode(...)` (máx. `--max-taps`, default 20). Exit code 1 si hay `failures`. Una coll rota no aborta el resto y cada fallo incluye su fase y el stack truncado. El entorno es siempre seguro: `network:'mock'` e in-memory, sin tocar red ni SQLite reales. Si `totals.stubWarnings > 0` en una coll que pasó, algún método fue absorbido por autostub (`kind: 'stub-method'`): no bloquea, pero repórtalo.
+
+**`run`** ejecuta un evento a nivel de coll (`before-edit`, `create`, `onback`) o inline de prop (`onclick`, `onchange`, con `--prop` y `--data`). Devuelve estado y `log` de side-effects: navegación, mensajes, refrescos, HTTP, cambios de datos y errores.
+
+**`render`** renderiza una coll a HTML con ciclo de vida (`--no-flow` para renderizar en frío). `--group N` renderiza una página concreta de un swipe, por su `id`. `--active-color <hex>` sustituye el valor de `MAP_COLORACTIVO`.
+
+**`login` + `render --session` van juntos**, y ninguno sirve por separado: `login` ejecuta el `login()` **de la propia app** y vuelca la sesión a un fichero, que luego consume `render --session` para pintar pantallas que están detrás del login.
+
+- **Completar significa salir de la coll de login.** Si al terminar se sigue en ella, el comando lo dice (`El login no completó: se sigue en "X"`), **no escribe el fichero de sesión** y devuelve **exit 1**. Que el script haya corrido no basta: en una prueba real se vio `appData.login(...)` ejecutarse y disparar su `onLoginSuccessful` con su toast, y aun así el login se consideró no completado por no haber navegado.
+- **En el fallo imprime el log de side-effects** (`executeNode`, `appData.login`, mensajes), que es por dónde se empieza a diagnosticar.
+- **Los defaults casi nunca encajan.** Son `--coll Login`, `--user-prop MAP_EMAIL`, `--pass-prop MAP_PASS`, `--login-prop MAP_LOGIN_BTN`, `--boot EntradaApp` y `--timeout 30`. Un proyecto que llame a las cosas de otra manera necesita los cuatro overrides —por ejemplo `--coll LoginColl --user-prop MAP_USUARIO --pass-prop MAP_PASSWORD --login-prop MAP_LOGIN`—. Antes de dar por roto el login, comprueba que apuntas a la coll y los props que el proyecto realmente tiene.
+
+`--db-path` debe apuntar a una **copia** de la base de datos: el simulador puede mutarla. `--db-prefix` fija el prefijo de tablas, y está disponible en `run` y en `render`.
+
+### Leer datos de la BD
+
+Además de `validate-db`, `xone-db-tools` tiene dos comandos que **devuelven datos**, y son la forma de responder «¿qué hay realmente en la base?» sin abrir SQLite a mano.
+
+**`describe-table <gestion.db> <tabla>`** devuelve el esquema: por cada columna, `position`, `name`, `type`, `nullable`, `default` y `primaryKey`. Con `--json` sale estructurado; sin `--json`, como tabla legible. Es lo que confirma si una columna existe y con qué tipo, antes de culpar al XML.
+
+**`execute-sql <gestion.db> "<sql>"`**, o `--file <consulta.sql>` para una consulta larga, ejecuta SQL arbitrario. Un `SELECT` devuelve un array de objetos fila; una escritura devuelve `{changes, lastInsertRowid}`.
+
+> **`execute-sql` NO es de solo lectura: ejecuta lo que le pases, incluidos `INSERT`, `UPDATE`, `DELETE` y DDL, y muta el fichero.** Comprobado. Trabaja siempre sobre una **copia** de `gestion.db`, igual que con `--db-path` del simulador, y no lo apuntes a la BD del repositorio. Para inspeccionar, limítate a `SELECT`.
+
+Recuerda el contrato del generador: tablas en minúsculas con prefijo `gen_`, campos en mayúsculas — por eso las consultas son de la forma `SELECT NOMBRE FROM gen_clientes`.
+
+## Códigos del validador
+
+### Errores
+
+| Código | Significado |
+|--------|-------------|
+| `XML_PARSE` | XML mal formado en un `.xne` |
+| `INVALID_PROP_TYPE` | Tipo de prop no soportado |
+| `PROP_MISSING_NAME` / `PROP_MISSING_TYPE` | Prop sin `name` o sin `type` |
+| `COLL_MISSING_PROGID` | Coll con `objname` pero sin `progid` |
+| `GROUP_MISSING_ID` | Grupo sin atributo `id` |
+| `APP_NO_ENTRY` | `app.xml` sin punto de entrada (`entry-point`) |
+| `DUPLICATE_COLL_NAME` | Nombre de colección duplicado |
+| `DUPLICATE_NAME_IN_COLL` | Nombre repetido dentro de una coll |
+| `REF_MAPCOL_MISSING` | `mapcol` apunta a una coll inexistente |
+| `REF_CONTENTS_SRC_MISSING` | `contents src` apunta a una coll inexistente |
+| `REF_INHERITS_MISSING` | `inherits` apunta a una coll inexistente |
+| `ANTIPATTERN_MULTIPLE_BEFORE_EDIT` | Más de un `before-edit` en la misma coll |
+| `ANTIPATTERN_SELF_AS_FUNCTION` | `self` usado como función |
+| `ANTIPATTERN_MACRO_SYNTAX` | `macro` llamado como método de `coll` |
+| `ANTIPATTERN_SELF_LOCK` | `lock`/`unlock` llamados sobre `self` |
+| `ANTIPATTERN_VBSCRIPT` | Include con `language="vbscript"` (descontinuado) |
+| `JS_SYNTAX` | Error de sintaxis JavaScript |
+| `JS_TEMPLATE_LITERAL` | Template literals no soportados |
+| `JS_ASYNC_AWAIT` | `async`/`await` no soportados |
+
+### Warnings
+
+| Código | Significado |
+|--------|-------------|
+| `ANTIPATTERN_LOAD_EVENT` | Se usa `<load>`; preferir `<before-edit>` |
+| `REF_MAPFLD_MISSING` | `mapfld` no es campo de la coll de `mapcol` |
+| `REF_LINKEDFIELD_MISSING` | `linkedfield` no es campo de la coll de `mapcol` |
+| `REF_JS_COLL_MISSING` | Script referencia una colección inexistente |
+| `REF_NODE_MISSING` | Referencia a nodo o evento inexistente |
+| `REF_FUNC_MISSING` | Referencia a función inexistente |
+
+Los códigos son case-sensitive. Cada warning debe justificarse o corregirse.
+
+## Qué revisar en cada capa
+
+Las reglas y los anti-patrones de cada capa viven en la skill `xone-development`, que es donde se escriben una sola vez. Antes de marcar un hallazgo, contrástalo allí:
+
+- Reglas transversales, tipos de prop, visibilidad, ciclo de vida y sintaxis del motor: `xone-development/SKILL.md`.
+- Anti-patrones por área (XML, JavaScript, CSS, datos, dispositivo): sección «Anti-patrones» de `xone-development/SKILL.md`.
+- Detalle de un atributo, una API o un valor admitido: el índice de referencias de `xone-development/SKILL.md`.
+
+**No reportes como hallazgo nada que no puedas anclar al validador o a esas reglas.**
+
+## Checklist de entrega
+
+- [ ] `validate` sin errores; warnings justificados o corregidos.
+- [ ] `smoke` con exit 0.
+- [ ] Pantallas nuevas siguen la jerarquía de `xone-development`.
+- [ ] Colls de datos con `sql`, `objname` y `updateobj`; `progid` según la regla de `xone-development`.
+- [ ] `##PREF##` en toda SQL de colección.
+- [ ] Todo `unlock` con su `lock` en `finally`; todo `startBrowse` con su `endBrowse`.
+- [ ] Cursores y conexiones SQL cerrados, patrón de `xone-development`.
+- [ ] Callbacks asíncronos preservando `self`.
+- [ ] Validación de entrada antes de `save()`.
+- [ ] SQL parametrizado.
+- [ ] CSS con unidades (`p`/`%`) y colores (`#AARRGGBB`) correctos.
+- [ ] `allowUnsafeCertificates: false`; sin credenciales hardcodeadas.
+- [ ] Solo se han tocado los `.xne` fuente (regla en `xone-development`).
+
+## Severidad y reporte
+
+| Severidad | Definición | Acción |
+|---|---|---|
+| Crítico | Bloquea entrega: error del validador, SQL injection, `before-edit` duplicado, referencias rotas | Corregir antes de entregar |
+| Alto | Riesgo de bug en runtime: `self` en callback, lock sin `finally`, `-8100` por no validar | Corregir en el mismo cambio |
+| Medio | Mala práctica o rendimiento: `load`, refresh global, espera bloqueante | Corregir o registrar deuda técnica |
+| Bajo | Estilo y consistencia: nombres, comentarios, organización del CSS | Sugerencia, no bloqueante |
+
+Reporta cada hallazgo con `archivo:línea`, severidad, código del validador si existe, y causa raíz con la corrección propuesta. Al final indica qué se corrigió, qué se verificó (`validate` + `smoke`) y qué no has podido verificar, incluidas las limitaciones del sandbox.
+
+## Diagnóstico rápido
+
+- XML mal formado o encoding → revisa el prólogo y que el `encoding` declarado coincida con cómo está guardado el `.xne`.
+- Pantalla vacía → XML, primer `newline` de cada fila, nombres duplicados, `visible`/`disablevisible`, `special` junto a `sql` y `compatibility-mode`.
+- Inicialización que no ocurre → mueve la lógica de `load` a `before-edit` o `create`.
+- Coll que falla en `smoke` pero no en `validate` → `run` con `--json` para ver el stack de runtime.
+- Muchos `stubWarnings` → reporta qué APIs del sandbox no están cubiertas; no son errores bloqueantes.
+
+## Fuente de las reglas
+
+Los códigos del validador vienen del paquete `xone-linter`; las reglas de cada capa, de la skill `xone-development`. Para confirmar la forma correcta de algo antes de marcarlo como hallazgo o de aplicar un arreglo, lee `xone-development/SKILL.md` y su índice de referencias.
+
+Para diagnosticar un fallo a partir de su síntoma, usa `xone-debugging`.