xonecode 0.1.0

package/skills/xone-project-generator/references/fases-0-2-analisis-y-modelo-de-datos.md

@@ -0,0 +1,350 @@
+# Generación XOne — Fases 0-2: flujo, requisitos y modelo de datos
+
+> Fuente: `xone/v2/xone-project-generator/references/xone-project-generation-workflow.md` §1–§3. Referencia de la skill; el índice está en [../SKILL.md](../SKILL.md).
+
+Contenido: §1 Fase 0 diagrama de flujo completo · §2 Fase 1 análisis de requisitos (datos mínimos, inferencias, regla de decisión técnica) · §3 Fase 2 diseño del modelo de datos (colecciones base obligatorias, tipos de propiedades, visibilidad, foreign keys)
+
+---
+
+## 1. Fase 0: Diagrama de Flujo Completo
+
+```
+INICIO: Usuario solicita nuevo proyecto
+         |
+         v
+[FASE 0] Diagrama / Planificacion
+         |
+         v
+[FASE 1] Analisis de Requisitos
+         |-- Identificar sector y funcionalidades
+         |-- Determinar colecciones necesarias
+         |-- Identificar pantallas requeridas
+         |-- Definir paleta de colores e iconos
+         |
+         v
+[FASE 2] Diseno del Modelo de Datos
+         |-- Colecciones base (Empresas, Usuarios)
+         |-- Colecciones adicionales del proyecto
+         |-- Relaciones entre colecciones
+         |-- Tipos de campos y visibilidad
+         |
+         v
+[FASE 3] Estilos CSS
+         |-- default.css (estilos globales)
+         |-- colors.css (paleta de colores, opcional)
+         |
+         v
+[FASE 4] Creación de Estructura de Carpetas
+         |-- bd/, icons/, files/, fonts/
+         |
+         v
+[FASE 5] Generacion de Archivos de Configuración
+         |-- app.xml (configuracion global)
+         |-- app.ini (metadatos)
+         |-- mappings.xne (SOLO Empresas y Usuarios)
+         |
+         v
+[FASE 6] Generacion de Colecciones
+         |-- Un archivo .xne por cada coleccion adicional
+         |-- Definir campos, tipos, visibilidad
+         |
+         v
+[FASE 7] Generacion de Pantallas
+         |-- Decidir si la app tiene autologin o login
+         |-- Login.xne (solo si NO es autologin)
+         |-- EntradaApp.xne / MenuPrincipal.xne (punto de entrada)
+         |-- Consola.xne (obligatoria, siempre; con replica completa o solo info de dispositivo)
+         |-- Pantallas de listas, detalle, mapas, config
+         |
+         v
+[FASE 8] Eventos y Reglas de Negocio
+         |-- Eventos de ciclo de vida (create, insert, before-edit, after-edit, delete)
+         |-- Eventos de coleccion Empresas (onlogon, onlogoff, maintenance, replica-ok...)
+         |-- Eventos de contents (selecteditem, load, auto-selecteditem)
+         |-- Eventos de controles (onclick, onchange, onback, onfocus...)
+         |-- Eventos especiales de app (on-app-foreground, on-app-background, inactividad)
+         |
+         v
+[FASE 9] Funciones JavaScript
+         |-- functions.js (funciones globales)
+         |-- Scripts adicionales si es necesario
+         |
+         v
+[FASE 10] Generacion de READMEs
+         |-- README.md en cada carpeta (bd/, icons/, files/, fonts/)
+         |-- README.md principal con prompt detallado
+         |
+         v
+[FASE 11] Tareas Finales (en este orden exacto)
+         |-- 1. Generar base de datos con xone_db_generator
+         |-- 2. Insertar datos iniciales (Empresa + Usuario admin)
+         |-- 3. Descargar iconos (Iconify API — PNG, JPG o SVG validos)
+         |
+         v
+[FASE 12] Validación
+         |-- Ejecutar checklist completo
+         |-- Verificar estructura, BD, iconos
+         |
+         v
+FIN: Proyecto completo y validado
+```
+
+---
+
+## 2. Fase 1: Análisis de Requisitos
+
+### 2.1 Objetivo
+
+Entender que hay que construir antes de escribir código. El agente debe inferir todo lo que pueda del contexto de la solicitud, y preguntar **únicamente lo que no pueda deducir por si mismo**.
+
+> **REGLA:** No lanzar un interrogatorio. Analizar primero la solicitud, inferir, y preguntar solo lo mínimo imprescindible para no poder continuar.
+
+---
+
+### 2.2 Datos Mínimos Obligatorios
+
+Son los únicos datos sin los cuales es imposible iniciar el proyecto. Si no están presentes en la solicitud, preguntar **en un único mensaje**, todos juntos:
+
+| Dato | Por que es obligatorio |
+|------|------------------------|
+| **¿Que hace la app?** — descripción breve | Sin esto no se puede inferir nada: colecciones, pantallas, lógica |
+| **¿Con login o sin login (autologin)?** | Determina si se genera Login.xne y como se configura app.xml |
+| **¿Tiene replica con servidor?** | Determina el contenido de la Consola y la configuración de license.ini |
+
+Si el programador ya lo ha descrito en su solicitud, no volver a preguntar.
+
+---
+
+### 2.3 Datos que el Agente Infiere
+
+El agente deduce estos datos del contexto sin preguntar. Si la inferencia es dudosa, aplica el valor por defecto y avanza:
+
+| Dato | Como inferirlo | Valor por defecto |
+|------|----------------|-------------------|
+| Nombre del proyecto | Del título o descripción de la solicitud | `MiProyecto` |
+| Sector | De las entidades y funcionalidades descritas | `Servicios` |
+| Colecciones necesarias | De las funcionalidades y entidades mencionadas | Se modelan según el sector |
+| Pantallas necesarias | De las colecciones y el flujo descrito | Lista + Detalle por cada coleccion |
+| Pantalla de entrada | Si no se indica, usar `EntradaApp` | `EntradaApp` |
+| Roles de usuario | De la descripción o del sector | `Administrador, Usuario` |
+| Prefijo BD | Si no se indica explicitamente | `gen` |
+| Plataforma | Si no se indica | Android |
+| Orientación | Si no se indica | Portrait |
+| Resolución de referencia | Si no se indica | 1080x1920 |
+| Colores | Si no se indican, usar paleta Material Design neutra | `#2196F3`, `#757575`, `#FF5722` |
+| Fuente | Si no se indica | `Roboto-Regular.ttf` |
+| Integraciones (GPS, camara, PDF...) | De las funcionalidades descritas | Ninguna |
+| Datos iniciales BD | Siempre | Empresa de prueba + usuario admin |
+
+---
+
+### 2.4 Datos que el Programador Puede Aportar Voluntariamente
+
+El agente no pregunta por estos, pero si el programador los aporta, los usa:
+
+- Diseños de pantallas (Figma, wireframes, imágenes)
+- Colores corporativos o logo
+- Fuente tipografica corporativa
+- Campos especificos de las entidades
+- Restricciones técnicas (versión Android, seguridad, inactividad)
+- URL del servidor de replica e intervalo de sincronización
+- Prefijo de BD diferente a `gen`
+
+---
+
+### 2.5 Regla de Decisión Técnica
+
+```
+ANTES de escribir codigo:
+1. ¿Existe documentacion en las knowledgebases?
+   -> SI: Seguir la documentacion exactamente
+   -> NO: Buscar ejemplos en templates/projects/
+
+2. ¿Hay ejemplos similares en los proyectos?
+   -> SI: Analizar el patron y adaptarlo
+   -> NO: Preguntar al usuario antes de improvisar
+
+3. ¿El atributo/funcion/propiedad esta documentado?
+   -> SI: Usar solo valores documentados
+   -> NO: NO inventar, buscar alternativas documentadas
+```
+
+---
+
+### 2.6 Donde Buscar Referencia
+
+| Necesidad | Fuente |
+|-----------|--------|
+| Estructura de proyecto | `knowledgebase/docs/xone-project-structure-knowledgebase.md` |
+| Atributos XML | `knowledgebase/docs/xone-xml-structure-knowledgebase.md` |
+| API JavaScript | `knowledgebase/docs/xone-javascript-api-knowledgebase.md` |
+| Estilos CSS | `knowledgebase/docs/xone-css-knowledgebase.md` |
+| Guía paso a paso | `knowledgebase/docs/xone-new-project-guide-knowledgebase.md` |
+| Proyecto de ejemplo | `knowledgebase/examples/UseCars/` |
+| Proyectos reales | `templates/projects/` |
+
+
+## 3. Fase 2: Diseño del Modelo de Datos
+
+### 3.1 Objetivo
+
+Disenar el modelo de datos completo del proyecto, incluyendo colecciones, campos, tipos, visibilidad y relaciones entre entidades.
+
+### 3.2 Colecciones Base Obligatorias
+
+Toda aplicación XOne debe tener al mínimo estas dos colecciones en `mappings.xne`.
+
+**Estructura mínima obligatoria de `mappings.xne`:**
+
+```xml
+<?xml version="1.0" encoding="iso-8859-15"?>
+<xml>
+  <collprops type="general">
+
+    <coll name="Empresas" title="la empresa"
+          sql="select e.* from ##PREF##empresa e"
+          objname="empresa" updateobj="empresa" progid="ASGestion.CASEmpresa">
+      <group name="General" id="1">
+        <prop name="CODIGO" visible="3" type="N" fieldsize="12" />
+        <prop name="NOMBRE" type="T" fieldsize="30" size="250" />
+      </group>
+    </coll>
+
+    <coll name="Usuarios" title="el usuario"
+          sql="select u.* from ##PREF##usuarios u"
+          objname="usuarios" updateobj="usuarios" progid="ASGestion.CASUser">
+      <group name="General" id="1">
+        <prop name="IDEMPRESA" visible="0" type="N" mapcol="Empresas" mapfld="ID" />
+        <prop name="CODIGO" visible="3" type="T" fieldsize="10" size="50" />
+        <prop name="LOGIN" visible="3" type="T" fieldsize="10" size="50" />
+        <prop name="PWD" type="X" fieldsize="10" size="50" visible="0" />
+        <prop name="NOMBRE" visible="3" type="T" fieldsize="30" size="50" />
+      </group>
+      <create>
+        <action name="setval" field="IDEMPRESA" value="##ENTID##" />
+      </create>
+    </coll>
+
+  </collprops>
+</xml>
+```
+
+**Reglas críticas del mappings.xne:**
+- Solo contiene `Empresas` y `Usuarios`. El resto de colecciones van en archivos `.xne` separados
+- El campo de relación en Usuarios es `IDEMPRESA` (FK a Empresas), con `mapcol="Empresas" mapfld="ID"`
+- El evento `<create>` en Usuarios asigna automáticamente `##ENTID##` al crear un nuevo usuario
+- El encoding puede ser UTF-8 o `iso-8859-15` (coherente con los bytes; el motor respeta el declarado)
+
+### 3.3 Tipos de Propiedades Disponibles
+
+Los tipos de XOne se dividen en dos categorías: los que **se persisten en base de datos** y los que son **solo visuales** (no generan columna en BD).
+
+#### Tipos de Datos (se persisten en BD)
+
+| Tipo | SQLite | Descripción | Ejemplo de Uso |
+|------|--------|-------------|----------------|
+| `T` | TEXT | Texto. Admite variantes: texto simple, multilinea (con `lines`) o mapeada (con `linkedto`) | Nombres, descripciones, campos enlazados |
+| `N` | INTEGER | Número entero | IDs, cantidades, flags numéricos |
+| `N2` | REAL | Número con 2 decimales | Precios, importes |
+| `N3` | REAL | Número con 3 decimales | Coordenadas |
+| `N4` | REAL | Número con 4 decimales | Precisión alta |
+| `N5` | REAL | Número con 5 decimales | Precisión muy alta |
+| `N6` | REAL | Número con 6 decimales | GPS lat/lon |
+| `TN` | TEXT | Número almacenado como texto (entero) | Números con leading zeros, códigos numéricos |
+| `TN2` | TEXT | Número almacenado como texto (2 decimales) | Importes formateados como texto |
+| `TN3` | TEXT | Número almacenado como texto (3 decimales) | Medidas con precisión |
+| `TN4` | TEXT | Número almacenado como texto (4 decimales) | Precisión alta |
+| `TN5` | TEXT | Número almacenado como texto (5 decimales) | Precisión muy alta |
+| `TN6` | TEXT | Número almacenado como texto (6 decimales) | GPS como texto |
+| `X` | TEXT | Password — se muestra enmascarado, admite `hash-type` y `encode` | Contrasenas |
+| `D` | TEXT | Fecha | Fechas |
+| `DT` | TEXT | Fecha y hora | Timestamps |
+| `TT` | TEXT | Hora en formato texto | Horas, duraciones |
+| `NC` | INTEGER | Checkbox / Toggle (0=no, 1=si) | Opciones booleanas |
+| `IMG` | TEXT | Imagen (ruta al fichero) | Fotos referenciadas, logos |
+| `PH` | TEXT | Fotografía — captura desde camara del dispositivo | Fotos tomadas en campo |
+| `VD` | TEXT | Video — grabacion, selección o escaner QR/barcode | Grabacion de video, lectura de códigos |
+| `AT` | TEXT | Adjunto — permite adjuntar ficheros al registro | Documentos adjuntos |
+| `DR` | TEXT | Dibujo / firma a mano alzada (ruta al fichero) | Firmas, croquis |
+| `WEB` | TEXT | WebView — URL o HTML embebido | Contenido web, videos online |
+| `O` | (no aplica) | Sub-objeto JavaScript — NO genera columna ni se persiste | Estructuras temporales en memoria |
+
+#### Tipos de UI (NO se persisten en BD — solo visuales)
+
+Estos tipos definen controles visuales que **no generan columna en la base de datos**. Se usan exclusivamente para la interfaz.
+
+| Tipo | Descripción | Uso |
+|------|-------------|-----|
+| `L` | Etiqueta de texto (solo lectura) — forma preferida. Muestra el `title`; sin `title`, usa el valor del campo como fallback | Títulos, labels, textos informativos o valores dinámicos |
+| `TL` | Alias legacy de `L` (mismo control) | Equivalente a `type="L"` |
+| `THTML` | Etiqueta con contenido HTML enriquecido | Textos con formato HTML embebido (negrita, colores, enlaces) |
+| `B` | Botón | Acciones, navegación, llamadas a ExecuteNode |
+| `Z` | Contents — lista embebida dentro de otra coleccion | Subgrids, detalles de maestro-detalle, mapas (`viewmode="mapview"`), kanban, slider, etc. |
+
+### 3.4 Sistema de Visibilidad (Bitmask)
+
+El atributo `visible` define **en que contextos de la UI se pinta el campo**. Es estático — no se puede cambiar en tiempo de ejecución por script ni por condiciones. Si un campo tiene `visible="0"`, no existe en pantalla en ningun momento.
+
+Cada bit representa un contexto:
+
+| Bit | Valor | Contexto |
+|-----|-------|----------|
+| Bit 0 | 1 | Edición (formulario individual) |
+| Bit 1 | 2 | Lista (vista de registros) |
+| Bit 2 | 4 | Content (lista embebida `type="Z"`) |
+| Bit 3 | 8 | Combo (desplegable) |
+
+Cualquier combinacion de bits es valida. Las más usadas:
+
+| Valor | Contextos | Uso típico |
+|-------|-----------|------------|
+| `0` | Ninguno | Campo puramente interno — solo para lógica |
+| `1` | Edición | Solo en formulario individual |
+| `2` | Lista | Solo en vista de registros |
+| `3` | Edición + Lista | En formulario y en lista |
+| `4` | Content | Solo en listas embebidas |
+| `7` | Edición + Lista + Content | **El más habitual** |
+| `8` | Combo | Solo en desplegables |
+| `15` | Todos | Edición + Lista + Content + Combo |
+
+**Regla general:**
+- Campos de BD internos (ID, ROWID): `visible="0"`
+- Campos visibles para el usuario: `visible="7"`
+- Campos solo en formulario: `visible="1"`
+- Campos solo en listas: `visible="2"`
+
+> **Diferencia con `disablevisible`:** `visible` es estático — decide si el campo existe en pantalla en ese contexto. `disablevisible` es dinámico — el campo existe pero se muestra u oculta según el valor de otro campo en tiempo de ejecución.
+
+### 3.5 Relaciones entre Colecciones (Foreign Keys)
+
+Las relaciones se definen con los atributos `mapcol` y `mapfld`:
+
+```xml
+<!-- Campo que referencia otra coleccion -->
+<prop name="IDEMPRESA" type="N" visible="7" mapcol="Empresas" mapfld="ID" />
+<!-- Significa: IDEMPRESA referencia al campo ID de la coleccion Empresas -->
+```
+
+### 3.6 Ejemplo de Diseño de Modelo
+
+Para una app de gestion de entregas:
+
+```
+Empresas (mappings.xne)
+├── CODIGO, NOMBRE (declarar como <prop>; ID y ROWID los gestiona XOne, no hace falta declararlos)
+├── CIF, DIRECCION, TELEFONO (adicionales)
+
+Usuarios (mappings.xne)
+├── CODIGO, NOMBRE, IDEMPRESA, LOGIN, PWD (declarar como <prop>; ID y ROWID los gestiona XOne)
+├── ROL, EMAIL, TELEFONO, ACTIVO (adicionales)
+
+Clientes (Clientes.xne)
+├── ID, CODIGO, NOMBRE, DIRECCION, TELEFONO, EMAIL, LATITUD, LONGITUD
+
+Pedidos (Pedidos.xne)
+├── ID, ID_CLIENTE (FK->Clientes), FECHA, ESTADO, TOTAL, OBSERVACIONES
+
+Entregas (Entregas.xne)
+├── ID, ID_PEDIDO (FK->Pedidos), ID_REPARTIDOR (FK->Usuarios)
+├── FECHA_ENTREGA, FIRMA, FOTO_ENTREGA, LATITUD, LONGITUD, ESTADO
+```

package/skills/xone-project-generator/references/fases-10-12-readmes-y-validacion.md

@@ -0,0 +1,194 @@
+# Generación XOne — Fases 10-12: READMEs, tareas finales y validación
+
+> Fuente: `xone/v2/xone-project-generator/references/xone-project-generation-workflow.md` §11–§13. Referencia de la skill; el índice está en [../SKILL.md](../SKILL.md).
+
+Contenido: §11 Fase 10 READMEs · §12 Fase 11 tareas finales (base de datos, datos iniciales, iconos) · §13 Fase 12 checklist completo de validación
+
+---
+
+## 11. Fase 10: Generación de READMEs
+
+### 10.1 Objetivo
+
+Crear un README.md en cada carpeta del proyecto y un README.md principal con el prompt detallado de generación.
+
+### 10.2 READMEs por Carpeta
+
+Cada carpeta obligatoria debe tener un README.md que describa:
+
+- **bd/README.md**: Proposito de la carpeta, como se genera gestion.db, comando `xone_db_generator`
+- **icons/README.md**: Fuente de iconos (Google Material Icons), formato PNG, tamanios estándar, nomenclatura
+- **files/README.md**: Proposito (archivos dinámicos), como acceder desde código (appData.getFilesPath())
+- **fonts/README.md**: Fuentes incluidas, formatos soportados (TTF, OTF), uso en CSS y XML
+
+### 10.3 README.md Principal (Raiz del Proyecto)
+
+El README.md principal debe ser un **prompt detallado** que describe completamente como crear la aplicación. Debe contener:
+
+1. **Descripción General** - Que hace la app, sector, plataformas
+2. **Funcionalidades** - Lista detallada de funciones principales
+3. **Modelo de Datos** - Todas las colecciones con sus campos, tipos y relaciones
+4. **Pantallas** - Descripción de cada pantalla con su proposito y elementos
+5. **Flujos de Usuario** - Pasos de interaccion para cada funcionalidad
+6. **Reglas de Negocio** - Validaciones, calculos y restricciones
+7. **Integraciones** - GPS, camara, firma digital, NFC, Bluetooth, etc.
+8. **Paleta de Colores** - Colores hex del proyecto (primario, secundario, acento, estados)
+9. **Iconos Requeridos** - Lista completa de iconos necesarios con nombre y pantalla
+10. **Comandos de Generación** - Como generar BD, descargar iconos, convertir e insertar datos
+
+---
+
+## 12. Fase 11: Tareas Finales
+
+### 11.1 Objetivo
+
+Ejecutar las tareas finales de generación en el orden exacto especificado. Estas tareas se ejecutan DESPUES de generar todo el código fuente.
+
+### 11.2 Orden de Ejecución (OBLIGATORIO)
+
+1. Generar base de datos (`xone_db_generator`)
+2. Insertar datos iniciales (Empresa + Usuario admin)
+3. Descargar iconos (Iconify API — PNG, JPG o SVG validos)
+
+### 11.3 Tarea 1: Generar Base de Datos
+
+Comando:
+
+```bash
+python3 -m xone_db_generator NombreProyecto --overwrite
+```
+
+Verificación: sqlite3 .../bd/gestion.db ".tables"
+
+Las tablas deben tener el prefijo `gen_` y estar en minúsculas (ej: `gen_empresas`, `gen_usuarios`). Los campos se generan en mayúsculas.
+
+**Mapeo de Tipos XOne a SQLite:**
+
+| Tipo XOne | SQLite | Descripción |
+|-----------|--------|-------------|
+| T, L, TL, X, PH | TEXT | Texto |
+| D, DT | TEXT | Fechas |
+| IMG, VD, F, M | TEXT | Rutas |
+| N | INTEGER | Entero |
+| NC, R | INTEGER | Boolean |
+| N1-N6 | REAL | Decimales |
+| C | TEXT | Combo |
+| B, Z, L, S, P, O | NO SE CREA | UI |
+
+### 11.4 Tarea 2: Insertar Datos Iniciales
+
+Registros obligatorios:
+- Empresa: CODIGO=1, NOMBRE="EMPRESA DE PRUEBA", ROWID=GUID_32_hex
+- Usuario: CODIGO=1, NOMBRE="admin", LOGIN="admin", IDEMPRESA=1, ROWID=GUID_32_hex
+
+GUID sin guiones: python3 -c "import uuid; print(uuid.uuid4().hex)"
+
+### 11.5 Tarea 3: Descargar Iconos
+
+Fuente: Google Material Icons via Iconify API
+URL: https://api.iconify.design/ic/baseline-{nombre}.svg?color={color}
+
+XOne soporta PNG, JPG y SVG — no es necesario convertir SVG a PNG.
+Iconos comunes: home, search, arrow-back, save, settings, person, add, delete, edit, check, close, menu
+
+### 11.6 Nota sobre formatos de iconos
+
+XOne soporta PNG, JPG y SVG directamente — no es necesario convertir ni eliminar los SVG.
+Si por preferencia del proyecto se quiere usar solo PNG, se puede convertir con cairosvg (pip install cairosvg), pero no es obligatorio.
+
+**Anti-patrón a evitar — NO renderices un SVG con `type="WEB"`:** el soporte de SVG en XOne es nativo y completo. Un `.svg` es una imagen más; se refiere con `type="IMG"` (`path="dibujo.svg"`) o con los atributos `img`/`imgbk`, igual que un PNG. El control `WEB` (WebView) es solo para contenido web remoto (URLs `http`/`https`, vídeos embebidos); usarlo para mostrar una imagen local SVG/PNG/JPG es innecesario y rompe el escalado y la integración con el control.
+
+---
+
+## 13. Fase 12: Validación
+
+### 12.1 Objetivo
+
+Ejecutar el checklist completo de validación para asegurar que el proyecto esta completo y funcional.
+
+### 12.2 Checklist Completo
+
+#### Archivos raiz
+- [ ] app.xml existe con `prefix="gen"` (o el especificado por el usuario)
+- [ ] app.xml tiene `<connection>`, `<entry-point>`, `<style>` e `<include>`
+- [ ] app.xml declara un encoding coherente con sus bytes (UTF-8 o iso-8859-15)
+- [ ] app.ini existe con `name`, `icon`, `IconFolder=icons`, `FilesFolder=files`
+- [ ] license.ini existe con `Connstring=bd/gestion.db`
+- [ ] mappings.xne existe SOLO con Empresas y Usuarios
+- [ ] mappings.xne declara un encoding coherente con sus bytes (UTF-8 o iso-8859-15)
+- [ ] mappings.xne tiene `progid="ASGestion.CASEmpresa"` en Empresas y `progid="ASGestion.CASUser"` en Usuarios
+- [ ] Usuarios tiene evento `<create>` con `setval field="IDEMPRESA" value="##ENTID##"`
+
+#### Campos obligatorios en mappings.xne
+- [ ] Empresas tiene: `CODIGO` (N), `NOMBRE` (T)
+- [ ] Usuarios tiene: `IDEMPRESA` (N, FK a Empresas), `CODIGO` (T), `LOGIN` (T), `PWD` (X), `NOMBRE` (T)
+
+#### Colecciones de negocio
+- [ ] Cada coleccion adicional tiene su propio archivo `.xne` (NINGUNA en mappings.xne)
+- [ ] Cada coleccion tiene `sql` con `##PREF##` y el campo `ID` en el SELECT
+- [ ] Cada coleccion tiene `objname`, `updateobj` y `progid="ASData.CASBasicDataObj"`
+- [ ] Tipos de campos validos: `T`, `N`, `N1`-`N6`, `X`, `D`, `DT`, `NC`, `IMG`, `PH`, `VD`, `AT`, `DR`, `TT` para datos; `L` (o su alias legacy `TL`), `THTML`, `B`, `Z` solo para UI
+- [ ] Valores de `visible` usan bitmask correcto (0-7)
+- [ ] Campos enlazados de JOINs llevan prefijo `MAP_` y están marcados como `locked="true"`
+- [ ] Campos FK se nombran `IDLOQUESEA` (todo junto en mayusculas) y usan `mapcol`/`mapfld`
+- [ ] Campos tipo Z llevan prefijo `@` en el name y tienen su `<contents>` asociado
+- [ ] Filtros van en `filter`, ordenaciones en `sort` — NUNCA en el `sql`
+- [ ] No se usan `px` en dimensiones — solo `p` o `%`
+
+#### Pantallas
+- [ ] Existe punto de entrada (`EntradaApp.xne` o `MenuPrincipal.xne`) declarado en `<entry-point>` del app.xml
+- [ ] Si `autologon="false"`: existe `Login.xne` declarado en `<login-coll>` del app.xml
+- [ ] Existe `Consola.xne` (siempre obligatoria)
+- [ ] Pantallas con replica: Consola tiene todos los grupos (info replica, dispositivo, ficheros)
+- [ ] Pantallas sin replica: Consola tiene solo el grupo de información del dispositivo
+- [ ] Todas las colecciones-pantalla tienen `<onback>` definido
+- [ ] Grupos fijos (header/footer) usan `fixed="true"` con `orientation="top|bottom"`
+- [ ] Events usan sintaxis correcta: `<action name="runscript"><script language="javascript">`
+
+#### Estilos CSS
+- [ ] `default.css` existe en la raiz del proyecto
+- [ ] No hay `compatibility-mode="true"` en app.xml (anularia los CSS)
+- [ ] Unidades en `p` o `%` (NUNCA `px`, `em`, `rem`)
+- [ ] `resolution-width` y `resolution-height` coinciden con el dispositivo físico de referencia
+- [ ] Tamaños de UI usando los valores estándar documentados (TopBar=164p, Botón=124p, Campo=144p)
+- [ ] Fuentes definidas en CSS con clases `.fontN` o con `fontsize` directo en el prop
+- [ ] Colores en formato `#RRGGBB` o `#AARRGGBB` (alpha primero)
+- [ ] Selectores validos: `coll`, `group`, `frame`, `prop`, `prop:TIPO`, `.clase`
+- [ ] `extends:.clase` referencia clases existentes
+
+#### JavaScript
+- [ ] `functions.js` existe con funciones globales
+- [ ] Solo usa API documentada: `ui.*`, `appData.*`, `self.*`, `replica.*`
+- [ ] NO usa APIs del DOM: `document`, `document.getElementById`, `document.querySelector`, `window`, `localStorage`, `sessionStorage`, `XMLHttpRequest`, `navigator`, `history` (sí están disponibles `fetch`, `Promise`, `setTimeout`, `URL` con implementación custom).
+- [ ] NO usa `async`/`await` (parse error). Para asincronía prefiere callbacks idiomáticos XOne; `Promise` está disponible si el caso lo justifica.
+
+#### Unicidad de nombres (restricción crítica — AMBITO: la coll ENTERA, no el group/frame)
+
+> **PASO OBLIGATORIO antes de entregar cada `.xne`:** extraer con regex `name="([^"]+)"` todos los `name=` declarados en nodos `<group>`, `<frame>` y `<prop>` (NO contar `<field name>` de `<onchange>`, ni `name=` de la propia `<coll>`, ni el valor del atributo `fontname=`). Verificar que la lista resultante **no contiene duplicados**. Si hay alguno, renombrar — la solución canónica para campos BD que aparecen en listado + detalle con estilos distintos es declararlos UNA SOLA VEZ en el grupo detalle y añadir aliases `MAP_LIST_*` en el `sql=` para el listado (ver fila "Caso típico" de la tabla `Naming y unicidad` en SKILL.md).
+
+- [ ] No hay dos `<coll>` con el mismo `name` en el proyecto
+- [ ] No hay dos `<group>` con el mismo `name` dentro de la misma `<coll>`
+- [ ] No hay dos `<group>` con el mismo `id` dentro de la misma `<coll>`
+- [ ] No hay dos `<frame>` con el mismo `name` dentro de la misma `<coll>` (ámbito coll, NO group — un mismo nombre de frame en dos grupos distintos también colisiona)
+- [ ] No hay dos `<prop>` con el mismo `name` dentro de la misma `<coll>` — incluido el caso típico: campo BD declarado en `grpLista` (visible="2") y otra vez en `grpDetalle` (visible="1") con clase distinta. Si necesitas estilos distintos por modo, declarar el real solo en detalle y usar alias `MAP_LIST_*` en el SELECT para el listado
+- [ ] No hay dos eventos del mismo tipo (ej. dos `<before-edit>`) en la misma `<coll>`
+
+#### Estructura de carpetas
+- [ ] `bd/` existe con `README.md`
+- [ ] `icons/` existe con `README.md`
+- [ ] `files/` existe con `README.md`
+- [ ] `fonts/` existe (recomendado)
+
+#### Base de Datos
+- [ ] `gestion.db` generado con `xone_db_generator`
+- [ ] Tablas tienen prefijo `gen_` (o el especificado)
+- [ ] Empresa inicial: `CODIGO=1`, `NOMBRE="EMPRESA DE PRUEBA"`
+- [ ] Usuario admin: `CODIGO=1`, `LOGIN="admin"`, `IDEMPRESA=1`
+
+#### Recursos gráficos
+- [ ] Archivos de iconos en `icons/` en formato PNG, JPG o SVG
+- [ ] Nomenclatura consistente: `ic_` (acciones), `app_` (icono app), `avatar_` (usuarios)
+
+#### README
+- [ ] `README.md` en la raiz con descripción del proyecto
+- [ ] `README.md` en `bd/`, `icons/`, `files/`