Los expedientes de trabajadores dejaron de tener base propia: 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 segunda app que se muda, tras quell101, y con ella se retira la «central» de roster101: el alta de una empresa va por master101. Las dos puertas —el trabajador con su correo y un código, la empresa con su cuenta de la suite— siguen siendo dos.
Al 19 de septiembre de 2026Contrato de la API 0.17.0Decisiones de Mike: todo en la base de la suite · retirar la central · un Worker por empresa
Antes y después
Hasta el 19 de septiembre cada empresa tenía un Worker de roster101 con su base D1 y su bucket R2 propios, y aparte existía la «central»: un registro donde una empresa nueva entregaba sus papeles y roster101 le abría su portal (tenía cero empresas). Desde el 19, el Worker de cada empresa sólo sirve la pantalla y todo lo demás está en la suite; la central se retiró.
La pantalla no cambió y las reglas tampoco: lo que se movió fue dónde corren y dónde guardan. La central desapareció porque master101 ya hace lo que hacía.
Por qué así
Una base por empresa, para todo. Los expedientes viven junto a las obras de quell101 y las cuentas de dash101, en la base que nace sola al primer uso. Si una empresa apaga roster101, sus expedientes siguen ahí; si la reactiva, los vuelve a ver.
El motor se movió tal cual. Los frenos de datos repetidos, la papelera de 30 días, las fichas en PDF, la exportación en ZIP, los tres niveles del panel y sus candados: es el mismo archivo que corría en el Worker, con cuatro cambios (tablas con prefijo, la sesión la da la puerta de la suite, documentos en el bucket de la suite, los datos de la empresa llegan en cada petición). Por eso sus pruebas pasaron a la API sin reescribirse.
Las dos puertas siguen siendo dos. Mike lo decidió el 16 de septiembre: el trabajador entra con su correo y un código, sin cuenta en la suite, y así sigue; sólo que ahora su cookie la firma el secreto de la suite. El panel entra con la cuenta de la suite. Por eso roster101 tiene su propia puerta en la API (/roster/…) en vez de colgar de la de siempre, que exige sesión para todo.
Un Worker por empresa, como siempre. Mike escogió seguir así en vez de un solo portal con la empresa en la liga. Cada empresa tiene su dirección y su Worker; lo que ya no tiene es base ni bucket propios: el Worker sólo sabe de qué empresa es (ORG_ID) y cómo se llama en lo que ve su gente.
La central se retiró. Tenía cero empresas y hacía a mano lo que master101 hace desde el 18 de septiembre: dar de alta una empresa. Ahora el alta es: la empresa en master101 con roster101 prendida, y un archivo de configuración para su Worker. El dueño y la administración de la empresa abren el panel como dueños desde el primer día, sin que nadie los apunte.
roster101 ganó staging. Antes cada cambio se probaba contra los expedientes de verdad. Ahora hay un Worker de staging contra la API de staging y la empresa demo, y el despliegue entra al panel, entra como trabajador, acepta el aviso y borra lo que creó 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ántos expedientes, documentos, avisos aceptados, cuentas del panel, y cuáles de ésas no tienen todavía cuenta en la suite); si cuadra, trae de verdad: filas con la misma llave y la misma fecha, documentos copiados al bucket de la suite bajo la empresa. Se puede repetir: lo que ya está se actualiza, nada se borra.
Qué
De dónde
A dónde
Expedientes, consentimientos, papelera, bitácora
la D1 t101-trabajadores
las tablas roster_* de la base de la empresa
Las cuentas del panel (de qué nivel es cada quien)
administradores de esa D1
roster_administradores; se dice cuáles no tienen cuenta en la suite todavía
Documentos
el bucket t101-documentos
el bucket suite101, bajo orgs/{empresa}/roster/, con la misma llave
Los códigos de acceso y las tablas de la contraseña vieja del panel
se quedan atrás: valen diez minutos, o ya estaban vacías
La base y el bucket viejos no se borran el mismo día. Quedan en Cloudflare, sin que nadie los lea, como red de seguridad. Se borran cuando la mudanza lleve unos días sin sorpresas.
Lo que cambia para cada quien
Para el trabajador: nada a la vista. Misma dirección, misma pantalla, mismo correo y código. Quien tenía la sesión abierta vuelve a pedir su código una vez.
Para la administración de la empresa: nada a la vista. El dueño y la administración de la empresa entran como dueños del panel aunque nadie los haya dado de alta en él.
Para MASTER101: dentro de cada empresa ve cuántos expedientes, documentos y cuentas del panel tiene en roster101, y el botón de la mudanza. Y da de alta empresas para roster101, que antes era cosa de la central.
Para la seguridad: los documentos se sirven desde dentro de la base de la empresa: quién puede ver cada uno lo dice la base (su dueño o el panel), no la dirección. Nada de una empresa se alcanza desde la puerta de otra.
Cómo se probó
API: 275 pruebas en workerd, 28 nuevas: la puerta (sin X-App, sin empresa, con roster101 apagada), quién entra al panel (el dueño de la suite y el de la empresa como dueños; sin roster en su lista, 401; consulta no exporta; apagar una cuenta surte efecto al momento; el último dueño no se borra), el trabajador por su puerta (código, cookie, aviso obligatorio, un documento que ve él y el panel pero no otro trabajador, la CURP repetida que no se guarda), el panel (captura a nombre del trabajador, fichas en PDF y ZIP, exportación, bitácora, papelera con el choque de NSS y el borrado con documentos), y la mudanza desde una D1 sembrada con el esquema real: en seco no escribe; de verdad trae filas y archivos; repetirla no duplica.
roster101: el cascarón con una suite de mentiras (22 comprobaciones: ruta, empresa, cookies, datos de la empresa en ASCII, cuerpos JSON y multipart) 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).