xonecode 0.19.0 → 0.20.3

package/skills/xone-development/references/fundamentos/errores-comunes.md

@@ -300,6 +300,40 @@ Declararlas explícitamente (`<prop name="ID">` / `<prop name="ROWID">`) **no ca
 
 **Lo que NO es valido:** dos `<coll>` con el mismo `name` en el proyecto.
 
+### Error 12: Pedir un control con `getControl` cuando todavía no existe
+
+```javascript
+// MAL: en <create> la vista aún no está montada
+function calcInit() {
+    var c = getControl("MAP_EXPRESION");   // LANZA
+    c.setText("0");
+}
+```
+
+`getControl("X")` **lanza** una `IllegalArgumentException` («Cannot find control "X"») si el control no existe, y **un
+`try/catch` de JavaScript no la detiene**: viene del puente nativo, aborta el evento entero (`CXoneDataObject::OnCreate
+failed`) y deja un diálogo de error encima de la pantalla. Medido en un emulador Android.
+
+**No existen** los controles de la vista durante `<create>` (todavía no está montada) ni los hijos de un frame
+**oculto** (`visible="0"`), como un cajón cerrado.
+
+```javascript
+// BIEN: en <create> solo estado y valores
+function calcInit() {
+    self.MAP_EXPRESION = "0";
+}
+
+// BIEN: una sonda que NO lanza, para un control que puede no existir
+function calcControl(nombre) {
+    var v = ui.getView(self);
+    return v ? (v[nombre] || null) : null;   // ui.getView(self)["X"] da undefined, no lanza
+}
+```
+
+La documentación de `getControl` y la indexación de la vista (`ui.getView(self)["X"]`) las presenta como equivalentes:
+para acceder no lo son, y esa diferencia es la que evita el diálogo. **Y un texto que cambia desde JavaScript no va en
+un `L`/`TL`** (pintan su `title`): usa un `T` con `labelwidth="0"` y `locked="true"`.
+
 ---
 
 Esta guía ha cubierto los conceptos fundamentales de XOne:

package/skills/xone-hotswap/SKILL.md

@@ -26,6 +26,7 @@ No cuestan lo mismo, ni de lejos. Por orden de lo que vas a necesitar:
 |---|---|---|
 | **dónde estoy** | `screen` | una línea: colección activa, diálogos abiertos, ventana con el foco |
 | **qué está fallando** | `xone-log-android` | un error de JavaScript o una excepción salen ahí con su mensaje y su línea |
+| **qué ha pasado tras una acción** | `xone-log-android --limpiar`, la acción, `xone-log-android --app` | trae SOLO los `console.log` de la app, sus errores y qué manejador corrió (`Executing script: [MenuPrincipal][btnD8][onclick]`): casi siempre basta sin captura |
 | **el valor de un campo** | `getText name=X` | un viaje, una respuesta corta |
 | **varios campos** | `getFields names=A,B,C` | UN viaje; un campo que falle no tumba a los demás |
 | **el contenido de una lista** | `getRows content=X fields=…` | alcanza todas las filas, no solo las pintadas |
@@ -117,6 +118,7 @@ xone-hotswap waitForElement name=BTN_OK timeout=5000 -- click name=BTN_OK   # UN
 # Por qué algo no se pinta o la app se muere: las excepciones del aparato.
 xone-log-android
 xone-log-android --limpiar        # aísla lo que pase a partir de ahora
+xone-log-android --app            # SOLO los console.log de la app, sus errores y qué manejador corrió
 
 # RESPALDO de la captura, para cuando el canal no contesta: `adb exec-out screencap` pero
 # guardándola donde toca. Nunca redirijas ese `adb` tú: el `cwd` es la raíz del proyecto.

package/skills/xone-hotswap/scripts/xone-log-android

@@ -17,6 +17,7 @@
  *   xone-log-android                      errores y excepciones recientes
  *   xone-log-android --lineas 400         más cola
  *   xone-log-android --todo               todo lo del host, no solo errores
+ *   xone-log-android --app                SOLO lo que escribió la app con console.log, más sus errores
  *   xone-log-android --limpiar            vacía el buffer y sale (para aislar lo siguiente)
  *   xone-log-android --serie emulator-5554
  */
@@ -32,6 +33,7 @@ if (args.includes("--help") || args.includes("-h")) {
   xone-log-android                 errores y excepciones recientes (por omisión, 200 líneas)
   xone-log-android --lineas 400    más cola
   xone-log-android --todo          todo lo del host, no solo errores
+  xone-log-android --app           SOLO los console.log de la app (etiqueta XOneJavaScript) y sus errores
   xone-log-android --limpiar       vacía el buffer y sale, para aislar lo que pase después
   xone-log-android --serie <id>    con varios aparatos conectados
 
@@ -62,6 +64,13 @@ if (args.includes("--limpiar")) {
 
 const lineas = Number(opcion("lineas") ?? 200);
 const todo = args.includes("--todo");
+/**
+ * `--app`: lo que la APP escribió con `console.log`, y sus errores, sin el resto del host. Medido en el emulador: un
+ * `console.log("X")` de un script sale como `V XOneJavaScript: X` en el log del host, y la vista por omisión —solo
+ * errores— lo tira; `--todo` lo entierra entre cientos de líneas del sistema. `appData.writeConsoleString` (legacy) no
+ * deja nada en el log de Android. Es lo que hay que leer para saber qué ha pasado tras una acción, antes que una captura.
+ */
+const app = args.includes("--app");
 
 /** El PID del host, si está vivo. Sin él no se puede acotar por proceso: se dice y se sigue. */
 let pid;
@@ -76,7 +85,7 @@ const salida = [];
 if (pid !== undefined && pid !== "") {
   const suyo = adb("logcat", "-d", "--pid", pid, "-t", String(lineas));
   salida.push(`--- ${PAQUETE} (pid ${pid}) ---`);
-  salida.push(todo ? suyo : soloInteresante(suyo));
+  salida.push(todo ? suyo : app ? soloDeLaApp(suyo) : soloInteresante(suyo));
 } else {
   salida.push(`--- ${PAQUETE} no está vivo ahora mismo: solo queda lo que dejó escrito ---`);
 }
@@ -91,6 +100,14 @@ if (caidas !== "") {
   salida.push("", "--- caídas duras (cualquier proceso) ---", caidas);
 }
 
+/** Los `console.log` de la app (etiqueta XOneJavaScript) y los errores del host, en su orden. */
+function soloDeLaApp(texto) {
+  const filas = texto.split("\n").filter((l) => /\sXOneJavaScript\s*:/.test(l) || /\s[EF]\s/.test(l) || /Caused by:|Exception/.test(l));
+  return filas.length === 0
+    ? "(la app no ha escrito nada con console.log ni ha dado errores en esas líneas; si esperabas una línea, no se ejecutó ese código)"
+    : filas.join("\n");
+}
+
 /** Lo que merece la pena leer de un volcado del host: errores, avisos y trazas de excepción. */
 function soloInteresante(texto) {
   const filas = texto.split("\n").filter((l) => {

package/skills/xone-plan-builder/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: xone-plan-builder
-description: "Descomponer el PLAN.md (spec) de xone-spec-builder en un plan de ejecución (TASKS.md): tareas tracer-bullet verticales con dependencias explícitas. Valida el spec, descompone en cortes verticales (coll + pantalla + eventos + estilo), cada uno demoable y verificable con xone-review. Dependencias naturales XOne: mappings.xne → colls base → colls negocio → pantallas entidad → pantallas especiales → integraciones dispositivo (GPS, cámara, firma DR, escáner, biometría) → estilo → sincronización → validación. Prefactoring: reestructuras que facilitan el cambio. Refactors amplios: expand-contract. Quiz al usuario: granularidad, dependencias, partición. Tareas: una por context window, qué entrega (no cómo), bloqueada por, criterios verificables. Hitos con validación xone-review. Es análisis, no entrevista: no toma decisiones de diseño, si el spec tiene huecos lo devuelve a xone-spec-builder."
+description: "Descomponer el PLAN.md (spec) de xone-spec-builder en un plan de ejecución (TASKS.md): tareas tracer-bullet verticales con dependencias explícitas. Valida el spec, descompone en cortes verticales (coll + pantalla + eventos + estilo), cada uno demoable y comprobable en el aparato. Dependencias naturales XOne: mappings.xne → colls base → colls negocio → pantallas entidad → pantallas especiales → integraciones dispositivo (GPS, cámara, firma DR, escáner, biometría) → estilo → sincronización → validación. Prefactoring: reestructuras que facilitan el cambio. Refactors amplios: expand-contract. Quiz al usuario: granularidad, dependencias, partición. Tareas: una por context window, qué entrega (no cómo), bloqueada por, criterios verificables. Hitos que cierran con una comprobación en el aparato. Es análisis, no entrevista: no toma decisiones de diseño, si el spec tiene huecos lo devuelve a xone-spec-builder."
 ---
 
 # XOne Plan Builder
@@ -17,7 +17,7 @@ Esta skill es **análisis y descomposición**, no entrevista. No afina el domini
 xone-spec-builder  →  PLAN.md (el spec)
 xone-plan-builder   →  TASKS.md (el plan de ejecución)  ← esta skill
 xone-project-generator  /  xone-development  →  ejecutan una tarea cada vez
-xone-review             →  valida con xone-simulator
+arnés + device-controller →  valida: el verificador al cerrar el turno, el aparato con toques reales
 ```
 
 ## Estructura de archivos
@@ -79,7 +79,7 @@ Si algo falta, no lo inventes: devuelve a `xone-spec-builder` con una nota espec
 Una tarea es un **corte vertical** que atraviesa todas las capas que necesite para entregar un comportamiento completo y verificable:
 
 - **Vertical, no horizontal.** «Crear coll Clientes + su pantalla de lista + su pantalla de edición + su estilo» es vertical. «Crear todas las colls» es horizontal —no es una tarea, es una capa.
-- **Demoable o verificable por sí sola.** Al cerrar la tarea, hay algo que funciona de principio a fin y se puede validar con `xone-review`.
+- **Demoable o verificable por sí sola.** Al cerrar la tarea, hay algo que funciona de principio a fin y se puede comprobar: el verificador del arnés (corre `xone-simulator validate` solo, al cerrar cada turno que escribió) y la comprobación en el aparato de `device-controller`.
 - **Cabe en una sesión de agente.** Si una tarea es tan grande que no cabe en un context window, pártela.
 - **Declara sus dependencias.** Qué tareas deben cerrarse antes de que ésta pueda empezar.
 
@@ -104,7 +104,7 @@ El orden de ejecución sigue las dependencias del framework:
    ↓  — puede ir en paralelo desde el principio; ajuste fino al final
 8. Sincronización y seguridad               (réplica, OAuth2, tokens…)
    ↓  — si el desarrollo la toca
-9. Validación con xone-review               (xone-simulator validate + smoke)
+9. Comprobación en el aparato               (device-controller; el verificador del arnés corre solo)
 ```
 
 ### Reglas de secuenciación
@@ -115,7 +115,7 @@ El orden de ejecución sigue las dependencias del framework:
 - **El comportamiento se comprueba ANTES que el pulido.** En una pantalla interactiva, la tarea «la app reacciona a un toque» —una captura antes y otra después de la zona que debe cambiar— va justo detrás del esqueleto visual y antes de cualquier tarea de aspecto fino. Si no, se pule algo que no funciona: medido, un display que no se repintaba vivió siete pasadas de retoques visuales.
 - **Estilo en paralelo.** `default.css` con las clases base puede empezar desde la tarea 1, pero el ajuste fino de pantallas específicas va después de que la pantalla exista.
 - **Integraciones después de su contenedor.** La firma DR en Pedidos va en una tarea que depende de que Pedidos (coll + pantalla de edición) ya exista.
-- **Validación al final de cada hito.** Si el plan tiene varios hitos, cada uno cierra con una tarea de validación `xone-review`.
+- **Comprobación al final de cada hito.** Si el plan tiene varios hitos, cada uno cierra con una tarea de comprobación en el aparato (`device-controller`); la validación estática la hace el verificador del arnés solo.
 
 ### Prefactoring
 
@@ -128,7 +128,7 @@ Solo propón prefactor si el spec lo justifica o si al leer el proyecto existent
 Un **refactor amplio** es un cambio mecánico cuyo **radio de explosión** cubre todo el proyecto —renombrar una coll, cambiar el tipo de un campo compartido, migrar de `load` a `before-edit` en todas las colls—. No se puede partir en un corte vertical porque un solo edit rompe miles de sitios. Secuenciálo como **expand–contract**:
 
 1. **Expand:** añade la nueva forma junto a la vieja, sin romper nada.
-2. **Migra** los sitios de uso en lotes (por carpeta, por módulo), cada lote su propia tarea bloqueada por el expand, manteniendo `xone-review` verde lote a lote.
+2. **Migra** los sitios de uso en lotes (por carpeta, por módulo), cada lote su propia tarea bloqueada por el expand, manteniendo el verificador del arnés en verde lote a lote.
 3. **Contract:** borra la forma vieja cuando nadie la usa, en una tarea bloqueada por todos los lotes.
 
 Si el spec no describe un refactor amplio, no lo fuerces. Es excepción, no regla.
@@ -182,7 +182,7 @@ Ver [TASKS-FORMAT.md](references/TASKS-FORMAT.md) para la plantilla completa. Re
 
 ## Hitos
 
-{si aplica: qué conjunto de tareas forma un hito verificable con xone-review}
+{si aplica: qué conjunto de tareas forma un hito comprobable en el aparato}
 ```
 
 ## Reglas
@@ -192,7 +192,7 @@ Ver [TASKS-FORMAT.md](references/TASKS-FORMAT.md) para la plantilla completa. Re
 - **Nombres consistentes con el spec**, y el `MAP_` según `xone-development`.
 - **No inventes lo que el spec no dice.** Si falta algo para descomponer, devuelve a `xone-spec-builder`.
 - **Evita rutas de archivo o snippets de código específicos** —envejecen rápido. Excepción: si un prototipo o el spec produjo un snippet que codifica una decisión más preciso que prosa (esquema, state machine), inclúyelo y nota su origen.
-- **La validación es una tarea.** Si el plan tiene hitos, cada hito cierra con una tarea `xone-review`. Si no, al menos una tarea de validación al final.
+- **La comprobación es una tarea.** Si el plan tiene hitos, cada hito cierra con una tarea de comprobación en el aparato. Si no, al menos una al final. No nombres herramientas que no estén en las skills de los especialistas: quien ejecuta las buscará.
 
 ## Cierre
 
@@ -203,9 +203,9 @@ Antes de entregar `TASKS.md`:
 - [ ] El orden de ejecución respeta las dependencias naturales de XOne (mappings → colls → pantallas → integraciones → estilo → validación).
 - [ ] No hay tareas que dependan de cosas que el spec no especifica —o están marcadas como notas.
 - [ ] El usuario aprobó el desglose.
-- [ ] Las tareas de validación `xone-review` están en su sitio.
+- [ ] Las tareas de comprobación en el aparato están en su sitio.
 
-Al entregar, señala el siguiente paso: `xone-project-generator` (app nueva) o `xone-development` (sobre existente) ejecutan una tarea cada vez, y `xone-review` valida los hitos.
+Al entregar, señala el siguiente paso: `xone-project-generator` (app nueva) o `xone-development` (sobre existente) ejecutan una tarea cada vez, y el verificador del arnés (al cerrar cada turno) y device-controller en el aparato validan los hitos.
 
 ## Referencias
 

package/skills/xone-plan-builder/references/TASKS-FORMAT.md

@@ -43,13 +43,13 @@
 6. 06 — Integración GPS + ClientesMapa (bloqueada por 02)
 7. 07 — Firma DR en Pedidos (bloqueada por 03)
 8. 08 — Estilo: default.css completo + variantes (en paralelo desde 01)
-9. 09 — Validación xone-review (bloqueada por 02-08)
+9. 09 — Comprobación en el aparato con device-controller (bloqueada por 02-08)
 
 ## Hitos
 
 {si aplica: qué conjunto de tareas forma un hito verificable. Ejemplo:}
 
-- **Hito 1 — CRUD básico:** tareas 01-04. Al cerrar, validar con xone-review.
+- **Hito 1 — CRUD básico:** tareas 01-04. Al cerrar, comprobarlo en el aparato con device-controller.
 - **Hito 2 — App completa:** tareas 05-09. Validación final.
 ```
 
@@ -83,9 +83,9 @@ y quien empiece un encargo con este plan lo lee primero. Ejemplo:}
 - **Decisiones, no código.** Sin XML/JS/CSS pegado. Excepción: si un snippet codifica una decisión más preciso que prosa (esquema, state machine), inclúyelo y nota su origen.
 - **Nombres consistentes con el spec**, y el `MAP_` según `xone-development`.
 - **Evita rutas de archivo específicas.** Envejecen rápido. El ejecutor las infiere del spec y del proyecto.
-- **Criterios de aceptación verificables.** Cada criterio debe poder comprobarse —con `xone-review`, con un smoke, o con un comportamiento observable.
+- **Criterios de aceptación verificables.** Cada criterio debe poder comprobarse —en el aparato con un toque y lo que dice el log, o con un comportamiento observable.
 - **El comportamiento antes que el pulido.** En una pantalla interactiva, «reacciona a un toque» (captura antes y después) va tras el esqueleto visual y antes del aspecto fino.
-- **La validación es una tarea.** Cada hito cierra con una tarea `xone-review`, o al menos una al final del plan.
+- **La comprobación es una tarea.** Cada hito cierra con una tarea de comprobación en el aparato (`device-controller`). La validación estática no es una tarea: la hace el verificador del arnés solo, al cerrar cada turno. No nombres herramientas que no estén en esta skill ni en las de los especialistas: quien ejecuta las buscará.
 
 ## Ejemplo: feature sobre existente
 
@@ -136,5 +136,5 @@ Antes de entregar el plan:
 - [ ] El orden respeta las dependencias naturales de XOne (mappings → colls → pantallas → integraciones → estilo → validación).
 - [ ] No hay tareas que dependan de cosas que el spec no especifica —o están marcadas como notas.
 - [ ] El usuario aprobó el desglose.
-- [ ] Las tareas de validación xone-review están en su sitio.
+- [ ] Las tareas de comprobación en el aparato están en su sitio.
 - [ ] Los hitos (si los hay) están definidos y cierran con validación.

package/skills/xone-spec-builder/SKILL.md

@@ -18,7 +18,7 @@ El spec builder es el primer paso de cualquier trabajo XOne. Lo que sigue:
 - **`xone-plan-builder`** lee el `PLAN.md` y lo descompone en tareas tracer-bullet con dependencias (`TASKS.md`).
 - **App nueva** → `xone-project-generator` lee el `PLAN.md` y genera el proyecto completo.
 - **Feature, refactor, integración, cambio de modelo, rediseño** sobre un proyecto existente → `xone-development` aplica el `PLAN.md` sobre los `.xne`, `.js` y `.css` que ya viven en el repo.
-- **Validación final** → `xone-review` con `xone-simulator` en ambos casos.
+- **Validación final** → el verificador del arnés (corre `xone-simulator validate` solo, al cerrar cada turno que escribió) y la comprobación en el aparato de `device-controller`, en ambos casos.
 
 `xone-spec-builder` es **especificación**: produce decisiones de diseño y un spec, no código ni tareas. La tentación de empezar a generar archivos o a descomponer el trabajo es la señal de que has llegado al borde del spec; para ahí y entrega el `PLAN.md`.
 
@@ -76,7 +76,7 @@ No toda petición necesita una entrevista de 8 rounds. Antes de empezar, clasifi
 
 | Nivel | Cuándo | Qué hace el spec-builder |
 |---|---|---|
-| **Trivial** | Una sola acción mecánica, sin decisiones de diseño. Ej: «añadir un prop EMAIL (T) a Clientes», «cambiar el color del header», «añadir un botón de salir». | **No produces PLAN.md.** Confirmas la petición en 1-2 preguntas, ejecutas con `xone-development` o `xone-project-generator` directamente, y validas con `xone-review`. Sin `CONTEXT.md` ni ADRs. |
+| **Trivial** | Una sola acción mecánica, sin decisiones de diseño. Ej: «añadir un prop EMAIL (T) a Clientes», «cambiar el color del header», «añadir un botón de salir». | **No produces PLAN.md.** Confirmas la petición en 1-2 preguntas, ejecutas con `xone-development` o `xone-project-generator` directamente; lo valida el verificador del arnés (al cerrar cada turno) y device-controller en el aparato. Sin `CONTEXT.md` ni ADRs. |
 | **Simple** | Un cambio acotado con alguna decisión menor. Ej: «añadir campo IVA a LineasPedido con formula», «pasar Clientes a mapa», «añadir escáner QR en una pantalla». | **Spec ligero.** Entrevista reducida: solo los rounds que apliquen (típicamente 1, 3 y/o 4 y/o 5). `PLAN.md` en formato condensado —una sección por round, sin secciones vacías—. `CONTEXT.md` solo si hay término de dominio nuevo; ADR solo si hay decisión dura. |
 | **Normal** | Feature con varias colls/pantallas, refactor, integración multi-pantalla. Ej: «firma de entrega en Pedidos», «login con OAuth2», «módulo de incidencias con fotos». | **Spec completo.** Entrevista con los rounds que apliquen al tipo. `PLAN.md` con las secciones condicionales del formato. `CONTEXT.md` y ADRs según se resuelvan. |
 | **Grande** | App nueva completa, re-arquitectura, o un desarrollo que no cabe en una sesión de plan-builder. | **Spec completo + considerar wayfinder.** Entrevista los 8 rounds. Si el scope es tan grande que ni el spec cabe en una sesión, considera dividir el esfuerzo con un enfoque tipo wayfinder (chart el mapa de decisiones primero, luego spec por contexto). |
@@ -209,7 +209,7 @@ Revisa el `PLAN.md` completo contra el checklist de [PLAN-FORMAT.md](references/
 - ¿Los términos de dominio nuevos están en `CONTEXT.md` y las decisiones duras en ADRs?
 - ¿Quedan preguntas abiertas? Márcalas en `PLAN.md` §Pendientes; no las resuelvas tú.
 
-Si falta algo, vuelve al round correspondiente. Si todo está, entrega el spec y señala el siguiente paso: `xone-plan-builder` para descomponer en tareas, después `xone-project-generator` (app nueva) o `xone-development` (sobre existente), y `xone-review` para validar al final.
+Si falta algo, vuelve al round correspondiente. Si todo está, entrega el spec y señala el siguiente paso: `xone-plan-builder` para descomponer en tareas, después `xone-project-generator` (app nueva) o `xone-development` (sobre existente), y el verificador del arnés (al cerrar cada turno) y device-controller en el aparato para validar.
 
 ## Disciplina durante la entrevista