Operaciones, lanzamiento y negocio

Este documento define cómo se opera, se lanza y se sostiene económicamente «EL JUEGO» (Argentum Web, provisional): infraestructura y CI/CD, observabilidad, backups, seguridad, monetización sin pay-to-win, comunidad, betas, el lanzamiento como evento, gobernanza, métricas y riesgos. La tesis operativa sale de la evidencia (research/04, /05, /06): en este nicho el operador ES el producto — la causa nº1 de éxodo en los 6 comparables es el operador no confiable, no el juego. Todo lo repetible se automatiza porque el equipo es 1 humano + IA; todo lo público se publica con números reales, porque los números inflados se auditan solos (Ravendawn).

#0. Principios operativos (no negociables de esta área)

1. Números reales siempre: contador online público real, changelogs públicos, sanciones públicas, post-mortems públicos. Evidencia: research/06 regla de oro nº7 ("los claims inflados se auditan solos") y la queja nº1 del AO20 oficial: staff opaco (research/05).
2. El operador es el producto: gobernanza y moderación transparentes son el diferencial más barato y potente del proyecto (research/05, implicación nº1).
3. Equipo 1+IA ⇒ automatización radical: CI/CD, bots de carga, restore drills, wiki auto-generada, triage de moderación asistido por IA. Lo que no se automatiza, se recorta.
4. Cualquier error de monetización se revierte en menos de 72 horas con refund (Ravendawn sobrevivió al suyo revirtiendo; los que no revierten mueren — research/04 y /06).
5. LatAm-first: la infra se decide por latencia a Buenos Aires primero (el núcleo del público es argentino: 82% de reseñas en español, r/argentina, research/05). El resto del mundo llega por CDN y, después, por nodo EU.
6. El silencio se lee como abandono: cadencia pública chica y constante por sobre anuncios grandes espaciados (research/06 regla nº6; AO20 se estabilizó con parches semanales, research/05).

#1. Infraestructura

#1.1 Dónde vive el megaservidor LatAm

Decisión ya tomada: un (1) megaservidor LatAm con población concentrada; nodo España/EU después. Acá se decide ciudad y proveedor.

Marco de latencia: el juego es por casillas con intervalos server-enforced largos (caminar 210 ms/tile, melee 1165 ms, cast 1230 ms, combo 800 ms — research/01). Eso hace el PvE jugable hasta ~150 ms RTT. Pero el «agite» (PvP skill-based, lo sagrado del nicho — research/05) se disputa en ventanas de combo de 800 ms: para el núcleo competitivo queremos < 60–80 ms RTT y, sobre todo, jitter bajo y estable. La muerte jamás puede sentirse culpa del lag (research/06: "la muerte debe ser SIEMPRE culpa del jugador").

RTT típicos entre ciudades candidatas (rangos de referencia por peering regional conocido; se validan con sondas antes de firmar — ver método abajo):

Lecturas:

• Buenos Aires es óptima para el núcleo AR/UY (mayoría absoluta del público) y aceptable para CL; castiga a México (~170 ms, jugable en PvE, malo para agite).
• São Paulo es el mejor promedio regional, tiene 10× más oferta de proveedores y mejor mitigación DDoS comercial; castiga levemente al núcleo AR (+35–50 ms).
• México como nodo único: descartado (destroza al núcleo AR). Miami: descartada como nodo único por la misma razón; era el compromiso de los 2000, hoy hay oferta real en la región.
• Madrid/EU: nunca como server LatAm; es el futuro nodo EU (España tiene comunidad AO histórica).

Método de decisión con datos, no con opiniones: la landing de pre-registro incluye una sonda de latencia (WebSocket ping a 3–4 endpoints candidatos: BsAs, Santiago, São Paulo) y reporta percentiles reales del público que de verdad se registró. La decisión final de ciudad se toma con esa distribución en la mano.

Proveedores candidatos (criterios: CPU dedicada, ancho de banda incluido decente, mitigación DDoS, presencia en la ciudad, precio):

Cálculo de egress que descarta a los hyperscalers: con interest management por celdas (patrón AO20, research/01 y /03), un cliente consume ~2–8 KB/s. A 500 CCU ≈ 2,5 MB/s ≈ 6,5 TB/mes; a 2.000 CCU ≈ 26 TB/mes. En AWS São Paulo eso es USD 975–3.900/mes solo de salida; en Vultr/Latitude/Linode está incluido o cuesta un orden de magnitud menos. Regla: el WebSocket del juego jamás en un hyperscaler; los hyperscalers quedan para nada o para servicios accesorios.

⚠️ DECISIÓN PENDIENTE DE PABLO — Ciudad y proveedor del megaservidor:

• Opción A (recomendada si el pre-registro confirma >60–70% AR/UY): Buenos Aires con Latitude.sh bare metal. Núcleo con 2–10 ms, el agite se siente local, narrativa "el server está en Argentina" (valor de marca en este público).
• Opción B: São Paulo (Vultr dedicado o Latitude). Mejor promedio para CL/MX/resto, más oferta y mejor DDoS comercial, +40 ms para el núcleo AR.
• Opción C: Santiago (Vultr). Compromiso AR+CL, oferta menor. La sonda de latencia del pre-registro decide entre A y B con datos.

#1.2 Specs por fase (sin fechas: por hito)

El servidor Rust/tokio maneja el número de conexiones sin despeinarse; el límite real en una caja de 4 vCPU es simulación + broadcast (research/03). Dimensionar SIEMPRE a 3–5× lo esperado (error de lanzamiento nº2 documentado: Ravendawn balanceado para 10k y llegaron 30k — research/04).

Notas de diseño de capacidad:

• Un proceso de juego single-shard (mundo en RAM) + Postgres para persistencia. El "escalado" del launch no es horizontal: es (a) caja sobrada, (b) cola de login justa y visible, (c) spawns que escalan + canales (innegociable de diseño que absorbe la densidad).
• CPU pinning, tokio multi-thread, tick de simulación heredado (nominal 40 ms/25 Hz), broadcast de red a 10–20 Hz con interpolación (research/03: sobra para juego por casillas).
• NVMe local para Postgres (WAL fsync feliz), nunca storage de red barato.

#1.3 Base de datos

• Postgres autogestionado en host propio contiguo al juego (misma LAN/datacenter), con réplica streaming asíncrona a un segundo host (puede ser el de staging/monitoreo al principio).
• Postgres gestionado en LatAm = solo hyperscalers (caro + egress + latencia entre nubes). No hay opción gestionada buena en BsAs.
• Tuning inicial modesto (el estado caliente vive en RAM del proceso de juego; Postgres persiste snapshots de personajes, cuentas, ledger de economía append-only, mercado, logs de moderación).
• Migraciones versionadas (sqlx/refinery) con regla expand → migrate → contract: ninguna migración destructiva en el mismo release que la usa (habilita rollback del binario sin rollback de datos).

⚠️ DECISIÓN PENDIENTE DE PABLO — Postgres: autogestionado (recomendado, USD ~0 extra, más operación) vs gestionado en hyperscaler (menos operación, más costo + latencia + egress). La recomendación es autogestionado con el runbook de backups/DR de §4; elegir gestionado implica revisar §1.1 completo.

#1.4 CDN y distribución del cliente

• Cliente estático + assets por Cloudflare: Pages (o R2 + CDN) para el bundle TS/Three.js y R2 para assets glTF/KTX2/OGG. Egress USD 0 vía CDN de Cloudflare; POPs en Buenos Aires, Santiago, São Paulo y México cubren LatAm.
• Versionado por hash en filename + cache-immutable; el service worker de la PWA maneja precache del core y lazy-load por zona (los 1.430 OGG y los assets de mundo se bajan por región visitada, no upfront — el presupuesto exacto de peso es de la sección técnica de cliente).
• Música original servida desde el mismo CDN (gatillo nostálgico nº1 — research/05 — tiene que sonar en el primer click, no después de una descarga de 200 MB).
• Estrategia del WebSocket:
  • Opción A (recomendada): WS del juego detrás de Cloudflare proxy (soporta WebSocket; con POP local el hop agregado es mínimo). Beneficios: IP de origen oculta, capa DDoS L3/L4/L7 gratis, TLS gestionado.
  • Opción B: IP directa del proveedor con su mitigación DDoS (Latitude perfil gaming). Menos capas, más exposición.

  • ⚠️ DECISIÓN PENDIENTE DE PABLO — WS detrás de Cloudflare (A) vs directo con DDoS del proveedor (B). Recomendación: A, y medir el overhead real en beta cerrada; si el hop agregado supera ~5–10 ms para el núcleo AR, pasar a B con la IP protegida.

#1.5 Dominio, DNS y correo transaccional

• El nombre del juego está pendiente (decisión de otra sección). Checklist operativo al decidirlo, todo el mismo día: dominio .com (Cloudflare Registrar at-cost o Porkbun) + defensivos razonables (.gg opcional, .lat barato; .com.ar vía NIC.ar si el nombre lo amerita), handles en YouTube/X/Instagram/TikTok/Twitch/Reddit/Telegram/VK, nombre en Discord, org en GitHub.
• DNS en Cloudflare con DNSSEC. Subdominios estándar: play. (cliente), api., ws., wiki., status., staging. (protegido).
• Correo transaccional (verificación, recuperación, avisos de seguridad): Resend (ya operado por Pablo en otros proyectos) con dominio verificado, SPF/DKIM/DMARC desde el día 1. Nada de marketing por email al principio; solo transaccional + un opt-in explícito de "avisame del lanzamiento".

#1.6 Entornos

Staging corre siempre la rama main y es donde los bots de carga nocturnos pegan (§2.2). Regla: nada llega a prod sin haber corrido en staging con bots.

#1.7 El VPS ruso existente

No se usa para producción del juego: RTT Moscú↔Buenos Aires ~300 ms — injugable para el agite y mala señal para "la muerte jamás por lag". Usos legítimos: mirror de descarga/CDN para RU si hiciera falta, staging de la localización RU, y candidato natural a nodo EU/RU futuro.

⚠️ DECISIÓN PENDIENTE DE PABLO — Nodo EU/RU futuro: reutilizar el VPS ruso existente (costo hundido, pero hardware compartido con otros proyectos y jurisdicción RU para datos de jugadores EU) vs contratar Hetzner dedicado para EU (AX/CPX, €40–80/mes, jurisdicción alemana, aísla el juego de los otros proyectos). Recomendación: Hetzner para el nodo EU; el VPS ruso solo como mirror RU sin datos de cuentas.

#2. CI/CD (GitHub Actions)

#2.1 Pipeline de PR (gates obligatorios)

Monorepo (cliente TS + servidor Rust + conversor + herramientas), jobs paralelos:

• Caches agresivos (cargo registry+target, node_modules) para que el ciclo sea corto — con equipo 1+IA, un CI lento es burnout puro.
• cargo audit + npm audit + Dependabot semanal agrupado (ver §5).

#2.2 Nocturnos: bots de carga y smoke E2E

• Bots de carga: binario Rust loadbot que habla el protocolo binario real (login → caminar → atacar → castear → chatear → comerciar), con perfiles mezclados (leveo, agite, trabajador AFK-ish). Corre cada noche contra staging con escalones 500 → 2.000 → 5.000 conexiones; exporta p50/p99 de tick, RTT de eco, paquetes/s, RAM. Falla el workflow si p99 de tick supera el umbral o si hay drift de memoria (soak prolongado). Histórico graficado en Grafana: la regresión de performance se ve el día que se introduce, no en el launch.
• Smoke E2E de navegador (Playwright, headless): visita la URL real de staging → juega como invitado → camina → pega → muere → desconecta a la fuerza y verifica la reconexión con gracia (la feature nº1, research/05/06) → registra cuenta. Corre nightly y post-deploy.
• Drill de restore mensual automatizado (§4).

#2.3 Deploy: blue-green con estado y rollback

• main → deploy automático a staging. Prod: tag vX.Y.Z + aprobación manual (GitHub Environments con required reviewer).
• Cliente/landing/wiki: deploy atómico por CDN (instantáneo, rollback = repuntar al hash anterior).
• Servidor de juego (stateful) — "blue-green" adaptado a un mundo vivo:
  1. Build y provisión del binario verde en el host.
  2. Aviso in-game con cuenta regresiva corta ("mantenimiento en N minutos").
  3. Drain: se pausa el ingreso, se persiste el estado completo, se cierra azul.
  4. Boot verde sobre el mismo estado; los clientes reconectan solos (la reconexión con gracia se reutiliza; los personajes quedan protegidos durante el mantenimiento — la muerte JAMÁS por mantenimiento, misma regla que por desconexión).
  5. Smoke test automático (login bot + invariantes de economía §3.2); si falla, rollback automático al binario azul (posible porque las migraciones son expand/contract, §1.3).
• Objetivo operativo: reinicios que se cuentan en segundos y se anuncian; jamás "se cayó el server" sorpresa. Cada mantenimiento no programado tiene post-mortem público (§0).
• Imágenes en GHCR; infra descrita como código (compose/ansible) en el repo, secretos con sops (§5) — el host se reconstruye desde cero con un runbook (§4).

#2.4 ¿Repo abierto o cerrado?

Tensión real: la cultura AO es de código abierto y el código abierto genera confianza (LambdaClass abrió su rewrite; ao-org es público — research/01), pero la enfermedad de la escena es la fragmentación en servers privados que mueren a los 6 meses (research/05): un fork trivial de nuestro server alimenta exactamente eso, y el anti-cheat/anti-bot pierde ventaja si el server es público.

⚠️ DECISIÓN PENDIENTE DE PABLO — Apertura del código:

• Opción A (recomendada): híbrido. Cliente y protocolo eventualmente abiertos (auditable = confianza, mods de UI estilo RuneLite a futuro), servidor y anti-cheat cerrados, conversor cerrado (es parte del foso).
• Opción B: todo cerrado (máximo foso, cero capital de confianza open source).
• Opción C: todo abierto (máxima confianza, regala el foso y facilita la fragmentación que queremos curar).

#3. Observabilidad

#3.1 Errores

• Sentry SaaS (free tier al inicio, Team si se queda corto): browser JS con sourcemaps del build + sentry-rust en server, release tracking atado al tag de deploy, alerta de spike. Self-hosted (GlitchTip) solo si el volumen lo justifica económicamente — no antes: es un servicio más que operar con un equipo de 1.

#3.2 Métricas (Prometheus + Grafana)

Prometheus + Grafana en el host de monitoreo (no en el host del juego), node_exporter + postgres_exporter + endpoint /metrics del server. Métricas custom de primera clase:

#3.3 Alertas

Grafana Alerting → Telegram (Pablo) + Discord #estado (comunidad, filtrado). Reglas mínimas: proceso caído / healthcheck rojo; p99 tick sobre umbral sostenido; CCU cae >50% en 10 min (proxy de "algo se rompió aunque el proceso viva"); errores Sentry spike; drift del invariante de oro (prioridad máxima: dupe en curso); disco >80%; backup o restore drill fallido; certificado TLS por vencer; réplica de Postgres atrasada.

#3.4 Status page pública + contador online real

• status. con Uptime Kuma (self-hosted, gratis) o BetterStack free: uptime del juego/API/web, incidentes con timeline honesto.
• Contador de jugadores online público y real (innegociable ya decidido; acá se implementa): endpoint público GET /api/online (cache 30 s) que expone el CCU real del proceso — el mismo número que ve Grafana. Se muestra en la landing, en la status page y en Discord (bot). Prohibido inflarlo con bots o "cuentas conectadas": es auditable por terceros y la evidencia dice que se auditan solos (Ravendawn, research/06 regla nº7).
• Historial de CCU público (gráfico 24 h/30 d) — transparencia estilo SteamCharts por decisión propia, antes de que un tercero lo haga por nosotros.

#4. Backups y disaster recovery

La promesa Outlands que adoptamos ("tus personajes seguros, para siempre" — research/04) convierte la pérdida de datos en la muerte del proyecto. Por eso:

• pgBackRest (o wal-g): full nightly + incrementales + WAL archiving continuo (cada 1–5 min) ⇒ RPO ≤ 5 min. Destino: Backblaze B2 o Cloudflare R2 — SIEMPRE en un proveedor distinto al del hosting, cifrado con age.
• Retención: 30 diarios + 12 mensuales (costo de centavos en B2).
• Restore drill mensual automatizado (workflow nightly programado): baja el último backup a un contenedor limpio, aplica WAL, corre invariantes (conteo de cuentas/personajes, suma de oro vs ledger, arranque del server en modo verificación) y reporta a Telegram. Un backup que no se probó restaurar no es un backup. Drill rojo = alerta prioridad máxima.
• Snapshot de disco semanal del proveedor como capa extra (no reemplaza lo anterior).
• Runbook DR escrito y ensayado una vez antes del launch: "murió el host" → provisionar host nuevo (IaC §2.3) → restore → switch DNS/Cloudflare → smoke. RTO objetivo: horas, no días. Incluye el escenario "murió el PROVEEDOR" (restore en el proveedor B de la shortlist de §1.1).
• Backups accesorios: repo git (GitHub + mirror), R2/B2 de assets fuente, export periódico de la wiki y del Discord (canales de anuncios/guías).

#5. Seguridad operacional

• Secrets: sops + age en el repo (nunca en claro), GitHub Actions secrets por environment con required reviewers para prod, rotación al pasar a producción, principio de mínimo privilegio (deploy key por servicio, token de DB por rol).
• Dependencias: lockfiles committeados; cargo audit + cargo deny (licencias/duplicados/advisories) y npm audit en CI; Dependabot semanal agrupado; sin postinstall scripts sin revisar; imágenes base pinneadas por digest.
• Hardening de hosts: SSH solo con llave; administración por Tailscale (SSH y paneles internos sin superficie pública); nftables default-deny (público: solo 443); fail2ban; usuario no-root + systemd sandboxing (ProtectSystem, PrivateTmp, NoNewPrivileges); actualizaciones de seguridad automáticas.
• La superficie de ataque nº1 es el decoder del protocolo binario: fuzzing con cargo-fuzz sobre el parser de paquetes en CI (job periódico), límites duros de tamaño de paquete, rate-limit por tipo de paquete por conexión (patrón que AO20 ya usa — research/01), desconexión con backoff ante basura.
• Anti-DDoS: capa Cloudflare (§1.4) + límites de conexiones por IP + costo de handshake mínimo antes de autenticar. Runbook DDoS: activar "under attack mode", subir umbrales, comunicar por status page/Discord con plantillas listas.
• Cuentas: argon2id, rate-limit de login por IP+cuenta, 2FA TOTP opcional (AO20 ya la ofrece — paridad mínima), emails de aviso de login nuevo, flujo de recuperación que no filtra existencia de cuentas. Evidencia: "seguridad de cuentas" es pedido explícito en OSRS (research/06).
• Pentest básico pre-launch: checklist OWASP ASVS nivel 1 sobre API de cuentas/tienda (auth, sesiones, IDOR, CSRF), escaneo automatizado (nuclei/ZAP) en CI contra staging, revisión específica de: race conditions en trade/banco/mercado (el dupe de Ravendawn fue noticia de portada a las 5 semanas — research/04), y de todos los caminos que crean/destruyen oro contra el ledger.
• Red team comunitario: en beta, recompensas cosméticas + hall of fame por reportes de seguridad/dupes responsables. Canal privado de reporte.

  ⚠️ DECISIÓN PENDIENTE DE PABLO — ¿Formalizar bug bounty con recompensas (cosméticos/oro in-game, sin dinero real al inicio) sí/no? Recomendación: sí, es marketing de confianza barato y los dupes son el riesgo económico nº1.

• Datos personales al mínimo: email + hash y nada más de PII; sin PII en logs; export y borrado de cuenta self-service; privacy policy y ToS trilingües (entregable legal mínimo).

#6. Monetización sin pay-to-win

#6.1 Líneas rojas — lo que JAMÁS se vende (con su evidencia)

Regla de reversión (principio nº4): cualquier ítem/mecánica de tienda que la comunidad lea como cruce de línea se retira y refundea en menos de 72 horas, con post público. Sin defensa orgullosa: Ravendawn sobrevivió a su error solo porque revirtió rápido.

Regla de sometimiento a gobernanza: los cambios de monetización se anuncian antes de salir y tienen encuesta no vinculante previa (§11.1) — nadie puede votar INTRODUCIR P2W (veto de diseño), pero la comunidad siempre ve venir la tienda.

#6.2 Qué SÍ se vende (catálogo)

Evidencia base: la comunidad AO acepta y celebra cosmética y QoL — "la gente mete 40 lucas para crear clan y comprarse ropa" (research/05); Outlands vive de donaciones 100% cosméticas con 0/300 acusaciones de P2W (research/06); Tibia/OSRS/Albion monetizan conveniencia+cosmética a escala (research/04).

Cosméticos (nunca afectan stats, hitboxes ni velocidad):

• Skins de equipo (transmog: el ítem real sigue siendo el que es y el que se dropea; la skin es una capa visual de la CUENTA, no se dropea).
• Tintes de ropa/armadura.
• Monturas cosméticas (misma velocidad que las domadas; la doma sigue siendo el camino de juego).
• Mascotas decorativas (sin pelear, sin lootear).
• Efectos de meditación (el efecto de meditar es EL statement visual histórico de AO — es nuestro "hat de TF2").
• Títulos, marcos de retrato, emblemas de clan custom, colores de nombre en rankings web.
• Regla de legibilidad PvP: en combate, silueta/colores de facción y FX de hechizos hostiles son inalterables; el cosmético del enemigo se puede apagar client-side.

  ⚠️ DECISIÓN PENDIENTE DE PABLO — ¿FX cosméticos de hechizos (auras/colores de casteo propios) entran al catálogo con esa regla de legibilidad, o quedan fuera para blindar la lectura del agite? Opciones: (A) entran solo visibles para el caster y aliados; (B) entran visibles para todos con toggle de "modo competitivo"; (C) no entran.

• Cosméticos de temporada/evento: vuelven cada año (regla anti-FOMO, §6.7); los de logro (temporadas Leagues, torneos) NO se venden jamás — son los trofeos (research/04: los trofeos permanentes son el motor de Leagues).

Conveniencia no-poder:

• Pestañas extra de banco (el banco base es suficiente para jugar; la extra es comodidad de acumulador).
• Cambio de apariencia (dentro de la misma raza — la raza afecta stats en Balance.dat, así que cambio de raza NO existe ni pago).
• Cambio de nombre de personaje / de clan.
• Renombrar mascota, reordenar slots visuales, etc. (menudencias).

Pack Fundador (ventana del lanzamiento): cosmético exclusivo "de fundación" + título + nombre en un monumento in-game. Es el spike de ingresos del launch de todo revival (patrón Outlands) sin tocar poder. Se deja de vender al cerrar la ventana y JAMÁS vuelve (esta exclusividad sí es legítima: premia estar en el ritual, no pagar más).

#6.3 ¿Suscripción "premium de conveniencia"?

⚠️ DECISIÓN PENDIENTE DE PABLO — Sub premium sí/no y contenido. Opciones:

• (A) Sin sub: solo tienda cosmética + conveniencia unitaria. Purismo máximo, ingresos menos predecibles. Es el modelo Outlands (donaciones).
• (B) — recomendada — "Mecenas": sub barata (precio PPP) que da SOLO: un cosmético mensual, badge/título, rol en Discord, nombre en créditos, y acceso anticipado visual a previews (no a contenido jugable). Cero poder, cero conveniencia bloqueada: nada del juego se siente "capado" sin sub (la queja de Albion es exactamente "premium sentido como obligatorio" — research/06). MRR predecible sin tocar las líneas rojas.
• (C) Sub con conveniencia real (banco extra incluido, cola prioritaria post-launch estilo Tibia Premium): más atractiva y más riesgosa; la cola prioritaria y el banco "de alquiler" rozan la percepción de obligatoriedad. Si se elige B, la conveniencia (banco/cambios) se sigue vendiendo unitaria y permanente (comprada = tuya para siempre; nada de "alquiler" que expira — regla TibiaME).

#6.4 Trading oficial taxeado (palanca futura, NO al lanzar)

El modelo Tibia (Coins tradeables + Char Bazaar con 12% de comisión) es la monetización más densa del nicho (research/04), pero Tibia Coins es de facto comprar oro con tarjeta y la propia comunidad de Tibia lo lista entre lo que odia ("credit card training", research/06). Posición:

• Al lanzar: NO existe moneda premium tradeable ni compra de oro oficial. El RMT negro se combate con anti-bot + sinks + vigilancia del ledger.
• Futuro: si el RMT negro crece pese a todo, se lleva a encuesta no vinculante + poll la introducción de un mercado oficial taxeado (la comunidad decide si prefiere RMT legalizado y taxeado o guerra eterna al negro).
• Char Bazaar (subasta oficial de personajes con comisión): solo tiene sentido con años de acumulación; queda documentado como palanca de largo plazo, sometida al mismo proceso.

#6.5 Precios regionales PPP

Precios por país del medio de pago (referencia de multiplicadores estilo Steam):

Reglas anti-arbitraje: precio según país del medio de pago (no VPN); los ítems de tienda no son tradeables entre cuentas (elimina el arbitraje regional y el RMT de cosméticos); regalos entre cuentas deshabilitados al inicio.

#6.6 Pasarelas de pago

Arquitectura recomendada: tienda web propia (en play./cuenta web, fuera del client nativo) con MercadoPago para LatAm + MoR (Paddle o Lemon Squeezy) para el resto. Desktop y PWA compran por web sin fee de plataforma.

⚠️ DECISIÓN PENDIENTE DE PABLO — TWA de Play Store y la tienda: (A) TWA incluye tienda con Play Billing (Digital Goods API, 15% de fee, precios idénticos — obligatorio por política si se vende DENTRO de la app, research/03); (B) TWA sin tienda (se compra por web fuera de la app; la app no linkea a la tienda). Recomendación: B al lanzar (simple, sin fee), A después si Play se vuelve un canal de adquisición relevante.

⚠️ DECISIÓN PENDIENTE DE PABLO — Medios de pago RU (hay idioma ruso día 1): (A) lanzar SIN pagos RU — los rusos juegan gratis todo el juego (los cosméticos no bloquean nada) y se agrega después; (B) YooMoney/Robokassa vía la estructura RU que Pablo ya opera para otros proyectos (separación contable estricta del resto); (C) distribución RuStore/VK Play de la TWA con sus pagos, después. Recomendación: A al lanzar (cero riesgo de compliance en el momento de máxima exposición), evaluar B con asesoría.

⚠️ DECISIÓN PENDIENTE DE PABLO — Estructura de facturación: qué entidad cobra (monotributo/SAS AR para MercadoPago + MoR para el resto ¿a nombre de qué entidad?). Esto es pregunta legal-impositiva abierta (ver preguntas finales); bloquea la puesta en producción de la tienda, no del juego.

#6.7 Reglas de la tienda (percepción)

• Sin FOMO agresivo: sin timers de "quedan 2 horas", sin escasez artificial; lo estacional vuelve cada año (única excepción: Pack Fundador, §6.2).
• Todo lo comprado es permanente en la cuenta.
• Precios visibles en moneda local, sin moneda premium intermedia opaca al inicio (comprás la skin, no "gemas") — las monedas intermedias son la herramienta clásica de ofuscación y esta audiencia la huele.
  • Nota: si se implementa Play Billing (§6.6-A) puede forzar SKUs; mantener mapping 1:1 visible.
• La tienda nunca interrumpe el juego (sin popups, sin "ofertas" al morir — morir y que te ofrezcan algo pago sería leído como P2W emocional).
• Página pública "Qué vendemos y qué jamás venderemos" con las líneas rojas de §6.1 firmadas — el pledge Outlands ("0/300 acusaciones de P2W" se logra con años de pledge cumplido, research/06).

#6.8 Proyección simple de ingresos/costos mensuales (USD)

Supuestos explícitos (conservadores, mezcla de pagos con AR pesado y PPP):

• CCU pico ≈ 10–15% del MAU; "activos" = MAU.
• Conversión pagadora mensual: pesimista 2% / base 4% / techo 8% (el techo es Tibia-like y requiere años de confianza).
• ARPPU mensual PPP-mixto: pesimista 6 / base 9 / techo 14 (neto de fees de pasarela ~7%).
• No incluye: tiempo de Pablo, arte comisionado, música, marketing pago (se asume USD 0 de marketing: Outlands creció 6+ años con presupuesto $0 — research/04).

Lecturas honestas:

• El proyecto se autofinancia en infra desde ~500 MAU en el escenario base; no paga un sueldo a 2.000 MAU. El negocio real aparece en el orden de 10–20k MAU (escala Argentum United 560 CCU ya la insinúa; Tibia con ~13-14k CCU factura €24M/año — research/04 — ese es el techo del nicho, no el plan).
• Los picos reales de ingresos son eventos: launch (Pack Fundador), lanzamientos de colecciones de temporada, nodo EU. Presupuestar contra el valle, no contra el pico.
• Disciplina: la infra se dimensiona para poder achicarse (§1.2) si el post-luna-de-miel es duro; el proyecto debe poder correr indefinidamente en modo mínimo (~USD 150/mes) sin presión — "para siempre" es parte del pitch.

#7. Comunidad

#7.1 Discord trilingüe (el hub)

• Estructura: #anuncios (ES/EN/RU espejados), #estado-del-server (webhooks de status + contador CCU), categorías por idioma (ES primario, EN, RU) con canales de: general, dudas-newbies, clanes/reclutamiento, mercado, capturas-y-clips, guías, sugerencias (alimenta el pipeline de polls §11.1), soporte con tickets (bot), #registro-de-sanciones (espejo público §11.2), #changelog (webhook del repo).
• Onboarding con selección de idioma y rol. Verificación anti-raid nivel medio.
• Rol "Veterano AO" auto-servido con pregunta de época ("¿en qué server jugabas?") — segmenta para la beta cerrada (§8.1) y da pertenencia.
• Integración cuenta↔Discord (OAuth) para rol "jugador", y bot propio que publica hitos del juego (jefe caído, torneo, poll abierto).
• Para RU: espejo de anuncios en canal de Telegram y grupo VK (donde vive esa audiencia); para el resto, Discord es el canónico.
• Moderación del Discord con las mismas reglas públicas del juego (§11.2) — el doble estándar entre juego y Discord es donde se pudre la percepción.

#7.2 Wiki oficial desde el día 1 (modelo Outlands)

Evidencia: Outlands usa "wiki profesional + tutoriales en video" como onboarding y es parte del estándar de oro (research/04); "tutorial/wiki" está en el top de pedidos del nicho (research/05).

• Auto-generada desde los datos reales del juego: el conversor ya parsea obj.dat (4.996 ítems), npcs.dat (1.404 NPCs), Hechizos.dat (293 hechizos, bilingüe parcial), recetas, quests (research/01) ⇒ un job de CI genera el sitio estático (Astro/Starlight + búsqueda Pagefind) con una página por ítem/NPC/hechizo/mapa, siempre exacta a la versión deployada (la wiki se regenera en cada release). Diferencial directo contra las wikis muertas de los servers privados.
• Capa editorial a mano: guías de inicio, clases, mapa interactivo, "cómo funciona la muerte", glosario del agite — ES completo; EN desde los datos bilingües; RU auto-traducido con revisión.
• SEO: la wiki es además el motor de adquisición orgánica ("argentum online browser", nombres de ítems/hechizos que los veteranos googlean de memoria).

⚠️ DECISIÓN PENDIENTE DE PABLO — Wiki: (A — recomendada) estática auto-generada + guías del equipo (cero moderación, siempre exacta); (B) MediaWiki/wiki.gg editable por la comunidad (más "wiki viva", requiere moderación y se desactualiza). Camino medio: A al lanzar, y abrir contribuciones vía PRs de la comunidad si hay demanda.

#7.3 Programa de creadores

Los streamers en portugués lideraron el resurgimiento de Tibia en Twitch (63% de horas vistas — research/04); el ciclo nostálgico de AO se gatilla por videos y música (research/05). El programa:

• Lista objetivo: los canales del nicho identificados en research/05 (hidE-Zone y el ecosistema YouTube/Twitch de AO — completar la lista con criterios: canales con videos de AO con >10k views en los últimos 2 años; streamers de AO20/Argentum United según SullyGnome; los canales que suben los soundtracks de Nix/Ulla con 15–21k views son distribución directa del gatillo nostálgico).
• Tier 1 "Socios de contenido" (5–10 elegidos): acceso a beta cerrada, línea directa (canal privado), códigos de invitación para su audiencia (medibles por canal), cosmético de creador, aviso anticipado de cada release (embargo suave).
• Tier 2 "Creadores" (abierto con requisitos mínimos): kit de prensa (logos, GIFs, B-roll de la demo, capturas 4K, la historia del proyecto en 1 página, ES/EN/RU), códigos de cosméticos para sortear a su audiencia.
• Regla de integridad: los creadores NO reciben ventaja de progreso jamás (ni head-start en launch, §9); reciben acceso, información y cosmética. Cualquier "pagado" se declara.
• Post-launch: eventos co-organizados (torneos casteados por creadores con premios cosméticos/oro), y el espectador clickeable ("mirá el torneo → click → jugás") es la ventaja browser que ningún comparable tiene (research/04).

#7.4 Redes y canales (prioridad por evidencia de audiencia)

Cadencia editorial mínima sostenible (anti-burnout): 1 devlog video por ciclo de release + 1 post corto semanal + changelog SIEMPRE. Regla dura anti-silencio: nunca más de 14 días sin una señal pública de vida (changelog, poll, devlog, post) — el silencio se lee como abandono (research/06).

⚠️ DECISIÓN PENDIENTE DE PABLO — Regla de cadencia pública: máx. 7 vs 14 días sin señal de vida (7 = más confianza, más presión personal; 14 = sostenible). Recomendación: 14 como piso duro con aspiración a 7.

#8. Plan de betas

#8.1 Beta cerrada: el «Consejo de Veteranos» (validación del riesgo nº1)

Objetivo único: validar que "se siente como AO" con la gente que puede certificarlo — veteranos de miles de horas. Este es el plan de validación con veteranos que arranca en F4 (numeración de fases del plan maestro).

• Reclutamiento (50 → 200 → 500 en oleadas, por código de invitación con canal de origen medible): Atlas Argentum, servers-argentum.foroactivo.com, GS-Zone, r/argaming, grupos de Facebook AO, rol "Veterano AO" del propio Discord. NO pescar dentro del Discord oficial de AO20 (5.733 miembros): además de hostil, necesitamos diferenciarnos del oficial, no parasitarlo.
• Segmentar el reclutamiento por arquetipo: PvPers de agite (validan combate/timings), trabajadores/economía (validan rates y mercado), líderes de clan (validan social), ex-GMs/moderadores de comunidades (validan las herramientas de §11).
• Instrumento de validación (no "che, ¿te gustó?"):
  • Encuesta estandarizada "AO-feel score" post-sesión por bloque: laneo en grilla, melee, magia/palabras mágicas, inventario/loot, muerte/fantasma, sonido/música, UI. Escala 1–10 + campo "qué te sacó del feel".
  • Umbral de salida: promedio ≥8 en cada bloque entre veteranos, con los intervalos exactos verificados por telemetría (210/1165/1230/800 ms son server-enforced por diseño; lo que se valida es la PERCEPCIÓN: interpolación, sonido, feedback de golpe).
  • Sesiones observadas (streaming privado + telemetría de inputs) y tests A/B de variantes de feel con feature flags, sin redeploy.
• Recompensa a testers: título + cosmético "Fundador de la beta" permanentes (cero poder). Sin NDA (es comunidad, no corporación); sí un pedido explícito de no spoilear hasta el anuncio público.
• La beta cerrada también ensaya: moderación (§11.2), soporte, kit de retención, telemetría de reconexión.

#8.2 Beta abierta

• Pública, con el funnel completo real: invitado al primer click → cuenta después (la tesis de adquisición, research/04: "link → personaje en pantalla en <30 s").
• Kit de retención encendido (rachas, prey, criatura del día): se mide D1/D7 real por primera vez.
• Stress test público anunciado como evento ("vení a ayudarnos a romperlo", con la comunidad + bots sombra hasta 3–5× el CCU humano): convierte QA en marketing y ensaya el día D.
• Tienda: apagada durante la beta abierta (nada de monetizar antes del launch), con la página "qué venderemos y qué jamás" ya publicada para que la promesa preceda a la tienda.

⚠️ DECISIÓN PENDIENTE DE PABLO — Wipe de la beta abierta: (A — recomendada) beta abierta CON wipe único, anunciado desde el día 0 en el banner de la beta; los testers conservan SOLO cosmético/título de fundador ⇒ preserva intacto el ritual "todos arrancan juntos" del launch (el evento nº1 de esta comunidad, research/05) y permite probar economía sin herencia sucia. (B) beta abierta sin wipe que se convierte en launch blando ⇒ mata el evento de apertura. La evidencia anti-wipe del nicho aplica a wipes REPETIDOS post-launch (los "reset" de los privados y las seasons de AO20), no a un único wipe de beta claramente pactado.

#8.3 Criterios go/no-go entre fases

Checklist medible para pasar de cerrada→abierta→launch (cada ítem verde o no se avanza):

• AO-feel score ≥8 por bloque (cerrada→abierta).
• Bots de carga a 3–5× el objetivo con p99 de tick bajo umbral y cero muertes por desconexión (abierta→launch).
• Reconexión con gracia: tasa de reconexión exitosa >99% en el escenario E2E nightly.
• Invariante de oro sin drift durante toda la beta abierta.
• Restore drill verde el mes corriente + runbook DR ensayado.
• Moderación: reports de beta respondidos dentro del SLA (§11.2).
• Funnel invitado→cuenta y D1/D7 medidos con tableros funcionando (§12).

#9. El lanzamiento como evento

La apertura de server es EL evento social del año de esta comunidad: fecha y hora publicadas, cuenta regresiva, "nos juntamos esa noche picada y vicio" (research/05). El lanzamiento se diseña como ritual, no como deploy.

#9.1 Antes: pre-registro y cuenta regresiva

• Landing con: la demo/beta jugable (el único argumento que atraviesa el escepticismo — research/05), cuenta regresiva a fecha y hora exactas, contador público de pre-registros (real, §0), la sonda de latencia (§1.1) y el pledge de monetización (§6.7).
• Pre-registro = email + país (dimensiona capacidad y regiones) + opt-in de aviso.
• Anuncio de fecha con presencia coordinada: listing en Atlas Argentum (el canal ritual del nicho), foros, grupos FB, Discord/Telegram/VK, creadores (Tier 1 con embargo hasta el anuncio).

  ⚠️ DECISIÓN PENDIENTE DE PABLO — Pre-registro con reserva de nombre de personaje: (A) sí, gratis por pre-registrarse (growth loop + apego temprano; el nombre es identidad en AO); (B) no (nombres por orden de llegada el día D, más "salvaje" y ritual). Si A: reserva expira si no se usa en la primera semana post-launch. Nunca se vende. ⚠️ DECISIÓN PENDIENTE DE PABLO — Día/hora de apertura. Recomendación: viernes a la noche hora Argentina (el ritual del vicio de viernes con amigos, research/05); la hora exacta balancea AR/CL/MX (ej. 21:00 AR = 18:00 MX). Definir con el mapa de países del pre-registro.

#9.2 El día D: runbook

• Congelamiento de deploys salvo hotfix crítico desde 48 h antes; snapshot completo pre-launch; go/no-go checklist (§8.3) firmada.
• Capacidad 3–5× pre-registros estimados activos; si igual se excede: cola de login justa y visible (posición + estimación honesta), jamás crash, jamás cola paga.
• Guardia: Pablo + tooling IA de triage; panel único de guerra (Grafana: CCU, tick p99, errores, invariante de oro, reconexiones).
• Plantillas de comunicación de incidentes listas en ES/EN/RU (status page + Discord + Telegram/VK): la diferencia entre "se cayó y no dicen nada" (muerte reputacional) y "se cayó, lo dijeron en 3 minutos con timeline" (confianza).
• Todos arrancan juntos: cero head-start — ni creadores, ni testers, ni el propio Pablo (los fundadores tienen cosmético, no ventaja).
• Apertura sincronizada con los creadores streameando en vivo el minuto cero.

  ⚠️ DECISIÓN PENDIENTE DE PABLO — ¿Stream oficial de apertura (Pablo/el proyecto como host, con countdown y "abrimos… YA") además de los streams de creadores? (A) sí — refuerza "administrado en serio, con cara" (la evidencia premia devs con cara: Outlands, research/06); (B) no — dejar el show a los creadores y operar en silencio. Recomendación: A, corto y sobrio.

#9.3 Prensa y canales

• Nicho primero: los canales/foros/grupos del ecosistema AO (son la audiencia real) + comunidades de MMOs old-school.
• Medios gaming AR (Cultura Geek, Malditos Nerds, Press Over y similares) con el ángulo "el MMO argentino de los cibers vuelve en el navegador, sin pay-to-win": es una historia de nostalgia + orgullo patrio (los dos positivos top de las reseñas de AO20, research/05).
• Kit de prensa listo (§7.3); acceso de prensa/creadores en la última ventana de beta (sin progreso trasladable).

#9.4 La primera semana post-apertura

• Presencia GM visible y diaria (la contra-imagen del staff ausente/corrupto del oficial).
• Eventos chicos diarios (el sistema de invasiones heredado de AO da eventos baratos de correr — research/01).
• Cadencia de hotfixes con changelog público inmediato.
• Primer poll de gobernanza en la semana 1 (uno chico pero real): instala el hábito y el mensaje "acá se vota de verdad" desde el inicio.
• Métrica de obsesión de la semana: muertes por desconexión (debe ser 0) y cola máxima.

#10. Calendario de contenido post-launch

Cadencia chica constante > expansiones espaciadas (research/06 regla nº6; el silencio de Ravendawn se leyó como abandono; AO20 se estabilizó con parches semanales — research/05).

Reglas:

• El contenido que cambia mecánicas pasa por poll 70% (§11.1); buff libre, nerf consultado (research/06 regla nº3 — OSRS revirtió un nerf en 24 h por motín).
• Nada de "segundo juego/modo" que compita por el equipo: RavenQuest mató a Ravendawn (research/06 regla nº8). Las temporadas son contenido del MISMO juego que alimenta al personaje permanente.
• Presupuesto de energía: si un ciclo viene corto de tiempo, se recorta contenido nuevo, JAMÁS ops (backups, moderación, changelog, polls).

⚠️ DECISIÓN PENDIENTE DE PABLO — Cadencia del ciclo de release: semanal (máxima señal de vida, presión alta — es lo que estabilizó a AO20) vs quincenal (sostenible para 1+IA, sigue siendo "vivo"). Recomendación: quincenal como compromiso público, con hotfixes libres en el medio; subir a semanal solo si la automatización lo hace gratis.

#11. Gobernanza

#11.1 Polls al 70% (estilo OSRS)

El polling al 70% es el único mecanismo documentado que permite agregarle años de contenido a un juego nostálgico sin revuelta (research/04), y el voto genera pertenencia.

Qué se vota (vinculante, umbral 70%):

• Adiciones de contenido y mecánicas nuevas.
• Nerfs y cambios de balance no urgentes ("buff libre, nerf consultado").
• QoL que toque el feel (todo QoL visible en el moment-to-moment).
• Cambios de economía (sinks/sources nuevos).
• Introducción futura de mercado oficial taxeado (§6.4).

Qué NO se vota (veto de diseño, publicado como tal):

• Los innegociables: no-P2W (tampoco se puede votar INTRODUCIR P2W), server-authoritative, full-loot core con sus mitigaciones, multi-personaje gratis, sin wipes, rates para adultos.
• Fixes de bugs/exploits, seguridad, anti-cheat (con comunicación post-hoc).
• Hotfixes de emergencia (con post-mortem público si tocaron gameplay).
• Precios y monetización concreta: encuesta no vinculante previa obligatoria (§6.1) — la comunidad opina siempre, decide el pledge.

Mecánica:

• Voto in-game (panel/NPC urna) + espejo web de resultados con números exactos e historial permanente.
• Elegibilidad anti-sybil: 1 voto por CUENTA (no por personaje — clave con 3 slots gratis), cuenta con antigüedad mínima y actividad mínima.

  ⚠️ DECISIÓN PENDIENTE DE PABLO — Umbral de elegibilidad y quórum: propuesta base = cuentas con ≥7 días de antigüedad y ≥5 horas jugadas; quórum mínimo = 10% del MAU con piso absoluto (p.ej. 100 votos) para que un poll valga. Ajustar números.

• Proceso: propuesta (equipo o comunidad vía #sugerencias con apoyo mínimo) → blog post con el diseño concreto → poll abierto varios días con recordatorio in-game → resultado público → implementación o archivo (lo rechazado puede volver reformulado más adelante).
• El primer poll ocurre en la semana 1 post-launch (§9.4).

#11.2 Moderación pública (el antídoto de la herida nº1)

La queja nº1 del AO20 oficial, por lejos: "staff corrupto, moderación arbitraria" (56+13 menciones — research/05). Nuestro diseño responde punto por punto:

• Código de conducta público con tabla falta→sanción→duración (matriz publicada; sin sanciones inventadas ad-hoc).
• Registro público de sanciones: nombre de personaje, categoría de falta, duración. La evidencia muestra que el enforcement visible se celebra (los ban-posts mensuales de Albion se upvotean; el ban-wave de OSRS fue lo más festejado del año — research/06). Jamás datos personales.
• Apelaciones con SLA: canal formal (ticket), toda sanción es apelable una vez, la revisión la hace alguien distinto de quien sancionó — operativamente: triage y armado de evidencia por tooling IA sobre logs server-side, decisión final humana (Pablo), todo registrado.

  ⚠️ DECISIÓN PENDIENTE DE PABLO — SLA de apelaciones: propuesta ≤72 h para primera respuesta y ≤7 días para resolución. Confirmar números (el SLA se publica; incumplirlo sistemáticamente es peor que uno más laxo cumplido).

• GMs estructuralmente incorruptibles: cuentas GM separadas sin personaje jugable con poderes en el server (la corrupción del AO histórico nace del GM-jugador); toda acción GM queda logueada; los GMs no participan de la economía.

  ⚠️ DECISIÓN PENDIENTE DE PABLO — Nivel de transparencia del log GM: (A) log de acciones GM público en crudo (auditoría radical, diferencial máximo contra el oficial); (B) resumen mensual público de intervenciones + log crudo disponible a pedido en disputas. Recomendación: B al lanzar (A puede exponer técnicas anti-cheat), reevaluar por poll.

• Anti-cheat como narrativa de retención (Tibia recuperó población tras BattlEye y lo usó de marketing — research/04): server-authoritative (ya innegociable) + detección estadística de macros/bots (entropía de input, patrones temporales) + honeypots + replays server-side de sospechosos + ban waves comunicadas con números.
• Soporte: tickets vía Discord/web; restauración de ítems SOLO con evidencia server-side de bug (el ledger lo permite), jamás por muerte legítima (línea clásica del género que protege la economía); recuperación de cuentas con flujo seguro (§5).

#12. Métricas de éxito y tableros

#12.1 Las métricas que definen éxito

#12.2 Tableros

• Ops en tiempo real: Grafana (§3.2) — infra, netcode, economía, guardia.
• Producto: eventos de gameplay/funnel a un pipeline de producto separado de Prometheus.

  ⚠️ DECISIÓN PENDIENTE DE PABLO — Herramienta de analytics de producto: (A) PostHog (ya lo opera en SolCraft/otros; funnels/retención resueltos; cloud free tier generoso o self-hosted); (B) Metabase sobre réplica Postgres + eventos propios (100% autocontrolado, más artesanal). Recomendación: A por familiaridad y velocidad; con anonimización (IDs de cuenta hasheados, sin PII).

• Ritual semanal de métricas (media hora, checklist fija: funnel, D-retención, pico/valle, economía, moderación) → decisiones al backlog. Los números clave (CCU, polls) son públicos por diseño (§0); el resto no se publica pero tampoco se miente.

#13. TOP 10 riesgos del proyecto (con mitigación y señal temprana)

Riesgos menores monitoreados (fuera del top 10): error de monetización percibido como P2W (mitigado por §6.1 + reversión 72 h), pérdida de datos (mitigada por §4 con drills), dependencia de plataformas (Cloudflare/GitHub/Play — mitigación: IaC portable, tienda web propia), cambios legales/impositivos de pagos en AR (mitigación: MoR §6.6).

#Criterios de terminado

Esta área está completa cuando TODO lo siguiente es verdadero y verificable:

Decisiones

• Todas las «⚠️ DECISIÓN PENDIENTE DE PABLO» de este documento están resueltas y anotadas acá mismo (22 decisiones: ciudad/proveedor, Postgres, WS/Cloudflare, nodo EU/RU, apertura de código, bug bounty, FX de hechizos cosméticos, sub premium, TWA/tienda, pagos RU, estructura de facturación, wiki, regla de silencio 7/14 días, wipe de beta abierta, reserva de nombre, día/hora de apertura, stream oficial, cadencia de release, umbrales de voto y quórum, log GM, SLA de apelaciones, analytics de producto).

Infraestructura y operación

• Prod + staging provisionados por IaC reproducible; el runbook "reconstruir desde cero" se ejecutó al menos una vez de verdad.
• CI en verde con todos los gates (§2.1) y bots de carga nightly pasando a 3–5× el target de launch.
• Deploy blue-green con rollback demostrado en staging (incluida una migración expand/contract real).
• Sentry + Grafana + alertas a Telegram/Discord funcionando; hubo al menos un incidente simulado con su post-mortem de práctica.
• Status page pública viva con contador online real embebido también en la landing.
• Backups continuos con RPO ≤5 min y restore drill automatizado en verde el mes corriente; runbook DR ensayado.
• Hardening (§5) aplicado y verificado; fuzzing del decoder en CI; pentest básico pre-launch ejecutado con hallazgos cerrados.

Negocio

• Página pública "qué vendemos y qué jamás venderemos" publicada; catálogo inicial definido con precios PPP por región.
• MercadoPago + MoR operativos en la tienda web con compra de prueba real completada y refund de prueba ejecutado.
• Proyección de §6.8 revisada contra números reales de beta y recalculada.

Comunidad y lanzamiento

• Discord trilingüe estructurado y moderado; espejo Telegram/VK activo; wiki auto-generada deployada y regenerándose por CI en cada release.
• Programa de creadores con lista objetivo completa y ≥5 socios Tier 1 confirmados; kit de prensa trilingüe listo.
• Beta cerrada ejecutada con AO-feel score ≥8 por bloque; beta abierta ejecutada con stress test público; checklist go/no-go (§8.3) completa en verde.
• Fecha y hora de apertura anunciadas con listing en Atlas Argentum, cuenta regresiva pública y runbook del día D escrito y ensayado (dry-run).

Gobernanza y métricas

• Código de conducta, matriz de sanciones, registro público de sanciones y flujo de apelaciones con SLA publicados y USADOS durante la beta.
• Sistema de polls funcionando in-game + web (probado con ≥1 poll real en beta) y calendario del primer poll post-launch definido.
• Tableros de §12 alimentándose con datos reales de beta; ritual semanal de métricas ocurrido ≥2 veces.
• Tabla de riesgos (§13) con sus señales tempranas instrumentadas (las medibles tienen alerta o panel).

#Reconciliación (2026-07-26)

Cierra los puntos del informe 90-huecos-y-decisiones.md asignados a este archivo: H3 (dotación de staff), C19/decisión 82 (wiki), H4 — lado documentos (legal), C17/C18/H14 (presupuestos y temporadas) y H5 (GDPR operativo). Cada subsección dice qué reemplaza. Está sincronizada con la Reconciliación de 05 (R3 temporadas, R6 staffing — donde difieran mecanismos o números, manda 05) y con las «notas desde 05-servidor» al final de este archivo, que quedan vigentes.

#R1. Dotación de staff y moderación por fase (nueva §11.3; acota el «1 humano + IA» de §0-3; alinea 05 §10 D7-(4) y 06 §7.3/§11)

El problema (H3). §0 define el equipo como «1 humano + IA», pero 05 §10 exige four-eyes en permban y apelación resuelta por staff distinto del emisor, 06 exige «ningún jugador moderado por quien no lee su idioma», y este documento promete SLA de apelaciones. Con un solo humano, eso es matemáticamente imposible. Resolución: el equipo remunerado sigue siendo 1 humano + IA; la moderación se sostiene con moderadores voluntarios comunitarios auditados, con poderes limitados, y toda promesa pública (SLA por idioma) se dimensiona a la dotación real de cada fase — jamás prometer lo que la dotación no cubre (el mismo principio P2 de honestidad de 06, aplicado a moderación). La spec canónica del sistema por capas es 05 R6 (escrita en paralelo y convergente con esto); esta sección aporta lo que 05 no cubre: dotación por fase con gates, pipeline por idioma y degradación honesta. Donde difieran números o mecanismos, manda 05 R6.

Modelo de tres patas (roles = matriz de 05 §10.1, sin cambios en la matriz):

1. Pablo (GM/Admin/Owner): única autoridad de tempban+, rollbacks, config runtime y gestión de staff. Decisión final de toda apelación de sanción grave.
2. IA (triage, jamás sanción): dedup de reportes, clasificación por idioma/categoría/severidad, armado del expediente (extractos de log + link al replay de 05 §7.5), borrador de resolución sobre plantilla, priorización de cola, y la detección estadística ya especificada en 05 §7.4. Límite duro: la IA no emite sanciones (las únicas acciones automáticas son las firmas deterministas de 05 §7.4 y el anti-flood, que son del server, no del triage).
3. Mods voluntarios por idioma (roles Guía y Moderador): poderes limitados a responder dudas, mute ≤ 24 h, jail ≤ 1 h y escalar el caso tipificado (límites exactos de 05 R6) — jamás ban de ningún tipo (la matriz de 05 §10.1 ya lo garantiza por construcción). Reclutados del arquetipo «ex-GMs/moderadores de comunidades» de la beta cerrada (§8.1) y del rol Veterano AO del Discord.

Salvaguardas de los mods voluntarios (auditados de verdad):

• Cuenta staff separada sin personaje jugable (regla existente de §11.2 y 05 §10.1); su cuenta de jugador es normal y pública ante el equipo.
• Toda acción queda en gm_actions (append-only); muestreo mensual de acciones por Pablo integrado al reporte de transparencia de 05 §10.2.
• Conflicto de interés codificado: el panel no asigna (y alerta si se fuerza) casos que involucren al propio mod, su clan o sus parties frecuentes.
• Identidad pública como rol («MOD-ES-01»), jamás nombre real ni personaje — coherente con 05 §10.2.
• 2FA obligatorio; revocación del rol inmediata y logueada; las plantillas de respuesta son catálogo versionado (06 R1): el voluntario elige plantilla y completa campos, no escribe prosa libre en nombre del juego.

Pipeline de reportes multilingüe (S38 → resolución; el detalle lingüístico en 06 R1):

Reporte S38 → cola única → IA: dedup + idioma + categoría + severidad + expediente
   ├─ severidad baja (spam/flood/primer aviso) → cualquier mod, con vista MT interna etiquetada
   ├─ severidad media (mute ≤ 24 h, jail ≤ 1 h) → mod QUE LEE el idioma del caso
   └─ severidad alta (candidata a tempban+) → escala a Pablo con expediente armado
Apelación → staff distinto del emisor, que lee el idioma original (06 §11) → resolución registrada y pública

Permban sin four-eyes posible (resuelve la imposibilidad de H3; mecanismo canónico en 05 R6):

• Mientras el staff humano sea 1 (single_staff_mode): permban en dos tiempos — suspensión inmediata de 7 días + registro público motivado (caso completo publicado: case_code, regla, evidencia citada) + ventana de revisión de 72 h antes de convertir a permanente. El «segundo par de ojos» del MVP es el público más la ventana: reversible por construcción. Excepción: firmas deterministas de bot/ataque convierten sin ventana, igualmente publicadas.
• La apelación de un permban la revisa Pablo con el expediente re-generado desde cero por el tooling (fresh-eyes procesal: la IA no le muestra su decisión anterior — 05 R6).
• Al existir un 2º staff humano de confianza (el «mod senior revisor» de la tabla de dotación): single_staff_mode se apaga y se activa el four-eyes real de 05 §10.2 — emisión por Admin + revisión registrada de un humano distinto.

Dotación mínima por fase (gate: sin la dotación, la fase no abre):

Degradación honesta: si un idioma pierde su mod, ese idioma pasa a «modo degradado» publicado: solo severidad baja se resuelve con vista MT, la severidad media/alta espera al humano del idioma o a Pablo, y el SLA público de ese idioma se ajusta en la página de soporte (06 R1 define la alerta). Lo inaceptable es el SLA incumplido en silencio, no el SLA más laxo declarado.

Valores de trabajo (números de 05 R6, que ajustan la propuesta de §11.2 en lo que difieran; ratificación formal de Pablo pendiente en 05 D7): primera respuesta automática con estado y evidencia < 1 h; primera respuesta humana ≤ 72 h para tempban y superiores, ≤ 7 días para sanciones menores; resolución ≤ 7 días; resumen mensual público de transparencia con cumplimiento real del SLA. La anonimización de sanciones menores en el registro público sigue abierta (05 D7-(2)). El evento GM semanal (02 adenda B) se sostiene con el formato semi-automatizado ya recomendado (decisión 47): plantillas + calendario, presencia en vivo solo en fechas especiales — no exige staff extra.

Actualización de riesgos: el riesgo nº4 (§13) suma como mitigación esta dotación por fase, y su señal temprana concreta es appeals_overdue > 0 sostenido o un idioma en modo degradado >30 días.

#R2. Wiki: decisión única (reemplaza la ⚠️ de §7.2; cierra C19 y la decisión nº82 del 90; 06 §8.2 queda subordinado a esto — ver 06 R2)

Decisión: wiki oficial mínima mantenida por el equipo + wiki comunitaria enlazada. Se cierra acá porque las recomendaciones de 07 §7.2-(A) y la consolidada del 90 convergen, y porque es la opción reversible: montar una wiki editable después es aditivo; cerrar una editable con contenido comunitario adentro no lo es. Además su costo de moderación es cero, coherente con la dotación de R1.

• Wiki oficial = estática auto-generada (Astro/Starlight + Pagefind, como ya describe §7.2): datos duros (ítems/NPCs/hechizos/quests/mapas) generados desde los catálogos i18n del juego en cada release — siempre exacta a la versión deployada, trilingüe gratis (el nombre RU canónico sale del catálogo).
• Páginas núcleo mantenidas por el equipo (capa editorial mínima, Tier 1 de traducción): (1) guía del novato / primeros pasos, (2) clases y razas, (3) muerte, fantasma y bendiciones (la promesa nº1 explicada en prosa, con las constantes públicas de gracia de 05 D5), (4) mapa de la región con zonas de riesgo. Nada más es obligatorio: el resto es bienvenido, no prometido.
• Contribuciones por PR con revisión del editor del idioma (06 §3.5): la comunidad puede sumar guías sin que exista superficie de vandalismo ni cola de moderación.
• Wiki comunitaria enlazada: si la comunidad monta la suya (wiki.gg/Fandom/Miraheze), la oficial la enlaza de forma visible con el disclaimer «no oficial — puede desactualizarse». El equipo no la administra, no la modera y no la traduce.
• Quién traduce qué: tabla completa en 06 R2 (datos duros = automático desde catálogos; páginas núcleo = Tier 1 con editor por idioma; guías extendidas = MT con banner hasta revisión comunitaria).

Nota a los criterios de terminado: en la lista de decisiones pendientes (22), «wiki» sale (cerrada acá) y entra «edad mínima» (R3): siguen siendo 22.

#R3. Checklist legal concreta (cierra el lado documentos de H4; las superficies del funnel las agrega la Reconciliación de 01; el lado i18n en 06 R3)

Piezas a redactar como textos, cada una trilingüe (Tier 1 con doble revisión, 06 §3.5/§8.4). «Revisión profesional» = abogado de la jurisdicción antes de ese hito.

⚠️ DECISIÓN PENDIENTE DE PABLO — Edad mínima declarada: (a) 13+ — estándar gaming global, pero en la UE el consentimiento digital varía 13–16 por país ⇒ exige lógica por jurisdicción o aceptar zona gris; (b) 16+ — un solo número global, elimina el problema de consentimiento parental GDPR, coherente con el contenido (full-loot PvP) y con la clasificación RU probable, y no recorta al público real (30–40 años, research/05). Recomendación: (b) 16+. La decisión fija el checkbox de S05, la fila COPPA y la pieza 6.

Coherencia con el funnel (H4 — implementa 01): S04 muestra la línea implícita «al jugar aceptás los Términos y la Política de privacidad» con links; S05/claim exige checkbox de ToS + declaración de edad; footer legal en S01 y S44. La cuenta guarda tos_version aceptada; si cambia una pieza vinculante, re-aceptación en el próximo login (modal con diff resumido en el idioma del jugador). Sin ese registro no hay base contractual para sanciones ni para el borrado de R5.

Secuencia (sin fechas, por hito): piezas 1–4 publicadas antes de la beta abierta (hay cuentas reales desde ahí); pieza 5 + revisión profesional de 1, 2 y 5 antes de encender la tienda (mismo gate que la decisión 81 de entidad); pieza 6 solo si se entra a stores RU. El idioma vinculante (decisión 76) queda pendiente, atado a la 81.

#R4. Presupuesto ops: tabla única por fase (reemplaza los costos de §1.2 y la columna «Costos infra+SaaS» de §6.8; resuelve C17 y C18; incorpora temporadas — H14. 05 §17 queda como referencia de ingeniería por CCU; esta tabla manda en lo presupuestario)

Resoluciones previas a la tabla:

• C18 (dimensionamiento del launch): se resuelve mirando el CCU que el propio §6.8 proyecta: 2.000 MAU ≈ 200–350 CCU pico — dentro del sobre de una caja 8 vCPU/32 GB según 05 §12.1 (diseñada para 2.500 CCU; AO20 aguanta 680 en VB6 mono-hilo). El bare metal 8–16 cores + PG separado + réplica de §1.2 estaba sobredimensionado contra el plan de negocio: queda como «seguro de pico» solo para la ventana de apertura (subir un escalón de máquina esa ventana y achicar después — el blue-green de §2.3 lo permite), no como base permanente.
• C17 (RPO y retención de backups): manda 05 §8.5 — RPO ≤ 60 s (WAL archive_timeout 60 s), retención WAL 14 días / diarios 30 días / semanales 6 meses. §4 queda corregido en esos dos números; el resto de §4 (pgBackRest, proveedor distinto, drill mensual, runbook DR) sigue vigente.
• Réplica streaming: diferida (palanca de 05 §12.4), no parte del launch. Gate para encenderla: tienda encendida (dinero real) O >500 CCU sostenido — lo que ocurra primero. Costo al encender: +40–80 (host chico dedicado; puede compartir con el host de monitoreo al principio).
• H14 (temporadas): topología canónica en 05 R3 — mismo binario con --season, base de datos separada (cero contaminación del mundo permanente), proceso en el mismo host mientras el headroom lo permita (USD 0) o VPS propio 4–8 vCPU/16 GB si la edición trae su propio pico; cierre por job transaccional que transfiere SOLO cosméticos vía seasons/season_rewards (05 §8.2) y archivo frío de la edición al bucket de backups. Se paga solo mientras una temporada está activa; la primera arranca recién con el juego principal estable (02 §19), por eso la fila aparece desde la Fase B.

Tabla única de costos (USD/mes, precios de lista jul-2026; fases = estados de población, no calendario):

Notas:

• Pre-launch (dev + staging + beta cerrada): sigue valiendo la fila «Alpha técnica / beta cerrada» de §1.2 (≈110–170), que no se toca.
• Ventana de apertura: «seguro de pico» opcional — subir el escalón de máquina (16 vCPU/64 GB o metal) solo esa ventana: +100–300 una única vez, se achica al estabilizar.
• Modo mínimo (riesgo nº9): con temporadas apagadas y una caja 4 vCPU/16 GB, el proyecto corre en ≈ 80–170/mes — el «para siempre» sigue siendo barato; se corrige la cifra suelta de «~USD 150» de §6.8/§13 a este rango.
• Lectura de §6.8 corregida: con estos costos, el breakeven del escenario base se corre a 500–1.000 MAU según dónde caiga el rango (antes: «breakeven a 500»). La conclusión de fondo no cambia: el costo del proyecto es tiempo, no fierro.

#R5. GDPR operativo: retención, export y borrado (cierra H5; la superficie de usuario es S44 de 01; el texto público es la pieza 2 de R3. Nota: H5 destinaba la spec de seudonimización a 05 §8/§9, pero la Reconciliación de 05 no la cubrió — la fuente queda acá y 05 §8.2 la implementa a nivel de schema sobre sus tablas append-only)

Principio (ya en §5): PII al mínimo — email + hash y poco más; sin PII en logs; lo append-only (ledger, sanctions, gm_actions) jamás se borra, se seudonimiza.

Tabla de retención por tipo de dato (fuente única; la política de privacidad se genera de acá):

Export self-service (S44 «Datos»): botón → job async → ZIP con JSON/CSV: datos de cuenta (sin hashes), personajes + skills + inventario/banco, historial de mercado propio, movimientos de ledger propios (CSV), sanciones y apelaciones propias, votos propios. Entrega: link firmado por email, expira a los 7 días; límite 1 export por 7 días (anti-abuso). SLA legal: 30 días; operativo: automático.

Borrado self-service (S44, con la fricción ya definida en 01): confirmación con password/2FA + escribir el nombre → estado pending_deletion con 30 días de gracia (email de confirmación; un login del titular durante la gracia ofrece cancelar) → job de purga:

1. Purga de PII: email, hashes, OAuth, TOTP, IPs, user-agents, device keys; revocación de todas las sesiones.
2. Seudonimización server-side (spec de esta sección — cierra H5): personajes → Borrado-#### (número aleatorio no secuencial, sin colisión); ledger/sanctions/gm_actions/appeals intactos pero sin PII; el nombre original queda liberado tras la cuarentena estándar de nombres.
3. Propagación a terceros: PostHog delete, Resend suppression, unlink de Discord.
4. Registro en erasure_log (id interno + hash del email + fecha, sin PII reversible): tras cualquier restore de backup, el runbook DR (§4) re-aplica todas las purgas del log posteriores al punto restaurado — sin esto, un restore resucita PII borrada y viola el derecho ejercido. Se agrega como paso explícito del drill mensual.
5. Excepción documentada en privacidad: cuentas con sanción activa por fraude/RMT/dupe conservan lo mínimo del caso (base: interés legítimo/defensa legal) hasta cerrar el caso.
6. Invitados sin claim: no tienen PII más allá del device_key — su «borrado» es el reciclaje de D10.

Criterios de terminado que se agregan a este documento: (a) dotación de staff por fase cumplida como gate de cada fase de §8.3; (b) piezas legales publicadas según la secuencia de R3; (c) tabla de R4 revisada contra facturas reales al final de la beta; (d) un borrado de cuenta de prueba ejecutado de punta a punta en staging — verificando purga, seudonimización, propagación a terceros y re-aplicación post-restore — antes del launch.

#Reconciliación (2026-07-26) — notas desde 05-servidor

Sincronización con 05-servidor-y-netcode.md, sección «Reconciliación (2026-07-26)»:

• Staffing (cierra H3; ajusta §11.2 y el «1 humano + IA» de §0.3) — la dotación real por fase queda definida en 05 R6: beta = Pablo + ≥ 2 moderadores voluntarios de confianza; launch = ≥ 1 mod voluntario por idioma (objetivo 2), con poderes limitados (mute ≤ 24 h, jail ≤ 1 h, escalar) y auditoría pública total. Four-eyes de permban con 1 solo staff humano se sustituye por «permban en dos tiempos»: suspensión inmediata de 7 días + registro público motivado + ventana de revisión de 72 h antes de convertir a permanente (four-eyes real se activa al existir 2º staff). SLA realista: respuesta automática con evidencia < 1 h; respuesta humana ≤ 72 h para tempban+, ≤ 7 días para sanciones menores; cumplimiento publicado en el reporte mensual. Esto reemplaza los números de la propuesta de SLA de §11.2 en lo que difieran.
• Temporadas (cierra H14; extiende la tabla de §1.2) — el server de temporada es el mismo binario con --season, base de datos separada, merge de trofeos (solo cosméticos) al main por job transaccional al cierre (05 R3). Fila de costo a agregar en §1.2: servidor de temporada solo mientras corre una edición — USD 0 (mismo host, MVP con headroom) a 25–60/mes (VPS propio), + 1–3 de archivo frío de ediciones cerradas.
• Recordatorio de C14 (informe del crítico): el tick es 20 Hz (50 ms) según 05 §3.2; la mención de «40 ms/25 Hz» en §1.2 queda corregida por esta nota — 05 manda.
• La API pública read-only para fan-tools que §7 necesitaba (mods estilo RuneLite, atlas, planillas) queda especificada en 05 R9 (endpoints, rate-limit 60 req/min por IP + API keys gratuitas, términos de uso). Anunciarla es parte del kit de prensa.

#Barrido final (2026-07-26)

Última pasada contra el «Estado post-reconciliación» de 90-huecos-y-decisiones.md. Cierra H20 (página «Para siempre»), H22 (gate del proxy EU) y dos líneas de sync.

#B1. Página «Para siempre» (cierra H20; extiende §6.7 — la página «Qué vendemos y qué jamás venderemos» se amplía a EL pledge del proyecto)

Una sola página pública, trilingüe, firmada por Pablo con nombre y cara (la evidencia premia devs con cara — Outlands, research/06), que junta los compromisos hoy dispersos:

1. No-wipe: «tu cuenta y tu personaje son para siempre». Única excepción, declarada ahí mismo: el wipe único y pactado de la beta abierta (decisión nº84) — anunciado desde el día 0, jamás repetible post-launch.
2. No-P2W: las líneas rojas de §6.1 completas (el contenido que ya tenía la página de §6.7).
3. Números públicos: link al contador real, al registro de sanciones y al tablero de balance; y la cifra que hace creíble el «para siempre» — «este juego corre indefinidamente con ~USD 80–170/mes (modo mínimo, R4); no necesita ser un negocio para seguir abierto».
4. Cadencia: el piso duro de señal de vida (decisión nº83 — 14 días máximo, aspiración 7).
5. Si algún día cierra (el compromiso que ningún server AO dio jamás): aviso con meses de antelación publicado en esta misma página, el mundo no se apaga en silencio. (Redacción final con la pieza 1 de R3 — es texto legal-adyacente, Tier 1.)

Superficies: franja de confianza de S01 (01-barrido B6) + footer + tienda. Los hitos de research/06 («personajes seguros 5/10/15 años» estilo Outlands) se van agregando como aniversarios — la página envejece a favor.

#B2. Gate métrico del proxy EU y mensaje RU (cierra H22; extiende §1.7; el mensaje de expectativa vive en 06-barrido B2)

• La métrica: RTT p95 por país (el panel de §3.2 ya la recoge vía telemetría de conexión de 05 §13.1) + % del MAU por región, ambas en el tablero de §12.2 desde la beta.
• El gate (des-vaguea el «después, medido» de 05 D4/decisión nº64): se abre la evaluación del proxy de borde EU (Madrid/Hetzner — el CÓMO ya está decidido en nº64) cuando se sostenga 30 días: EU+RU ≥ 15 % del MAU con RTT p95 ≥ 180 ms desde esa región. Números de trabajo en config del tablero, ratificables por Pablo con el primer dato real; el disparo es «evaluar y anunciar», no «contratar en silencio» — la decisión de mundo EU separado sigue exigiendo CCU sostenido + voto 70 % (nº64, intacto).
• El mensaje: la expectativa de ping se dice ANTES de que duela — línea honesta en la landing/ficha RU (06-barrido B2) y respuesta precargada en el FAQ/Discord («¿va a haber server EU?» → link a la métrica pública del gate). El gate público convierte el reclamo nº1 previsible del público RU en un contador que ellos mismos pueden empujar.

#B3. Líneas de sync

• H19 (sonda de latencia): la superficie quedó en 01-barrido B4 (S02 mide RTT a 3–4 endpoints candidatos en silencio y lo envía con el pre-registro); §1.1 y §9.1 ya la exigían — el dato alimenta la decisión nº61 y de paso siembra la métrica de B2. Fila menor de privacidad: la medición se declara en la política (07 R5).
• Edad mínima (residuo nº1): R3 queda tal cual (⚠️ de Pablo, recomendación 16+) — era 01 quien la daba por fijada y ya se corrigió (01-barrido B2). Los 3 archivos dicen lo mismo.