La bitácora de obra dejó de tener base propia: sus datos viven en la base por empresa de la suite, junto con los de las demás apps, y su motor corre dentro de la API. Es la primera app que se muda; roster101 sigue el mismo camino. Cómo se hizo sin cambiar una sola regla de obra, y cómo se trajeron los datos.
Al 19 de septiembre de 2026Contrato de la API 0.16.0Decisión de Mike: todo lo de una empresa en su base de la suite
Antes y después
Hasta el 18 de septiembre quell101 era un programa completo: su pantalla, su motor y su base (una D1 de una sola empresa) vivían en su propio Worker. Desde el 19, el Worker sólo sirve la pantalla; todo lo demás está en la suite.
La pantalla no cambió y las reglas tampoco: lo que se movió fue dónde corren y dónde guardan.
Por qué así
Una base por empresa, para todo. Es la promesa de la suite desde el 7 de septiembre: si una empresa apaga quell101, sus obras siguen en su base; si la reactiva, las vuelve a ver. Y una empresa nueva recibe su bitácora sin que nadie cree nada: la base nace sola al primer uso.
El motor se movió tal cual. Los recortes del contratista, la cara de cliente, el código único por obra, la fila sin señal: todo es el mismo archivo que corría antes, con tres cambios (tablas con prefijo, la sesión la da la puerta de la suite, archivos en el bucket de la suite). Por eso las 95 comprobaciones de obra pasaron a la API sin reescribirse.
El dueño de la empresa entra solo. El director que master101 dio de alta abre quell101 y nace como dueño de la bitácora; desde ahí da de alta a su gente. Antes había que apuntarlo a mano en otra base.
quell101 ganó staging. Antes no tenía: cada cambio se probaba contra la obra real. Ahora hay un Worker de staging contra la API de staging y la empresa demo, y el despliegue entra, levanta una obra con su plano y su ítem, lo lee, lo sirve y lo borra antes de tocar producción.
Cómo se trajeron los datos
La mudanza es una ruta de la API que sólo abre el dueño de la suite, con un botón en master101 dentro de cada empresa. Primero cuenta sin escribir (cuántas obras, planos, ítems, fotos; quién tiene cuenta en la suite y quién no); si cuadra, trae de verdad: filas con la misma llave y la misma fecha, archivos copiados al bucket de la suite bajo la empresa. Se puede repetir: lo que ya está se actualiza, nada se borra, y lo que la empresa creó después se queda.
Qué
De dónde
A dónde
Obras, planos, ítems, bitácora, pendientes, dudas, contratistas por ítem, etapas
la D1 bitacora-obra
las tablas quell_* de la base de la empresa
Quién es cada quien en obra (dueño, supervisor, contratista, cliente)
users de esa D1
quell_users, casado por correo con la cuenta de la suite
Planos y fotos
el bucket bitacora-obra-files
el bucket suite101, bajo orgs/{empresa}/quell/
Instaladores de Android y Windows
se quedan donde estaban: no son datos de ninguna empresa
La base vieja no se borra el mismo día. Queda en Cloudflare, sin que nadie la lea, como red de seguridad. Se borra cuando la mudanza lleve unos días sin sorpresas.
Lo que cambia para cada quien
Para el taller y sus contratistas: nada a la vista. Misma dirección, misma pantalla, misma cuenta.
Para MASTER101: dentro de cada empresa ve cuántas obras, planos, ítems y fotos tiene en quell101, y el botón de la mudanza.
Para la seguridad: una regla más en la puerta de la suite. Un cliente, además de su estado de cuenta, abre lo que quell101 le recorta (su plano y sus puntos por definir). Es la única excepción a «un cliente sólo abre /peek», y está probada renglón por renglón.
Cómo se probó
API: 247 pruebas en workerd, 19 nuevas: la puerta (el dueño nace como dueño de la bitácora; sin quell101 en la lista, 403; sin renglón en obra, 401), planos al bucket de la empresa y servidos sólo con sesión, el código por obra, los contratistas y el recorte del servidor, la cara de cliente con la invitación pasando por la suite, borrar una obra con sus archivos, y la mudanza desde una D1 sembrada con el esquema real: en seco no escribe; de verdad trae filas y archivos; repetirla no duplica ni borra lo nuevo.
quell101: la puerta del cascarón (26 revisiones: a qué empresa le toca cada quien, qué viaja y qué no) y el humo de staging de punta a punta en cada despliegue.
master101: el recorrido con navegador contra staging (el bloque cuenta lo que hay; contar en seco contesta con palabras).