normativas-israel Simulación · cumplimiento · informes
Hito activo M1 · Geometría viva

Estado de construcción · 2026-07-15

M1 sigue activo; el hospital de geometría es ahora el control obligatorio previo a cualquier motor real.

Cinco de las seis piezas de M1 están listas. Su cierre formal espera repetir el recorrido completo con una selección real. En paralelo, el fixture sintético Level-1 ya recorrió cálculo y veredicto, y el programa para completar los siete motores empezó corrigiendo la publicación del motor de sombra: cada resultado se arma en privado, Contract C se publica al final y un fallo tardío no deja mallas parciales. El pipeline Docker común ya ejecutó la imagen reproducible de sombra dentro de Linux/amd64, admitió y publicó Contract C, evidencia, logs y PLY, reprodujo exactamente los mismos bytes sin crear un segundo contenedor y dejó el lifecycle limpio. Acceso solar en espacio abierto ya cuenta con receta neutral, fixture Level-0, runner sellado, imagen real reproducible, evidencia estricta, admisión independiente y una vista three.js que muestra exactamente una de sus dos capas con escala autenticada, siempre sin regla ni veredicto. La imagen pública pasó los probes NREL/Radiance y produjo dos ejecuciones no-root, sin red y read-only con 16 artefactos byte-idénticos admitidos como completed. Viento peatonal ya congela una receta CFD neutral sobre OpenFOAM Foundation 13, los cinco archivos estándar con EPW aprobado, ocho direcciones, malla, convergencia y validación, pero sigue sin motor, regla ni veredicto; los datos horarios recientes con QC y aceptación municipal quedan para una futura capa de autoridad y uso legal. Reflejos con calor solar ya define elevación, iluminancia e irradiancia añadida como mediciones neutrales; temperatura superficial queda fuera de v1 y tampoco existe motor, regla ni veredicto. M4 comparó tres renderers RTL y la preparación técnica previa a M5 añadió dos corpus separados. El corpus urbano conserva 500 escenas canónicas y 14 casos recorrieron el visor WebGL. La nueva escalera densa verifica offline un caso al límite de 1.024 objetos y un caso balanceado de 393.216 triángulos; el mismo caso balanceado también quedó registrado en el visor local con navegación, mientras CI navega el caso ligero de 24.576 triángulos. Son pruebas sintéticas de límites exactos y compatibilidad, no una promesa de FPS ni de rendimiento de un proyecto real. No corren todavía el motor de sombra sobre estas escenas, no sustituyen una geometría real de Enrique y no significan que M5 haya empezado o cerrado. Ninguna de estas pruebas representa un proyecto real ni cierra anticipadamente los hitos.

Conclusión: M1 mantiene su compuerta real; los demos Level-1 de M2 y M3 prueban la cadena técnica sin adelantar el cierre formal.

1hito cerradoM0 · Esqueleto
5/6piezas de M1listas y verificadas offline
2demos técnicosM2 y M3 · Level-1 · sintéticos
7estudios previstospara el MVP de Tel Aviv

01 · Arquitectura explicada

El recorrido de la aplicación

De izquierda a derecha: lo verde está construido, lo azul puede avanzar offline y lo gris pertenece a los siguientes hitos.

  1. 01
    Construido

    Autodesk Forma

    El panel privado prepara una selección para el recorrido controlado.

  2. 02
    Construido

    Speckle

    Transporta la versión exacta; los tokens se quedan fuera de git.

  3. 03
    Construido

    Watcher

    Detecta versiones nuevas una sola vez y deja un registro durable.

  4. 04
    Construido

    Geometry prep

    Valida, repara y publica una escena privada para el visor.

  5. 05
    Construido

    Visor three.js

    Tarjetas vivas, capas, aislar, ocultar y escenas que descansan cuando están quietas.

  6. 06
    Demo técnico reproducible

    Orquestador

    El demo Level-1 conserva entradas, salidas y evidencia, y conecta el cálculo con la evaluación determinista.

  7. 07
    Demo técnico Level-1

    Motores físicos

    Sombra ya ejecuta el fixture Level-1 en el runtime compatible y entrega una capa visual verificable.

  8. 08
    Demo técnico Level-1

    Reglas y veredictos

    La primera regla pasó el ciclo de aprobación y el demo Level-1 genera un veredicto técnico trazable. Falta aplicarlo a un proyecto real.

  9. 09
    Prueba técnica RTL

    Informe final

    La prueba hebrea RTL de cinco páginas ya compara tres renderers gratuitos. Falta reproducir un informe municipal aceptado antes de elegir el renderer y construir borrador, aprobación y PDF final.

02 · Hoja de ruta

Seis hitos hasta el informe real

Cada hito termina con una demo reproducible. No se cierra por fecha ni por cantidad de commits.

  1. M0EsqueletoRepo, contratos, CI, fixture y dashboard
  2. M1Geometría vivaForma a visor con una escena real
  3. M2Primer cálculoDemo técnico Level-1 listo; cierre formal pendiente
  4. M3Regla y veredictoDemo técnico Level-1 listo; cierre formal pendiente
  5. M4InformePrueba RTL lista; plantilla aceptada, borrador y aprobación pendientes
  6. M5Proyecto realCorpus sintético listo; geometría real y flujo completo pendientes

Despiece del hito activo

5 de 6 entregables terminados
Deterministic Speckle watcherlisto
Forma to Speckle publisherlisto
Speckle geometry materializationlisto
Live project cardslisto
three.js layers, isolate and hidelisto
Real publish-to-orbit demofalta demo

Límite de realidad

La evidencia actual usa geometría sintética.

Los demos técnicos ya recorren cálculo, evaluación y visualización, pero todavía no representan un resultado de proyecto real ni cierran un hito formal.

No existe todavía

  • validación Level-2 del gate geométrico con un proyecto real de Forma
  • motor físico integrado con un proyecto real
  • regla municipal aplicada a un proyecto real
  • veredicto de un proyecto real
  • borrador automático conectado a Contract D
  • plantilla municipal aprobada y PDF final

03 · Alcance físico

Los siete estudios del MVP

Sombra abre el camino. Los otros seis reutilizarán el mismo patrón cuando el primer motor esté validado.

Demo técnico reforzado

Sombra

Es el primer estudio implementado. Su demo Level-1 recorre cálculo, evaluación, evidencia y visualización. El runner ya prepara resultados completos en staging, publica Contract C al final y revierte fallos tardíos sin exponer diagnósticos privados. Falta repetir el recorrido sobre una selección real antes del cierre formal.

Motor, runtime y visor técnicos listos

Acceso solar en espacio abierto

La receta técnica neutral define duración de sol directo e irradiación directa sobre superficies SceneV1 seleccionadas explícitamente. El fixture procedural de 10 m por 10 m fija dos regiones de 50 m²; las mallas de 1 m y 0.5 m generan exactamente 100 y 400 receptores. El motor compone los cinco inputs, EPW, calendario, SPA portable, Radiance particionado, evidencia JSONL y dos PLY. Dos builds Linux/amd64 sin caché y con BuildKit pinneado produjeron el mismo manifest, config y archivo Docker; la imagen real pasó los probes NREL/Radiance y dos ejecuciones no-root, sin red y read-only publicaron 16 artefactos byte-idénticos admitidos como completed. El visor three.js valida B/C, motor, SHA-256, capas y unidades, toma la escala sólo de evidencia autenticada y renderiza una sola malla para evitar z-fighting. El demo visual usa una matriz analítica sintética, no Radiance, y conserva la etiqueta SYNTHETIC TECHNICAL RESULT · NO RULE · NO VERDICT.

Receta CFD neutral congelada

Viento peatonal

Receta técnica para RANS estacionario de ABL neutra sobre OpenFOAM Foundation 13: cinco entradas estándar con EPW aprobado, ocho direcciones, plano a 1,5 m y gates de malla, convergencia, backflow, paralelismo y AIJ. Está congelada sin motor, regla ni veredicto; los datos horarios recientes con QC y aceptación municipal quedan como futura autoridad para uso legal.

Brief técnico listo

Reflejos + calor solar

El brief técnico neutral define elevación del rayo reflejado, iluminancia vertical añadida e irradiancia añadida sobre selectores explícitos. La temperatura superficial queda fuera de v1. No crea una regla ni un veredicto; faltan fixture, motor, imagen, admisión B/C, CI y capa visual.

Por definir

Insolación térmica

Ligada al rendimiento térmico y deliberadamente TBD; dirección EnergyPlus, receta aún no definida.

Planificado

Energía por recinto

EnergyPlus con honeybee-energy como candidato principal; interiores derivados desde uso y SI 1045.

Investigado

Ruido

SI 1004 identificado y reutilización investigada; faltan estándar vigente, motor y referencia de validación.

04 · Tu sesión

Qué puedes hacer hoy

Objetivo de la sesión Cerrar el hospital de geometría hasta producir HBJSON analítico y SceneV1 de producto trazables, y bloquear todo motor que no tenga un recibo válido de geometría lista.
  1. Conservar obligatorio el control de geometría lista para toda entrada real de motores
  2. Conservar listo (ready), observación (observation), decisión humana (human_gate) y rechazado (rejected) como estados distintos y verificables
  3. Mantener M1 abierto en 5 de 6 hasta disponer de una sesión real de Forma
  4. Mantener visibles las etiquetas de geometría sintética en toda evidencia Level-1
  5. Conservar entradas, salidas y logs de cada ejecución técnica
  6. No presentar el demo técnico como evaluación de un proyecto real
  7. Repetir Forma → visor cuando exista una sesión real disponible
  8. Cerrar M2 y M3 formalmente solo después de respetar la secuencia de hitos
  9. Mantener la prueba M4 rotulada como sintética
  10. Reproducir el informe municipal aceptado con Playwright y Vivliostyle antes de seleccionar el renderer de M4
  11. No habilitar aprobación ni PDF final antes de los gates de completitud
  12. Mantener las 500 escenas fuera de Level-2 y sin lenguaje de cumplimiento
  13. Reanudar motores nuevos sólo después de fusionar el gate geométrico verde, manteniendo fixtures sintéticos explícitos hasta Level-2
  14. Mantener el informe final y el proyecto real detrás de resultados técnicos y reglas aprobadas para cada estudio requerido

Compuertas

Lo que mantiene abierto el hito formal

Evidencia real de Forma al visor

La implementación offline está completa y el doctor de solo lectura pasa los gates configurados de Speckle y Supabase. Para cerrar M1 falta una sesión real de Forma y evidencia de publicación, materialización y apertura de la misma versión, sin revelar secretos.

Referencia municipal aceptada para M4

Las pruebas RTL están completas, pero docs/references todavía no contiene el informe real que spec 06 exige clonar. Sin esa referencia y la comparación visual aprobada no se puede seleccionar el renderer ni afirmar que existe una plantilla final.

05 · Después del demo

El camino crítico

La secuencia protege al proyecto de confundir una simulación técnica con una regla legal.

  1. Fusionar el gate geométrico cuando CI confirme tests, goldens, replay y demo; después reanudar el siguiente slice de motor.
  2. Recorrer Level-2 con una selección real de Forma cuando esté disponible y validar visualmente la misma versión desde origen hasta visor.
  3. Mantener PCERT Landscaping en human_gate hasta contar con autoridad exacta de CRS, norte, exterior y propiedades ópticas; nunca inventarlas.
  4. Conservar la escalera densa como diagnóstico reproducible, ejecutar el perfil extendido sólo en ambientes registrados y no convertir sus observaciones en una promesa de FPS.
  5. Incorporar un informe real aceptado por una municipalidad y reproducir su estructura con los dos renderers RTL que pasaron.
  6. Conservar y automatizar la evidencia reproducible de los demos técnicos Level-1.
  7. Completar la fase ejecutora del doctor AI con ledger bloqueado, estado armado, transporte sin proxy y deadline externo; sólo después hacer una llamada pública explícita y probar lesiones Landscaping.
  8. Completar el demo real de M1 y verificar que la misma versión de Speckle llega a SceneV1 y al visor.
  9. Repetir el cálculo y el veredicto sobre una selección real cuando M1 cierre.
  10. Mantener la regla aprobada limitada a su aplicabilidad documentada.

06 · Memoria del proyecto

Actividad del repositorio

Commits recientes

  • privadoLa actividad detallada permanece en el dashboard local privado.

Decisiones recientes

  • privadoEl detalle de decisiones permanece en el dashboard local privado.

07 · Confianza

Salud y verificación

CIEl PR #216 pasó en GitHub Actions los cuatro gates del cambio: CI de Python, pipeline Docker común, imagen reproducible de acceso solar y viewer. Cloudflare Pages también está verde; Supabase Preview se omitió sin ejecutar cambios.bien
GeometríaPublicación, detección, reparación, Contract A y escena privada están implementados.bien
VisorTarjetas autenticadas, capas, aislar, ocultar, rendimiento en reposo, un límite estricto de Contract D y la vista solar sintética de una sola capa están listos.bien
ContratosA–D tienen modelos y schemas; B/C y el primer sobre interno D cuentan con persistencia determinista e integridad, y el visor valida D sin resolver referencias.bien
OrquestaciónEl demo Level-1 conecta el cálculo con una evaluación determinista y conserva la evidencia completa. Las escrituras idénticas concurrentes del veredicto convergen sin confundir progreso legítimo con corrupción.bien
Motor de sombra Level-1La ejecución reproducible, la capa visual y la publicación segura de resultados pasan las verificaciones técnicas; Contract C es el sello final y los fallos tardíos no dejan mallas parciales.bien
Programa de siete motoresLa evidencia técnica ya construida se conserva: sombra probó el pipeline Docker común y acceso solar en espacio abierto probó su receta, imagen reproducible, replay y vista sintética. Reflejos con calor solar y viento peatonal permanecen como briefs o recetas, sin motor completo. El gate geométrico ya persiste ambos productos, completa los cuatro estados y bloquea entradas reales sin recibo. Después de su CI y merge puede reanudarse el programa de motores; hasta Level-2 sólo se permiten fixtures sintéticos explícitos, sin regla ni veredicto.atención
Ejecutor de motoresEl lifecycle rechaza paths de mount no canónicos, conserva la identidad exacta de /out y puede exigir el mismo device e inode de /in antes de crear y antes de arrancar el contenedor. Éxito y fallo durable se releen como evidencia autenticada bajo capacidades retenidas; la publicación de éxito exige el mismo device e inode de la materialización derivada del sello y rechaza una cadena de otro trabajo aunque use la misma imagen. El output completo y Contract C se escriben y verifican bajo un solo bloqueo, con inventario exacto y detección de sustitución del directorio. El recorrido común ya compone sello, /in, Docker, admisión y publicación; un timeout autenticado conserva logs y no publica Contract C. La VM Linux/amd64 ejecutó la imagen reproducible completa: Contract C, evidencia, logs y PLY fueron admitidos y publicados, el replay conservó exactamente los mismos bytes, Docker registró un solo create y no quedó ningún contenedor administrado. El éxito y replay sin segundo contenedor están probados localmente y el job Common engine pipeline · real Docker pasó en GitHub Actions en el PR #216.bien
Configuración de proyectoEl orquestador resuelve el único project.toml aprobado por bytes exactos, valida metros, EPSG:2039, norte verdadero, Asia/Jerusalem y la referencia climática, lo cruza con la escena y el EPW, conserva los cinco bytes en un sello inmutable y materializa exclusivamente ese sello en el /in retenido. Ningún caller elige bytes, digests, receipts, authority ni paths internos.bien
Especialista AIEl runner mock-first de GPT-5.6 Sol pro/max y el planificador público ya están probados. El primer expediente redactado pesa 2.7 KB y liga el request exacto, evidencia, presupuesto, retención y confirmaciones con un hash; el comando imprime NO CALL y no lee claves. Aún no se hizo una llamada pagada. Blender/Bonsai, trimesh, OCCT, CGAL y Ladybug son instrumental opcional.bien
Primera regla aprobadaLa regla pasó el ciclo manual requerido y ya participa en el demo técnico Level-1.bien
Prueba RTL M4Tres candidatos ejecutaron el mismo fixture; Playwright y Vivliostyle pasan y el fallo visible de Typst queda preservado.bien
Plantilla municipal M4Faltan el informe aceptado y la revisión visual de Enrique; todavía no hay renderer seleccionado ni plantilla final.atención
QA sintético previo a M5El corpus urbano verifica 500 SceneV1 y 14 casos WebGL. La escalera densa verifica offline el límite de 1.024 objetos y un caso balanceado de 393.216 triángulos; ese caso también fue navegado en el visor local. Es evidencia sintética con ambiente registrado, no una promesa de FPS ni reemplaza geometría Level-2.bien
Hospital de geometríasEl paciente sano y las dos reparaciones Level-0 pasan el mismo gate como ready. IfcOpenShell genera SceneV1 desde el producto IFC completo; Honeybee/Ladybug conserva HBJSON como autoridad analítica de Rooms, superficies, adyacencias, energía y Radiance. El recibo liga IFC, manifest, HBJSON, SceneV1, coordenadas, transformación de ejes, semántica, procedencia, reparaciones, validadores, exports y replay. PCERT Rooms y openings quedan en observation; Landscaping ejecuta human_gate; unidades incoherentes y pacientes inválidos nunca se corrigen en silencio. El orquestador exige el handoff exacto antes de sellar una entrada real y el demo offline muestra nueve paneles con etiquetas persistentes. En paralelo, Level-2 privado ya produce un inventario estructural y un censo IfcSpace owner-only, timeboxed y source-bound; todavía no genera HBJSON ni autoriza motores hasta recibir y validar una geometría real de Forma. El fixture público 2L añade dos BReps de 60 m³, placements anidados, escala de milímetros a metros y una pared física de 0,20 m; cinco mutantes aíslan lesiones de reciprocidad, placement, escala, parent/child y cierre sin confundirlas con fallos de sólidos. El comparador gobernado ejecuta BRep directo, kernel y boundaries como autoridades distintas, nunca por votación: el caso sano coincide, las cinco lesiones producen su diagnóstico exacto y cualquier lesión mantiene HBJSON denegado. El supervisor aislado limita tiempo y salida, conserva fallos durables y publica recibos owner-only, write-once y byte-idénticos.bien
Límite sintéticoToda evidencia Level-1 permanece rotulada como sintética y no se presenta como cumplimiento de un proyecto real.bien
Demo M1No queda desarrollo offline pendiente dentro de M1; los gates de proveedor pasan y falta la publicación real desde Forma con su evidencia.atención
Runtime localEl entorno compatible ya construye y ejecuta de forma reproducible el motor de sombra.bien
Sin cajas negras.

Cada corrida conservará entradas, salidas y logs. Si falla un motor, falla toda la corrida y queda registrado.