Bitácora de producto

Mesita mejora
todos los días.

Un diario automático de lo que cambió, por qué se hizo y cómo mejora la experiencia del restaurante.

0

cambios recientes

0

días registrados

Fuente automática: commits de GitHubContexto editorial: TODAY.mdSe refresca cada 15 min · cada deployment

Historias destacadas

Qué cambió y por qué

16 sept 2026

Dependabot: los majors del toolchain (TypeScript 7, @types/node 26, vitest 5) salen del tren semanal y el tsconfig declara ES2022 — PR contra main, nada a production

Por qué

JuanJa pidió resolver los tres PRs rojos de dependabot (#322, #324, #325). Ninguno puede ponerse verde sin un cambio de runtime o de framework: TypeScript 7 elimina baseUrl (TS5102) y typescript-eslint 8.70 solo acepta <6.1; @types/node 26 describe un Node que no es el 20 de CI y producción (y al perder los shims viejos, los 9 usos de .at() fallaban con TS2550 porque el lib decía ES2020); @vitest/coverage-v8 5 exige vitest 5 exacto y el regenerador de lockfile de dependabot se cayó con $postcss.

Qué mejora

dependabot deja de abrir PRs rojos por esos majors (se suben a mano en la Fase 5), vitest y sus plugins llegan siempre en un solo PR, y el tsconfig dice la verdad sobre lo que el código ya usa (ES2022: .at()), así que un cambio de tipos no vuelve a romper el typecheck por eso. Verificado: tsc limpio, eslint sin avisos, tests que usan .at() 18/18. No toca el bridge ni el POS de Bogo (config de CI y de tipos; ni una línea de runtime). Los tres PRs se cierran con la explicación. ### 2026-09-16 (17)

15 sept 2026

MES-49: puerta 3 encendida y probada — migrate conecta, pero el check de DDL destructivo tropieza con las tablas del simulador (MES-47)

Por qué

verificar la puerta 3 sin esperar a una promoción real.

Qué mejora

preflight ya solo avisa por la puerta 4 (adrede); gate y backup verdes; migrate conecta y prisma migrate status dice «56 migrations found — Database schema is up to date» — no hay nada pendiente. Falla el paso siguiente, «Rechazar DDL destructivo»: compara la base viva contra schema.prisma (migrate diff --from-url … --to-schema-datamodel) y la base viva tiene en public 9 tablas que no son de esta app (categorias, cobros, documentos, documento_detalles, mesas, mesitaqr_sessions, ordenes, orden_de

14 sept 2026

MES-49: environment production-database creado; los required reviewers los bloquea el plan Free

Por qué

MES-49 llevaba desde el 09-09 en Todo esperando a un admin; desde el 14-09 Juan Javier lo es. Se avanzó todo lo que no requiere pegar una credencial ni pagar el plan.

Qué mejora

el environment ya existe, así que en cuanto se cargue PRODUCTION_DIRECT_URL el job migrate de «Deploy production» deja de omitirse. OJO: sin reviewers no hay puerta humana — migrate correría solo en cada push a production (con respaldo previo y el check de DDL destructivo, pero sin aprobación). Es la misma exposición que hoy tiene migrate-production.yml, no peor, pero hay que decidirlo a propósito antes de cargar el secret. La puerta 4 (VERCEL_*) queda apagada adrede: encenderla sin desactivar l

14 sept 2026

Caja 0.12.27: el updater ya no queda apuntando al feed viejo cuando fallan los dos (MES-89)

Por qué

caso real en fake-club (Mac, 0.12.26) a las 01:19Z del 15-sep: un ERR_NETWORK_CHANGED hizo fallar la org y luego la dirección vieja. La rotación volvió a la org por dentro, pero nadie llamó a setFeedURL, así que electron-updater y el heartbeat siguieron en manuelmmontufarm-dev/…. Hoy no rompe nada (la redirección de GitHub funciona), pero si esa redirección desapareciera la caja se quedaría pegada al feed muerto y nunca volvería a la org, justo lo que MES-60 quería evitar.

Qué mejora

tras un corte que tumba los dos feeds, la caja vuelve a leer de MesitaQr/mesita-caja-releases y lo reporta así. El resto del comportamiento no cambia.

Actividad automática

Cambios por día

Cada commit nuevo aparece agrupado por fecha de Ecuador.

No se pudo consultar GitHub en este momento.

La bitácora volverá a intentarlo automáticamente.