@rlabs-cl/arketum 0.0.0-stage → 1.0.1

package/catalogo-de-ejemplo/carriles/despliegue.yaml

@@ -0,0 +1,36 @@
+# Desplegar es parte del trabajo guiado. Antes de preparar el despliegue hay un
+# levantamiento completo de la infraestructura (que puede quedar pendiente: el
+# cuestionario lo genera Arketum y se escribe fuera del repositorio); el modo se
+# elige después de entender; el despliegue es un artefacto del sistema
+# (`despliegue-compose` en este catálogo), y el hito lo cumple la persona al
+# confirmar que se desplegó y corrió.
+#
+# Cambios:
+# - 1.1.0: el hito `despliegue <entorno>` lo cumple la confirmación de la persona por el canal interactivo («¿se desplegó en <entorno> y corrió?», sí o no): la marca `humo` pasa a llamarse `confirmacion` y la prueba de humo deja de exigirse.
+name: despliegue
+version: 1.1.0
+when: Desplegar un sistema que existe por primera vez, en un entorno nuevo, o cambiar lo acordado de un entorno.
+milestones: [despliegue]
+steps:
+  # El levantamiento de infraestructura: los papeles de la fase 1, con la instrucción del nivel por delante en lo técnico.
+  - { id: infraestructura, kind: artifact, archetype: { name: levantamiento-de-infraestructura }, gate: true, pendientes: true, feeds: [sistema, preparado] }
+  # Añade el artefacto de despliegue al proyecto si todavía no existe.
+  - { id: arquitectura, kind: artifact, archetype: { name: arquitectura-de-sistema }, optional: true, gate: true }
+  # Publica el arquetipo de un modo que no está en los catálogos (pipeline, script…).
+  - { id: arquetipo, kind: artifact, archetype: { name: arquetipo-autor }, optional: true, gate: true }
+  - { id: sistema, kind: system, fedBy: [infraestructura] }
+  - id: preparado
+    kind: evidence
+    fedBy: [infraestructura]
+    # Además, la verificación de cada referencia verificable del levantamiento (`infraestructura/<id>`, `on: entorno`).
+    requires:
+      - { id: validacion, describes: "la validación en seco de la definición del despliegue (en el compose, `docker compose -f despliegue/compose.yaml config --quiet`)", classes: [execution], expect: success, on: change }
+  - id: hito
+    kind: milestone
+    optional: true
+    gate: true
+    # `despliegue <entorno>`: exige la confirmación de la persona por el canal interactivo
+    # (`despliegue/<entorno>/confirmacion`: «¿se desplegó en <entorno> y corrió?», sí o no); una ejecución
+    # o un reporte del CI son respaldo opcional. No se completa mientras una decisión de antes de
+    # desplegar ese entorno siga por decidir.
+    confirmacion: true

package/catalogo-de-ejemplo/carriles/digestion.yaml

@@ -0,0 +1,14 @@
+# Digerir un código que ya existe: proponer su estructura base (los artefactos
+# con su stack y su componente o su arquetipo, la forma con su variante y sus
+# escalones, el andamiaje y la cobertura), que la persona confirma en el gate.
+# Al aprobarse, Arketum la escribe en `proyecto.yaml` sin fijar tocados ni
+# cambiar código; no infiere requisitos funcionales. En un proyecto que ya tiene
+# artefactos, legaliza lo que está fuera de lo declarado (y retira artefactos sin
+# raíz, sin unidad viva y sin requisitos).
+name: digestion
+version: 1.0.0
+when: Un código que ya existe sin la estructura base de Arketum, o lo que está fuera de lo declarado en un proyecto que ya la tiene.
+milestones: []
+steps:
+  - { id: digestion, kind: artifact, archetype: { name: digestion }, gate: true, digestion: true }
+  - { id: arquetipo, kind: artifact, archetype: { name: arquetipo-autor }, optional: true, gate: true }

package/catalogo-de-ejemplo/carriles/funcionalidad.yaml

@@ -0,0 +1,34 @@
+# Una funcionalidad en un sistema que existe: se pide (PRD), se acota (radio de
+# alcance) y se construye en los artefactos tocados, con aceptación y sin
+# regresiones.
+#
+# Cambios:
+# - 1.2.0: la aceptación exige además las salidas de los tocados (`salidas: true`).
+# - 1.3.0: el hito `despliegue <entorno>` cuenta (`humo: true`): exige la prueba de humo y que el entorno exista.
+# - 1.4.0: el hito `despliegue <entorno>` lo cumple la confirmación de la persona por el canal interactivo («¿se desplegó en <entorno> y corrió?», sí o no): la marca `humo` pasa a llamarse `confirmacion` y la prueba de humo deja de exigirse.
+# - 1.5.0: el radio de alcance y la arquitectura opcional son gates del proceso (`gate: proceso`): una delegación de la persona los aprueba; lo que se construye (el PRD) y el hito siguen siendo de ella.
+name: funcionalidad
+version: 1.5.0
+when: Añadir o cambiar una funcionalidad de un sistema que ya existe.
+milestones: [despliegue, entrega, ejecucion]
+steps:
+  - { id: prd, kind: artifact, archetype: { name: prd }, gate: true, levantamiento: true, feeds: [sistema] }
+  - { id: radio-de-alcance, kind: artifact, archetype: { name: radio-de-alcance }, gate: proceso, feeds: [sistema] }
+  - { id: arquitectura, kind: artifact, archetype: { name: arquitectura-de-sistema }, optional: true, gate: proceso }
+  - { id: arquetipo, kind: artifact, archetype: { name: arquetipo-autor }, optional: true, gate: true }
+  - { id: sistema, kind: system, fedBy: [prd, radio-de-alcance] }
+  - id: aceptacion
+    # Además de lo suyo, las salidas de cada tocado cuyo arquetipo efectivo las pide:
+    # el suelo y la suite e2e entera, con sus comandos compuestos (`salidas/<artefacto>/…`).
+    salidas: true
+    kind: evidence
+    requires:
+      - { id: aceptacion, describes: la funcionalidad hace lo que pide el PRD, classes: [execution], expect: success }
+      - { id: no-regresion, describes: lo que ya funcionaba sigue funcionando, classes: [execution], expect: success }
+  - id: hito
+    kind: milestone
+    optional: true
+    gate: true
+    confirmacion: true
+    requires:
+      - { id: cumplido, describes: la persona confirma que el hito se cumplió, classes: [statement] }

package/catalogo-de-ejemplo/carriles/migracion.yaml

@@ -0,0 +1,27 @@
+# Una migración: qué hace hoy el sistema, cómo se mueve (el plan fija los
+# tocados) y la evidencia de que funciona después. El inventario lo aprueba la
+# persona y alimenta al sistema: lo que hoy hace el sistema lo tiene que atender
+# lo migrado, y sus funciones pueden sembrar el índice de requisitos.
+#
+# Cambios:
+# - 1.2.0: el hito `despliegue <entorno>` cuenta (`humo: true`): exige la prueba de humo y que el entorno exista.
+# - 1.3.0: el hito `despliegue <entorno>` lo cumple la confirmación de la persona por el canal interactivo («¿se desplegó en <entorno> y corrió?», sí o no): la marca `humo` pasa a llamarse `confirmacion` y la prueba de humo deja de exigirse.
+name: migracion
+version: 1.3.0
+when: Llevar un sistema existente a otra forma, plataforma o arquitectura sin perder lo que hace.
+milestones: [despliegue, entrega, ejecucion]
+steps:
+  - { id: inventario, kind: artifact, archetype: { name: inventario-funcional }, gate: true, feeds: [sistema] }
+  - { id: plan, kind: artifact, archetype: { name: plan-de-migracion }, gate: true, fixesTouches: true, feeds: [sistema] }
+  - { id: sistema, kind: system, fedBy: [inventario, plan] }
+  - id: evidencia
+    kind: evidence
+    requires:
+      - { id: funciona, describes: lo migrado hace lo que hacía, classes: [execution], expect: success }
+  - id: hito
+    kind: milestone
+    optional: true
+    gate: true
+    confirmacion: true
+    requires:
+      - { id: cumplido, describes: la persona confirma que el hito se cumplió, classes: [statement] }

package/catalogo-de-ejemplo/carriles/nuevo.yaml

@@ -0,0 +1,30 @@
+# Un producto nuevo: del PRD a la arquitectura, que fija los artefactos, y de
+# ahí al sistema, aceptado con evidencia.
+#
+# Cambios:
+# - 1.2.0: la aceptación exige además las salidas de los tocados (`salidas: true`).
+# - 1.3.0: el hito `despliegue <entorno>` cuenta (`humo: true`): exige la prueba de humo y que el entorno exista.
+# - 1.4.0: el hito `despliegue <entorno>` lo cumple la confirmación de la persona por el canal interactivo («¿se desplegó en <entorno> y corrió?», sí o no): la marca `humo` pasa a llamarse `confirmacion` y la prueba de humo deja de exigirse.
+name: nuevo
+version: 1.4.0
+when: Un producto o sistema que todavía no existe, sin proyecto que tocar.
+milestones: [despliegue, entrega, ejecucion]
+steps:
+  - { id: prd, kind: artifact, archetype: { name: prd }, gate: true, levantamiento: true, feeds: [sistema] }
+  - { id: arquitectura, kind: artifact, archetype: { name: arquitectura-de-sistema }, gate: true, fixesTouches: true }
+  - { id: arquetipo, kind: artifact, archetype: { name: arquetipo-autor }, optional: true, gate: true }
+  - { id: sistema, kind: system, fedBy: [prd] }
+  - id: aceptacion
+    # Además de lo suyo, las salidas de cada tocado cuyo arquetipo efectivo las pide:
+    # el suelo y la suite e2e entera, con sus comandos compuestos (`salidas/<artefacto>/…`).
+    salidas: true
+    kind: evidence
+    requires:
+      - { id: aceptacion, describes: el producto hace lo que pide el PRD, classes: [execution, statement], expect: success }
+  - id: hito
+    kind: milestone
+    optional: true
+    gate: true
+    confirmacion: true
+    requires:
+      - { id: cumplido, describes: la persona confirma que el hito se cumplió, classes: [statement] }

package/catalogo-de-ejemplo/formas/aplicacion-por-capas.yaml

@@ -0,0 +1,185 @@
+# Forma de sistema: una aplicación de un solo despliegue, con datos que
+# persisten o con varias pantallas o actores.
+#
+# Cambios:
+# - 1.2.0: los papeles de la fase 2 (`implementador` y `revisor`) y las
+#   salidas (`suelo` y `e2e`) en las dos variantes; el contrato de arranque
+#   en el `oficio` del componente.
+# - 1.1.0: señales `pantallas` y `actores`; variantes (`simple` y `completa`,
+#   con el componente `aplicacion`) y los escalones `varios-actores`,
+#   `varias-pantallas` e `integraciones`. Un artefacto con capas declara `stack`
+#   y `componente: aplicacion`; la profundidad la pone la variante.
+name: aplicacion-por-capas
+version: 1.2.0
+description: >-
+  Una aplicación de un solo despliegue con datos que persisten, o con varias pantallas o actores: sus reglas separadas de cómo se guardan los datos y de cómo se usa.
+orden: 2
+senales:
+  despliegues: numero
+  integraciones: numero
+  pantallas: numero
+  actores: numero
+aplica:
+  - [despliegues, '<=', 1]
+  - [integraciones, '<=', 3]
+diseno:
+  - Una sola aplicación, con sus reglas separadas de cómo se guardan los datos y de cómo se usa (pantallas o comandos).
+  - Lo que se guarda sobrevive a cerrar y volver a abrir; si no se puede leer, se avisa y no se sigue con vacío ni se sobrescribe.
+  - Las reglas que dependen del tiempo reciben el instante; no dependen de cuándo se ejecutan.
+huecos:
+  - Qué datos se guardan, de dónde salen los primeros y qué tiene que seguir ahí al cerrar y volver a abrir.
+  - Qué se calcula a partir del tiempo (días, semanas, cambios de fecha) y desde cuándo cuenta.
+  - Quién la usa, para qué cada uno, y qué puede cambiar cada uno.
+  - Qué hay que poder corregir cuando alguien se equivoca, y si importa lo que había antes.
+  - Qué pasa si los datos guardados se estropean o no se pueden leer.
+
+variantes:
+  - nombre: simple
+    aplica:
+      - [actores, '<=', 1]
+      - [pantallas, '<=', 2]
+    papeles: &papeles
+      - nombre: implementador
+        para_que: construye el sistema en el paso de sistema (el código, sus pruebas y las salidas que exige el paso de evidencia)
+        texto: >-
+          PAPEL: IMPLEMENTADOR (fase 2). Construyes lo acordado, nada más: los requisitos que trae la unidad y los técnicos vigentes, con el oficio del arquetipo.
+          Desciendes cada artefacto tocado nivel a nivel y el código se queda como lo pide su stack; no lo deformas para encajar.
+          Cada funcional que construyes lleva su prueba de extremo a extremo, que arranca el artefacto por su contrato de arranque y lo usa como una persona:
+          una prueba que llama por dentro a una función que el camino real no usa no demuestra nada.
+          Copias las fijaciones del catálogo tal cual y no las editas. Corres tú las pruebas, el suelo y la suite e2e entera, y vinculas cada ejecución
+          a sus requisitos con `satisfies`. No rebajas ni borras una prueba para que pase. Si algo que funcionaba se rompe, lo arreglas;
+          si no puedes, lo reportas con `solicitar` (`pide: defecto`) y decide la persona. Nunca lo escondes.
+      - nombre: revisor
+        para_que: revisa en el paso de evidencia que lo construido funciona por el camino real, antes de entregar la evidencia
+        texto: >-
+          PAPEL: REVISOR (fase 2). No escribes el código: lo revisas como lo usaría la persona. Compruebas que cada funcional construido tiene su prueba e2e,
+          que arranca el artefacto por su contrato de arranque y no lo llama por dentro, y que pasa; que las fijaciones del catálogo no se tocaron;
+          y miras las pruebas modificadas o borradas desde la foto (las lista el resumen del paso): si alguna se rebajó para que pase, lo dices.
+          Corres el suelo y la suite e2e entera con el comando compuesto exacto y entregas esa evidencia. Lo que falla no lo das por bueno:
+          se arregla, o se reporta como defecto con `solicitar` y decide la persona. Si un funcional no admite una prueba automática
+          (un correo, algo visual, una integración externa), lo pides con `solicitar` (`pide: sin_e2e`), con el motivo.
+    salidas: { suelo: true, e2e: true }
+    componentes:
+      - nombre: aplicacion
+        oficio: &oficio
+          - "Arranque: la aplicación se lanza con `sh arrancar.sh` desde la raíz del artefacto, en una terminal. Recibe del entorno `DATOS_DIR` (la carpeta de sus datos) y `PUERTO` (si sirve HTTP, escucha en 127.0.0.1 en ese puerto). Escribe en la terminal qué es y cómo se sale, responde a lo que se teclea, termina limpio (código 0) con `q`, con `salir` y Enter o al cerrarse la entrada, y vuelve a arrancar con los datos que dejó."
+        description: >-
+          La aplicación entera, en tres peldaños: lo que se pide, sus capas y el código, con el dominio separado del almacén y de la interfaz.
+        kinds:
+          - { name: objetivo, describes: "pieza de la solicitud (L0), sin ubicación en el árbol", ubicado: false }
+          - { name: modulo, describes: la definición del paquete o del módulo, ubicado: true }
+          - { name: dominio, describes: "las entidades y sus reglas, puras: sin ficheros, sin interfaz y sin leer el reloj", ubicado: true }
+          - { name: almacen, describes: guardar y cargar el estado, ubicado: true }
+          - { name: servicio, describes: "un caso de uso por acción, sobre el dominio y el almacén, sin interfaz", ubicado: true }
+          - { name: interfaz, describes: "la presentación y la lectura de órdenes; llama a los servicios", ubicado: true }
+          - { name: cliente, describes: el único sitio que habla con otro sistema, ubicado: true }
+          - { name: arranque, describes: "compone almacén, servicios e interfaz y arranca", ubicado: true }
+          - { name: prueba, describes: fichero de prueba, ubicado: true }
+        coRequirements:
+          - { when: servicio, requires: [prueba] }
+        levels:
+          - id: L0
+            requiredRoles: []
+            title: SOLICITUD
+            instruction: Declara qué tiene que hacer la aplicación, para quién y qué tiene que seguir ahí al cerrarla y volver a abrirla.
+          - id: L1
+            requiredRoles: []
+            title: CAPAS
+            instruction: Propón las piezas por capa (dominio, almacén, servicios, interfaz, arranque), con el dominio sin ficheros ni interfaz.
+            fanout: { min: 3, max: 16 }
+          - id: L2
+            requiredRoles: []
+            title: IMPLEMENTACIÓN
+            instruction: Escribe el código; cada servicio con su prueba, que no abre la interfaz.
+            fanout: { min: 1, max: 60 }
+        selfReview:
+          criteria:
+            - check: La interfaz solo llama a los servicios; nunca al almacén ni a ficheros
+              how: Busca en la interfaz cualquier uso del almacén o de ficheros.
+              evidence: medida
+            - check: Lo que se guarda sobrevive a cerrar y volver a abrir, y un fallo al leerlo se avisa
+              how: Lee la prueba que guarda, vuelve a cargar y la que lee un fichero estropeado.
+              evidence: medida
+  - nombre: completa
+    aplica: []
+    papeles: *papeles
+    salidas: { suelo: true, e2e: true }
+    componentes:
+      - nombre: aplicacion
+        oficio: *oficio
+        description: >-
+          La aplicación entera, en cinco peldaños: lo que se pide, sus capas, sus contratos, el cableado y el código.
+        kinds:
+          - { name: objetivo, describes: "pieza de la solicitud (L0), sin ubicación en el árbol", ubicado: false }
+          - { name: modulo, describes: la definición del paquete o del módulo, ubicado: true }
+          - { name: dominio, describes: "las entidades y sus reglas, puras: sin ficheros, sin interfaz y sin leer el reloj", ubicado: true }
+          - { name: almacen, describes: guardar y cargar el estado, ubicado: true }
+          - { name: servicio, describes: "un caso de uso por acción, sobre el dominio y el almacén, sin interfaz", ubicado: true }
+          - { name: interfaz, describes: "la presentación y la lectura de órdenes; llama a los servicios", ubicado: true }
+          - { name: cliente, describes: el único sitio que habla con otro sistema, ubicado: true }
+          - { name: arranque, describes: "compone almacén, servicios e interfaz y arranca", ubicado: true }
+          - { name: prueba, describes: fichero de prueba, ubicado: true }
+          - { name: dependencia, describes: "arista del cableado (L3) entre dos piezas declaradas", ubicado: false }
+        coRequirements:
+          - { when: servicio, requires: [prueba] }
+          - { when: almacen, requires: [prueba] }
+        levels:
+          - id: L0
+            requiredRoles: []
+            title: SOLICITUD
+            instruction: Declara qué tiene que hacer la aplicación, para quién y qué tiene que seguir ahí al cerrarla y volver a abrirla.
+          - id: L1
+            requiredRoles: []
+            title: CAPAS
+            instruction: Propón las piezas por capa (dominio, almacén, servicios, interfaz, arranque), con el dominio sin ficheros ni interfaz.
+            fanout: { min: 3, max: 20 }
+          - id: L2
+            requiredRoles: []
+            title: CONTRATOS
+            instruction: Declara cada caso de uso con lo que recibe, lo que devuelve y cómo falla; y qué guarda el almacén.
+            fanout: { min: 1, max: 40 }
+          - id: L3
+            requiredRoles: []
+            title: CABLEADO
+            instruction: Declara qué depende de qué; el dominio no depende de nadie y la interfaz solo de los servicios.
+            fanout: { min: 1, max: 50 }
+          - id: L4
+            requiredRoles: []
+            title: IMPLEMENTACIÓN
+            instruction: Escribe el código; cada servicio y el almacén con su prueba, que no abre la interfaz.
+            fanout: { min: 1, max: 90 }
+        selfReview:
+          criteria:
+            - check: La interfaz solo llama a los servicios; nunca al almacén ni a ficheros
+              how: Sigue las dependencias declaradas en L3 desde la interfaz.
+              evidence: medida
+            - check: Lo que se guarda sobrevive a cerrar y volver a abrir, y un fallo al leerlo se avisa
+              how: Lee la prueba que guarda, vuelve a cargar y la que lee un fichero estropeado.
+              evidence: medida
+
+escalones:
+  - nombre: varios-actores
+    cuando:
+      - [actores, '>=', 2]
+    diseno:
+      - Cada actor tiene su vía y solo ve lo suyo; lo que es de gestión no se mezcla con el uso diario.
+    huecos:
+      - Qué puede hacer cada actor y qué no, y cómo se sabe quién es.
+    oficio:
+      - Cada actor tiene su vía en la interfaz; lo que es de gestión no se mezcla con el uso diario.
+  - nombre: varias-pantallas
+    cuando:
+      - [pantallas, '>=', 3]
+    oficio:
+      - Cada pantalla es una función de la interfaz con su propia lectura de órdenes; un mismo menú no se copia en varios sitios.
+  - nombre: integraciones
+    cuando:
+      - [integraciones, '>=', 1]
+    diseno:
+      - Cada sistema ajeno se usa a través de un solo sitio, que se puede sustituir por un doble para probar.
+    huecos:
+      - Qué pasa cuando el otro sistema falla, tarda o responde algo inesperado.
+    oficio:
+      - Cada cliente de otro sistema tiene un doble para probar sin el sistema real, que cubre el fallo y la demora.
+    coRequirements:
+      - { when: cliente, requires: [prueba] }

package/catalogo-de-ejemplo/formas/juego-terminal.yaml

@@ -0,0 +1,161 @@
+# Forma de sistema: un juego de una pantalla en la terminal, para una persona,
+# sin datos que guardar.
+#
+# Cambios:
+# - 1.2.0: los papeles de la fase 2 (`implementador` y `revisor`) y las
+#   salidas (`suelo` y `e2e`) en las dos variantes; el contrato de arranque
+#   en el `oficio` del componente.
+# - 1.1.0: variantes (`simple` y `completa`, con el componente `juego`) y el
+#   escalón `varias-pantallas`. Un artefacto con capas declara `stack` y
+#   `componente: juego`; la profundidad la pone la variante.
+name: juego-terminal
+version: 1.2.0
+description: >-
+  Un juego de una pantalla en la terminal, para una persona, sin datos que guardar entre partidas ni otros sistemas.
+orden: 1
+senales:
+  pantallas: numero
+  actores: numero
+  persistencia: booleano
+  integraciones: numero
+  despliegues: numero
+aplica:
+  - [pantallas, '<=', 3]
+  - [actores, '<=', 1]
+  - [persistencia, '==', false]
+  - [integraciones, '==', 0]
+  - [despliegues, '<=', 1]
+diseno:
+  - Un solo programa de una pantalla, sin datos que guardar entre partidas.
+  - La lógica del juego (estado, reglas, puntuación) está separada de cómo se dibuja y de cómo se leen las teclas.
+huecos:
+  - Con qué teclas se juega y cómo se sale.
+  - Cómo empieza y cómo termina una partida, y qué se ve al terminar.
+  - Contra quién o qué se juega y qué lo hace más difícil.
+  - En qué tamaño de pantalla tiene que caber y qué pasa si no cabe.
+
+# De la más simple a la más completa: vale la primera cuyo `aplica` se cumple.
+variantes:
+  - nombre: simple
+    aplica:
+      - [pantallas, '<=', 1]
+    papeles: &papeles
+      - nombre: implementador
+        para_que: construye el sistema en el paso de sistema (el código, sus pruebas y las salidas que exige el paso de evidencia)
+        texto: >-
+          PAPEL: IMPLEMENTADOR (fase 2). Construyes lo acordado, nada más: los requisitos que trae la unidad y los técnicos vigentes, con el oficio del arquetipo.
+          Desciendes cada artefacto tocado nivel a nivel y el código se queda como lo pide su stack; no lo deformas para encajar.
+          Cada funcional que construyes lleva su prueba de extremo a extremo, que arranca el artefacto por su contrato de arranque y lo usa como una persona:
+          una prueba que llama por dentro a una función que el camino real no usa no demuestra nada.
+          Copias las fijaciones del catálogo tal cual y no las editas. Corres tú las pruebas, el suelo y la suite e2e entera, y vinculas cada ejecución
+          a sus requisitos con `satisfies`. No rebajas ni borras una prueba para que pase. Si algo que funcionaba se rompe, lo arreglas;
+          si no puedes, lo reportas con `solicitar` (`pide: defecto`) y decide la persona. Nunca lo escondes.
+      - nombre: revisor
+        para_que: revisa en el paso de evidencia que lo construido funciona por el camino real, antes de entregar la evidencia
+        texto: >-
+          PAPEL: REVISOR (fase 2). No escribes el código: lo revisas como lo usaría la persona. Compruebas que cada funcional construido tiene su prueba e2e,
+          que arranca el artefacto por su contrato de arranque y no lo llama por dentro, y que pasa; que las fijaciones del catálogo no se tocaron;
+          y miras las pruebas modificadas o borradas desde la foto (las lista el resumen del paso): si alguna se rebajó para que pase, lo dices.
+          Corres el suelo y la suite e2e entera con el comando compuesto exacto y entregas esa evidencia. Lo que falla no lo das por bueno:
+          se arregla, o se reporta como defecto con `solicitar` y decide la persona. Si un funcional no admite una prueba automática
+          (un correo, algo visual, una integración externa), lo pides con `solicitar` (`pide: sin_e2e`), con el motivo.
+    salidas: { suelo: true, e2e: true }
+    componentes:
+      - nombre: juego
+        oficio: &oficio
+          - "Arranque: el juego se lanza con `sh arrancar.sh` desde la raíz del artefacto, en una terminal, y juega en ella. Termina limpio con `q`. A una pantalla más pequeña de la que necesita, avisa o sale limpio, sin traza."
+        description: >-
+          El juego entero, en tres peldaños: lo que se pide, sus partes y el código, con la lógica separada de la pantalla.
+        kinds:
+          - { name: objetivo, describes: "pieza de la solicitud (L0), sin ubicación en el árbol", ubicado: false }
+          - { name: modulo, describes: la definición del paquete o del módulo, ubicado: true }
+          - { name: dominio, describes: "el estado, las reglas y la puntuación, sin dibujar ni leer teclas", ubicado: true }
+          - { name: interfaz, describes: cómo se dibuja la pantalla y cómo se leen las teclas, ubicado: true }
+          - { name: arranque, describes: el punto de entrada del programa, ubicado: true }
+          - { name: prueba, describes: fichero de prueba, ubicado: true }
+        coRequirements:
+          - { when: dominio, requires: [prueba] }
+        levels:
+          - id: L0
+            requiredRoles: []
+            title: SOLICITUD
+            instruction: Declara qué juego se quiere, cómo se juega y cómo se gana o se pierde.
+          - id: L1
+            requiredRoles: []
+            title: PARTES
+            instruction: Propón las partes, con la lógica del juego separada de cómo se dibuja y de cómo se leen las teclas.
+            fanout: { min: 2, max: 12 }
+          - id: L2
+            requiredRoles: []
+            title: IMPLEMENTACIÓN
+            instruction: Escribe el código; la lógica se prueba sin terminal.
+            fanout: { min: 1, max: 40 }
+        selfReview:
+          criteria:
+            - check: La lógica del juego se prueba sin abrir la terminal
+              how: Busca en las pruebas del dominio cualquier uso de la pantalla o de las teclas.
+              evidence: medida
+            - check: Lo implementado es el juego que se pidió en L0, y no uno parecido
+              evidence: juicio
+  - nombre: completa
+    aplica: []
+    papeles: *papeles
+    salidas: { suelo: true, e2e: true }
+    componentes:
+      - nombre: juego
+        oficio: *oficio
+        description: >-
+          El juego entero, en cinco peldaños: lo que se pide, sus partes, sus contratos, el cableado y el código.
+        kinds:
+          - { name: objetivo, describes: "pieza de la solicitud (L0), sin ubicación en el árbol", ubicado: false }
+          - { name: modulo, describes: la definición del paquete o del módulo, ubicado: true }
+          - { name: dominio, describes: "el estado, las reglas y la puntuación, sin dibujar ni leer teclas", ubicado: true }
+          - { name: interfaz, describes: cómo se dibuja la pantalla y cómo se leen las teclas, ubicado: true }
+          - { name: arranque, describes: el punto de entrada del programa, ubicado: true }
+          - { name: prueba, describes: fichero de prueba, ubicado: true }
+          - { name: dependencia, describes: "arista del cableado (L3) entre dos piezas declaradas", ubicado: false }
+        coRequirements:
+          - { when: dominio, requires: [prueba] }
+        levels:
+          - id: L0
+            requiredRoles: []
+            title: SOLICITUD
+            instruction: Declara qué juego se quiere, cómo se juega y cómo se gana o se pierde.
+          - id: L1
+            requiredRoles: []
+            title: PARTES
+            instruction: Propón las partes, con la lógica del juego separada de cómo se dibuja y de cómo se leen las teclas.
+            fanout: { min: 2, max: 14 }
+          - id: L2
+            requiredRoles: []
+            title: CONTRATOS
+            instruction: Declara qué ofrece cada parte a las demás, y qué pasa en los bordes (la pantalla pequeña, la tecla que no vale).
+            fanout: { min: 1, max: 30 }
+          - id: L3
+            requiredRoles: []
+            title: CABLEADO
+            instruction: Declara qué depende de qué; la lógica no depende de la pantalla.
+            fanout: { min: 1, max: 40 }
+          - id: L4
+            requiredRoles: []
+            title: IMPLEMENTACIÓN
+            instruction: Escribe el código; la lógica se prueba sin terminal.
+            fanout: { min: 1, max: 70 }
+        selfReview:
+          criteria:
+            - check: La lógica del juego se prueba sin abrir la terminal
+              how: Busca en las pruebas del dominio cualquier uso de la pantalla o de las teclas.
+              evidence: medida
+            - check: Lo implementado es el juego que se pidió en L0, y no uno parecido
+              evidence: juicio
+
+escalones:
+  - nombre: varias-pantallas
+    cuando:
+      - [pantallas, '>=', 2]
+    diseno:
+      - Cada pantalla tiene su propia lectura de teclas; un mismo menú no se copia en varios sitios.
+    huecos:
+      - Cómo se pasa de una pantalla a otra y cómo se vuelve.
+    oficio:
+      - Cada pantalla es una función de la interfaz con su propia lectura de teclas.