Sorta

• Construir en fases aprobadas. No implementar un lienzo de anotación, importación de conjuntos de datos, entrenamiento, inferencia ni paneles de modelos hasta que cada uno se autorice por separado.
• Las decisiones de clasificación y segmentación se registran por separado y nunca se reducen a un único estado.
• Residual significa un elemento identificable visualmente que no pertenece a ninguna de las otras siete categorías. Nunca sustituye la incertidumbre, la falta de nitidez o la dificultad.
• Peligroso se asigna solo por una identidad visible o una regla aprobada; desconocer el contenido nunca es suficiente.
• Las etiquetas son metadatos descriptivos opcionales. Nunca son clases semánticas ni forman parte del objetivo de un modelo.
• Las imágenes originales siguen siendo privadas y nunca se publican en este sitio.

• Espacio de trabajo con autenticación y control de acceso en el servidor y la base de datos.
• Incorporación de imágenes: seleccionar una imagen, almacenarla de forma privada y guardar sus metadatos (nombre de archivo, tipo, tamaño, ubicación, procedencia, persona que la subió, marcas de tiempo y estado de revisión).
• Lista de cargas recientes con vistas previas firmadas de corta duración, limitada a quien las subió.
• Taxonomía V1 con versiones y exactamente ocho categorías: Orgánicos, Fibra, Plástico, Metal, Vidrio, Inertes/minerales, Peligrosos y Residuales.
• Se escriben registros de auditoría al registrar imágenes y al cambiar su estado de revisión.

• TanStack Start con rutas basadas en archivos, React, TypeScript y el sistema de diseño Tailwind/shadcn existente en el sitio.
• Rutas canónicas: /projects/sorta (información general pública), /projects/sorta/workspace (con autenticación) y /projects/sorta/documentation (esta página). Las rutas anteriores /waste-ai, /projects/sorta/model, y /projects/sorta/metrics redirigen a las nuevas ubicaciones.
• Un esquema normalizado con prefijos separa las versiones de taxonomía, categorías, fuentes, imágenes, instancias, anotaciones, etiquetas, eventos de revisión y configuración, preservando la procedencia y el borrado lógico.
• Un contenedor privado dedicado almacena las imágenes originales en rutas por usuario que evitan colisiones. El acceso al almacenamiento utiliza una capa de abstracción para poder sustituirlo más adelante por almacenamiento compatible con S3.

• Las pruebas automatizadas cubren la estabilidad de la taxonomía, las dimensiones independientes de estado, la validación de metadatos de carga, la normalización de etiquetas, las rutas por usuario y la limpieza de cargas.
• Pasan la comprobación de tipos y la compilación de producción.
• Las reglas de acceso, las restricciones de la base de datos y las políticas de almacenamiento se ejercitan mediante la aplicación en funcionamiento, en lugar de pruebas automatizadas de integración.

Las ocho categorías de la Versión 1 (Orgánicos, Fibra, Plástico, Metal, Vidrio, Inertes/minerales, Peligrosos y Residuales) tienen ahora definiciones aprobadas, con reglas estructuradas de inclusión, exclusión, precaución y notas guardadas junto a ellas. No existen más clases semánticas.

El orden de prioridad de clasificación es fijo:

1. Peligroso / manejo especial, solo por identidad visible o una regla aprobada, nunca por incertidumbre.
2. En caso contrario, la categoría del material principal que pueda justificarse.
3. En caso contrario, Residual, y solo cuando esté identificado de manera positiva.
4. En caso contrario, un estado de revisión: necesita revisión, ambiguo, no identificable o excluido. Los estados de revisión nunca son categorías semánticas ni etiquetas de entrenamiento.

Un peligro creíble pero no confirmado visualmente pasa a necesita revisión con una marca opcional de peligro potencial. El umbral de aceptación para enviar predicciones de baja confianza a revisión es un parámetro, inicialmente 0.80, y no una implementación de inferencia. La especificación completa aprobada se conserva en el repositorio en docs/waste-taxonomy-v1.0.md.

La Fase 2 se autoriza solo como un piloto estrictamente limitado: exactamente diez imágenes del conjunto oficial pedropro/TACO, fijadas a una revisión de origen y una suma de comprobación registradas en un manifiesto incluido en el repositorio para que la importación sea reproducible e idempotente.

• Los identificadores originales de imágenes COCO, nombres de archivo, dimensiones, licencias, categorías y segmentaciones poligonales se conservan como procedencia de origen. Las anotaciones importadas nunca se destruyen ni se sobrescriben silenciosamente: las correcciones crean una nueva revisión humana vigente y conservan el registro importado.
• Las categorías TACO se asignan a la Taxonomía V1.0 mediante correspondencias con versiones y un estado directo, condicional, revisión manual o excluido. Una correspondencia solo sugiere una clase; nunca aprueba una instancia.
• Todo lo importado permanece sin aprobar. La aprobación de categorías y la aceptación de máscaras son acciones humanas separadas, y una imagen solo queda revisada cuando el servidor confirma que se ha atendido cada objeto.
• Ambiguo, no identificable y excluido siguen siendo estados de revisión, nunca categorías semánticas, y nunca se vuelven elegibles para entrenamiento.
• Hay una exportación COCO de anotaciones revisadas disponible únicamente para imágenes revisadas e instancias elegibles para entrenamiento. No es Dataset v001.
• El editor de anotaciones, su cola, el conjunto de imágenes, la pantalla de correspondencias de taxonomía y la importación están dentro del espacio de trabajo privado con autenticación. Las imágenes TACO nunca se muestran públicamente y solo se sirven mediante URL firmadas de corta duración.

Estado (sustituido: véase abajo la entrada de cierre de la Fase 2 del 4 de septiembre de 2026): al escribir esta entrada, las diez imágenes piloto estaban importadas y las herramientas de revisión estaban activas, pero faltaba la revisión humana de las diez. Esa revisión y la aceptación humana final de calidad ya se completaron y la Fase 2 está cerrada; la importación completa de TACO sigue aplazada deliberadamente y requiere autorización por separado.

TACO es la fuente del piloto inicial limitado, no la única fuente de datos. La plataforma de anotación es independiente de la fuente: las cargas manuales con autenticación son elementos de trabajo de primera categoría que entran en la misma cola y el mismo editor de anotaciones, y sus anotaciones revisadas cuentan para la exportación COCO revisada.

• Flujo de carga a revisión: subir una imagen en el espacio privado, abrirla directamente en el editor de anotaciones, dibujar objetos omitidos, elegir una de las ocho categorías de la Taxonomía V1.0, aprobar la categoría y aceptar o corregir la máscara como acciones separadas, añadir notas y etiquetas opcionales, y completar la imagen solo cuando la misma validación del servidor confirme que cada objeto está atendido.
• Reglas de procedencia: las imágenes cargadas y las instancias creadas por personas conservan su propia procedencia de carga manual y se identifican así en el conjunto, el editor y la exportación. Nunca se presentan ni exportan como datos TACO.
• Interacción con el lienzo: el zoom se controla solo mediante botones compactos anclados a la esquina inferior derecha de la vista de imagen. La rueda, el panel táctil y los gestos de pellizco nunca amplían el lienzo. Para desplazar hay que pulsar y arrastrar deliberadamente; un clic sin movimiento nunca mueve la imagen, y el desplazamiento nunca empieza mientras se dibuja o se mueve un vértice.
• TACO sigue limitado estrictamente a diez imágenes tanto en el manifiesto como en el importador del servidor. La importación completa sigue bloqueada hasta completar la revisión del piloto y la revisión de experiencia de anotación resultante.

La Fase 2 sigue en curso.

El espacio de trabajo privado se organiza en cuatro pestañas: Panel, Editor, Conjunto de imágenes y Correspondencias de taxonomía. La antigua cola de revisión es ahora la pestaña Editor; su dirección anterior redirige allí.

• Panel ofrece una vista operativa general de todas las imágenes activas accesibles: total de imágenes, en cola (sin empezar), en revisión, revisadas, excluidas, porcentaje de finalización, total de objetos, objetos elegibles para entrenamiento y desglose de fuentes TACO frente a cargas manuales. Los recuentos se calculan a partir de filas distintas de imágenes e instancias, por lo que las uniones no pueden inflarlos. El piloto TACO aparece solo como una métrica compacta de fuente y una acción de importación (sustituida por la entrada del 3 de septiembre de 2026 que aparece abajo).
• Editor contiene el trabajo de anotación en cola. Muestra por defecto imágenes importadas y en revisión de todas las fuentes, con filtros por estado y fuente. Cada tarjeta incluye una miniatura, fuente, estado, recuentos de objetos, hora de carga y la acción Abrir editor.
• Conjunto de imágenes es la biblioteca completa, independientemente del estado de revisión. Incluye el formulario de carga manual, búsqueda por nombre de archivo, filtros de fuente y estado, y ordenación por carga más reciente (predeterminada), más antigua, revisión más reciente o nombre de archivo. Cada fila se abre en el editor.
• Flujo: subir desde Conjunto de imágenes, abrir la nueva imagen directamente en el editor, anotarla y completarla mediante la validación de revisión del servidor, que no cambia.
• Marcas de tiempo: created_at es la hora oficial de carga o importación; reviewed_at es la última finalización satisfactoria de la revisión.
• Las imágenes revisadas pueden reabrirse deliberadamente desde Conjunto de imágenes para corregirlas. Cualquier cambio sustancial de anotación, categoría o máscara devuelve una imagen revisada a en revisión, de modo que los datos revisados desactualizados no sigan siendo elegibles para entrenamiento; se conservan la marca de tiempo histórica y el registro de auditoría hasta completar la imagen otra vez.
• TACO sigue siendo una fuente entre otras y mantiene el límite de exactamente diez imágenes.

Registro de verificación (3 de septiembre de 2026): la implementación pasó 79 pruebas automatizadas, la comprobación de tipos, la compilación de producción y lint de los archivos modificados. La verificación en vivo tras la migración mostró 12 imágenes activas en total —10 del piloto TACO y 2 cargas manuales—, con 5 revisadas y 7 en cola, y reviewed_at registrado para cada imagen revisada. Estos recuentos son solo un registro fechado; el progreso de revisión sigue cambiando.

La Fase 2 sigue en curso.

Una limpieza exclusivamente visual hizo que el Panel del espacio de trabajo fuera neutral respecto a la fuente. No cambió ninguna ruta, dato, estado de revisión, imagen, anotación ni comportamiento de autenticación.

• Se eliminaron del Panel los botones duplicados «Revisar imágenes en cola» y «Abrir conjunto de imágenes», porque las pestañas persistentes del espacio de trabajo justo encima son la navegación canónica.
• Se eliminó del Panel el recuadro independiente «Fuente TACO — piloto limitado de 10 imágenes», con sus botones de importación y exportación: TACO es una fuente de imágenes, no la identidad del espacio de trabajo.
• TACO sigue representado de forma neutral como una línea normal en el desglose de fuentes del Panel junto a las cargas manuales, y mantiene el límite estricto de exactamente diez imágenes.
• La exportación COCO revisada pasó a la pestaña Conjunto de imágenes como una acción general que abarca varias fuentes, conservando la exportación con autenticación y los avisos de carga, error y éxito.
• El importador idempotente de TACO y su límite permanecen en el código para mantenimiento y reproducibilidad; como la importación piloto ya terminó, esa acción ya no aparece permanentemente en la interfaz.
• Motivo: reducir la navegación redundante y mantener el Panel independiente de la fuente.

Registro de verificación (3 de septiembre de 2026): pasaron las pruebas automatizadas, la comprobación de tipos, la compilación de producción y lint de los archivos modificados. La verificación en vivo confirmó que los datos no cambiaron: 12 imágenes activas (10 del piloto TACO y 2 cargas manuales), 5 revisadas y 7 en cola, con 32 instancias de anotación. Estos recuentos son solo un registro fechado.

La Fase 2 sigue en curso; no se inició ninguna fase posterior.

La herramienta «Añadir objeto omitido» del editor de anotaciones ahora confirma visualmente cada clic de inmediato. No cambió ninguna imagen, anotación, estado de revisión, ruta ni comportamiento de autenticación.

• Cada clic válido en el lienzo muestra un marcador de vértice de alto contraste en el punto registrado, visible tanto sobre imágenes claras como oscuras.
• Los puntos registrados se conectan mediante bordes de borrador visibles: una línea discontinua abierta hasta tener tres puntos y, solo entonces, una figura cerrada con un relleno ligero.
• El primer punto se dibuja de forma distinta para identificar claramente el vértice inicial del polígono, y junto a los controles de dibujo aparece el recuento de puntos en tiempo real.
• Finalizar polígono permanece oculto hasta tener al menos tres puntos; Cancelar y Escape funcionan como antes, y los indicadores de dibujo no son interactivos, de modo que un clic nunca puede registrar dos puntos.
• Los marcadores, bordes y el recuento de puntos del borrador se reinician al finalizar o cancelar el polígono, pulsar Escape o abrir otra imagen.
• El modo de dibujo sigue teniendo prioridad sobre el desplazamiento; no cambian el zoom mediante botones ni el desplazamiento por clic y arrastre fuera del modo de dibujo.
• Motivo: las personas deben poder confirmar que cada clic se registró al trazar un objeto, en lugar de deducirlo de una figura que solo aparece después.

Registro de verificación (3 de septiembre de 2026): pasaron 84 pruebas automatizadas, la comprobación de tipos, la compilación de producción y lint de los archivos modificados, incluidas nuevas pruebas de regresión de adición ordenada de puntos, la regla de tres puntos para finalizar y el reinicio del borrador. Estos recuentos son solo un registro fechado.

La Fase 2 sigue en curso; no se inició ninguna fase posterior.

Todas las imágenes ahora se abren totalmente visibles y centradas en el área del editor. No cambió ninguna imagen, anotación, estado de revisión, ruta ni comportamiento de autenticación.

• Al abrir el editor o navegar a otra imagen, se ajusta y centra automáticamente la imagen completa mediante geometría real de tipo «contain», a partir del tamaño medido del área visible y las dimensiones originales de la imagen en píxeles.
• Las imágenes verticales, horizontales y cuadradas se muestran completas, sin recortes ni deformaciones; el espacio sobrante se distribuye como bandas centradas.
• El control Ajustar (y f) restaura exactamente esta base centrada de imagen completa, en lugar de un zoom de 1 anclado arriba a la izquierda.
• La vista ajustada aparece como 100% en la interfaz, y los botones de zoom escalan respecto a esa base dentro del intervalo limitado existente.
• El ajuste se recalcula al cambiar el tamaño del área visible; nunca se reinicia inesperadamente el trabajo de zoom, desplazamiento, dibujo o edición de vértices, y las coordenadas guardadas del polígono no cambian porque solo se modifica la transformación visual.
• Las cargas manuales cuyas dimensiones en píxeles se completan después de cargar se ajustan en cuanto esas dimensiones están disponibles.
• Totalmente compatible con el zoom por botones, el arrastre deliberado para desplazar y la confirmación de vértices en cada clic; siguen desactivados el zoom con rueda, panel táctil y pellizco.

Registro de verificación (4 de septiembre de 2026): pasaron 95 pruebas automatizadas, la comprobación de tipos, la compilación de producción y lint de los archivos modificados, incluidas nuevas pruebas de regresión de ajuste completo para orientación, entradas inválidas, desplazamientos centrados, ajuste como 100% y correspondencia de coordenadas tras ajustar, ampliar y desplazar. Es solo un registro fechado.

La Fase 2 sigue en curso; no se inició ninguna fase posterior.

Auditoría en vivo del estado del piloto limitado de diez imágenes, fechada el 4 de septiembre de 2026. Esta entrada sustituye el texto anterior que describía la revisión humana de las diez imágenes como incompleta.

• 12 imágenes activas: 10 del piloto TACO y 2 cargas manuales.
• Las 12 imágenes están en estado REVIEWED; hay 0 en cola.
• Las 10 imágenes del piloto TACO están en estado REVIEWED.
• 34 instancias activas: 32 importadas y 2 añadidas por personas.
• 33 instancias elegibles para entrenamiento.
• Se conserva 1 instancia activa de falso positivo para auditoría y procedencia; no es elegible para entrenamiento.
• Todas las instancias activas están en estado HUMAN_VERIFIED para clasificación; 33 máscaras están en MASK_ACCEPTED y el falso positivo está en MASK_CORRECTED.
• La auditoría de revisión abarca selecciones y aprobaciones de categorías, aceptación de máscaras, 2 revisiones de polígonos, 2 incorporaciones de objetos omitidos, marcado de falsos positivos y finalización de imágenes.
• Se conservan las versiones de 60 correspondencias TACO vigentes: 34 DIRECT, 20 CONDITIONAL y 6 MANUAL_REVIEW.

Conclusión (sustituida por la entrada de cierre de la Fase 2 del 4 de septiembre de 2026 que aparece abajo): la implementación limitada de diez imágenes de la Fase 2 y la revisión del piloto estaban completas en la base de datos, y al auditar quedaba pendiente la aceptación humana final de calidad.

La importación completa de TACO se aplaza deliberadamente. No forma parte del cierre de este piloto de diez imágenes autorizado por el usuario y requiere autorización por separado después de aceptar el piloto. Dataset v001, el entrenamiento, el trabajo de modelos y la inferencia siguen perteneciendo a la Fase 3 y posteriores, y siguen sin autorización.

La verificación automatizada ya es satisfactoria: 95 pruebas, comprobación de tipos, compilación de producción y lint de archivos modificados. En esta sesión no se pudo completar una comprobación visual independiente en el navegador del comportamiento de ajuste completo más reciente porque la vista previa requería autenticación; no se afirma que esa comprobación haya pasado.

La Fase 2 está formalmente COMPLETA. Esta entrada sustituye todo texto anterior que describía la Fase 2 como en curso o enumeraba trabajo pendiente de esa fase. Solo documentación: esta entrada no cambió el comportamiento de la aplicación, rutas, autenticación, registros de base de datos, imágenes, anotaciones ni estados de revisión.

• El propietario del proyecto completó la aceptación humana final de calidad tras los últimos cambios de experiencia del editor (ajuste completo, zoom por botones, arrastre para desplazar, confirmación de vértices por clic, corrección de máscaras y reapertura de imágenes revisadas).
• Se completó la comprobación manual por muestreo de la exportación COCO revisada: archivos, polígonos, etiquetas de clase, dimensiones de imágenes y procedencia.
• Se resolvieron todos los defectos de la Fase 2 que impedían su cierre. No queda trabajo pendiente de la Fase 2.
• Se conserva el registro auditado en vivo: 12 imágenes activas, las 12 revisadas; 10 de 10 imágenes del piloto TACO revisadas; 34 instancias activas; 33 elegibles para entrenamiento; un falso positivo conservado; 60 correspondencias TACO vigentes con versiones.
• La verificación automatizada sigue siendo satisfactoria: 95 pruebas, comprobación de tipos, compilación de producción y lint de archivos modificados.
• La limitación de autenticación antes documentada para la comprobación independiente del navegador queda solo como contexto histórico; la aceptación humana completada por el propietario la sustituye como decisión de cierre.
• La importación completa de TACO sigue aplazada por separado y requiere autorización explícita. No es un elemento pendiente de este piloto limitado de diez imágenes.
• Dataset v001, el entrenamiento, el trabajo de modelos y la inferencia pertenecen a la Fase 3 y posteriores, y no han comenzado.

La base de la Fase 3 está construida: instantáneas reproducibles de conjuntos de datos, un agente de entrenamiento local y un registro de modelos. Deliberadamente, aún no se utiliza. No se ha creado Dataset v001, no se ha iniciado ninguna ejecución de entrenamiento y Model v001 no existe. No se importaron imágenes TACO adicionales; se mantiene el límite de diez. La inferencia sigue siendo parte de la Fase 4 y no ha comenzado. No se desplegó nada.

• Ocho tablas nuevas registran versiones de conjuntos de datos y sus miembros congelados de imágenes e instancias, ejecuciones de entrenamiento y evaluación, versiones de modelos, métricas y un historial de auditoría que solo admite adiciones. Todas tienen seguridad por fila únicamente para miembros autenticados del equipo, sin acceso anónimo ni eliminación.
• Las validaciones del ciclo de vida están tanto en la base de datos como en la aplicación: una instantánea pasa de Draft → Frozen → Archived y una instantánea congelada es inmutable; una ejecución de entrenamiento termina en Succeeded, Failed o Cancelled y nunca se reabre; un modelo solo llega a Champion mediante una promoción humana explícita, y puede existir como máximo un campeón a la vez.
• Dos contenedores privados de almacenamiento guardan los manifiestos de instantáneas con su exportación COCO y los artefactos de modelos. El agente de entrenamiento solo recibe URL firmadas de corta duración; ninguna clave de servicio sale del servidor.
• Las particiones son deterministas y evitan filtraciones de datos entre ellas. La unidad es el grupo, no la imagen: las imágenes que comparten una suma SHA-256 exacta o una agrupación manual siempre quedan en la misma partición. El orden depende solo de la semilla y la clave del grupo. No se ha implementado la agrupación perceptual de casi duplicados, y se declara esa limitación en lugar de darla por resuelta.
• Cada instantánea congela un manifiesto canónico: identificadores de imágenes e instancias, identificadores de anotaciones actuales y sumas de comprobación de su geometría, versiones de taxonomía y anotaciones, procedencia, asignaciones de partición, recuentos por clase, autor, fecha, notas, política confirmada y suma de comprobación de la exportación. La suma de comprobación del manifiesto es reproducible en ambos extremos.
• La validación de preparación es configurable y distingue bloqueos de advertencias. Crear una instantánea requiere escribir una confirmación, devolver el hash exacto de preparación mostrado y justificar por escrito cualquier bloqueo aceptado. Cada umbral propuesto —las proporciones 70 / 15 / 15, la semilla fija y los requisitos de clases y sumas de comprobación— es una propuesta pendiente de confirmación del operador, no una regla aprobada.
• El agente de entrenamiento local está en el repositorio en training-agent/ y se ejecuta aparte del sitio. Inicia sesión con las propias credenciales de espacio de trabajo del operador, rechaza claves de servicio, verifica cada archivo descargado contra el manifiesto antes de usarlo, nunca vuelve a dividir los datos, prefiere MPS, luego CUDA y luego CPU registrando cada alternativa, y mantiene la arquitectura Mask R-CNN detrás de un adaptador intercambiable.
• Dos pestañas nuevas del espacio privado muestran el trabajo: Versiones de conjuntos de datos (auditoría de preparación, propuesta de partición, vista previa de simulación, creación y congelación con validaciones) y Entrenamiento y modelos (configuración del agente, conjuntos congelados, historial de ejecuciones, registro de modelos y cuadro de resultados base).

Preparación en vivo en esta fecha: 12 imágenes activas, todas revisadas, 33 instancias elegibles para entrenamiento. La cobertura por clase es FIBER 2 imágenes / 3 instancias, GLASS 4 / 4, HAZARDOUS 1 / 1, METAL 4 / 7, ORGANICS 1 / 1, PLASTIC 7 / 17; INERT_MINERAL y RESIDUAL no tienen ninguna instancia elegible, y dos imágenes aún no tienen una suma de comprobación guardada. Por ello, la validación informa bloqueos, que es el resultado correcto: una instantánea tomada hoy no podría afirmar honestamente una base de ocho clases.

Registro de verificación (5 de septiembre de 2026): 124 pruebas automatizadas, incluidas 29 pruebas nuevas de Fase 3 sobre sumas de comprobación, serialización canónica, particiones deterministas y sensibles a la semilla, contención de duplicados, bloqueos y advertencias de preparación, transiciones del ciclo de vida y estabilidad del manifiesto, además de comprobación de tipos, compilación de producción y lint de archivos modificados. Las pruebas Python del agente solo requieren CPU y no pudieron ejecutarse en este entorno porque pytest no está instalado; no se afirma que esa comprobación haya pasado. El registro completo está en docs/waste-ai-phase-3-dataset-and-training.md.

Se retira el estado «base de la Fase 3 completa» registrado antes ese mismo día. Una auditoría encontró defectos suficientemente graves como para que esa etiqueta no estuviera justificada. Abajo se enumeran junto con lo que se hizo en cada caso. Ahora se considera que la base corregida es sólida, pero sigue sin haberse utilizado: no existe ninguna versión de conjunto de datos, ejecución de entrenamiento, ejecución de evaluación ni versión de modelo, no se importaron imágenes, no cambió ningún estado de revisión, no se desplegó nada y la inferencia de Fase 4 sigue fuera del alcance.

• La auditoría de preparación informaba de un corpus vacío. La consulta de candidatos nunca resolvía la categoría de una instancia, de modo que todas fallaban la prueba de elegibilidad y la página daba a entender que no había datos para entrenar. Ahora se resuelven las categorías antes de la prueba y la auditoría informa del corpus real: 12 imágenes revisadas y 33 instancias elegibles. Se excluyen, como corresponde, las instancias eliminadas, marcadas como falso positivo o sin geometría vigente.
• Las instantáneas no eran realmente inmutables. Una instantánea congelada registraba qué anotaciones le pertenecían, pero volvía a leer su geometría de las tablas activas al exportar, por lo que una edición posterior modificaba silenciosamente un conjunto «congelado». Ahora cada fila de pertenencia guarda la geometría exacta junto con su suma de comprobación; la congelación y la exportación COCO leen solo esa copia guardada, y cada suma se recalcula y compara antes de escribir nada. Una sola diferencia cancela la congelación.
• Parte del manifiesto contenía valores de relleno. Podía escribirse con un hash de preparación vacío, recuentos vacíos, una marca de tiempo nueva en lugar de la registrada para las anotaciones y el código de la instantánea usado como nombre. Ahora se construye íntegramente a partir del registro guardado y su pertenencia congelada, y se valida contra su esquema antes de subirlo; la falta de procedencia es un error, no un campo vacío.
• La creación de instantáneas podía dejar datos a medio escribir. La creación ahora se ejecuta como una sola transacción de base de datos mediante un único procedimiento almacenado, de modo que un fallo no deja una instantánea parcial. La congelación valida todo antes de subirlo y elimina cualquier objeto que acabe de escribir si falla el paso final.
• Los archivos guardados no estaban limitados a su propietario. Los manifiestos, exportaciones y artefactos de modelos ahora se guardan bajo un prefijo por usuario y las reglas de almacenamiento comprueban ese prefijo, por lo que un operador autenticado ya no puede leer ni escribir archivos de otro. Cada tabla de Fase 3 tiene reglas de acceso basadas en propiedad y cada endpoint del agente filtra y valida por usuario autenticado: las cargas solo entran en una ejecución propia satisfactoria, solo se registra un artefacto que existe con el tamaño previsto y los modelos nuevos siempre empiezan como candidatos.
• Las reglas de pertenencia fallaban al eliminar. La validación hacía referencia a una fila que no existe durante una eliminación, lo que provocaba un error. Ahora el propietario puede corregir o revertir la pertenencia de borradores; la pertenencia congelada y archivada sigue siendo inmutable.
• El agente de entrenamiento podía haber etiquetado mal los objetos. Deducía la lista de clases de las que aparecieran y emparejaba imágenes mediante suposiciones. Ahora lee las ocho clases del manifiesto en su orden definido, resuelve cada imagen por su identificador registrado y se niega a etiquetar un objeto real como fondo. Ya no se puede omitir la verificación de sumas de comprobación; puede proporcionarse un token de acceso directamente en lugar de una contraseña; el archivo de sesión guardado es accesible solo por su propietario; y la ejecución ahora genera y sube su registro, checkpoints, configuración, métricas e informe de evaluación, registrando los resultados de evaluación en el espacio de trabajo.

Verificación en esta fecha: pasan 138 pruebas automatizadas del sitio (14 nuevas sobre elegibilidad, integridad de geometría congelada, determinismo de exportación, contenido del manifiesto y rutas por propietario), comprobación de tipos, compilación de producción y lint de archivos modificados. Pasan las 23 pruebas Python del agente, incluida una nueva prueba de contrato cuyos datos de prueba genera el mismo código del sitio que escribe una instantánea real; demuestra una partición de entrenamiento no vacía, emparejamiento correcto de imágenes y una etiqueta correcta distinta de fondo para las ocho clases. Se abrieron y comprobaron ambas páginas protegidas del espacio de trabajo. Una comprobación de la base en vivo confirma 12 imágenes, todas revisadas, 34 instancias y 33 elegibles, sin cambios, y todas las tablas de Fase 3 todavía vacías. El registro completo está en docs/waste-ai-phase-3-dataset-and-training.md.

Una limpieza pequeña y específica antes de importar datos. No se creó, importó ni desplegó nada: sigue sin haber ninguna versión de conjunto de datos, ejecución de entrenamiento, ejecución de evaluación o versión de modelo, y la inferencia de Fase 4 sigue fuera del alcance.

• La herramienta de entrenamiento tenía dos copias de los mismos dos comandos. Las definiciones duplicadas para crear y actualizar una evaluación se ocultaban entre sí; queda un único par correcto.
• Las puntuaciones de evaluación no se habrían registrado. La herramienta leía las puntuaciones del lugar equivocado en su propio informe, de modo que una evaluación real no habría guardado ningún número. Ahora lee el informe real y guarda cada puntuación (exactitud general y sus variantes) tanto de cajas como de máscaras. Cuando no puede calcularse una puntuación, se registra el motivo en lugar de un cero engañoso.
• Los checkpoints intermedios nunca se subían. Registrar un modelo ahora sube cada checkpoint por época junto con el modelo final, su configuración, métricas, registro e informe de evaluación, verificando nombres de archivo e impidiendo duplicados.
• Se habían incluido archivos de compilación en caché de Python en el repositorio. Se eliminaron y ahora se ignoran.
• El paso de instantánea de todo o nada ahora está respaldado por una prueba. Su presencia y nombre exacto se confirmaron directamente en la base de datos.
• Los permisos de medición eran demasiado amplios. Ahora un operador autenticado solo puede adjuntar una medición a una instantánea, ejecución o modelo propios, según el tipo de medición.

Verificación en esta fecha: 141 pruebas automatizadas del sitio, 28 pruebas del agente (cinco nuevas sobre ambas estructuras de informe de evaluación y búsqueda de checkpoints), comprobación de tipos, compilación de producción, lint de archivos modificados y comprobación de compilación Python. Una comprobación de la base en vivo confirma 12 imágenes, todas revisadas, 34 instancias activas y 12 revisiones, sin cambios, con todas las tablas de Fase 3 aún vacías. El registro completo está en docs/waste-ai-phase-3-dataset-and-training.md.

La ampliación autorizada añadió 188 imágenes TACO únicas, llevando la biblioteca a 200. Se eligieron deliberadamente: primero las que mostraban tipos de residuos sin ejemplos, luego los raros y después las que ofrecían mayor variedad, rechazando automáticamente imágenes casi idénticas. Se omitieron once imágenes muy similares.

Una comprobación en vivo confirma 200 imágenes, todas distintas, 1,355 objetos anotados (34 ya revisados por una persona, 1,321 pendientes) y exactamente 200 archivos guardados, sin faltantes, sobrantes ni diferencias de tamaño o forma.

• Corregido: algunas imágenes mostraban «0 objetos». El espacio de trabajo solo podía leer los primeros mil objetos a la vez, por lo que todo lo posterior parecía vacío. Ahora los lee todos, por páginas.
• Corregido: algunas vistas previas no aparecían. Los enlaces de imágenes ahora se solicitan por lotes en vez de uno a uno, para que se carguen todas las miniaturas.

Comprobado en el espacio de trabajo en funcionamiento: recuentos correctos de objetos, todas las vistas previas visibles, sin errores y apertura de una imagen importada en el editor con sus contornos intactos.

Con 188 imágenes pendientes, aprobar cada objeto por separado era la parte más lenta del trabajo. Ahora una imagen puede confirmarse con una sola acción, manteniendo el criterio humano: los objetos están numerados en la imagen y en la lista, cada uno muestra de dónde procede su tipo de residuo sugerido y cualquier tipo que solo se aplica bajo una condición muestra esa regla con palabras claras.

Antes de confirmar, el panel detalla exactamente qué se registrará: cuántos tipos sugeridos se aceptarán, cuántos son condicionales, cuántas decisiones propias se aprobarán, cuántos contornos se aceptarán y cuántos objetos quedarán fuera del entrenamiento. Todo lo no resuelto aparece como un elemento numerado que se puede pulsar para ir directamente al objeto.

• No se registra nada a menos que toda la imagen supere las comprobaciones: un contorno inválido o un objeto cuyo tipo de origen necesita una decisión individual detiene la acción y deja la imagen exactamente como estaba.
• Prevalecen tus propias decisiones. Un tipo que elegiste, un contorno que corregiste, un objeto marcado como inexistente y todo lo apartado por falta de claridad conservan su decisión y quedan fuera del entrenamiento.
• Si la imagen cambió desde que la abriste, la acción se rechaza y pide recargar, para que dos personas no puedan sobrescribir el trabajo de la otra.
• Confirmar dos veces no registra nada la segunda vez, y cada imagen completada deja una única entrada de auditoría con sus recuentos.

• Los contornos se comprueban estrictamente: deben coincidir con el tamaño real de la imagen, permanecer dentro de ella, tener al menos tres vértices distintos y encerrar un área real.
• Un tipo de residuo que ya no forme parte de la lista actual de ocho tipos, o una regla de origen modificada desde que se incorporaron las imágenes, detiene la acción y solicita una decisión individual.
• Todo se registra junto o no se registra nada: se vuelve a comprobar la imagen en el último momento y, si algo cambió durante la acción, se cancela todo y no se escribe nada.
• Si estás dibujando un objeto omitido o editando un contorno sin guardar, la acción no está disponible y lo indica; vuelve a estarlo al guardar o borrar ese dibujo.

Verificado el 6 de septiembre de 2026 con imágenes temporales de prueba procesadas por la ruta real con sesión iniciada y eliminadas después: se rechazaron intentos sin sesión e intentos desactualizados; los objetos que requerían decisión humana se bloquearon con un motivo para cada uno; se confirmó una imagen válida (un tipo sugerido aceptado, dos decisiones propias aprobadas, tres contornos aceptados), y repetir el clic no registró nada. Se confirmó que la biblioteca permanecía idéntica: 200 imágenes, 12 revisadas, 188 pendientes, 1,355 objetos con 1,321 aún sin revisar y 34 aprobados.

Para dejar constancia, los tipos de residuos mostrados en los 1,321 objetos pendientes son sugerencias incorporadas con las imágenes, no tipos confirmados: 573 residuales, 369 plásticos, 108 vidrios, 101 fibras, 54 metales, 5 inertes minerales y 111 sin sugerencia. Por nivel de confianza, 400 son sugerencias directas, 810 solo aplican bajo una condición que una persona debe revisar y 111 requieren una decisión individual. Nada de esto cuenta como resultado revisado.

Informado ese día: confirmar una imagen cuyos tipos y contornos parecían correctos fallaba con «No se cambió nada. La correspondencia de origen necesita una decisión individual de categoría», repetido dos veces y sin indicar qué objetos causaban el problema.

Causa. Cada regla de origen que solo aplica bajo una condición también lleva la marca «una persona debe revisar esto». El editor permitía confirmar con una acción, pero la rutina de guardado interpretaba esa marca como «debe decidirse objeto por objeto» y rechazaba toda la imagen. Esa discrepancia afectaba a las 20 reglas condicionales, que cubrían 810 objetos pendientes. No se estableció el número de imágenes afectadas.

Corrección. La marca ahora significa lo que dice: una persona debe dar su aprobación y la confirmación deliberada de una sola acción constituye esa aprobación. Por ello, ese clic puede aceptar un tipo condicional siempre que sea la regla vigente, no haya cambiado desde que se incorporaron las imágenes, apunte a un tipo de residuo activo y muestre su regla en el objeto. Todo lo demás sigue bloqueado como antes: reglas que requieren decisión individual, reglas sin tipo sugerido, reglas excluidas y —con rigor deliberado— una regla directa simple que lleve inesperadamente la marca «debe revisarse». No cambian las comprobaciones de contornos y tipos actuales, la protección que pide recargar datos desactualizados, las decisiones propias, los contornos corregidos ni los objetos apartados. Los mensajes ahora indican el número de objeto y el motivo real en lugar de repetir una línea genérica.

Evidencia. Pasa la batería completa de pruebas (177 comprobaciones, 13 archivos), incluidas 26 de esta pantalla con casos nuevos basados en los datos reales de reglas: se acepta condicional con marca y directo sin marca; se bloquean directo con marca, revisión obligatoria, ausencia de tipo sugerido y cambios desde la importación; y se comprueban mensajes por objeto. La comprobación en vivo se ejercitó contra la base real con registros temporales dentro de una transacción revertida: dos objetos condicionales con marca se completaron con una acción (dos tipos aceptados, dos contornos aceptados, dos elegibles para entrenamiento); una imagen mixta con un objeto sin resolver fue rechazada con un solo mensaje que lo identificaba y no escribió nada; y una regla directa con la marca siguió rechazada. Se confirmó que la biblioteca permanecía idéntica: 200 imágenes, 12 revisadas, 1,355 objetos, 34 aprobados, 1,357 contornos y 60 reglas vigentes, sin dejar registros de prueba. No se publicó nada, no se incorporaron imágenes, no se ejecutó entrenamiento ni se creó una versión de conjunto de datos.

Model v001 es un primer modelo medido con cuidado y repetible, orientado al mejor rendimiento práctico de reconocimiento y trazado de contornos de nuestros ocho tipos de residuos con esta biblioteca. No es una demostración. El entrenamiento solo comienza cuando se cumple todo lo siguiente:

1. Una persona ha revisado cada contorno incluido en el conjunto de entrenamiento.
2. Cada tipo de residuo tiene suficientes ejemplos, atendiendo deliberadamente a los tipos raros.
3. Las imágenes similares se mantienen juntas en un lado de la partición, para que nada usado para entrenar reaparezca en la prueba.
4. La forma aprobada de dividir los datos se registra y bloquea junto con el conjunto.
5. Los resultados se miden en imágenes reservadas y no usadas para entrenar, tanto para cajas como para contornos, con un desglose de errores por tipo de residuo.
6. Esos hallazgos se incorporan al trabajo de anotación y categorías antes de promover cualquier modelo.

Todavía no se ha creado ningún conjunto de entrenamiento, ejecución de entrenamiento, evaluación ni modelo, y utilizar un modelo dentro del sitio sigue siendo una fase posterior.

El repositorio privado de código ahora se llama mlinton-ftggcig/for-the-greater-good-community. Lovable detectó automáticamente el cambio de nombre y confirmó que la rama main seguía conectada y sincronizada. Se conservaron el propietario del repositorio, la configuración de privacidad y el historial completo de cambios.

GitHub Desktop se instaló y conectó con la aprobación del operador. Se verificó una copia local con los 578 commits frente a la última corrección de revisión, 98d529a. Ahora el desarrollo puede editar archivos directamente sin enviar indicaciones al chat de Lovable; los cambios solo llegan a GitHub y Lovable después de confirmarlos y enviarlos.

Esta configuración también corrige la explicación del error de correspondencias condicionales de arriba: el editor permitía confirmar mientras la rutina de guardado lo rechazaba. No cambiaron datos de imágenes, revisiones, entrenamiento de modelos ni ajustes de despliegue. Estas ediciones de documentación se prepararon localmente; la configuración en sí no publicó el sitio ni volvió a ejecutar toda la batería de pruebas de la aplicación.

Cada cambio relevante de Sorta recibe aquí una entrada fechada que cubre su alcance, motivo y comportamiento resultante, el flujo de trabajo, rutas y datos afectados, cómo se verificó y qué queda pendiente junto con los límites de la fase actual. Esta pestaña Documentación es el registro vivo del proyecto.

Los siguientes límites y secuencia se registraron en el traspaso de la Fase 2. Se conservan como contexto, no como el límite de importación ni el estado de implementación actuales.

• Aún no construido: instantáneas de conjuntos de datos, importación completa de TACO, entrenamiento, inferencia, aprendizaje activo y paneles de métricas.
• El acceso es para «cualquier miembro autenticado del equipo»; los roles llegarán después.

Las Fases 1 y 2 están completas. La Fase 2 abarcó el piloto de diez imágenes TACO descrito arriba y el flujo de anotación de cargas manuales independiente de la fuente; la importación TACO en sí sigue limitada a diez imágenes y la importación completa sigue aplazada por separado. El resto del orden maestro de desarrollo que sigue está planificado, pero aún no autorizado.

1. Construir una excelente pantalla de anotación.
2. Probarla manualmente con unas 20–50 imágenes.
3. Corregir la experiencia de anotación a partir de esa prueba.
4. Importar TACO.
5. Comenzar la revisión manual completa.
6. Crear Dataset v001 solo cuando existan suficientes datos revisados.
7. Construir el agente de entrenamiento M4 y entrenar Model v001.
8. Solo entonces conectar la inferencia al sitio web.