尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
依最近已完成的 8 小時觀測回合間的 GitHub 星號增量排序
免費開源的 Mac 清理工具，可清理快取、Xcode 垃圾與應用殘留。優先放入廢紙簍，無遙測。可用 Homebrew 安裝，或下載以用於 macOS 13+。
AI 翻譯
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權，自行管理介紹，無需管理員核准。
登入並產生驗證檔案，在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案，即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入，將前往登入頁面。登入後請回到此處，再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify，即可驗證所有權並自行管理介紹。
一分鐘完成驗證製作者的介紹僅有上面的一句話。 更多詳情請閱讀儲存庫 README。 儲存庫 README ↗
正在載入完整 README。
檢視完整 README ↗Demo funcional con datos y nombres ficticios (ningún mandante, contratista ni persona real). Una restricción recorre los cuatro niveles de gobernanza: POD/3WLA → revisión del Owner → Sponsor Meeting → Steerco, con el módulo de Seguridad Psicológica (escala de Edmondson) como alerta temprana.
npm install
npm run build && npm start # http://localhost:3000
No requiere servidor de base de datos: usa Postgres embebido (PGlite) en memoria. Cada arranque, o el botón
“Reiniciar datos de la demo”, deja la base en el estado inicial. El esquema está en db/schema.sql y es SQL de Postgres,
portable a un Postgres real.
| Pantalla | Regla de negocio activa |
|---|---|
| Restricciones · 3WLA | Sin SMART → ELIMINAR · fecha anterior a la carga → CNC · dueño por defecto según causa · al cerrar la 3WLA, lo del Owner no liberado escala al Sponsor |
| Lookahead · ITE | Ejecutable = liberado y sin restricción abierta; liberar una restricción libera sus ítems |
| POD asistido (6 pasos) | Asistencia con personal clave y regla de más de 80% · cruz de seguridad y riesgos críticos · turno anterior con PPC (meta 90%), PF, pareto de CNC y reasignación · plan de hoy con actividades restringidas fuera del plan y backlog · compromiso confiable (sin responsable o fecha no se registra; más de 3 turnos se deriva al Obeya Táctico) · minuta generada y checklist POD de 22 ítems puntuado (auto y manual) |
| Sponsor Meeting | Decisiones desde lo escalado; acta con informativos y compromisos que se arrastran; respuestas del Owner a tiempo |
| Steerco | Abre con el % de cumplimiento de la sesión anterior |
| Seguridad Psicológica | Encuesta QR anónima; grupos bajo el umbral mínimo no se muestran; solo datos agregados |
| Agente de sesión | Guionado (sin servicios externos): propone, el responsable valida; solo lo validado entra al registro |
| Carpeta | Contenido |
|---|---|
app/ | Pantallas y acciones de servidor (Next.js, App Router) |
components/ | Componentes compartidos (gráficos, reloj, copiar minuta) |
lib/ | Reglas de negocio (rules.ts, checklist.ts, pod.ts), consultas, datos ficticios (seed.ts) y notas del agente (notas.ts) |
db/schema.sql | Esquema Postgres de la demo |
El paso "Turno anterior" del POD de obra se basa en registros de tool time sobre una jornada de 12 h. Cada segmento se clasifica con la nomenclatura del Estudio de Factores que Afectan la Productividad en la Construcción Minera 2015: AV (agrega valor), So (soporte), NAV (no agrega valor, las interferencias, con su causa 6M) y DA (detención autorizada). De ahí salen JT, WT, TE y TNU, que se comparan con la Oferta Técnica del contrato: el ciclo de turno ofertado (casa de cambio, charla, traslados, trabajo en frente 1, colación, trabajo en frente 2, salida) y las horas efectivas prometidas, editables en /configuracion. Lo que una detención autorizada excede de su bloque se cuenta como interferencia. Cada actividad medida muestra sus horas efectivas, contributivas e interferencias y su línea de tiempo.
Una unidad de trabajo completada (IWP) se protocoliza. Cada unidad tiene sus protocolos requeridos (por ejemplo enfierradura, moldaje y hormigonado en una losa); el contratista declara el avance físico y solo los protocolos aprobados lo validan: avance validado = el menor entre el declarado y la proporción de protocolos requeridos aprobados. Los protocolos siguen un flujo (pendiente, revisión interna, enviado al Owner, aprobado, aprobado con observaciones o devuelto), una revisión del Owner de más de 7 días se marca como atrasada, y uno devuelto crea un compromiso para levantar las observaciones. Solo un protocolo aprobado puede adjuntarse a un Estado de Pago en borrador, y cada uno aporta su parte del valor de la unidad. Se ve en /calidad, en el paso "Calidad y protocolos" del POD de obra y en cada ítem del lookahead.
/configuracion): ítems, pesos y ítems propios. Los ítems con clave automática se evalúan con los datos de la sesión.git remote add origin [email protected]:<tu-usuario>/<repo-privado>.git
git push -u origin main
Guion de presentación: /guion dentro de la app.
/estado-pago: EDP con partidas, cantidades protocolizadas, GG/utilidades, reajuste IPC, IVA y avance financiero vs. programado./horas-efectivas: serie diaria de horas efectivas contra la oferta técnica y pareto de excesos. ?fuente=importado muestra los datos cargados desde /importar./importar: carga de la base de Gemba walk (hoja “BD …”, columnas por nombre) y de protocolos de calidad (CSV/xlsx; plantilla en /importar/plantilla-protocolos). Lo importado usa ids imp-…, se reemplaza en cada carga y no toca los datos de ejemplo.
LKS_PERSIST=1 npm start guarda la base en .data/lks (ignorado por git)./portafolio: cartera con dos configuraciones del mismo motor. Por Gates (FEL): Gate 1, 2A, 2B y 3 con escenarios y reapertura. Por API: autorización por etapa, reformulaciones y post-evaluación. Cada fase tiene tres nombres (Gate o API / FEL / nombre) y el catálogo, la cadena de aprobación y los umbrales de semáforo son datos editables./portafolio/[id]: ficha del proyecto (estado general con sus causas, preparación del Gate con criterios manuales y automáticos, cadena de aprobación, escenarios, API, alertas A/M/B, hitos, decisiones solicitadas y evidencia). Pasar el Gate exige criterios al 100%, sin alertas altas abiertas y la cadena firmada./portafolio/[id]/informe: capítulo 1 del informe mensual generado desde los datos (indicadores, hechos, visión general, alertas, hitos)./portafolio/[id]/costo: CAPEX entre revisiones por fase, tendencias con causa raíz, reformulaciones y post-evaluación (promesa contra real)./steerco: sesión con las decisiones pendientes del portafolio y el cumplimiento de la sesión anterior.db/api-referencia.json (cifras anonimizadas: montos x 0,37, años +6, sin nombres ni códigos reales). Los umbrales de semáforo, el umbral de reformulación (10%), las transiciones de las tendencias y las reglas de preparación del Gate son supuestos a validar. Diseño y plan: docs/PROPUESTA_MODULO_STEERCO.md.localhost:3000 y limpio, NODE_PATH=$(npm root -g) node tests/e2e/port.js. Reinicia el servidor entre suites porque las pruebas modifican datos.campo-app/, estática): /campo-app/index.html (y /campo redirige allí). Se compila a public/campo-app/ con npm run build:campo (parte de npm run build); es la misma carpeta que Capacitor usará como webDir en la etapa 3. Funciona con y sin señal: guarda primero en el teléfono y envía después.lib/campo-calc.ts, funciones puras): HH de un intervalo = duración en horas × personas a cargo; HH gastadas de la tarea = suma. Niveles del autorreporte: efectivo + contributivo combinado, interferencia y detención autorizada. El exceso de una detención sobre lo ofertado pasa a interferencia (causa 1.6). Con varias tareas, la detención se reparte en proporción a las HH directas y nunca se cuenta dos veces. Se calculan siempre las dos bases del PF; la oficial es el parámetro pf_base del contrato. Duración del turno como parámetro y turnos que cruzan la medianoche. El servidor recalcula siempre.navigator.onLine. Service worker para abrir la app sin señal./api/campo/*, token por dispositivo, roles supervisor, jefe_terreno, productividad y owner_lectura, CORS abierto para la app empaquetada): usuarios, login (5 intentos y bloqueo de 5 min), tareas, tooltime (idempotente por client_uuid; responde aceptado, duplicado, conflicto 409 con motivo o rechazado 422) y hora.Al enviar, la app toma un solo punto GPS (sin seguimiento continuo; si no hay permiso o señal en 8 s, el envío sigue sin él). El servidor valida el rango y lo compara con los puntos de ubicacion_ref (tipo FRENTE o SALA_OBEYA, con radio en metros). Guarda el frente más cercano, la distancia y gps_fuera si excede el radio; marca, no rechaza. Los puntos del demo son inventados: el cliente carga los suyos. Pendiente: pantalla para cargarlos o importarlos desde KMZ, mapa de interferencias por frente, cruce con restricciones y Sala Obeya por geolocalización, y el permiso de ubicación en el APK (etapa 3).
Pantalla /gobernanza. Instancias del modelo de gobernanza con su cadencia y su próxima fecha (si los días no están confirmados se muestra «por definir», no se inventan), semana de cada contrato según el día 1 del corte del P6 (lunes o sábado), las tres semanas del 3WLA (semana 1 de control y semanas 2 y 3 por liberar) y el registro unificado con los cinco orígenes B.LOG, O.GER, CHAMP, C.PSR y EECC. Lógica en lib/gobernanza.ts con 21 pruebas. Diseño de la fase siguiente en docs/MODELO_DATOS_ITE_SC.md.
Cada sesión de la Obeya Gerencial (una por cartera), del Obeya Táctico y del POD muestra su encuesta y se responde desde el celular en /encuesta?i=<instancia>&c=<ámbito>&f=<fecha>. Escala de 7 ítems en Likert 1–5, con P1, P3 y P5 invertidos (6 − valor), según el manual entregado (lib/edmondson.ts, 23 pruebas). Zonas del manual: 1,00–2,99 ansiedad o miedo; 3,00–3,79 neutral; 3,80–5,00 aprendizaje; desviación estándar mayor a 1,0 marca «cultura fragmentada». Supuestos míos: desviación muestral (n − 1) y promedio redondeado a 2 decimales antes de clasificar.
Anónima por diseño (lib/sp-edmondson.ts, 19 pruebas): no se guarda persona, dispositivo ni hora; solo los 7 valores y un identificador aleatorio que agrupa una respuesta. Bajo el mínimo de respuestas no se muestra ni un promedio. El mínimo y el tamaño esperado dependen de la sesión (tamaños dichos por Jorge; mínimos provisorios): POD unas 20 personas, mínimo 8; Obeya Táctico unas 10 (los líderes de cada contratista), mínimo 5; Obeya Gerencial unas 10, mínimo 5. Se muestra también la participación sobre el tamaño esperado. Los datos pertenecen a la organización dueña de la instalación de LKS (config.dueno_datos). Pendiente: un código por sesión para evitar respuestas repetidas sin identificar a nadie, y el límite entre organizaciones cuando haya varias en la misma instalación.
lib/xer.ts lee un XER (actividades, relaciones, WBS, calendarios, avance, campos de usuario y códigos de actividad) y compara dos revisiones; lib/plan.ts lo importa como una revisión del contrato; pantalla /plan para subir archivos de hasta 25 MB. Probado con cinco XER reales (0,1 a 1 segundo por archivo; los archivos reales quedan fuera del repositorio) y con un XER ficticio en las pruebas (lib/xer-demo.ts). Avance: terminada 100, no iniciada 0, en curso según el tipo de avance de P6 (físico o por duración); se guardan ambos. Ciclo de aprobación del trisemanal en lib/gobernanza.ts. Falta el ITE, la sesión del 3WLA y la Semana de Control sobre estas tablas.
Pantalla /ite sobre el último XER importado del contrato. Cada actividad tiene un estado: liberada, en ejecución, restringida, detenida, stand by o cerrada (lib/ite.ts, 36 pruebas). Solo lo liberado o en ejecución sin restricciones es elegible para la Semana de Control. Una restricción puede afectar una tarea del POD, una actividad, un entregable o el contrato completo (por ejemplo un accidente, que además detiene los trabajos). Detener o poner en stand by una actividad lo hace solo su dueño (jefe de terreno o jefe de especialidad) y exige un motivo; todo queda registrado en ite_estado_log. En la demo se elige quién actúa; en producción lo define el usuario autenticado.
Catálogos de CNC por contrato en cnc_catalogo, validados por Jorge: la primera clasificación es siempre las 6M. El de construcción trae 92 causas y el de ingeniería 31 (lib/cnc-catalogo-data.ts, genérico, sin nombres de empresas). Tres códigos venían duplicados en el origen (1.3, 8.6 y 10.1) y el segundo quedó con sufijo «b». La clasificación de cada causa de construcción en las 6M es propuesta de Claude.
Pantalla /trisemanal (lib/trisemanal.ts, 42 pruebas). El contratista programa tres semanas a partir del ITE: la semana 1 es la siguiente a la de la sesión y es la Semana de Control, así que solo entra lo liberado de restricciones; en las semanas 2 y 3 entra también lo restringido o detenido, que es lo que se va liberando. Lo cerrado nunca. Al enviarlo, la semana 1 debe tener actividades y todas deben seguir libres de restricciones en ese momento. El dueño lo aprueba u observa (observar exige una nota; que pueda observarlo y devolverlo es un supuesto por confirmar). Un trisemanal enviado o aprobado no se modifica. Al aprobarlo, su semana 1 es la Semana de Control vigente. Todo queda en una bitácora. Una sola sesión por semana 1 y contrato.
Pantalla /avance (lib/evm.ts con 32 pruebas, lib/avance.ts). Con las HH de mano de obra que trae el XER (recursos de tipo mano de obra) calcula, a la fecha de corte de la última revisión: BAC, PV (reparto lineal entre inicio y fin de cada actividad), EV (BAC × avance), AC (HH reales), CPI, SPI, SV, CV, PF (= AC / EV = 1 / CPI), EAC, ETC, VAC y TCPI, con las fórmulas de la hoja PMP entregada. Tres escenarios de cierre por fórmula (optimista: el resto al plan; base: BAC / CPI; pesimista: AC + (BAC − EV) / (CPI × SPI)), curva S planificada contra los puntos reales de cada revisión, HH por semana (programado, real con tool time y proyectado en el trisemanal), cumplimiento semanal, revisiones del programa con el cambio del término y acciones sugeridas con umbrales provisorios. Dos medidas de avance conviven: el de la cabecera pondera por HH y el de la tabla de revisiones, por duración.
La infografía de ejemplo no cumple sus propias fórmulas (con CPI 0,70 el EAC por BAC / CPI es 14,3 y no 12,0); el sistema usa las fórmulas de la hoja, no las cifras de la infografía. Aún no están: pipeline de personal y de maquinaria, género y región, matriz de riesgos, estados de pago real contra programado y notas y órdenes de cambio.
El trisemanal ahora proyecta HH por actividad y semana (si no se indican, se proponen las HH restantes del programa) y el dueño puede aprobar, aprobar con observaciones (queda aprobado) o devolverlo.
Pantalla /semana-control (lib/sc-cierre.ts, lib/semana-control.ts; 47 pruebas del cierre). La Semana de Control es la semana 1 de un trisemanal aprobado. El contratista registra por actividad si se cumplió, las HH ganadas y, en cada «NO», la causa de no cumplimiento del catálogo validado del contrato (primero las 6M). Reglas: el PPC es cumplidas sobre planificadas; una fila en blanco cuenta como no realizada y también pide su causa; un «NO» sin causa no deja cerrar; el trabajo adicional se registra aparte y no suma al PPC; una semana cerrada no se modifica. HH perdidas = HH planificadas − HH ganadas en lo no cumplido. Al cerrar, lo que sube al Obeya Táctico es la serie de PPC y el pareto de las HH perdidas por causa, por M y por responsabilidad (gestión de la contratista, o del dueño y externas); lo no cumplido llega al 3WLA en la pantalla del trisemanal, con su causa. La Semana de Control se cierra al terminar la semana (regla de Jorge): no antes de su último día. En la demo hay un botón para simular el fin de la semana.
Decisión de Jorge: la escala de Edmondson está validada, así que reemplaza al OPSI de 4 ítems provisorios. /sp muestra, por contrato, el índice (0–100), el promedio, la zona, los 7 ítems y las sesiones de la última semana con su participación. El índice de la cartera y del Sponsor Meeting sale de ese cálculo. El mínimo de respuestas y el tamaño esperado de cada tipo de sesión (POD, Obeya Táctico y Obeya Gerencial) se ajustan en /configuracion; el mínimo no puede bajar de 3 para proteger el anonimato. /encuesta pide elegir la sesión.
/checklist-sesiones (lib/checklist-sesion.ts, lib/seed-checklists.ts): checklists del Trisemanal (21 ítems) y de la Obeya (20 ítems), además del POD que ya existía. Cada plantilla indica a qué sesión corresponde. Cinco bloques (preparación, rutina, cumplimiento, terreno y cultura) con pesos normalizados dentro de cada bloque; la Obeya tiene cuatro bloques de 25 %. Cada evaluación queda guardada y se ve la adherencia en el tiempo. Los textos están resumidos de las planillas de adherencia entregadas.
Pantalla /flujo: los cinco niveles (Steerco, Obeya Gerencial, Obeya Táctico y 3WLA, POD y Campo) con lo que sube a cada uno, lo que baja y un dato real de la demo. El Tool Time del supervisor es el origen de lo que sube. Las tareas del POD se vinculan a las actividades del programa (tarea_pod.actividad_codigo), de modo que el tool time confirmado llega a la Semana de Control: cada actividad muestra las HH gastadas y el PF que dice el tool time y la pantalla sugiere las HH ganadas (el usuario las ajusta). La ruta /guion parte por este mapa y por Campo.
/decisiones: registro de decisiones con porqué, alternativas, reversibilidad y condición de revisión; decisiones fuera del sistema con enlace a su evidencia (sin enlace, «pendiente de formalizar»); atribución por restricción y actividad (quién detecta, frena, replantea y libera, con su límite). El trisemanal exige el porqué al aprobar, aprobar con observaciones o devolver; detener, reanudar y liberar restricciones también dejan su decisión./modelo: el macroproceso y la gobernanza sobre el ciclo Last Kata® (imagen en public/modelo/lks-macroproceso.svg), con el vínculo de cada parte a su pantalla.El paso 5 de la app del supervisor («Seguridad») pregunta si hubo accidentes en el turno y, si hubo, de qué tipo (daño material, STP o CTP). Es obligatorio para enviar y no admite nombres. En el POD del turno siguiente, la pestaña de seguridad muestra lo informado y llena con un clic la cruz de seguridad del día de ese turno (lib/seguridad-turno.ts, tabla seguridad_turno, 25 pruebas unitarias y la suite seg). La alerta inmediata y la detención de trabajos ante un accidente siguen pendientes.
El POD de obra no se inicia hasta que todos los supervisores del turno anterior cierran su tool time (todas sus tareas enviadas y la seguridad respondida). La pantalla del POD muestra a cada supervisor con sus tareas enviadas; si falta alguno, solo se inicia indicando el motivo, que queda registrado (lib/cierre-tooltime.ts, 14 pruebas unitarias y la suite seg).
/mejoramientos: las HH perdidas por CNC se tratan según su umbral y su impacto. Por frente, el contratista abre un RDP (A3 de 3 u 8 pasos); por contrato, el dueño abre un Kaizen; lo demás es un compromiso de mejora del Obeya Táctico. Cada uno termina en compromisos (que liberan una restricción o mejoran una CNC) y su efecto se mide en HH perdidas, PF, SPI y el KPI del A3 a una fecha de corte. Registro con código A3, estado y vista mensual (lib/mejoramiento.ts, 44 pruebas unitarias y la suite mej). Umbrales ficticios en la demo; el nivel es una sugerencia y queda su porqué en /decisiones.
/plan revisa la calidad del XER importado con 9 de los 14 puntos de la verificación DCMA y declara los 5 que no evalúa. /avance muestra el SPI de costo junto al SPI(t) (cronograma ganado) y al BEI, porque el SPI de costo tiende a 1 al terminar aunque haya atraso (lib/calidad-programa.ts, lib/evm.ts; 13 y 9 pruebas unitarias nuevas). Referencia: A. M. Badr, guía independiente, 2026. El manual de usuario está en docs/LKS_manual_de_usuario.docx.
El logo de Last Kata System está en public/brand/ y se usa en el menú lateral, el favicon, el login de la app de campo y los documentos. Autor: Jorge Vilches.
/obeya-tactico: la reunión semanal del contrato, con el Owner invitado, en seis pasos (asistencia y preparación, resultados, causas y mejoramientos, restricciones y compromisos, avance y escalamiento, cierre). Trae los datos de la Semana de Control, los mejoramientos, las restricciones y el avance, y genera la minuta (lib/obeya-tactico.ts, 18 pruebas unitarias y la suite obt).
/areas: bandeja de restricciones y requisitos previos de cada jefe o líder de área, con las HH que bloquean y su fecha límite (7 días antes de la semana programada en el trisemanal). Aceptar con fecha, liberar sin evidencia, replantear, agregar requisitos, envío diario y corte semanal por área que entra al 3WLA (lib/areas.ts, 33 pruebas unitarias y la suite areas).
/plan-dia: la salida del POD para supervisores y jefes del ITE, con las columnas del plan real de un contratista (N° POD, responsable, área, actividad y ID del P6, ítem, categoría primaria o soporte, cantidad y unidad, recursos por rol, contrato). Se imprime, se ve en la plataforma o se comparte por QR y WhatsApp (lib/plan-dia.ts, 17 pruebas unitarias y la suite plandia).
Jornada = detención autorizada + tiempo hábil; tiempo hábil = tiempo efectivo (agrega valor + soporte) + no agrega valor. Explicación, ejemplos y fuentes en docs/METODO_TIEMPOS.md.
La app de campo tiene el rol jefe_area: cada jefe o líder de área ve su bandeja de restricciones, acepta con una fecha, libera con una línea de qué hizo o replantea con su motivo, incluso sin señal. Las acciones se envían al volver la conexión; si la restricción ya cambió, el servidor lo informa como conflicto (lib/ite-campo.ts, 12 pruebas unitarias y la suite iteArea). Demo: Diego Fuentes (PIN 7777, contratista) y Camila Rojas (PIN 9999, dueño).
/encuesta muestra las siete frases de Edmondson con una escala de círculos (de totalmente de acuerdo a totalmente en desacuerdo), más fácil de responder en el celular. No requiere cuenta ni PIN: también la responden las visitas, y nadie queda identificado. Los valores y el cálculo no cambian (tests/e2e/encuesta.js).
Antes de responder la encuesta de seguridad psicológica, la persona acepta una cláusula. Al aceptar se guardan la hora y, si autoriza el GPS, su ubicación y la faena más cercana, en una tabla separada de las respuestas y sin vínculo con ellas. El comprobante sirve una vez (lib/consentimiento-sp.ts, 9 pruebas unitarias y la suite encuestaClausula). Pendiente la revisión legal de datos personales y geolocalización.
/avance muestra el tablero de 10 indicadores de gestión de construcción (SPI, IPT, IPOD, PF, PPF, CPI, PAC, PTL, PIE, BAI). Cada mandante define sus metas y alarmas en /configuracion. Hoy se calculan seis; los otros cuatro se declaran no evaluados con su motivo (lib/kpi-construccion.ts, 25 pruebas unitarias y la suite kpi).
lib/riesgo.ts (funciones puras) y lib/riesgo-db.ts (tablas riesgo_umbral, riesgo_actividad, riesgo_excepcion, param_tooltime).
param_tooltime). El supervisor confirma cada corte en la app de campo, también sin señal (cola corte_cola).lib/seed-riesgo.ts) es ficticia y sigue la estructura de una matriz SSOMA. Las matrices reales están solo en lks-private/riesgos/./configuracion-riesgo (menú Configuración): umbrales, matriz por actividad, cortes de Tool Time (día y noche) y excepciones, por contrato./configuracion), oferta técnica, seguridad psicológica · mínimos, indicadores · metas por mandante, riesgo y Tool Time, y adherencia./avance como «Restricciones levantadas a tiempo» (meta y alarma por mandante).registro_riesgo). El registro de riesgos del día se ve en «Plan de hoy» del POD, por actividad en ejecución y con la verificación del riesgo crítico (riesgo_critico.tarea_id). El paso Calidad del POD muestra solo el resumen; la gestión está en la sección «Calidad». Al iniciar un POD o un Obeya Táctico aparece la guía con cronómetro y el asistente que transcribe y resume (ver CLAUDE.md).El ITE es el aplicativo con el que las jefaturas de cada área de conocimiento, del contratista y del dueño, liberan restricciones. Tablas: area_conocimiento (catálogo), persona.area_id y restriccion.area_id.
/areas, pestaña «Panel por área»): por cada área, quiénes la representan de cada parte, restricciones abiertas, vencidas, que vencen esta semana, por aceptar, HH en juego y de quién son (dueño, contratista o terceros). Sin ranking ni puntaje./areas (por área) y en /ite (restricciones del contrato por área); al registrar una restricción se elige su área.lib/area-conocimiento.ts).tests/unit/area-conocimiento.test.ts y la suite areaCon.Las APK https de la versión 0.5.1 vienen apuntando a https://www.lastkata.store (ver docs/APK_LKS_CAMPO.md). La plataforma web exige login con cuentas Gmail (docs/AUTENTICACION.md).
La app de campo empaquetada como tres aplicaciones Android con Capacitor (capacitor.config.ts, proyecto android/ con tres sabores, docs/APK_LKS_CAMPO.md): LKS Tool Time para los supervisores (Tool Time y cortes del turno) y LKS ITE para los jefes de área que liberan restricciones y LKS Calidad para el inspector de calidad del contratista (emitir a revisión interna, enviar al dueño y reenviar los protocolos devueltos; aprobar o devolver es del dueño; lib/calidad-campo.ts, campo-app/Calidad.tsx, suite calidadCampo y tests/unit/calidad-campo.test.ts). Cada una solo deja entrar a su rol, se instalan a la vez y funcionan sin señal. Dos variantes de red: https (recomendada) y red local http (solo pruebas, sin cifrar). Se compilan con npm run apk (JDK 21 y Android SDK 36). Estado: APK de prueba firmados con la clave de depuración, probada solo hasta la pantalla de ingreso en un teléfono real; faltan la firma de lanzamiento, la distribución y un servidor con https.
package.jsonnpm run test:unit (cálculo, 59 casos hechos a mano), npx tsx tests/unit/campo-servidor.test.ts (servidor: 50) y NODE_PATH=$(npm root -g) node tests/e2e/campo.js (celular sin señal, cola, idempotencia, conflicto y roles; servidor limpio).riesgoiteAreaareasttcampokpi