Decisiones del proyecto Lota Indómito
Registro de decisiones tomadas. Fecha + decisión + razón + contraparte analizada.
Índice
Por estado
| Estado | Decisiones |
|---|---|
| --- | --- |
| **Vigentes** (encuadran el proyecto hoy) | [D-006](#d-006--servidor-fase-1--python-fastapi), [D-007](#d-007--interfaz--vue-3--typescript), [D-011](#d-011--camino-c-confirmado--motor-propio-s60--pipeline-gpu-activo-2026-08-09), [D-012](#d-012--arquitectura-de-integracin-sentinel--gpu-confirmada-2026-08-09), [D-014](#d-014--encuadre-vigente-concepto-real-del-proyecto-2026-08-10-corregida-el-mismo-da), [D-016](#d-016--reemplazo-de-carboncillo-por-sistema-multi-moneda-de-minerales-2026-08-10-aprobada-el-2026-08-12), [D-017](#d-017--subastas-digitales-de-cosas-reales-con-pago-en-minerales-2026-08-10-aprobada-el-2026-08-12), [D-018](#d-018--wire-format-s60-componentes-explcitos-en-api-rest-y-websocket-2026-08-12), [D-019](#d-019--experiencia-de-juego-mmo-ra-urbano-pokmon-go--wow-con-patrullas-sincronizadas-2026-08-13), [D-020](#d-020--mochila-minera-y-bitcora-de-despachos-meso-loop-2026-08-13) |
| **Propuestas** (pendientes de aprobación) | — |
| **Operativas** (reglas y procedimientos) | [D-001](#d-001--sync-bidireccional-con-drive-para-lotaindomito), [D-002](#d-002--transcripcin-local-con-faster-whisper), [D-003](#d-003--espaol-chileno-obligatorio-en-redaccin) |
| **Históricas** (contexto de módulos y decisiones viejas) | [D-002](#d-002--memoria-operativa-en-docs-separada-de-_analisis), [D-003](#d-003--event-engine-ejemplo-celestialrs--sincronizacin-eventos-digitales--reales), [D-004](#d-004--entregable-para-el-fondo--propuesta--maqueta--demo-de-interfaz), [D-005](#d-005--alcance-del-piloto--lean-doc-04-sin-3d-ni-minijuegos), [D-008](#d-008--la-pila-tcnica-del-juego-la-elige-cliente-de-un-men-de-opciones), [D-009](#d-009--autorizacin-de-uso-de-celestialrspy-en-lota-indmito), [D-010](#d-010--lota-indmito-integra-mdulos-matemticos-del-core-s60-de-sentinel-celestial-como-caso-de-uso), [D-010-A](#d-010-a--mdulos-del-framework-sentinel-identificados-para-integrar-al-juego-rol-especfico-propuesto-pendiente-confirmacin), [D-013](#d-013--dos-pilotos-en-paralelo-motor-propio-vs-tecnologa-de-mercado-2026-08-10) |
Por dominio
| Dominio | Decisiones |
|---|---|
| --- | --- |
| **Concepto / diseño del juego** | [D-014](#d-014--encuadre-vigente-concepto-real-del-proyecto-2026-08-10-corregida-el-mismo-da), [D-016](#d-016--reemplazo-de-carboncillo-por-sistema-multi-moneda-de-minerales-2026-08-10-aprobada-el-2026-08-12), [D-017](#d-017--subastas-digitales-de-cosas-reales-con-pago-en-minerales-2026-08-10-aprobada-el-2026-08-12), [D-019](#d-019--experiencia-de-juego-mmo-ra-urbano-pokmon-go--wow-con-patrullas-sincronizadas-2026-08-13), [D-020](#d-020--mochila-minera-y-bitcora-de-despachos-meso-loop-2026-08-13) |
| **Motor / Piloto B (Sentinel S60)** | [D-009](#d-009--autorizacin-de-uso-de-celestialrspy-en-lota-indmito), [D-010](#d-010--lota-indmito-integra-mdulos-matemticos-del-core-s60-de-sentinel-celestial-como-caso-de-uso), [D-010-A](#d-010-a--mdulos-del-framework-sentinel-identificados-para-integrar-al-juego-rol-especfico-propuesto-pendiente-confirmacin), [D-011](#d-011--camino-c-confirmado--motor-propio-s60--pipeline-gpu-activo-2026-08-09), [D-012](#d-012--arquitectura-de-integracin-sentinel--gpu-confirmada-2026-08-09), [D-013](#d-013--dos-pilotos-en-paralelo-motor-propio-vs-tecnologa-de-mercado-2026-08-10), [D-018](#d-018--wire-format-s60-componentes-explcitos-en-api-rest-y-websocket-2026-08-12) |
| **Piloto A (frontend PWA)** | [D-005](#d-005--alcance-del-piloto--lean-doc-04-sin-3d-ni-minijuegos), [D-007](#d-007--interfaz--vue-3--typescript), [D-008](#d-008--la-pila-tcnica-del-juego-la-elige-cliente-de-un-men-de-opciones), [D-018](#d-018--wire-format-s60-componentes-explcitos-en-api-rest-y-websocket-2026-08-12), [D-019](#d-019--experiencia-de-juego-mmo-ra-urbano-pokmon-go--wow-con-patrullas-sincronizadas-2026-08-13), [D-020](#d-020--mochila-minera-y-bitcora-de-despachos-meso-loop-2026-08-13) |
| **Backend / infra** | [D-001](#d-001--sync-bidireccional-con-drive-para-lotaindomito), [D-006](#d-006--servidor-fase-1--python-fastapi), [D-018](#d-018--wire-format-s60-componentes-explcitos-en-api-rest-y-websocket-2026-08-12) |
| **Operación y reglas del proyecto** | [D-002](#d-002--transcripcin-local-con-faster-whisper), [D-002](#d-002--memoria-operativa-en-docs-separada-de-_analisis), [D-003](#d-003--espaol-chileno-obligatorio-en-redaccin), [D-003](#d-003--event-engine-ejemplo-celestialrs--sincronizacin-eventos-digitales--reales), [D-004](#d-004--entregable-para-el-fondo--propuesta--maqueta--demo-de-interfaz) |
2026-08-13
D-020 · Mochila Minera y Bitácora de Despachos: Meso-Loop y Coleccionismo Diegético (2026-08-13)
- Decisión: estructurar el inventario del jugador y el registro de misiones activas bajo la metáfora diegética de Mochila de Barretero y Bitácora de Despachos.
- Componentes:
- Categorías de Ítems: Minerales & Combustibles (Carbón Grasa, Pirita), Fichas de Pulpería (Ficha Cousiño 1895), y Reliquias & Documentos Históricos (Órdenes de Despacho Ferroviario, Cartas Lacradas de Isidora, Lámpara Davy).
- Sistema de Rareza y Lore: Cada ítem cuenta con memoria histórica narrada en primera persona para reforzar la identidad patrimonial de Lota.
- Bitácora de Misiones Activas: Seguimiento de progreso, objetivo en metros/zona y entrega de recompensas vinculada a la billetera y geofencing.
- Implementación:
piloto-a/src/stores/inventory.tsy componentepiloto-a/src/components/MochilaMinera.vue.
D-019 · Experiencia de juego MMO-RA Urbano: Pokémon GO × WoW con patrullas sincronizadas (2026-08-13)
- Decisión: redefinir formalmente el género y la experiencia de juego de Lota Indómito como un MMO-RA Urbano en el Mundo Real, fusionando la exploración territorial (Pokémon GO) con la profundidad de rol, facciones, clases, cadenas de misiones (Quest Chains) y World Bosses / Raids cooperativos en RA (World of Warcraft).
- Pilares clave:
- Patrullas de NPCs en movimiento: los personajes históricos patrullan activamente las calles con horarios y turnos reales; el jugador los intercepta a pie y camina a su lado en RA ("hombro a hombro").
- Sincronización extrema: visibilidad colectiva y determinista de apariciones en el espacio físico para todos los jugadores presentes.
- Diseño "Ojos Arriba" (Look-Up Design): eliminación de minijuegos 2D abstractos/QTE aislados en favor de dinámicas que exigen observar y alinear elementos del entorno patrimonial real en RA.
- Facciones y Clases: 3 facciones históricas (Hermandad del Carbón, Linaje de la Luz, Gremio de las Mareas) y 4 clases (Barretero, Chinchorrera, Cronista de Salón, Fogonero) con habilidades de campo pasivas.
- Economía de Fichas de Pulpería: integración diegética de minerales del juego (Cu/Au/Sn) con canje en el comercio real de Lota.
- Razón: supera las limitaciones de las audioguías gamificadas y minijuegos desconectados del entorno físico, dotando al juego de tensión, inmersión, identidad de rol y autenticidad histórica.
- Estado: APROBADA por INTERLOCUTOR (2026-08-13). Documentación actualizada en
docs/concepto-juego.mdy_analisis/20_loop_jugador_dia_a_dia.md.
2026-08-12
D-018 · Wire format S60 componentes explícitos en API REST y WebSocket (2026-08-12)
- Decisión: las coordenadas geográficas de los NPCs transmitidas por la API REST (
/npcs) y eventos WebSocket se serializan como cinco componentes sexagesimales enteros explícitos:{"d": i64, "m": i64, "s": i64, "t": i64, "q": i64}(0 ≤ m,s,t,q < 60). NO se transmitei64plano raw ni floats en el contrato de API. - Razón técnica: los cálculos compuestos (distancias, proyecciones, sumas e integraciones temporales) acumulan error de redondeo si se truncan a
i64plano entre operaciones, destruyendo la coherencia de fase en cristales y memorias S60. El formato de 5 componentes mantiene la estructura sexagesimal completa y permite carries discretos exactos entre órdenes. La conversión a grados decimales ocurre únicamente en la última milla del cliente (PWA Vue → MapLibre) mediantes60ToDegreesconBigInt. Regla dura "0 floats en CPU del motor" respetada. - Implementación:
- Backend:
rust/src/server/mod.rsfuncióni64_to_s60_componentsy structNpcWire. - Frontend:
piloto-a/src/utils/s60-to-degrees.tshelper y tests Vitestpiloto-a/tests/s60.spec.ts. - Reversible: sí, si se modifica la API de wire format.
2026-08-10
D-016 · Reemplazo de Carboncillo por sistema multi-moneda de minerales (2026-08-10, aprobada el 2026-08-12)
- Decisión: reemplazar el Carboncillo (
₡) como moneda única del juego por un sistema multi-moneda de minerales con tres monedas: Cobre (Cu, común, base), Oro (Au, medio, 100 cobre), Estaño (Sn, raro, 10.000 cobre = 100 oro). Cada mineral tiene identidad narrativa propia, valor relativo, y se gana por acciones diferenciadas (cobre por misiones de comercio, oro por eventos del cielo, estaño por portales S60). Las monedas son transferibles entre usuarios (P2P), truequeables bilateralmente, comercianteables en el comercio local, y usables en subastas digitales de cosas reales. - Razón: el carbón no es un metal precioso — es combustible, no resuena con la identidad minera metálica de Chile (cobre sobre todo). Una moneda única no incentiva interacción social ni crea economía emergente. El sistema multi-moneda refuerza D-014 (autofinanciamiento) con tres vías nuevas: (1) misiones World Event que requieren el comercio real, (2) comercio acepta múltiples minerales a tipo de cambio configurable, (3) subastas de cosas reales con pago en minerales + comisión del juego.
- Contraparte analizada: mantener Carboncillo único (rechazado — desaprovecha interacción social y economía emergente).
- Reversible: sí. El sistema puede volver a Carboncillo si el piloto no valida la hipótesis.
- Estado actual (2026-08-12): APROBADA por INTERLOCUTOR. Sistema multi-moneda cobre/oro/estaño vigente, reemplaza a Carboncillo como mecánica oficial. Diseño completo en
_analisis/23_sistema_monedas_minerales.md. GDD actualizado con §4 sistema multi-moneda. Implementación del wallet pendiente de materializar en Piloto A y backend.
D-017 · Subastas digitales de cosas reales con pago en minerales (2026-08-10, aprobada el 2026-08-12)
- Decisión: integrar al juego un sistema de subastas digitales donde usuarios listan productos o servicios del comercio local para subastar, otros pujan usando únicamente minerales del juego (cobre, oro, estaño), el juego cobra una comisión del 5-10% y la entrega se coordina localmente en Lota. Objetos subastables: gastronomía local, artesanía, souvenirs del juego, libros, edición limitada, servicios (tour guiado, cena en restaurant, hospedaje, taller). Pago en CLP está excluido (sin Webpay, sin MercadoPago). Sistema de escrow retiene minerales hasta confirmación de entrega; sistema de reputación bilateral; resolución de disputas manual.
- Razón: convierte al juego en marketplace soberano, refuerza D-014 por una vía nueva (la comisión por subasta crea flujo de ingresos directo), diferencia la propuesta (no hay otra plataforma en Chile que mezcle turismo + patrimonio + economía interna de juego + subastas reales). El mineral estaño (rara) gana demanda real para subastar productos caros, lo que ata la rareza del estaño al valor económico concreto.
- Contraparte analizada: venta directa sin subasta (rechazado — pierde tensión de puja y engagement). Pago en CLP (rechazado — pierde integración con el juego y agrega dependencia de sistemas externos).
- Reversible: sí. El sistema puede desactivarse si la complejidad operativa no se justifica en el piloto.
- Estado actual (2026-08-12): APROBADA por INTERLOCUTOR. Sistema de subastas digitales con pago en minerales vigente (sin pago en CLP). Diseño completo en
_analisis/24_subastas_reales.md. GDD actualizado con §11 subastas digitales. Implementación del servicio de subastas pendiente en backend.