# Registro de cambios — renaser Registro técnico detallado, fase a fase, en orden cronológico. Formato inspirado en *Keep a Changelog*. Para la crónica en lenguaje llano, ver `DIARIO.md`; para el estado y los planes, `ROADMAP.md`. --- ## Fase 1 — El primer microsegundo — 2026-05-21 ### Infraestructura - Espacio de trabajo Cargo, `kernel/Cargo.toml`, `.cargo/config.toml`, `rust-toolchain.toml`. - Target inicial: especificación JSON propia `x86_64-renaser.json` — PIC, soft-float, sin SSE, enlazador `lld`. ### Añadido - `kernel/src/main.rs`: punto de entrada con el macro `entry_point!` de `bootloader_api` 0.11. - Adopción y verificación con seguridad de tipos del framebuffer GOP (ancho, alto, formato de píxel, *stride*). - Lienzo intermedio estático de 8 MiB en `.bss`, alineado a página: la técnica de doble búfer para evitar parpadeos. - `#[panic_handler]` que dibuja una franja roja directamente sobre el framebuffer mediante escrituras volátiles. - Dependencias: `bootloader_api` 0.11, `x86_64` 0.15, `embedded-graphics` 0.8. ### Notas - Corrección clave: `bootloader` (constructor de imagen, lado anfitrión) no es `bootloader_api` (la API `no_std` que consume el kernel). --- ## Fase 1.5 — Empaquetado y arranque — 2026-05-21 ### Cambiado - Migración del target del kernel: de la JSON propia `x86_64-renaser.json` al target nativo precompilado `x86_64-unknown-none`. Elimina `build-std` y la burocracia de compilador asociada. ### Añadido - Miembro `boot/`: orquestador de anfitrión. Dependencia de artefacto (RFC 3028) sobre el kernel; construcción de la imagen de disco UEFI con `bootloader::UefiBoot`; lanzador de QEMU. ### Toolchain - Instalación de la toolchain nightly (la máquina solo tenía la estable). ### Corregido - Los nightly recientes exigen `-Zjson-target-spec` para usar specs JSON (resuelto al migrar al target nativo). - Sintaxis del acelerador de QEMU: `-machine q35,accel=kvm:tcg`. ### Verificado - Arranque en QEMU: superficie índigo limpia a 1280×800. - Baliza de pánico (franja roja) confirmada inyectando un pánico de prueba. --- ## Fase 2.0 — Cimientos del manejo de fallos — 2026-05-21 ### Añadido - `kernel/src/gdt.rs`: GDT propia, TSS y un stack de emergencia (IST) reservado para el manejador de doble fallo. - `kernel/src/interrupts.rs`: IDT con manejadores de excepción de CPU. El breakpoint (#BP) es recuperable; #UD, #DE, #GP, #PF y #DF son fatales y encienden la baliza. - `#![feature(abi_x86_interrupt)]`. ### Corregido - La GDT debe recargar los registros SS/DS/ES con un segmento de datos del kernel: el cargador deja `SS = 0x10`, valor que en la GDT nueva pasa a ser el descriptor del TSS; el primer `iretq` de una rutina de excepción provocaba un #GP. Diagnosticado con la traza `-d int` de QEMU. ### Verificado - Excepción `int3` atrapada y superada; línea-latido teal dibujada como prueba. --- ## Fase 2.1 — Interrupciones de hardware — 2026-05-21 ### Añadido - `kernel/src/pic.rs`: remapeo del par 8259 (PIC) fuera del rango de las excepciones (vectores 0x20+); programación del temporizador PIT a 100 Hz; IRQ1 de teclado. - Bucle de render en `kernel_main`, despertado por el temporizador, en sustitución del `hlt` estático. ### Verificado - La línea-latido se anima (temporizador en marcha); las pulsaciones de teclado inyectadas cambian el cuadro-eco (teclado en marcha). --- ## Fase 3 — Memoria dinámica y reactor asíncrono — 2026-05-21 ### Añadido - `kernel/src/memory/`: `linked_list_allocator` como `#[global_allocator]` sobre una región estática en `.bss`. - `#[alloc_error_handler]`: franja naranja de agotamiento de memoria. `#![feature(alloc_error_handler)]`. - `kernel/src/async_system/`: reactor cooperativo — `Executor`, `Task`/`TaskId`, `Waker` (vía `alloc::task::Wake`) y `ScancodeStream`. - `kernel/src/texto.rs`: rasterización de tipografía vectorial con `fontdue`; TTF Adwaita Mono empotrada con `include_bytes!`. - Dependencias: `linked_list_allocator` 0.10, `spin` 0.9, `crossbeam-queue` 0.3, `futures-util` 0.3, `fontdue` 0.9. ### Cambiado - Heap ampliado de 16 MiB a 64 MiB: `fontdue`, al analizar una tipografía real, agotaba los 16 MiB iniciales. El `#[alloc_error_handler]` lo delató pintando la franja naranja — el guardarraíl funcionó en silicio real. ### Corregido - El modo `no_std` de `fontdue` está condicionado a su feature `hashbrown`; sin ella recae en `std`. Se fija `default-features = false, features = ["hashbrown"]`. ### Verificado - Rótulo de bienvenida rasterizado al arranque; el texto tecleado aparece en vivo. --- ## Fase 4 — El escudo de aislamiento WASM — 2026-05-21 ### Añadido - `kernel/src/wasm/`: intérprete `wasmi` 1.0.9 en modo `no_std`. `env.rs` define la matriz de capacidades — exactamente dos funciones de host: `sys_render_frame(ptr, len)`, con validación infranqueable de los límites de la memoria lineal, y `sys_get_scancode()`. - `apps/hello_wasm/`: primera aplicación del userspace — módulo `wasm32-unknown-unknown` (cdylib), un cuadrado móvil dirigido por teclado. Se empotra en el kernel con `include_bytes!`. - Dependencia: `wasmi` 1.0. ### Cambiado - El kernel se EXCLUYE del espacio de trabajo (`exclude = ["kernel", "apps"]`): al añadir `wasmi`, `cargo build` intentaba compilar el kernel para el anfitrión y fallaba por un símbolo `_start` duplicado. El kernel pasa a construirse únicamente como dependencia de artefacto de `boot`. ### Corregido - `wasmi` `no_std` necesita `default-features = false, features = ["hash-collections"]`. - `wasmi` 1.0.9 usa `Linker::instantiate_and_start` (no existe `instantiate`). ### Verificado - La aplicación WASM pinta su propia superficie y responde a las pulsaciones de teclado inyectadas, sin más vía hacia el kernel que las dos capacidades. --- ## Mantenimiento — Estructura, documentación e integración — 2026-05-21 ### Cambiado - Refactorización: `main.rs` dividido de 692 a ~155 líneas. Se extraen los módulos `sync.rs`, `grafico.rs`, `consola.rs` y `baliza.rs`. Sin cambios de comportamiento (verificado en QEMU). ### Añadido - Documentación: `CLAUDE.md`, `README.md`, `ARCHITECTURE.md`, `ROADMAP.md`, `CHANGELOG.md` y `DIARIO.md`. - Integración con git: repositorio inicializado, remoto `origin` en Gitea, `.gitignore`. ### Seguridad - `renaser.txt` —un borrador de trabajo que contenía una credencial— se subió por error en el commit inicial. Se purgó de todo el historial con `git filter-branch` y se reescribió el remoto con `push --force`. La credencial expuesta debe rotarse. --- ## Fase 5 — Multitarea cooperativa, guardarrail de fuel y reloj — 2026-05-22 Unificación de la Fase 3 (reactor) y la Fase 4 (WASM): el userspace deja de ser una sola app que monopoliza la CPU y pasa a ser un conjunto de aplicaciones cooperativas, aisladas también en el TIEMPO. ### Añadido - `kernel/src/async_system/reloj.rs`: convierte la IRQ0 (PIT, 100 Hz) en una primitiva asíncrona. `CONTADOR_PULSOS` (`AtomicU64`) y `EsperaFrame`, un `Future` que se resuelve en el siguiente pulso — la unidad de cesión cooperativa del userspace. Censo de wakers tras `Mutex`, drenado por la IRQ0. - `kernel/src/wasm`: ABI de fotograma. `AplicacionWasm` —instancia PERSISTENTE entre fotogramas (`Store` + `TypedFunc<(), ()>` + región)— sustituye al `wasm::ejecutar` de fuego-y-olvido. El módulo del userspace exporta ahora `init()` (una vez) y `tick()` (un fotograma, y retorna). - Escudo de combustible: `Engine` con `Config::consume_fuel(true)` y `CompilationMode::Eager` (el `fuel` mide solo ejecución). Presupuesto recargado antes de cada `tick` — `FUEL_ARRANQUE` (20 M) y `FUEL_FOTOGRAMA` (2 M). - `kernel/src/wasm/env.rs`: capacidad `sys_render_frame` con **regiones de dibujo** — cada fotograma se compone desplazado por el `(offset_x, offset_y)` de la app; un tamaño ajeno a la región se rechaza. Canal de teclado **por aplicación**: la IRQ1 difunde cada scancode a TODOS los canales, de modo que varias apps reciben la entrada en paralelo sin robársela. - `kernel/src/grafico.rs`: `RegionPantalla` y `Color::DESALOJO` (púrpura). - `apps/discola/`: aplicación WASM construida para portarse mal — su `tick` es un bucle cerrado. Demuestra el guardarrail de fuel en vivo. ### Cambiado - `apps/hello_wasm`: migrada al ABI `init`/`tick`; su lienzo se dimensiona a la región (480×560). El estado del cuadrado persiste en su memoria lineal. - `interrupts.rs`: la IRQ0 avanza el `reloj`; la IRQ1 difunde a los canales. - `consola.rs`: `volcar_marco` compone en una sub-región; `pintar_desalojo` tatúa la baliza púrpura. - Contención de fallos: el subsistema WASM ya no usa `.expect()`. Toda falla —carga, instanciación, desbordamiento, agotamiento de fuel— se devuelve como `Result`; la tarea desaloja la app (baliza púrpura) y el kernel sigue vivo. ### Verificado - QEMU: tres apps concurrentes. Dos instancias de `hello_wasm` (mismo bytecode, regiones izquierda y derecha) renderizan y responden a W/A/S/D **en paralelo**, con movimiento idéntico. La app díscola es desalojada en su primer fotograma por agotamiento de combustible: su región queda púrpura y el sistema —kernel y apps vecinas— no sufre un solo sobresalto. --- ## Fase 6.0 — Cuotas de memoria y ciclo de vida del userspace — 2026-05-22 El aislamiento de las aplicaciones, que la Fase 5 hizo temporal (combustible), se completa ahora en la dimensión espacial (memoria) y se cierra la fuga de recursos del ciclo de vida. ### Añadido - Techo de memoria lineal por aplicación: `4 MiB`. `wasm/mod.rs` construye un `StoreLimits` (`StoreLimitsBuilder::memory_size` + `trap_on_grow_failure`) y lo liga al `Store` con `Store::limiter`. Un `memory.grow` que rebase la cuota se convierte en trampa; el kernel la captura y desaloja la app. - `FallaApp::SinMemoria` y `Color::DESALOJO_MEMORIA` (amarillo pálido). El desalojo distingue la causa por color: púrpura (tiempo/aborto), amarillo (memoria). La clasificación es robusta — `Error::as_trap_code()` da un código público y unívoco: `TrapCode::GrowthOperationLimited`. - `Drop` para `AplicacionWasm`: al morir una app desalojada, su canal de teclado se da de baja del censo de difusión de la IRQ1 — cierra la fuga señalada en la Fase 5. `async_system::teclado` se reorganiza en `crear_canal` / `registrar_canal` / `cerrar_canal`; el canal se inscribe al FINAL de la carga, de modo que una carga fallida no deja canales huérfanos. - `apps/glotona/`: aplicación WASM construida para devorar memoria — su `tick` invoca `memory.grow` sin freno. Demuestra el guardarrail espacial en vivo. ### Verificado - QEMU: cuatro apps concurrentes. Las dos `hello_wasm` renderizan y responden al teclado en paralelo; la app díscola es desalojada por combustible (franja púrpura) y la app glotona por cuota de memoria (franja amarilla), ambas en su primer fotograma, sin que el kernel ni las apps honradas se inmuten. --- ## Fase 6.1a — Sonda PCI y disco de pruebas — 2026-05-22 Primer paso de la estrategia incremental hacia el almacenamiento: derribar el muro del descubrimiento de hardware antes de diseñar nada encima. ### Añadido - `kernel/src/drivers/`: nuevo subsistema de drivers. `pci.rs` enumera el bus PCI por fuerza bruta mediante el mecanismo de configuración #1 —puertos de E/S `0xCF8` (dirección) y `0xCFC` (datos)—; recorre buses y dispositivos leyendo el Vendor/Device ID, y localiza el disco virtio-blk (vendor `0x1AF4`, device `0x1001`/`0x1042`), devolviendo su ubicación y sus seis BARs. - `kernel_main`: tras fundar la consola, sondea el bus PCI y deja constancia visual del hallazgo. ### Cambiado - `boot/src/main.rs`: forja un disco de pruebas `target/disk.img` (fichero disperso de 32 MiB; se respeta si ya existe) y lo adjunta a QEMU como `virtio-blk-pci`. **Corrección de plataforma:** la máquina `q35` es x86_64 y exige la transmisión PCI; `virtio-blk-device` (su gemelo MMIO) es de ARM. ### Verificado - QEMU: el kernel enumera el bus y reporta en pantalla `virtio-blk en bus 0 dev 3 :: BAR0 E/S 0x6000` — un dispositivo virtio-blk transicional (device `0x1001`), con su BAR0 en espacio de E/S. El muro del descubrimiento PCI queda derribado; las cuatro apps del userspace siguen operando sin alteración. --- ## Fase 6.1b — HAL, DMA y lectura del sector 0 — 2026-05-22 Segundo paso del sustrato de almacenamiento: el diálogo real con el disco. El kernel monta el dispositivo virtio-blk y lee su primer sector por DMA. ### Añadido - Dependencia `virtio-drivers` 1.13 (`no_std`, `default-features = false`, feature `alloc`). - `kernel/src/drivers/disco.rs`: - **Asignador de marcos** «bump» — reparte páginas físicas de 4 KiB para el DMA, tomadas de la mayor región de RAM libre que el cargador reporta. No libera: suficiente para una sonda (la gestión fina llegará con el grafo). - **`KernelHal`** — implementa el `trait Hal` de `virtio-drivers`. `dma_alloc` entrega marcos físicos a cero; `mmio_phys_to_virt` traduce los BARs (el cargador mapea ≥ 4 GiB de memoria física, que cubre todo MMIO de PCI); `share`/`unshare` usan un buffer rebote para que cualquier región del kernel pueda viajar al dispositivo. - **`montar_y_leer_sector0`** — enumera el bus, habilita E/S + memoria + bus-master, monta el `PciTransport` y el `VirtIOBlk`, y lee el sector 0 por **sondeo** del *used ring* (sin depender aún de interrupciones). - `kernel/src/drivers/pci.rs`: reescrito como `CamPuertos`, la implementación de `ConfigurationAccess` de `virtio-drivers` sobre los puertos `0xCF8`/`0xCFC`. - `kernel_main` captura `physical_memory_offset` y la región de RAM de `BootInfo`, funda el subsistema de disco y reporta el resultado de la sonda. ### Cambiado - `boot/src/main.rs`: al forjar el disco de pruebas graba una firma (`renaser-6.1b`) en su sector 0 — el testigo del viaje de ida y vuelta. ### Verificado - QEMU: el kernel reporta `virtio-blk :: bus 0 dev 3 :: 65536 sectores :: s0=renaser-6.1b`. La firma grabada por el anfitrión se lee de vuelta intacta: descubrimiento PCI, transporte, DMA y transferencia funcionan de punta a punta. Las cuatro apps del userspace siguen operando sin alteración. --- ## Fase 6.1c — El grafo de objetos direccionado por contenido — 2026-05-22 Tercer y último paso del sustrato de almacenamiento. El disco deja de ser un dispositivo que se sondea y pasa a ser una MEMORIA QUE PERDURA: un grafo dirigido acíclico de objetos direccionados por contenido — no un sistema de archivos plano POSIX. ### Añadido - `kernel/src/almacen.rs` — el grafo de objetos: - **Objeto** — una carga útil de bytes (`datos`) y una lista de aristas (`hijos`: hashes de otros objetos). Las aristas hacen del almacén un DAG. - **Direccionamiento por contenido** — la identidad de un objeto es el hash BLAKE3 de su forma serializada. De ello se siguen dos propiedades que un sistema de archivos jamás regala: INTEGRIDAD (el contenido leído se rehashea y se verifica contra el hash pedido) y DEDUPLICACIÓN (contenido idéntico produce el mismo hash; se almacena una sola vez). - **Disco como log** — el sector 0 es el superbloque (magia `RENASGRF`, versión, cursor del log y hash de la raíz); tras él se anexan los registros de objetos, `[longitud u32 LE][payload postcard][relleno a cero]`. Un índice en memoria (hash -> sector) se reconstruye al arrancar recorriendo el log de cabo a rabo. - API: `init` —monta el disco, lee o forja el superbloque, reconstruye el índice—, `almacenar`, `recuperar`, `raiz` y `fijar_raiz`. - Cinco capacidades nuevas del host en `wasm/env.rs` — `sys_object_put`, `sys_object_datos`, `sys_object_hijo`, `sys_object_raiz` y `sys_object_fijar_raiz` —, con la misma validación infranqueable de límites de la memoria lineal que `sys_render_frame`. Distinguen dos clases de fallo: un puntero inválido ABORTA la app —es su culpa, se traduce en trampa—; un fallo del almacenamiento le devuelve un código de error negativo —no lo es—. - `apps/cronista/` — la primera aplicación del userspace que escribe en el almacenamiento PERSISTENTE. En cada arranque consulta la raíz del grafo, graba un objeto nuevo —`datos`: el número de arranque; `hijos`: la raíz anterior, el eslabón del DAG— y lo corona como raíz. Pinta una celda por arranque registrado y un testigo de integridad que recorre la cadena entera. - Dependencias: `serde` 1 y `postcard` 1 (serialización binaria compacta, el formato que viaja al disco) y `blake3` 1 (la función hash). Las tres `no_std`. ### Cambiado - `kernel/src/drivers/disco.rs` reescrito para un sustrato PERMANENTE: - El asignador de marcos «bump» de la Fase 6.1b cede el paso a uno de MAPA DE BITS con liberación real. `dma_dealloc` y `unshare` devuelven los marcos a la arena: un almacén vivo, con su trasiego incesante de DMA, ya no la agota. - El `VirtIOBlk` deja de montarse y destruirse en cada llamada: se monta UNA vez y queda tras un `Mutex` global. `leer_sectores` / `escribir_sectores` exponen la E/S de bloques — el disco deja de ser de solo lectura. Se retira `montar_y_leer_sector0`, la sonda de un solo uso de la Fase 6.1b. - `boot/src/main.rs`: el disco de pruebas pasa a ser el disco de objetos. Ya no se le graba una firma — se forja virgen, a cero, y el kernel lo formatea la primera vez que no halle el superbloque. - `main.rs`: `informar_disco` (la sonda de la Fase 6.1b) se sustituye por `informar_almacen`, que funda el grafo. El userspace pasa de cuatro a cinco apps; las regiones de discola y glotona se reajustan para alojar a cronista. ### Notas - **blake3 forzado a escalar.** El target del kernel corre sin SSE; un camino SIMD de blake3 activado por detección en tiempo de ejecución ejecutaría instrucciones que la CPU, sin `CR4.OSFXSR`, rechazaría con un #UD. Se fija blake3 con `pure` + los cuatro `no_*` (`sse2`, `sse41`, `avx2`, `avx512`): implementación puramente escalar, sin SIMD ni ensamblador. ### Verificado - QEMU, TRES arranques consecutivos sobre el mismo disco persistente: la app cronista pinta 1, luego 2, luego 3 celdas — la cuenta de arranques sobrevive a los reinicios porque vive en el grafo, en el disco, no en la RAM. El testigo de integridad queda VERDE en los tres: el DAG entero se recorre, de la raíz al primer eslabón, y su profundidad cuadra con la cuenta. El superbloque en disco confirma la magia `RENASGRF`, versión 1, cursor 4 y la raíz del tercer arranque; el registro del primer arranque guarda `datos = 1` y cero hijos. Las otras cuatro apps siguen su curso sin alteración — las dos `hello_wasm` renderizando, discola desalojada en púrpura, glotona en amarillo. --- ## Fase 6.2 — E/S de disco asíncrona por interrupción — 2026-05-22 La Fase 6.1 hizo hablar al disco, pero por SONDEO: el procesador se quedaba en espera activa vigilando el *used ring* de virtio, incapaz de atender nada más. La 6.2 libera el planificador cooperativo — la E/S de bloques pasa a ser REACTIVA, guiada por la interrupción física del dispositivo. ### Añadido - `EsperaDisco` (`drivers/disco.rs`): una transferencia de bloques expresada como `Future` nativo. Posee sus buferes DMA —`BlkReq`, `BlkResp` y los datos, en el heap para una dirección estable—; su `poll` envía la petición por la API NO BLOQUEANTE de `virtio-drivers` (`read_blocks_nb`/`write_blocks_nb`), consulta el *used ring* (`peek_used`) y, si la transferencia sigue en vuelo, inscribe el waker y cede. `leer_bloques`/`escribir_bloques` lo construyen. - La IRQ del disco: `montar` descubre la línea de IRQ legada del dispositivo (registro «Interrupt Line», offset 0x3C del espacio de configuración PCI), registra un manejador en la IDT y abre la línea en el PIC. `interrupts::irq_disco` → `disco::atender_irq` reconoce la interrupción en el dispositivo —leer su registro ISR baja la línea INTx— y despierta, vía un waker de ranura única, a la tarea que aguardaba el bloque. - `bloquear_en` — el puente para los contextos SÍNCRONOS (el arranque, las capacidades WASM, que no pueden `.await`): lleva un `Future` de disco hasta su final durmiendo la CPU con `hlt` —la despiertan la IRQ del disco o el temporizador, como red de seguridad—; jamás en espera activa con el sistema ya en marcha. - `pic::desenmascarar` / `pic::vector_irq`: abrir una línea concreta del par 8259 (con su cascada, si vive en el esclavo) y mapear línea → vector de IDT. - `pci::linea_irq`: leer el registro «Interrupt Line» de un dispositivo. - `tarea_sonda_disco` (`main.rs`): una tarea del reactor que lee el sector 0 de forma asíncrona — la prueba viva de que la IRQ conduce la E/S sin detener a las aplicaciones. ### Cambiado - `leer_sectores`/`escribir_sectores` se reescriben sobre la maquinaria asíncrona (`bloquear_en` + `EsperaDisco`). El `almacen` y las capacidades `sys_object_*` NO cambian una línea: heredan la E/S por interrupción de forma transparente — la espera de disco deja de quemar ciclos en sondeo. - El `VirtIOBlk` pide al dispositivo que emita interrupciones al completar cada petición (`enable_interrupts`). ### Decisiones de ingeniería - **PIC, no IOAPIC.** El kernel corre íntegramente sobre el par 8259 (`pic.rs`) y la crate `x86_64` no ofrece abstracción de APIC. Las IRQ legadas de PCI de la máquina `q35` se enrutan por el 8259: basta leer la línea que el firmware UEFI ya asignó y abrirla. Migrar al IOAPIC habría exigido levantar LAPIC + IOAPIC + parseo de tablas ACPI — un subsistema entero, desproporcionado para el objetivo. El resultado funcional es idéntico: E/S conducida por la interrupción física. - **Las capacidades WASM no `.await`-ean.** El intérprete `wasmi` ejecuta las funciones de host de forma SÍNCRONA: no hay manera de suspender un módulo a mitad de una llamada de host. Por eso `sys_object_*` no se vuelven asíncronas; usan `bloquear_en`, que duerme la CPU con `hlt` en lugar de sondear. El verdadero solapamiento E/S ↔ render lo aprovechan las TAREAS del reactor (`tarea_sonda_disco` hoy; la carga dinámica de módulos, mañana). - Una IRQ legada de PCI es de NIVEL: el manejador reconoce primero al dispositivo —lo que baja su línea— y sólo después cierra el EOI del PIC; el orden inverso reavivaría la interrupción en bucle. - Todo acceso al disco toma su `Mutex` con las interrupciones desactivadas (`without_interrupts`): la IRQ del disco jamás encuentra el cerrojo ocupado, lo que hace imposible el interbloqueo por interrupción. ### Verificado - QEMU: el disco virtio-blk se enruta a la IRQ 11. La `tarea_sonda_disco` reporta «sonda asíncrona OK -- 2 IRQ de disco atendidas»: la interrupción del disco dispara de verdad. La app cronista, sobre el disco persistente heredado de la Fase 6.1c, continúa la cuenta de arranques (3 → 4 → 5 celdas) con el testigo de integridad del DAG en verde — la nueva E/S asíncrona lee y escribe el grafo sin un solo fallo. Las cuatro apps WASM siguen su curso, sin un sobresalto ni un micro-congelamiento. ## Fase 7 — Apertura: Apps que nacen del Grafo — 2026-05-22 Apertura de la Fase 7. Este commit asienta el plan y el andamiaje; **no cambia el comportamiento del kernel**. La Fase 7 destierra el `include_bytes!` del userspace: las aplicaciones pasan a ser objetos del grafo, y un Manifiesto de Génesis —también en el grafo— dicta qué arranca, con qué cuota y en qué región. ### Añadido - `FASE7.md` — el plan de ataque: el objetivo, el problema huevo-y-gallina de la génesis, las sub-fases 7a (manifiesto + carga desde el grafo, con semilla por el kernel), 7b (siembra de la imagen por `boot`, muerte del `include_bytes!`) y 7c (persistencia inter-sesión), y los guardarraíles. - `kernel/src/manifiesto.rs` — andamiaje del Manifiesto de Génesis. Los tipos `Manifiesto` / `EntradaApp` y la (de)serialización `postcard` están completos; `cargar` y `sembrar_genesis` son esbozos hasta la Fase 7a. La sub-región se guarda en campos `u32` de ancho fijo (formato en disco), no como `RegionPantalla` (`usize`, ancho de plataforma). ### Notas - El módulo se declara en `main.rs` pero aún no se cablea a `kernel_main` (`#![allow(dead_code)]` temporal, hasta que la 7a le dé un llamador). El kernel compila y se comporta idéntico a la Fase 6.2 — nada observable que verificar en QEMU en esta apertura. ## Fase 7a — Apps que nacen del Grafo: el Manifiesto — 2026-05-22 El kernel deja de empotrar el userspace. Las cinco aplicaciones ya no llegan por `include_bytes!` en `main.rs`: nacen del grafo de objetos, gobernadas por un Manifiesto de Génesis que también vive en el grafo. ### Añadido - `kernel/src/manifiesto.rs` — el Manifiesto de Génesis implementado: tipos `Manifiesto` / `EntradaApp`, (de)serialización `postcard`, `cargar` (lee el manifiesto del grafo vía el ancla del superbloque) y `sembrar_genesis` (puebla un disco virgen con las cinco apps de génesis). - `almacen`: el `SuperBloque` gana el ancla `manifiesto: Option` — gemela de `raiz`, pero del lado del kernel. Accesores `manifiesto()` y `fijar_manifiesto()`. ### Cambiado - `almacen::VERSION` 1 → 2: el superbloque cambia de forma. Un disco v1 se reformatea al arrancar, como cualquier disco ajeno — la cuenta de la cronista reinicia una vez. - `kernel_main`: las cinco llamadas `encender_app` escritas a mano se sustituyen por `cargar_userspace`, que carga el manifiesto —o lo siembra si el disco está virgen— e itera sus `EntradaApp`. - `encender_app` recibe una `EntradaApp` y recupera el bytecode del grafo. `recuperar` ya recomputa y verifica el hash: un bytecode corrupto se niega, se pinta la baliza de desalojo en su región y el arranque continúa. - `wasm::AplicacionWasm::cargar` recibe el techo de memoria por-app (del manifiesto) en vez de la constante global `TECHO_MEMORIA`. ### Notas - La siembra es TRANSITORIA: el bytecode aún viaja empotrado en `manifiesto.rs` (`include_bytes!`) como semilla. La Fase 7b lo moverá al constructor de imagen `boot` y el `include_bytes!` morirá del todo. ### Pendiente de verificación - QEMU (la corre el operador): la pantalla debe verse idéntica a la Fase 6.2 —cinco apps en sus regiones—, más una línea de consola «manifiesto :: …». El primer arranque reformatea el disco v1→v2 y siembra la génesis; los siguientes cargan el manifiesto ya grabado en el grafo.