Potrero es un juego 3D de fútbol tenis: pasá la pelota por encima de la red y hacé que tu rival no pueda devolverla. Una cancha de barrio argentino, partidos cortos y ninguna descarga.
Un partido, o uno más
Jugá contra la CPU sin crear una cuenta. Aprendé en el tutorial, practicá libremente o explorá el barrio para conocer y desafiar a sus jugadores.
Reservale un lugar a un amigo
En la beta cerrada, el modo online usa una cuenta y una invitación a una sala privada. Compartí el código, esperá a tu rival y marquen que están listos. La beta es para mayores de 18 años.
De una cancha en el navegador a un barrio que se puede recorrer. Las etapas, las decisiones que las conectan y lo que hubo que corregir en el camino.
La historia, las decisiones y la evidencia están explicadas acá mismo. Las imágenes antiguas reejecutadas se identifican por revisión y fecha; usan el código histórico con herramientas locales actuales. Las cifras corresponden a cada etapa.
El proyecto arranca con un prototipo de fútbol-tenis en el navegador. Las primeras correcciones se concentran en conseguir que la escena cargue y se pueda ver.
La decisión
La base elegida fue Vite, React y Three.js. El registro conserva esa elección técnica, pero no documenta una comparación con otros motores.
Qué cambió
Queda una primera implementación sobre la cual iterar. Todavía no es el barrio que conocemos hoy.
Reejecución histórica · 2025-03-15 · 97097eb. Se ven la cancha verde, la red y el marcador mínimo; todavía no hay un entorno de barrio.
Ver decisiones y correcciones en detalle
Las primeras correcciones resuelven imports y configuración de texturas. Esta captura se obtuvo reejecutando la revisión 97097eb del 15 de marzo de 2025 el 8 de septiembre de 2026, con Cannon 6.6.0 y el resto de las herramientas locales actuales. Conserva el código de aplicación de esa revisión.
Lo que quedó documentado
Primera implementación
La primera escena contiene una cancha, una red, una pelota y un marcador. El menú ofrece iniciar la partida y enumera movimiento, salto y patada. Es la base mínima que se ve en la recreación.
c1fac16 · 2025-03-15
Corrección de arranque
La corrección agrega la referencia a Three.js que faltaba en la cancha. Esta revisión posterior del mismo día es la que pudimos volver a ejecutar y capturar.
Se rehacen el motor y la interfaz. Aparecen la carga de potencia, la puntería manual y sucesivas correcciones del saque cruzado y los piques.
La decisión
Se incorporan controles de potencia y dirección, junto con restricciones de saque. Los commits describen esos cambios; no registran un motivo de producto más específico.
Qué cambió
El prototipo gana un vocabulario de juego: apuntar, cargar, soltar y respetar el cuadrante de saque.
Reejecución histórica · 2026-08-27 · b3595fe. El HUD ya muestra saque cruzado, intentos y potencia; las figuras y el fondo siguen siendo simples.
Ver decisiones y correcciones en detalle
Esta etapa incluye la revisión del motor del 11 de agosto, la carga del 15 y ajustes posteriores de saque y puntería. Las reglas seguirían cambiando; no representa una certificación reglamentaria de la versión actual. La captura se volvió a ejecutar el 8 de septiembre de 2026; no es una imagen archivada de la fecha original ni una nueva prueba completa de esa versión.
Lo que quedó documentado
Motor e interfaz
El historial registra una revisión del motor y de la interfaz. Los siguientes cambios de agosto se apoyan en esa base; no hay una evaluación de alternativas de motor documentada.
0ab4460 · 2026-08-11
Potencia y puntería
Se incorpora la mecánica de cargar el golpe y orientar el tiro. En la versión capturada, el HUD explica mantener K para preparar un golpe con potencia.
cdff8ac · 2026-08-15
Ajuste manual de dirección
La dirección del tiro recibe ajuste manual. La captura de esta revisión muestra el cuadrante de saque, los intentos disponibles y los controles, junto a una cancha todavía sin barrio.
Neon Court incorpora partidas privadas online y luego adopta el nombre Sonnies. Llegan mejoras de reconexión, controles analógicos y render para equipos modestos.
La decisión
El muestreo de controles se separa de los cuadros dibujados: una caída del render no debe decidir cuándo se lee una entrada.
Qué cambió
Ya existe un flujo para jugar con otra persona, con trabajo explícito sobre conexiones y estados compartidos.
Reejecución histórica · 2026-08-28 · 173ef50. La etapa del estadio: gradas, anuncios y figuras de público. Esta imagen muestra solo en la versión que incorporó online.Reejecución histórica · El menú de agosto de 2026 incorpora Play online junto a los modos locales.
Ver decisiones y correcciones en detalle
Los cambios abarcan salas privadas, reincorporación, atribución de puntos y controles más suaves. Son antecedentes de la arquitectura online, no una afirmación sobre servidores desplegados hoy. La captura se volvió a ejecutar el 8 de septiembre de 2026; no es una imagen archivada de la fecha original ni una nueva prueba completa de esa versión.
Lo que quedó documentado
Primer multijugador
Se agrega el flujo de partidas privadas online, con lobby y estados compartidos. La imagen del menú muestra su punto de entrada; la imagen de cancha corresponde a solo en esa misma versión, no a una prueba de conexión histórica.
65a4853 · 2026-08-28
Entradas independientes del render
Las entradas dejan de muestrearse únicamente cuando se dibuja un cuadro. Esa separación es la decisión técnica que permite mantener el control independiente del ritmo visual.
39136ad · 2026-08-28
Salas y reconexión
Se refuerzan la entrada a salas y la reincorporación a partidas. El objetivo del cambio es recuperar el estado compartido después de una interrupción, no crear una partida distinta.
La escena adopta tierra, chapa, ladrillo y luz de tarde. Sonnies pasa a llamarse Potrero; los atletas y las hinchadas empiezan a darle escala humana.
La decisión
El cambio de identidad mantiene el cian y el coral de los equipos para que jugadores y pelota sigan siendo fáciles de distinguir. El HUD se adapta a la poca altura de los teléfonos en horizontal.
Qué cambió
El juego empieza a reconocerse por su barrio, con público sentado y una presentación pensada también para touch.
Reejecución histórica · 2026-09-04 · 4a36245. Aparecen el atleta y las hinchadas con caras y equipaciones. El cerco y las gradas todavía ocupan buena parte del encuadre.
Ver decisiones y correcciones en detalle
El atleta pasa por una variante KayKit y luego por el personaje animado de Kenney. En el primer cambio de ambiente se ocultaba el fondo en calidad reducida; más adelante se decide conservar las construcciones y simplificar sus detalles. La captura se volvió a ejecutar el 8 de septiembre de 2026; no es una imagen archivada de la fecha original ni una nueva prueba completa de esa versión.
Lo que quedó documentado
Identidad y legibilidad móvil
El cambio introduce tierra, chapa, ladrillo, polvo y luz cálida. También reduce la altura del HUD en teléfonos horizontales para que no tape el juego. Los colores de equipo se conservan por legibilidad.
19b94d3 · 2026-09-02
Sonnies → Potrero
El nombre Sonnies se reemplaza por Potrero en marca, paleta y nombres de paquetes. Es el cambio explícito de identidad, separado de las mejoras posteriores del entorno.
dafa2a9 · 2026-09-03
Nuevo atleta
El atleta pasa a un personaje animado de Kenney con equipaciones de equipo. Frente a las figuras geométricas anteriores, la captura permite reconocer cabeza, brazos, ropa y una postura de juego.
0b773ee · 2026-09-03
Las dos hinchadas
El público usa el atleta sentado y se divide en dos hinchadas. Se ve el cambio de las pequeñas formas de color del estadio a vecinos con cuerpos y caras reconocibles.
Se incorporan rebotes corporales, control de pelota, resistencia y partidos CPU contra CPU. El juego suma español e inglés y una revisión de la conexión online.
La decisión
Se aplanan trayectorias y se vuelve más decidida la CPU para evitar intercambios interminables. La predicción y la interpolación buscan reducir los saltos percibidos en online.
Qué cambió
Hay más herramientas de juego y de evaluación, además de una experiencia traducida con preferencia de idioma persistida.
Reejecución histórica · 2026-09-05 · 5564c27. El menú permite elegir dificultad, observar CPU contra CPU y cambiar entre EN y ES.
Ver decisiones y correcciones en detalle
La selección regional por latencia y los cambios de red están documentados en el PR de conexión. No se trasladan sus objetivos a promesas actuales de latencia. Las mecánicas de esta etapa se describen como históricas y fueron refinadas después. La captura se volvió a ejecutar el 8 de septiembre de 2026; no es una imagen archivada de la fecha original ni una nueva prueba completa de esa versión.
Lo que quedó documentado
Mecánicas y CPU contra CPU
Se añaden rebotes corporales, control de pelota, resistencia y CPU contra CPU. El menú capturado conserva la opción de observar a las dos CPU: sirve tanto como modo de observación como apoyo para evaluar el ritmo.
dd3da8e · 2026-09-05
Revisión de conexión
La red incorpora interpolación del rival, predicción de pelota y selección regional por latencia. Son mecanismos destinados a reducir saltos y espera percibida; las capturas no miden latencia histórica.
ec633ca · 2026-09-05
Español e inglés
La interfaz se traduce a español e inglés y guarda la selección. Los botones EN y ES del menú permiten ver que el cambio ya formaba parte del juego en esta revisión.
Movimiento, pelota y contactos pasan a compartir una simulación de 120 Hz entre solo, servidor y predicción. Se revisan golpes de pie y cabeza, carrera, salto y saque desde las manos.
La decisión
La animación de un golpe deja de bloquear la carrera. Las zonas de contacto son finitas y el saque sigue una secuencia compartida, para alinear lo que se ve con lo que resuelve el juego.
Qué cambió
En las mediciones de esa etapa, llegar al 90% de velocidad baja de 175 a 116,7 ms. El saque incorpora un lanzamiento de 400 ms antes del contacto.
Reejecución histórica · 2026-09-06 · bfd9493. La cámara se eleva, el HUD libera espacio y el saque empieza con la pelota en las manos.
Ver decisiones y correcciones en detalle
Las pruebas comparan solo y autoridad, controles a distintos FPS y contactos reales del rig. Las simulaciones CPU ayudan a medir ritmo y dificultad, pero no sustituyen partidas con personas. Los reportes no fijan un día único para todo este conjunto. La captura se volvió a ejecutar el 8 de septiembre de 2026; no es una imagen archivada de la fecha original ni una nueva prueba completa de esa versión.
Lo que quedó documentado
Física y movimiento
Las pruebas comparan solo, servidor y predicción paso a paso, incluyendo posición, velocidad, contactos y puntos. Se acorta la aceleración y el frenado para que la respuesta al control sea más inmediata.
gameplay-evidence.md
Carrera durante el golpe
La carrera continúa durante un golpe y durante las reacciones entre puntos. Se reemplazan bloqueos de animación de cuerpo completo por capas de golpe más cortas.
responsive-footwork.md
Saque desde las manos
Soltar K inicia un lanzamiento de 48 pasos de simulación, equivalente a 400 ms. El saque pasa de las manos al pie derecho; si el jugador está en el aire, espera al aterrizaje.
serve-evidence.md
Postura de salto
El salto cambia de una postura abierta y estática a hombros relajados, codos y rodillas flexionados y una transición de aterrizaje. Las capas de contacto conservan prioridad.
La pelota y los jugadores empiezan a chocar con el entorno. La primera interpretación de la regla hace perder al último que tocó la pelota, incluso después de un pique válido.
La decisión
Se corrige la regla: si la pelota picó legalmente y el rival no la devuelve antes de llegar al entorno, el punto es del atacante. Un choque directo sigue siendo afuera.
Qué cambió
La regresión de dificultad vuelve a pasar sin retocar la CPU. En el corpus documentado, Pro pasa de ganar 4/100 a 100/100 contra Easy desde el lado delantero.
Validación posterior · Prueba de la regla del pique legal en el barrio actual, 8 septiembre 2026. Ilustra el resultado conservado; no es una captura de la primera implementación.
Ver decisiones y correcciones en detalle
El cambio conserva la validación del saque y la responsabilidad de quien toca una devolución. También se comprueba que una pelota muerta no siga generando impactos, sonidos o puntos. La comparación corresponde a las mismas semillas y emparejamientos históricos.
Lo que quedó documentado
Primera implementación y problema
La primera regla de perder por cualquier choque con el entorno generó una regresión: un buen tiro profundo podía convertirse en derrota al tocar la pared después de picar.
scenery-evidence.md
Regla corregida y comparación
Se compara el mismo corpus de 800 partidos antes y después. La corrección respeta el pique legal y recupera la diferencia esperada entre Pro y Easy sin ajustar la CPU. El resultado se expresa como devolución no alcanzada.
La cancha deja de ser la única escena. Se puede caminar, mirar alrededor, hablar con Luca, Mora y Tano y aceptar sus desafíos.
La decisión
La progresión se basa en conocer y vencer a los habituales: sin monedas ni pérdida de avances al perder. Explorar tiene su propio controlador; desafiar vuelve al fútbol-tenis existente.
Qué cambió
Un primer bloque reúne comercios, peatones, chicos, público y ambiente sonoro. Ganar habilita al siguiente rival y la partida termina de vuelta junto a quien desafiaste.
Reejecución histórica · 2026-09-06 · 3fc7e6d. El jugador ya está fuera de la cancha: hay una calle, comercios y un objetivo para encontrar a Luca.
Ver decisiones y correcciones en detalle
El orden Luca → Mora → Tano y el progreso local quedan guardados. Perder, abandonar o repetir un resultado no concede avances adicionales. Teclado y touch comparten el recorrido; mapas y diálogos posteriores conservarán el soporte de retrato. La captura se volvió a ejecutar el 8 de septiembre de 2026; no es una imagen archivada de la fecha original ni una nueva prueba completa de esa versión.
Lo que quedó documentado
La idea: ganarse un lugar
La idea es llegar a una cancha conocida y ganarse un lugar jugando contra sus habituales. La recompensa es reconocimiento y acceso al próximo rival, sin monedas ni castigo sobre el progreso ya conseguido.
neighborhood-design.md
Entrega del primer barrio
El primer bloque incorpora cuatro peatones, tres chicos y seis espectadores sentados, además de comercios y ambiente sonoro. Los desafíos regresan junto al rival y guardan el orden Luca → Mora → Tano.
Se abre un distrito conectado con viviendas, comercios y plazas. El mapa orienta hacia los rivales y 72 recorridos de peatones dan actividad a las calles.
La decisión
El mapa marca un destino sin teletransportar. Un catálogo compartido define construcciones y colisiones; un conjunto acotado de personajes cercanos representa los recorridos para contener el costo.
Qué cambió
El barrio ya se puede recorrer de punta a punta. También se corrigen esperas dependientes del render y suscripciones de entrada en las pruebas de navegador.
Captura del juego · Distrito antes de la revisión de materiales, 8 septiembre 2026.
Ver decisiones y correcciones en detalle
Los 72 recorridos usan 24 personajes animados cercanos. La expansión aumenta el costo de render: los primeros datos se tomaron con render por software y no demostraban rendimiento en teléfonos. La captura conservada muestra este distrito al comenzar la revisión visual del 8 de septiembre.
Lo que quedó documentado
Diseño del distrito
El distrito se organiza en 36 lotes y 60 conexiones ortogonales. El mapa fija una dirección y distancia; no mueve al jugador ni inicia un desafío por él.
district-design.md
Entrega y costo de render
Se verifican conectividad, cruces libres, accesos y posiciones de retorno. Las primeras mediciones de rendimiento usan render por software; se conservan como evidencia de esa prueba y no como cifras de un teléfono.
district-evidence.md
Estabilidad del navegador
Las pruebas dejan de suponer que unos milisegundos equivalen a una distancia recorrida. Esperan velocidad, carga y cuadros realmente observados, y se corrige el momento de suscribir los controles al retomar el juego.
Se trabajan tierra, revoque, madera, cartelería y luz de tarde. Una referencia conceptual y tres revisiones independientes guían las correcciones.
La decisión
Se comparten texturas y se agrupa la geometría estática para dedicar detalle al entorno sin disparar las llamadas de dibujo. Las capturas reales se evalúan por separado del objetivo conceptual.
Qué cambió
La tercera revisión llega a 5,6/10 frente al objetivo de 8. El informe deja claro que no se alcanzó: el pase posterior de materiales no recibe una cuarta nota independiente.
Imagen conceptual generada · Objetivo de dirección artística; no es una captura del juego.Captura del juego · Pase de materiales en producción.
Ver decisiones y correcciones en detalle
Quedan superficies demasiado uniformes y menor profundidad en móvil. El material visual generado está identificado en la procedencia de assets. Esta evaluación histórica no debe confundirse con las revisiones posteriores de las tres canchas o del barrio compacto.
Lo que quedó documentado
Informe histórico de materiales
Se guardan concepto, tres candidatos, correcciones y capturas finales. La tercera revisión marca 5,6/10 y el informe conserva explícitamente el objetivo de 8 como no alcanzado.
previous-final-evidence.md
Tercera revisión
La crítica señala desgaste demasiado uniforme y menor profundidad en móvil. El pase posterior refuerza materiales, pero no se le adjudica una nota nueva que no recibió.
El Potrero, La Plaza y Club del Sur pasan a ser canchas jugables. Luca, Mora y Tano reciben un lugar con suelo, entorno y entrada propios.
La decisión
Se mantiene la misma área de juego y las mismas reglas: tierra, playón y club cambian la identidad visual, no los piques. Los desafíos usan cada sede y conservan el orden de progreso.
Qué cambió
Las tres canchas se pueden visitar y jugar. La segunda revisión visual alcanza 8/10 para esta expansión, con mejoras también en accesos, señalización y retorno tras los partidos.
Captura del juego · Club del Sur en la expansión de tres canchas.
Ver decisiones y correcciones en detalle
Las canchas comparten un catálogo de posiciones y colisiones. Solo rápido y online conservan el potrero original. Los videos recorren las conexiones con teclado y touch; el rendimiento móvil sigue medido en emulación.
Lo que quedó documentado
Galería de las tres canchas
La expansión registra partidos y entradas en el potrero, la plaza y el club, además de recorridos continuos con teclado y touch. La captura incorporada aquí muestra el club en esa etapa.
neighborhood-expansion-gallery.html
Informe de la expansión
Se mantienen 9 × 12,8 m de juego y la física de la pelota en las tres sedes. La identidad cambia con el suelo y la arquitectura; las partidas rápidas y online conservan la cancha original.
neighborhood-expansion-evidence.html
Revisión visual 2
La segunda revisión independiente de la expansión alcanza 8/10. Es una evaluación de esa entrega, no una nota retroactiva para las versiones anteriores.
Las casas aisladas dan paso a frentes continuos, patios interiores y comercios de esquina. El distrito llega a 249 edificios, con balcones, ochavas y veredas más completas.
La decisión
Las viviendas miran a la calle y el mayor detalle se concentra cerca de las canchas. Las construcciones permanecen en calidad reducida; se simplifican detalles y sombras. Una franja peatonal de dos metros queda libre.
Qué cambió
La revisión final no encuentra problemas visuales importantes pendientes. Los recorridos alcanzan picos de 136/116 llamadas de dibujo en desktop/móvil emulado, dentro de los límites de 300/150.
Captura del juego · Almacén, panadería, kiosco y balcón en el barrio actual.
Ver decisiones y correcciones en detalle
La revisión detectó y corrigió paredes laterales vacías, toldos con colisión invisible y una selección que no producía balcones. El resultado tiene 25 balcones y 26 edificios con ochavas reales, derivadas del mismo catálogo que sus colisiones. Pasaron 552 pruebas y 30 casos de navegador aplicables. La nota 2,45/3 corresponde solo a las categorías afectadas; siguen pendientes teléfonos reales y quedan árboles móviles simples y módulos de fachada repetidos.
Lo que quedó documentado
Informe del barrio compacto
El catálogo final contiene 249 edificios, 25 balcones y 26 construcciones con ochavas reales. Los 99 assets existentes conservan sus hashes y totalizan 2.398.002 bytes gzip; no se agregan recursos pagos.
final-evidence.html
Revisión independiente
Se corrigen paredes laterales sin ventanas, toldos invisibles con colisión y una selección de balcones que no generaba ninguno. La revisión final deja como detalles menores los árboles móviles y la repetición de módulos.
compact-visual-review.html
Antes y después de las calles
Las comparaciones parten de las mismas posiciones y cámaras. Se ven frentes continuos donde antes había casas aisladas y retiros de tierra; los cruces y accesos siguen abiertos.
Las próximas versiones incorporan sus cambios, decisiones y resultados a la historia que se puede leer dentro del juego.
La decisión
Mantener un único registro en español e inglés y exigir su actualización antes de publicar, para que la historia no quede atrás del juego. Es un pedido explícito del creador del proyecto.
Qué cambió
La revisión automática comprueba las traducciones, la evidencia local y los HTML generados. El despliegue requiere una entrada nueva respecto de la versión anterior de producción.
Ver decisiones y correcciones en detalle
La portada lee el mismo JSON que la galería y el HTML descargable. La regeneración de la historia conserva las capturas y los videos anteriores y funciona sin las carpetas privadas de recorridos. Esta etapa documenta un cambio del proceso de publicación.
Lo que quedó documentado
Una condición para publicar
El pedido fue que cada release agregue al changelog. Las instrucciones del repositorio, la plantilla de PR, CI y el script de AWS incorporan esa condición; no generan motivos ni fechas a partir de suposiciones.
La publicación del juego pasa a formar parte del flujo de GitHub: cada merge a main ejecuta las verificaciones y, si pasan, inicia el despliegue de esa revisión.
La decisión
Automatizar el despliegue después del merge, como pidió el creador, para que la versión publicada y la rama principal no dependan de un paso manual separado. GitHub usa credenciales temporales para acceder a la cuenta personal de AWS.
Qué cambió
El flujo exige CI completo y una entrada nueva respecto de la revisión real de producción. Comprueba la imagen activa, la salud del servicio y la historia publicada antes de registrar el nuevo release.
Ver decisiones y correcciones en detalle
Se conserva el servicio existente en us-east-1 y su configuración. Los despliegues se ejecutan de a uno y descartan revisiones superadas por un main más reciente. El proceso identifica cada imagen de forma inmutable y permite reintentar la verificación de una publicación interrumpida. Esta etapa cambia el proceso de entrega; no modifica reglas, protocolo ni partidas guardadas.
Lo que quedó documentado
Checks antes de publicar
El job de producción depende de quality, database y browser, y sólo se ejecuta para pushes a main. El entorno production también restringe el acceso a esa rama.
.github/workflows/ci.yml · docs/releases.md
Verificación de los límites del despliegue
Las pruebas del script cubren el rechazo de otras ramas y cuentas, las notas faltantes, las revisiones desactualizadas, los cambios de producción durante el build y el caso en que una imagen anterior sigue respondiendo saludablemente. También verifican que una falla de salud no avance el registro del release.
El CI del merge anterior registró una desconexión antes del primer saque en el test privado de dos jugadores. Ese escenario se ejecuta ahora en un runner separado de los recorridos largos y sin el overlay diagnóstico de colisiones, que no interviene en sus comprobaciones. Conserva el juego, la reacción, la reconexión y la revancha, con un margen acorde al render por software. El check de navegador exige que también pase este job.
CI 34364296012 · .github/workflows/ci.yml · e2e/private-match.spec.ts
Identidad inmutable para AWS
El primer intento automático no obtuvo credenciales porque GitHub emitió el formato de identidad inmutable de 2026. La confianza de AWS quedó vinculada a los IDs permanentes del propietario y del repositorio, además del entorno production; el intento fallido no construyó ni modificó producción.
La historia suma su punto de partida real: Funnis, el juego de fútbol-tenis de 2019 que precede a este proyecto. Se agrega como prólogo, con un enlace a la versión que sigue en línea.
La decisión
Reconocer el precursor sin alterar la cronología numerada: entra como bloque de origen arriba de las etapas, no como una etapa más. Se revisaron sus sonidos y animaciones para reutilizarlos, pero no se importaron.
Qué cambió
El relato ahora arranca en 2019. El enlace lleva a funnis.navarrolajous.com. Las etapas existentes conservan su número y su orden.
Ver decisiones y correcciones en detalle
Funnis es un proyecto de Unity/C# distinto, con dependencias de terceros propias; por eso se cita como origen y se enlaza, en lugar de incorporar sus binarios. Sus audios (silbato, gol, hinchada, patada, pique) mezclan clips de Freesound con atribución y música sin licencia documentada, incompatibles con la política de solo-CC0 verificada por hash de este repositorio, que además ya cubre esos eventos con sonidos CC0 de Kenney. Sus animaciones son capturas de movimiento propias, pero reorientarlas al esqueleto actual sería costoso y redundante. Se conserva, entonces, la herencia de diseño, no los archivos.
Lo que quedó documentado
El juego de 2019
Funnis, fútbol-tenis en Unity para ITBA IDV (Grupo 5): 1v1 local, Arcade y Práctica contra la CPU, energía, tiro cargado y autopase. Sigue jugable en línea.
Los audios y las capturas de movimiento de Funnis no cumplen la política de solo-CC0 con hash de este repositorio, o ya están cubiertos por assets CC0 actuales. Se documenta la decisión en lugar de incorporar archivos.
Potrero prepara analítica opcional de producto y errores del navegador con PostHog. No se carga ni envía nada a PostHog hasta que la persona lo permite expresamente.
La decisión
La elección se mantiene separada de la aceptación legal y se guarda sólo en el dispositivo. Se desactivan la captura automática, las vistas de página automáticas, los mapas de calor y Session Replay; los eventos y sus propiedades atraviesan listas permitidas para excluir identidad visible, códigos e identificadores de partidas, entradas libres del juego, orígenes web y parámetros de URL.
Qué cambió
Un aviso accesible en español e inglés ofrece permitir o rechazar con el mismo peso visual. Opciones de analítica permite cambiar la decisión; al retirarla, el cliente se excluye, borra su identidad y persistencia de PostHog y vuelve a cargar sin el SDK.
Captura local · escritorio en inglés. El aviso aparece después de hidratar la portada y presenta las dos decisiones con el mismo tamaño y tratamiento visual.Captura local · móvil en español. El aviso conserva el texto, el vínculo a privacidad y controles táctiles de ancho completo.
Ver decisiones y correcciones en detalle
La Política de Privacidad identifica a PostHog, el tratamiento en Estados Unidos, los eventos seudónimos y excepciones, conservación, retiro y derechos. La versión de privacidad cambia a 2026-09-09, por lo que la tabla legal existente solicita una nueva aceptación a quienes tienen cuenta sin agregar una migración. Los builds autenticados de producción preparan mapas de código ligados al SHA y los eliminan después de subirlos; los builds locales y de PR no realizan esa carga.
Lo que quedó documentado
Límite de captura
El navegador importa posthog-js dinámicamente sólo con una decisión vigente de permitir. Las pruebas cubren versión y lectura del consentimiento, inicialización única, identificación sólo por UUID interno, reinicio al salir, rutas normalizadas, redacción y listas permitidas.
Los builds autenticados reciben las credenciales para mapas de código de forma efímera y las eliminan junto con los mapas servidos después de la carga. El despliegue se detiene si falta configuración y ningún valor privado queda guardado en el código, el historial o la imagen final.
La configuración productiva vive fuera del repositorio y se valida con esquemas exactos antes de usarla. El wrapper trabaja con temporales privados, limita CI al alcance de build y se cierra ante datos ausentes o inválidos; el reporte público conserva sólo el resultado final sin identificadores operativos innecesarios.
La revisión final quitó del reporte público identificadores y respuestas operativas innecesarias, reforzó la limpieza de URLs y parámetros en errores, y aplicó las actualizaciones de dependencias compatibles señaladas por el audit. Las capturas regeneradas no contienen cuentas ni rutas privadas.
La imagen de producción incorpora el almacén de certificados del sistema que necesitan las herramientas autenticadas para validar conexiones HTTPS.
La decisión
Agregar únicamente los certificados raíz del sistema a la base mínima compartida por compilación y ejecución, sin desactivar TLS ni permitir que una falla de carga sea ignorada.
Qué cambió
El build conserva la publicación cerrada ante errores y puede verificar servicios HTTPS desde la imagen mínima. No cambia la información recopilada ni agrega credenciales a la imagen final.
Ver decisiones y correcciones en detalle
El primer preflight productivo detectó la ausencia del trust store antes de subir o activar una imagen. La corrección se limita a ca-certificates y mantiene los secretos en montajes efímeros de BuildKit.
Lo que quedó documentado
Validación TLS dentro del build
La etapa mínima instala raíces de confianza verificables antes de ejecutar herramientas que se conectan por HTTPS; los errores siguen deteniendo la publicación.
La analítica opcional, el control bilingüe de consentimiento y la política de privacidad actualizada ya están disponibles en producción.
La decisión
Publicar por el camino de recuperación verificado sólo después de completar el build autenticado, eliminar los mapas servidos y comprobar la versión exacta en el dominio público.
Qué cambió
La nueva revisión superó los controles de salud y de historial antes de quedar registrada como producción. La captura permanece desactivada hasta una elección expresa y Session Replay continúa fuera del alcance.
Ver decisiones y correcciones en detalle
La publicación conserva secretos fuera de la imagen, usa el SHA como versión de errores y verifica tanto el origen del servicio como playpotrero.com. Las entradas candidatas de este cambio pasan a fecha publicada una vez confirmada la disponibilidad pública.
Lo que quedó documentado
Publicación verificada
La revisión se registra sólo después de que salud e historial responden correctamente en los dos orígenes comprobados.
Las funciones sociales y competitivas —amigos, clasificatoria por habilidad y tablas de posiciones— quedan activadas por defecto, con recambio de temporada automático.
La decisión
Encender las tres funciones desde los valores por defecto del build, y no sólo en el entorno, para que el cambio quede documentado en el repositorio y viaje con el próximo despliegue.
Qué cambió
La navegación suma el acceso a Clasificatoria y las tres páginas cargan en lugar de redirigir. Las temporadas de ocho semanas ahora cierran y se reabren solas, y la lógica de Elo queda con una sola fuente en la base de datos.
Captura local verificada de la pantalla Clasificatoria en inglés, con los nuevos accesos visibles a Ranked, Friends y Rankings. Los datos de jugador y rating son de demostración local.
Ver decisiones y correcciones en detalle
Los flags de build pasan a verdadero en Docker, AWS, Playwright y los ejemplos. Una función de base de datos con pg_cron hace el recambio de temporada cada hora, se elimina el módulo y la exportación duplicados de Elo en TypeScript, y pruebas de navegador comprueban que dos jugadores permanentes pasan de la cola clasificatoria a la misma sala. El build de Docker compila las herramientas en la arquitectura del host e instala las dependencias de runtime para la arquitectura de destino, evitando ejecutar SWC mediante emulación durante una publicación local.
Lo que quedó documentado
Funciones activadas
Amigos, clasificatoria y tablas quedan en verdadero por defecto en el build, y la navegación suma el enlace de Clasificatoria.
La función rollover_due_seasons y un único trabajo horario de pg_cron quedan cubiertos junto con los caminos felices de amigos, desafíos y tablas; la suite de base de datos pasa 91 de 91.
Dos perfiles permanentes locales entran a la cola clasificatoria y llegan a la misma sala; las rutas y la navegación competitivas también quedan activas en la suite de navegador.
El barrio actual conserva lo aprendido: reglas compartidas, controles legibles y espacio para caminar entre partidos. Las capturas y revisiones anteriores siguen disponibles para comparar.
