Sistemas de juego core (reglas exactas)

Este documento fija las reglas de juego de EL JUEGO (Argentum Web, provisional): qué se hereda verbatim del Argentum Online open-source (ao-org), qué se moderniza y con qué números exactos. Es la fuente única para implementar servidor autoritativo y cliente: si una regla no está acá, no existe. Cada decisión abierta está marcada como «⚠️ DECISIÓN PENDIENTE DE PABLO».

#0. Principios rectores y fuente de verdad

#0.1 Doctrina: «paridad primero, rebalance después (votado)»

1. El AO20 de ao-org es el canon mecánico. Todos los números de balance (fórmulas, intervalos, stats, hechizos, ítems, NPCs, mapas) se heredan verbatim de ao-org/Recursos y del server VB6 (argentum-online-server) vía el conversor programático. No se «reinterpreta» balance a mano: 20+ años de tuning se importan tal cual (research/01: 4.996 ítems en obj.dat, 1.404 NPCs, 293 hechizos, Balance.dat, intervalos exactos).
2. La capa moderna no toca el feel. Rates, mitigaciones de muerte, canales de spawn, kit de retención y protecciones son capas ENCIMA del core, nunca reescrituras del core. El riesgo nº1 del proyecto es «no se siente como AO» (research/05 §implicación 6).
3. Buff libre, nerf consultado. Cualquier nerf a jugadores post-lanzamiento pasa por votación in-game al 70 % (regla de oro nº3, research/06; evidencia OSRS: revert en 24 h tras motín del 3-dic-2025). Los buffs y QoL pueden salir sin voto.
4. No votable (constitucional): no-P2W, anti-cheat server-authoritative, moderación transparente, reconexión con gracia, multi-personaje gratis. Esto no se somete a voto jamás.

#0.2 Pipeline de herencia de datos (contrato con el conversor)

El conversor (spec propia en otra sección del plan) emite JSON canónico consumido por servidor Rust y cliente TS:

Regla dura: el servidor Rust NO tiene números de balance hardcodeados; todo sale de los JSON. Cambiar balance = cambiar datos + changelog público.

#0.3 Golden tests de paridad

Toda fórmula portada del VB6 (SistemaCombate.bas, etc.) se valida con tests de paridad: corpus de casos (inputs → outputs) generado desde el código VB6 de referencia; la implementación Rust debe producir resultados idénticos. Los valores citados en este documento como «referencia clásica» sirven de sanity check; ante discrepancia, gana el código fuente de AO20, no este documento.

#1. Grilla, movimiento y laneo

El laneo en grilla es sagrado (research/05: «lo innegociable: el agite… el laneo en grilla»). Se replica exacto:

#1.1 Reglas de movimiento

#1.2 Netcode de movimiento (reglas de juego, no de infra)

• Server autoritativo total: el cliente envía intención de paso (dirección); el servidor valida colisión, intervalo y triggers, y confirma. El cliente interpola visualmente los 210 ms (el AO original ya hacía interpolación suave — research/01).
• Buffer de input: el cliente puede encolar 1 paso siguiente (mantener la tecla = caminar fluido sin gaps). El servidor rechaza pasos que lleguen a ritmo sostenido < 205 ms/tile (margen de jitter) y corrige con rubber-band. Esto ES el anti-speedhack básico.
• Click-to-move: el servidor NO hace pathfinding por el jugador en PvP-abierto; el cliente calcula la ruta (A* local) y emite pasos individuales, todos validados. Así el click-to-move no da ventaja de esquive automático sobre WASD (equidad de input, queja nº2 del cluster móvil — research/05).
• WASD relativo a cámara: con la cámara rotada 90°, W se mapea a la dirección de grilla «hacia arriba de la pantalla». El mapeo es client-side; el servidor solo ve direcciones de grilla.

#1.3 Apilamiento y piquete

• Un tile ocupado por un personaje/NPC bloquea el paso (no hay stacking de cuerpos), salvo tiles con trigger ANTI_PIQUETE (heredado): ahí no se puede permanecer parado (puertas de banco, muelles), el server te desplaza al tile libre más cercano tras 2 s.
• Los fantasmas (muertos) atraviesan personajes pero no bloqueos.

#2. Atributos, razas y clases

#2.1 Atributos (5, heredados)

Fuerza, Agilidad, Inteligencia, Carisma, Constitución. Rango efectivo 6–40 (base + raza + buffs; las pociones amarillas/verdes suben Fuerza/Agilidad temporalmente, cap +5 sobre base como en AO).

⚠️ DECISIÓN PENDIENTE DE PABLO: generación de atributos al crear personaje.

• (a) Dados clásicos (tiradas con re-roll): ritual nostálgico, pero fricción de onboarding y min-maxing tedioso.
• (b) Asignación fija por raza (todos arrancan con la misma base + modificador racial): moderno, cero fricción, balance parejo. Es la dirección que tomó AO20.
• Recomendación del documento: (b), y el ritual nostálgico se preserva en otra parte (música + apertura).

#2.2 Razas (6)

Modificadores exactos: heredados verbatim de Balance.dat [MODRAZA] → balance.json. Perfil funcional (referencia clásica, valida el conversor):

Regla de fidelidad: no se «arreglan» las razas malas para X clase; las combinaciones sub-óptimas (mago enano) son parte de la identidad y del meta. Rebalance solo por voto 70 %.

#2.3 Clases (12)

Las 12 desde el día 1 (la clase propia es identidad; quitar clases al lanzar = revuelta). Modificadores exactos de combate por clase (evasión, ataque armas, ataque proyectiles, daño armas, daño proyectiles, wrestling, escudo) heredados de Balance.dat [MODCLASE].

⚠️ DECISIÓN PENDIENTE DE PABLO: Pirata en el MVP. El slice vertical (1 ciudad interior + zonas + dungeon + arena) no tiene mar.

• (a) Lanzar las 12 igual y Pirata queda «cojo» hasta que entre navegación (honesto pero genera quejas).
• (b) Lanzar 11 y estrenar Pirata como EVENTO junto con la navegación/costa (convierte la carencia en hype).
• (c) Darle a Pirata un sustituto temporal (mods de abordaje aplicados en arena/dungeon).
• Recomendación: (b) — coherente con «apertura como evento ritual».

#2.4 Vida, maná y stamina por nivel

• HP por nivel: tirada entre mín–máx según clase y Constitución (curva heredada de Balance.dat). La varianza («promedio de vida») es cultura AO: los veteranos comparan promedios.
• Maná por nivel: Mago ≈ 3×INT, semi-mágicas ≈ 2×INT, Paladín ≈ 1×INT, no-mágicas 0 (referencia clásica; exacto de Balance.dat).
• Stamina: aumento plano por nivel (heredado); se gasta al golpear, castear (hechizos consumen maná y stamina — research/01) y trabajar.

⚠️ DECISIÓN PENDIENTE DE PABLO: tirada de vida.

• (a) Aleatoria fiel (min–max por nivel): genera la lotería nostálgica y personajes «bien tirados»… y frustración/reroll.
• (b) Promedio fijo: parejo, moderno, mata el ritual.
• (c) Piso garantizado (tirada aleatoria pero nunca debajo del promedio−1, con «pity» que compensa rachas malas): conserva la lotería sin personajes arruinados.
• Recomendación: (c), votable en beta.

#2.5 Nivel, XP y rates

• Curva ELU (XP para subir) heredada verbatim de la tabla del server AO20.
• Cap de nivel: 47 heredado (el balance de hechizos/PvP de AO20 asume ese techo).
• Progresión infinita post-cap (lección Tibia, research/04 §a-1): pasado 47, la XP alimenta un rango de Veteranía de cuenta (contador infinito visible, medallas por hito, posición en ranking) que NUNCA da stats. Treadmill infinito sin romper el PvP.
• Rates para adultos (innegociable; queja nº3 del oficial: «grindeo x1 para gente sin trabajo», research/05): multiplicador global sobre XP y skills respecto del x1 de AO20, calibrado para que una sesión de 30–45 min rinda progreso visible (research/04 §c-4).

⚠️ DECISIÓN PENDIENTE DE PABLO: rate global de lanzamiento: ×2 o ×3. La comunidad pide «x2–x3» explícitamente (research/05). Recomendación: lanzar ×3 en beta abierta y someter el rate definitivo a la primera votación 70 % (estrena el sistema de gobernanza con un tema que moviliza).

#3. Skills (~29, subidas por uso)

#3.1 Lista y mecánica

Lista completa heredada del server AO20 (~29: Magia, Robar, Tácticas de combate, Combate con armas, Meditar, Apuñalar, Ocultarse, Supervivencia, Talar, Comerciar, Defensa con escudos, Pesca, Minería, Carpintería, Herrería, Liderazgo, Domar, Proyectiles, Wrestling, Navegación, Equitación, Resistencia mágica, Sastrería, Alquimia, …— el conversor extrae el enum canónico). Rango 0–100.

• Subida por uso: cada uso exitoso (y parcialmente los fallidos) tiene probabilidad de +1, decreciente con el nivel de skill; multiplicada por el rate global (§2.5).
• Pity timer (moderno): si N usos consecutivos no suben una skill < 80, el siguiente uso sube garantizado (elimina las rachas secas absurdas sin cambiar el ritmo promedio). N calibrado para preservar el ritmo esperado del AO ×rate.
• Sin caps por clase en skills de trabajo; las skills de combate rinden según los modificadores de clase (un mago con Armas 100 sigue pegando como mago).

#3.2 Entrenamiento y cultura

• Las criaturas de entrenamiento en ciudad (muñecos/gólems pasivos) permiten subir skills de combate básicas hasta un umbral bajo (heredado), después hay que cazar.
• El skill-up es parte del grind identitario: NO se venden skills, NO hay boosts pagos (constitucional).

#4. Combate físico (fórmulas exactas)

Fórmulas portadas de SistemaCombate.bas con golden tests (§0.3). Formas canónicas de referencia:

#4.1 Probabilidad de impacto

PoderAtaqueArma:
  skill < 31   → SkillArmas × ModClase.AtaqueArmas
  31 ≤ s < 61  → (SkillArmas + AGI) × ModClase.AtaqueArmas
  61 ≤ s < 91  → (SkillArmas + 2×AGI) × ModClase.AtaqueArmas
  s ≥ 91       → (SkillArmas + 3×AGI) × ModClase.AtaqueArmas
  + 2,5 × max(0, Nivel − 12)

PoderEvasion = (Tacticas + Tacticas/33 × AGI) × ModClase.Evasion
               + 2,5 × max(0, Nivel − 12)
PoderEvasionEscudo = (DefensaEscudos × ModClase.Escudo) / 2   [se suma si lleva escudo]

ProbExito = clamp(50 + 0,4 × (PoderAtaque − PoderEvasionTotal), 10, 90)

• El clamp 10–90 garantiza que SIEMPRE hay chance de errar y de acertar: es la base del «agite» skill-based («el que manquea explota aunque esté 10 niveles arriba», research/05).
• Proyectiles usan PoderAtaqueProyectiles con la skill Proyectiles y mods propios.
• Fallo con escudo del defensor reproduce el sonido/FX de bloqueo original (feedback sagrado).

#4.2 Daño

DañoUsuario = rand(MinHIT_personaje, MaxHIT_personaje)
DañoArma    = rand(MinHIT_arma, MaxHIT_arma)
Daño        = (DañoArma + MaxHIT_arma/5 × max(0, Fuerza − 15) + DañoUsuario) × ModClase.DañoArmas
DañoFinal   = Daño − Defensa(objetivo)

• Defensa del objetivo: casco si el golpe va a cabeza, armadura+escudo si va a cuerpo (reparto de zona heredado). Contra NPCs: Daño − NPC.Def.
• MinHIT/MaxHIT de personaje crecen por nivel según clase (tabla heredada).
• Sin RNG de críticos moderno: el único «crítico» del AO es el apuñalamiento.

#4.3 Apuñalar (por clase)

• Requiere skill Apuñalar ≥ 10 y arma apuñaladora (daga).
• Probabilidad por clase (formas heredadas; referencia: Asesino ~24 % a skill 100, clases habilitadas no-asesino bajas ~5–10 %).
• Multiplicador de daño al proc: Asesino ×1,4 / resto habilitado ×1,5 (referencia clásica — validar contra AO20 en conversión; versiones difieren).
• Sin requisito posicional (no hace falta la espalda): fidelidad.

#4.4 Intervalos de combate (server-enforced)

El servidor valida CADA acción contra su intervalo con timestamp propio (anti-macro de velocidad). Los intervalos son idénticos para mouse, teclado y táctil (equidad de input).

#4.5 Línea de visión y alcance

• Melee: tile adyacente en el heading (Ctrl/Espacio golpea el tile de enfrente, como AO).
• Hechizos/proyectiles: click en objetivo dentro del área visible (rango heredado por hechizo/arma).

⚠️ DECISIÓN PENDIENTE DE PABLO: line-of-sight estricta. AO clásico es laxo con LoS (se castea a lo que se ve en pantalla, con esquinas permisivas).

• (a) Fiel laxo: idéntico al original, meta conocido.
• (b) LoS por Bresenham en grilla server-side: más «justo», cambia el meta de esquinas/paredes.
• Recomendación: (a) para no alterar el agite; (b) solo si el playtest muestra abusos nuevos por la cámara 3D.

#5. Magia: los 293 hechizos

#5.1 Herencia y presentación

• Los 293 hechizos se heredan completos de Hechizos.dat (bilingüe ES/EN parcial; completar EN/RU es tarea de localización): maná + stamina requeridos, skill Magia mínima, palabras mágicas, FX y sonido original (research/01).
• Palabras mágicas sobre la cabeza al castear — se renderizan SIEMPRE (es feel sagrado; ej. icónico: resucitar = «Rahma Nañarak O'al») con el OGG original de los 1.430 sonidos heredados.
• Aprendizaje: por pergaminos comprados/dropeados (heredado); el spellbook lista todo lo aprendido; la hotbar 1-9 equipa un subconjunto (el layout UI es de otra sección; la regla de juego: cambiar hechizos de hotbar es libre fuera de combate, con cooldown de 5 s si te golpearon recién).

#5.2 Familias de efecto (taxonomía para implementación)

El conversor clasifica los 293 por Tipo del .dat en estas familias; el motor implementa una familia una vez y los 293 son datos:

Regla: ningún hechizo nuevo en el MVP. El primer hechizo nuevo de la historia del juego se diseña con la comunidad (votación) post-lanzamiento.

#5.3 Meditar

• Maná se recupera solo meditando (o pociones azules): sentarse + FX de meditación original; tasa por skill Meditar y nivel (heredada); se interrumpe al recibir daño o moverse. La meditación es un momento social (charla en el templo) — se conserva tal cual.

#6. Estados y stacking

#6.1 Tabla de estados

#6.2 Reglas de stacking

• Parálisis e Inmovilizar no se acumulan: aplicar uno sobre el otro reemplaza (refresh de duración, nunca suma).
• Buffs del mismo atributo: refresh, no stack. Buff + debuff del mismo atributo: se netean.
• Invisibilidad y Oculto son excluyentes (aplicar uno cancela el otro).
• Veneno stackea en duración, no en daño.
• Ceguera + Estupidez pueden coexistir (el combo control clásico).

⚠️ DECISIÓN PENDIENTE DE PABLO: re-parálisis en PvP. En AO se puede re-paralizar en loop (el «paralock» decide duelos y es a la vez amado y odiado).

• (a) Fiel: re-paralizable infinito; el contrajuego es Remover y los potos.
• (b) Diminishing returns: cada re-aplicación en <15 s dura 50 % menos, piso 25 %.
• Recomendación: (a) al lanzar (fidelidad), someter (b) a votación 70 % con datos de la arena.

#6.3 Invisibilidad server-authoritative (ventaja estructural)

En el AO original el cliente conocía la posición del invisible y los cheats lo revelaban (plaga histórica). Acá el servidor deja de emitir la entidad invisible a los demás (salvo parpadeos periódicos heredados del diseño AO — flash breve cada ciertos segundos — y a su party). Anti-cheat por construcción: no hay nada que revelar en memoria del cliente.

• Se rompe al: atacar, castear ofensivo, comerciar, usar banco. No se rompe al tomar pociones (fiel).

#7. Supervivencia: HP, hambre, sed, descanso

• HP no regenera solo en combate; regen lenta natural solo con hambre y sed satisfechas (tick de regen 1 s heredado — research/01).
• Hambre y sed bajan con tick de 60 s (heredado); en 0: no regenera stamina, y penalizaciones heredadas. Comida y agua son ítems (sumidero para pesca/cocina).
• Stamina se recupera descansando (sentado/fogata) y con hambre/sed OK.
• Los newbies (§10) no sufren hambre/sed (heredado).

⚠️ DECISIÓN PENDIENTE DE PABLO: fricción de hambre/sed.

• (a) Fiel total (manual).
• (b) Fiel + QoL: opción «auto-consumir de la mochila» (compra la comida igual → el sumidero económico se conserva; desaparece el click repetitivo, respeto al tiempo adulto — research/06 PIDEN nº1).
• Recomendación: (b), con la opción desactivable.

#8. Muerte, drop y las 3 mitigaciones

#8.1 La regla base (fiel)

Morir en mapa con flag DropItems: se cae al piso TODO el inventario y el oro llevado; el personaje queda fantasma y camina hasta un sacerdote, tile AUTORESU o punto de ciudad para resucitar (research/01). El paseo del fantasma se conserva: es generador de memorias.

Qué no se pierde jamás: XP y nivel (AO no tiene skill/XP-loss al morir y NO lo agregamos — el skill-loss es de lo más odiado de Tibia, research/06), skills, hechizos aprendidos, oro en banco, todo lo de §8.3.

#8.2 Las 3 mitigaciones (evidencia research/04 §a-2: «nadie a escala shippea full loot noventero crudo»)

1. Equipo commodity barato (modelo Albion): el equipo de AO YA es commodity — sin rarezas, sin bind, 100 % crafteable/comprable. La regla nueva es económica: el pipeline de crafteo player-driven (§14) debe mantener el costo de reposición de un set estándar de nivel en ≤ 15–20 min de ingreso medio de ese nivel (métrica monitoreada; si reponerse cuesta una sesión, el sistema falla). Morir cuesta minutos, nunca semanas (regla de oro nº1, research/06).
2. Bendiciones recompradas con oro que escalan (modelo Tibia): compradas al sacerdote; se consumen al morir; recomprables al instante. Sumidero de oro perpetuo que escala con la riqueza del jugador (research/04: blessings = sumidero que sostiene la economía de Tibia hace 20 años).
3. Progresión de cuenta que nunca se dropea (modelo Outlands Aspects): logros, títulos, medallas, Veteranía (§2.5), recompensas-llave de quests (§13), cosméticos, trofeos de temporada, rating de arena, racha diaria. Nada de esto toca el piso jamás.

#8.3 Diseño exacto de bendiciones

• En zonas ROJAS (§8.4) los precios se multiplican ×2 (el riesgo alto también es sumidero).
• El oro llevado SIEMPRE cae (mantiene el incentivo de bancar y el botín del PK).

⚠️ DECISIÓN PENDIENTE DE PABLO: precios y alcance exactos de las bendiciones (los multiplicadores de arriba son propuesta para simular en la hoja de economía §15.5). Alternativa más fiel-Tibia: 5 bendiciones apilables que reducen % de drop cada una. Recomendación: el modelo simple de 2 (legible para el jugador nuevo).

#8.4 Zonas de riesgo escalonado (modelo Albion sobre flags de AO)

Los 843 mapas ya traen flags Seguro/DropItems/restricciones (research/01); el conversor les asigna un color de escalera:

• La recompensa escala con el riesgo: los mapas rojos tienen los mejores spawns/drops (heredado: ya es así en AO).
• El color de zona es visible SIEMPRE en la brújula/HUD (onboarding de reglas de muerte — falla señalada en Albion, research/06).

⚠️ DECISIÓN PENDIENTE DE PABLO: drop parcial exacto de zona amarilla (¿cae el inventario entero o un % aleatorio?). Recomendación: inventario entero pero nunca lo equipado — regla binaria, legible, sin RNG de rabia.

#8.5 Restitución por desconexión (innegociable, ver §22)

La muerte JAMÁS por desconexión (queja nº1 del cluster móvil: 77 votos, 6 años sin arreglar — research/05, research/06). Reglas exactas en §22; a nivel muerte: si el servidor determina que la muerte ocurrió bajo la gracia de DC, la restitución de lo dropeado es automática al reconectar.

#9. PvP: alineación, facciones y triggers

#9.1 Modo seguro y alineación

• Modo seguro (/SEG, toggle en HUD): impide iniciar ataques a ciudadanos (anti-accidente). Default ON para cuentas nuevas.
• Ciudadano / Criminal:
  • Atacar a un ciudadano te marca agresor 60 s (atacable sin pena por la víctima y sus aliados).
  • Matar a un ciudadano → Criminal.
  • Criminal: los guardias de ciudad lo atacan a vista; cualquier ciudadano puede matarlo sin pena; no opera banco/mercado en ciudades del reino (usa la ciudad criminal/mercado negro, heredado del diseño AO de facciones).
  • Redención: matar criminales y tiempo sin agredir suben la reputación hasta volver a ciudadano (curva heredada).

⚠️ DECISIÓN PENDIENTE DE PABLO: sistema de reputación.

• (a) 6 ejes clásicos (Nobleza/Plebe/Burguesía/Ladrón/Bandido/Asesino con promedio) — fiel al viejo AO, opaco.
• (b) Reputación escalar única oculta con umbrales Ciudadano/Criminal — legible, es la dirección AO20.
• Recomendación: (b); los matices de rol los dan las facciones.

#9.2 Facciones: Armada Real vs Legión Oscura

Heredadas completas (rangos, requisitos y recompensas exactos del .dat de facciones vía conversor):

• Armada Real: requiere ser ciudadano con historial limpio; se enlista en el NPC Rey/Reclutador; rangos por criminales/legionarios abatidos + nivel; recompensas por rango: título visible, armadura de facción exclusiva (cosmético-funcional heredado), acceso a cuarteles.
• Legión Oscura: requiere ser criminal con kills acreditados; espejo exacto.
• Desertar/re-enlistar tiene pena heredada (no se «farmea» el cambio de bando).
• Zonas de guerra faccionaria: mapas designados donde Armada vs Legión pelean con drop fiel + puntos de facción extra. Los rangos altos son la escalera de prestigio PvP del juego abierto (la arena §20 es la del PvP deportivo).
• Anti-blob (regla de oro nº2, research/06: «el asesino del full-loot es el 15v1»): los puntos de facción/reputación por kill escalan inversamente con la ventaja numérica local (matar 8v1 da ~0 puntos y no acredita rango). No se prohíbe el zerg (sandbox), se le quita el premio. Números exactos a simular en playtest.

#9.3 Los 40 triggers de tile y su traducción

El array de Triggers por tile viene del .csm (research/01). El conversor extrae el enum completo del server (40 tipos) y emite la tabla de mapeo 1:1 — entregable obligatorio del conversor. Traducción de los funcionalmente críticos al motor 3D:

Regla: ningún trigger se descarta en conversión; los que no apliquen al MVP quedan mapeados como no-op documentado.

#10. Protección newbie (anti-camping)

Evidencia: «PKs campeando newbies» es queja top del oficial y «hostilidad al nuevo» es odio universal nº5 (research/05, research/06).

• Newbie = nivel ≤ 12 (heredado). No dropea NADA al morir, no sufre hambre/sed, ítems newbie intransferibles (heredado — evita mulas).
• Zonas newbie gateadas por nivel: los mapas con restricción Newbie/nivel máx (flag heredado del .csm) expulsan a jugadores de nivel alto — un nivel 30 NO PUEDE ENTRAR al valle newbie. El gate es por flags de mapa ya existentes en los datos (research/01).
• Guardias en los accesos de zonas newbie: atacan a cualquier agresor.
• Pena real al matanovatos: matar a un jugador nivel ≤ 15 fuera de zona de guerra o duelo:
  • no da puntos de facción ni reputación (siempre),
  • aplica marca «Matanovatos» visible 24 h de juego: los guardias de TODAS las ciudades lo atacan, y su nombre aparece en el tablón público de la ciudad (vergüenza social, cultura AO).

⚠️ DECISIÓN PENDIENTE DE PABLO: dureza exacta de la pena a matanovatos. Opciones acumulables: (a) solo marca+guardias 24 h; (b) además bloqueo de bendiciones mientras dure (muere con drop fiel); (c) además prioridad de bounty: quien lo mate cobra recompensa del sistema. Recomendación: (a)+(c) — castigo jugable, no administrativo.

#11. NPCs e IA

1.404 NPCs heredados de npcs.dat con stats/drops/hechizos/respawn exactos (research/01). Arquetipos de IA (tick de IA 150 ms heredado — research/01):

Regla dura anti-cheat: TODA la IA corre en el servidor; el cliente solo renderiza. Los NPCs respetan los mismos intervalos y reglas de movimiento que los jugadores (nada de NPCs que caminan en diagonal).

#12. Spawns dinámicos y canales (la respuesta al «dominando»)

Evidencia: «dominando» (guilds privatizan spawns y extorsionan) es el pedido nº1 de Tibia con thread de 460 pts pidiendo instancias/channels (research/06). Innegociable del proyecto: spawns que escalan + canales.

#12.1 Spawns que escalan con densidad

• Cada zona de caza tiene su tabla de spawn heredada del .csm (posiciones + NPCs + respawn base).
• Escalado: el servidor mide jugadores activos por zona (ventana móvil 5 min). Propuesta inicial: con densidad sobre el umbral de diseño de la zona, el tiempo de respawn se reduce linealmente hasta −50 % y la cantidad simultánea sube hasta ×2 la base. Bajo densidad baja, vuelve a base (nunca menos que el AO original: un jugador solo nunca la pasa peor que en AO).
• El escalado aplica a mobs comunes, NO a jefes con nombre.

#12.2 Canales (channels) de zonas de caza

• Cuando una zona supera su cupo de diseño (propuesta inicial: 40 jugadores en un mapa de caza de 100×100), el servidor abre un canal espejo y los recién llegados entran al canal con lugar. Cambio manual de canal permitido con cooldown 60 s (anti-evasión de PvP: no se puede saltar de canal estando en combate — flag «en combate» = 30 s desde la última acción hostil).
• Los canales se drenan y cierran solos al bajar la población (merge suave: se avisa, nadie es teleportado en combate).
• La ciudad NUNCA se canaliza — la densidad social urbana es el producto (lección Outlands: «un solo mundo lleno ES el producto», research/06). Tampoco se canalizan las zonas de guerra faccionaria (el conflicto masivo es el punto).
• El HUD muestra el canal actual (ej.: «Bosque Oscuro · Canal 2») y la ocupación cualitativa de cada canal.

⚠️ DECISIÓN PENDIENTE DE PABLO: jefes con nombre y canales.

• (a) El jefe existe solo en el canal 1 (mundo «real»): fiel, competitivo, revive el dominando en jefes.
• (b) El jefe rota de canal aleatoriamente (anti-campeo, exige exploración).
• (c) Jefes con lockout personal instanciado (moderno, anti-dominando total, menos «mundo vivo»).
• Recomendación: (b) para jefes de zona + (a) para los jefes-evento de servidor (Gran Dragón), cuyos horarios anunciados los convierten en evento social.

#13. Quests estilo OSRS (pocas y artesanales)

Evidencia: las quests artesanales son de lo más amado de OSRS (research/06); el AO original tiene Quests.DAT (812 KB) pero su diseño es genérico («matá N»); la comunidad pide «PvE/quests con propósito» (research/05).

#13.1 Reglas del sistema

• Pocas, con nombre, hechas a mano. Nada de misiones repetibles generadas («las tareas» del kit de retención §18 cubren lo repetible; las quests son piezas únicas).
• Estructura obligatoria de cada quest: al menos 2 de 3 ingredientes — puzzle (deducción, exploración, diálogo), combate (encuentro diseñado), social (requiere o premia interactuar con otros jugadores).
• Sin markers en el mundo: ni flechas ni signos flotantes. El diario de quests (journal) registra automáticamente pistas claras por paso («El herrero mencionó una galería marcada con tiza en la mina norte»). Pistas suficientes para resolver sin wiki, escritas para releerse tras días sin jugar.
• Recompensas-llave permanentes: cada quest otorga al menos un desbloqueo permanente de cuenta/personaje que NUNCA se dropea (mitigación 3): capacidad, acceso, receta, título, cosmético. Las recompensas-llave no se compran ni se tradean.
• Title-card al completar: pantalla de cierre con arte, nombre de la quest y recompensas (el «Quest complete» de OSRS), compartible (screenshot limpio — growth loop).
• Quests encadenables por requisitos (nivel, quest previa, skill) declarados en el journal.
• XP de quest: paga bien pero no reemplaza la caza (propuesta: la cadena completa del MVP ≈ 1–2 niveles de la franja objetivo).

#13.2 Las quests propuestas para el MVP (Ullathorpe y alrededores)

⚠️ DECISIÓN PENDIENTE DE PABLO: aprobar la lista de 14 (o recortar a 10–12) y el tono del humor local (#12) antes de escribir diálogos. La #13 fija un sumidero diegético: validar contra la hoja de economía (§15.5).

#14. Trabajo: recolección, crafteo y el Trabajador

La cultura de alts trabajadores es diseño económico histórico de AO (cobrar los alts «mata el mercado» — queja nº4 del oficial, research/05). Multi-personaje gratis (§23) existe para esto.

#14.1 Recolección

• Sin nodos agotables ni competencia por nodo (anti-fricción; la competencia sana está en los precios, no en el click).
• La recolección da XP de nivel al Trabajador (heredado AO20: trabajar da XP — research/01 lista skills de trabajo entre las core).

#14.2 Crafteo

• Ramas: Herrería (armas/armaduras/cascos/escudos desde lingotes), Carpintería (arcos/flechas/instrumentos/botes post-MVP desde leña), Sastrería (vestimentas desde pieles), Alquimia (pociones desde raíces/ingredientes).
• Recetas heredadas verbatim de los .dat de recetas (research/01), con sus gates de skill por ítem.
• Sin fallo de crafteo (fiel): materiales + skill suficiente = ítem garantizado; el costo es stamina + tiempo por ítem (heredado).
• Sin calidad/rareza por ítem: el equipo es plano y fungible — es exactamente lo que hace viable el full-loot (mitigación 1, modelo Albion). No se introduce NUNCA un sistema de rarezas de equipo (constitucional, ligado a no-P2W y a la economía de reposición).
• Cola de producción (QoL): craftear 50 flechas = 1 orden con barra de progreso, interrumpible. No cambia costos ni tiempos totales.
• Los consumibles del combate (flechas, pociones, comida) son el motor de demanda perpetua del trabajo (destrucción de ítems = economía viva, research/04 §a-3).

#14.3 El Trabajador como profesión de primera

• Mods de Balance.dat lo hacen el mejor recolector/crafteador por margen amplio (heredado).
• Puede llegar a cap de nivel SOLO trabajando (XP por trabajo, heredado AO20).
• Tareas semanales y racha (§18) incluyen SIEMPRE una rama de trabajo (el trabajador tiene su kit de retención propio).
• Protección: los mapas de recursos de mayor tier son zona amarilla/roja (el riesgo lo cubre §8) pero los de tier base son verdes — un trabajador nuevo nunca está obligado al PvP para progresar temprano.

#15. Economía: oro, mercado, banco, ledger

#15.1 Fuentes de oro (grifos)

Drops de NPCs (GiveGLD heredado de npcs.dat), venta a NPCs (precios obj.dat), recompensas de quest (fijas, §13), tareas semanales (§18), premios de torneo (§20).

#15.2 Sumideros de oro (drenajes)

Regla de salud: relación grifos/drenajes monitoreada por telemetría desde el día 1 con alarma de inflación (research/04 §b-6: exploits de economía al lanzar = riesgo top; Ravendawn: «crafting no rentable al mes» por falta de sinks — research/06).

#15.3 Banco

• Bóveda por personaje (banquero «Goliath»), slots ampliables con oro (sumidero menor). Depósito/retiro gratis.
• El oro bancado NUNCA se dropea (§8.1).

⚠️ DECISIÓN PENDIENTE DE PABLO: bóveda compartida de cuenta (los 3 personajes ven una pestaña común).

• (a) Sí: QoL enorme para la cultura main+trabajadores; el traspaso igual ocurre hoy «por el piso», esto solo le quita fricción y riesgo de scam.
• (b) No: cada personaje es económicamente isla (más fiel, más fricción).
• Recomendación: (a).

#15.4 Comercio seguro y mercado

• Trade directo seguro (heredado mejorado): ventana de 2 paneles; ambos confirman; CUALQUIER cambio resetea ambas confirmaciones + lock de 3 s antes de poder reconfirmar (mata el switch-scam clásico). Log completo de cada trade.
• Mercado: punto único de compra/venta asíncrona.

⚠️ DECISIÓN PENDIENTE DE PABLO: formato del mercado del MVP.

• (a) Bazar global asíncrono (order book simple por ítem, escrow server-side, comisión 5 %): browser-friendly, consultable desde el celular, anti-scam total.
• (b) Tiendas físicas de jugador (AO20 las tiene): densidad urbana linda, mucha fricción.
• (c) (a) en MVP + (b) post-MVP como capa social.
• Recomendación: (c).

#15.5 Ledger anti-dupe (regla de juego, no solo infra)

• Todo movimiento de oro/ítem es un evento en un ledger append-only: (item_uuid | oro, cantidad, origen, destino, causa, timestamp). Cada ítem no-stackeable tiene UUID único de por vida.
• Invariantes verificadas periódicamente: oro_creado − oro_destruido = oro_total_en_mundo; ídem por ítem. Cualquier violación = alarma + congelamiento del ítem/cuenta involucrada (no rollback global).
• Trades, mercado y drops por muerte son transacciones atómicas (o pasa todo o no pasa nada). Un dupe de economía fue noticia de portada para Ravendawn a las 5 semanas (research/04 §b-6): acá el ledger existe ANTES del launch.
• Detección de anomalías: velocidad de enriquecimiento por cuenta, transferencias dirigidas repetidas (RMT), triangulaciones. Acciones de moderación con proceso transparente (la política de moderación es de otra sección; la regla de juego es que el dato existe).

#16. Clanes

Heredados de AO con su rasgo más singular intacto: la democracia interna.

• Fundación: nivel mínimo (heredado, ref. 25), pago único (§15.2), nombre único + tag. Sin límite artificial de cantidad de clanes.
• Elecciones periódicas de líder (heredado del AO clásico): voto in-game de los miembros en ciclo fijo anunciado; el resultado se aplica automático. (Coherencia total con la gobernanza 70 % del proyecto.)
• Estructura: líder + rangos internos configurables (permisos: invitar, expulsar, declarar).
• Alianzas y guerras: declaración formal entre clanes; en guerra, los miembros son atacables mutuamente SIN penas de alineación en cualquier zona no-segura (el casus belli limpio del PvP organizado).
• Antifacción: un clan no puede mezclar Armada y Legión activos (heredado).
• Tablón de clan + tesorería (depósitos voluntarios, log visible para todos los miembros — anti-robo de tesorería con transparencia, no con candados).
• Asedios de castillo: post-MVP (§24), diseñados junto a navegación/territorio.

⚠️ DECISIÓN PENDIENTE DE PABLO: upkeep de clan (costo semanal de mantenimiento como sumidero).

• (a) Sin upkeep (fiel).
• (b) Upkeep chico que escala con miembros (sumidero + limpia clanes muertos del listado).
• Recomendación: (b) con monto simbólico, votable.

#17. Parties y reparto de XP

Mandato: agrupar SIEMPRE rinde más que solo (research/06 PIDEN nº5) — pero el solo es ciudadano de primera (la pifiada de Albion fue abandonarlo).

• Tamaño: máx. 5 (heredado).
• Elegibilidad: XP compartida entre miembros a ≤ 18 tiles del kill (pantalla y media).
• Reparto: proporcional al nivel² de cada miembro presente (heredado del diseño clásico de party AO) sobre el total del kill.
• Bonus de grupo (moderno): XP total del kill × (1 + 0,10 × (miembros_presentes − 1)) → +40 % con party llena. Con reparto incluido, cazar en grupo parejo rinde más XP/hora por cabeza que solo contra el mismo spawn, siempre.
• Loot en party: ronda round-robin automática del oro y drops (configurable a «libre» por el líder). El botín de muerte PvP no se rige por party (lo levanta quien llega).
• Sin penalización por diferencia de nivel dentro del rango del mapa; el gate real son las restricciones de mapa (§10).
• El Liderazgo (skill heredada) gatea el tamaño de party liderable (fiel).

⚠️ DECISIÓN PENDIENTE DE PABLO: números del bonus de party (el +10 %/miembro es propuesta). Validar en playtest que party > solo por cabeza en XP/hora en los 3 spawns de referencia del MVP, y ajustar el coeficiente hasta que se cumpla.

#18. Kit de retención (día 1)

Todos los sobrevivientes del género lo retrofitearon (research/04 §a-5); acá nace incluido. Diseñado para la sesión adulta de 30–45 min.

⚠️ DECISIÓN PENDIENTE DE PABLO: entrenamiento offline.

• (a) Estilo Tibia: elegís una skill al desloguear en posada y entrena sola a ritmo reducido (cap 12 h de acumulación): progreso literal sin jugar.
• (b) Descanso bonificado (estilo rested-XP): acumulás hasta 12 h de «descanso» que al volver duplica la velocidad de skill-up por uso hasta agotarse: premia VOLVER a jugar, no estar ausente.
• Recomendación: (b) — más sano para un juego de sesión corta y no genera cuentas-maceta.

Regla transversal: TODO el kit paga en progresión, cosmético o conveniencia — jamás poder exclusivo. Y nada del kit exige > 45 min/día (anti-«segundo trabajo», research/06 ODIAN nº2).

#19. Temporadas tipo Leagues

Evidencia dura: Leagues rompió el récord de CCU de OSRS en TODAS sus ediciones; los wipes desnudos (Fresh Start Worlds) fracasaron 2/2 (research/04). El ciclo «server nuevo → 2 semanas → muerto» es LA enfermedad de la escena AO (research/05). Regla constitucional: jamás wipes desnudos; lo temporal alimenta al personaje permanente.

• Formato: servidor de temporada paralelo, personajes frescos, duración acotada y anunciada de antemano (referencia del género: el formato corto de OSRS Leagues).
• Reglas remix por edición: XP acelerada fuerte (ref. ×5–×10 sobre nuestro rate), restricciones creativas (zona limitada que se expande por hitos, drop-all global, solo-self-found, sin facciones, etc.) y reliquias: poderes elegibles por árbol exclusivos de la temporada (acá SÍ se experimenta con poder, porque muere con la temporada).
• Cosecha hacia el personaje permanente: puntos de temporada → tienda de trofeos SOLO cosméticos/prestigio (títulos, marcos, skins, mascota cosmética, mural del top 100 de la edición). NUNCA stats, oro ni ítems al servidor principal (cero contaminación económica).
• La apertura de cada temporada es EL evento ritual (fecha+hora con cuenta regresiva — la cultura de apertura de server de AO puesta a trabajar a favor: research/05 «la apertura de server es EL evento social del año»).
• La primera temporada arranca recién con el juego principal estable (el server permanente es el producto; la temporada es el condimento).

⚠️ DECISIÓN PENDIENTE DE PABLO: tema y reglas de la Temporada 1 (proponemos 3 candidatas a diseñar en detalle cuando el MVP esté cerrado: «Frontera» — mapa que se expande por hitos comunitarios; «Sangre y Oro» — drop-all global con economía acelerada; «Solitarios» — self-found sin trade). Se puede someter la elección a votación pública (marketing + gobernanza en un solo acto).

#20. Arena y torneos (PvP deportivo)

Evidencia: el Battle Server de AO20 (PvP instantáneo) le dio su pico 2026 de 308 CCU (research/05); «PvP estructurado además del abierto» es pedido universal nº7 (research/06).

• Modos: 1v1, 2v2, FFA (8–16).
• Personajes prestados: loadouts estandarizados por clase (nivel de referencia del meta, sets commodity fijos, hechizos completos): compiten TODOS desde el día 1 en igualdad — es además el «probá el juego en 30 segundos» para el turista nostálgico (research/05: la demo jugable instantánea «es el único argumento que atraviesa el escepticismo»).
• También hay colas con personaje propio (reglas de zona de torneo: sin drop, sin penas, restauración completa al salir — trigger de arena §9.3).
• Rating: Glicko-2 visible por modo, solo con personaje prestado (mismo loadout = mide skill puro). Placement de 10 partidas, decay suave por inactividad larga.
• Torneo semanal automático (heredando la infraestructura de torneos automáticos de AO20 — research/01 lista torneos entre los sistemas existentes): bracket single-elimination, inscripción in-game, horario prime LatAm, espectador habilitado; premios: título de la semana, cosmético, oro moderado.
• Espectador: cualquiera puede mirar partidas destacadas desde el cliente (palanca de streaming/comunidad).
• Anti-abuso: matchmaking bloquea colusión obvia (mismos IP/cuenta-pares repetidos en 1v1 clasificatorio), win-trading detectado por patrones → reset de rating de la dupla.

⚠️ DECISIÓN PENDIENTE DE PABLO: apuestas de oro en arena (duelos apostados con rake del sistema, p. ej. 5 %, como sumidero).

• (a) Sí: cultura de «agite» + sumidero; riesgo de fomento de RMT/ludopatía interna.
• (b) No al lanzar; revisar con datos.
• Recomendación: (b) — el rake no mueve la aguja económica al inicio y el riesgo reputacional de arrancar con timba es alto.

#21. Logros y rankings

#21.1 Logros

• Sistema heredado de AO20 (logros/medallas existentes — research/01) + categorías propias: Combate, Exploración, Trabajo, Social, PvP, Colección.
• Son progresión de cuenta (mitigación 3): no se dropean, no se venden.
• Cada logro «mayor» paga cosmético o título; los menores, puntos de logro (score público opt-in).
• Los hitos raros se celebran públicamente en el canal del sistema (el juego inmortaliza jugadores: el post nº1 del año de OSRS es un memorial — research/06 AMAN nº1/nº3; primera muerte del Lich del dungeon con nombre del party, etc.).

#21.2 Rankings

• Contador de jugadores online público y REAL en la web y el login (innegociable; regla de oro nº7: «los claims inflados se auditan solos» — research/06).

⚠️ DECISIÓN PENDIENTE DE PABLO: ranking público de oro/riqueza.

• (a) Sí: transparencia y aspiración.
• (b) No: pinta blancos para RMT/scam/acoso y expone la economía.
• Recomendación: (b).

#22. Reconexión con gracia (reglas de juego del DC)

Queja nº1 absoluta del cluster móvil: «desconexión → el personaje queda logueado → te matan → perdés todo» (77 votos, 6 años sin arreglar — research/05). Mandato: la muerte JAMÁS por desconexión.

#22.1 Reglas exactas

1. Reconexión instantánea: la sesión conserva token; reconectar dentro de la ventana devuelve el control exacto (misma posición, mismos estados) sin re-login completo.
2. Detección de DC: sin paquetes ni pong por 5 s → estado «desconectado» server-side.
3. Fuera de combate (sin acción hostil dada/recibida en los últimos 30 s): el personaje se retira del mundo a los 5 s de DC. Sin riesgo.
4. En combate: el personaje permanece 20 s más (anti combat-log: desenchufar el cable no puede ser un escape gratis del PvP). PERO:
   • Deja de ser objetivo válido para NPCs a los 5 s (los mobs se desagrean).
   • Contra jugadores: solo pueden seguir dañándolo quienes YA estaban en combate con él al momento del DC.
5. Restitución: si muere durante la ventana de DC y el jugador reconecta dentro de los 30 min, el sistema restituye automáticamente el 100 % de lo dropeado (los ítems levantados por otros se clonan-restituyen y el ledger §15.5 marca el evento para auditar abuso). El matador conserva lo levantado solo si el sistema clasifica el DC como combat-log deliberado.
6. Clasificador de combat-log: heurística server-side (cierre limpio de socket vs timeout, patrón de latencia previa, frecuencia de DCs «oportunos» de la cuenta). Los abusadores reincidentes pierden el beneficio de restitución por un período visible en su perfil (transparencia > castigo oculto).
7. Muerte por lag del SERVIDOR (tick degradado reconocido por monitoreo): restitución automática sin siquiera pedirla, con disculpa en el log personal (regla de oro: «la muerte debe ser SIEMPRE culpa del jugador» — research/06 ODIAN nº6).

⚠️ DECISIÓN PENDIENTE DE PABLO: agresividad del clasificador (umbral de falsos positivos aceptado). Opciones: (a) pro-jugador (restituir ante la duda — recomendado para lanzar; algo de abuso tolerado y auditable), (b) estricto (restituir solo DC probado). Recomendación: (a) con revisión por datos al mes de operación (la restitución es barata; la muerte injusta cuesta un jugador).

#23. Multi-personaje y cuentas

• 3 slots de personaje GRATIS por cuenta (innegociable; el paywall de Patreon de 1 personaje es queja nº4 del oficial — research/05). Slots extra: solo conveniencia cosmética si algún día se venden más — nunca menos de 3 gratis.
• 1 personaje conectado por cuenta a la vez.
• Los 3 personajes comparten: cuenta, logros/Veteranía/cosméticos (progresión de cuenta §8.2-3), racha diaria (la racha es de la cuenta), y bóveda común si se aprueba §15.3.
• NO comparten: nivel, skills, oro llevado, reputación/facción (un main legionario y un trabajador ciudadano conviven — cultura histórica).

⚠️ DECISIÓN PENDIENTE DE PABLO: política de multi-cuenta (multibox).

• (a) Prohibido conectar 2+ cuentas propias a la vez (enforcement imperfecto pero norma clara + detección por señales).
• (b) Permitido salvo en PvP/eventos (línea difusa, difícil de explicar).
• Recomendación: (a) — con los 3 slots gratis + bóveda compartida, la necesidad legítima de multibox (el trabajador de apoyo) queda cubierta secuencialmente; el multibox simultáneo es vector de abuso (dominando de spawns, votos duplicados en gobernanza).

#24. Fuera del MVP (post-MVP, heredable después)

Sistemas que EXISTEN en los datos heredados y entran por conversor+diseño después del slice vertical — se listan para que nada «se escape»:

⚠️ DECISIÓN PENDIENTE DE PABLO: Robar entre jugadores en MVP. (a) Fiel (el ladrón roba oro/ítems no equipados en zonas no seguras): folclore + griefing; (b) limitado a NPCs y oro con cap en MVP, completo por voto después. Recomendación: (b).

⚠️ DECISIÓN PENDIENTE DE PABLO: Domar en MVP. El Druida necesita identidad día 1. (a) Domar completo (mascotas persistentes máx. 3); (b) solo invocaciones por hechizo en MVP (ya cubiertas por spells.json) y doma completa post-MVP. Recomendación: (b) si el presupuesto de IA de mascotas compromete el slice; (a) si no.

#25. Tabla maestra de intervalos (server-enforced)

Fuente: research/01 + intervalos.ini heredado completo vía conversor (los no listados acá salen del .ini verbatim).

Criterio de fidelidad del feel: una grabación lado a lado (AO20 vs EL JUEGO) de caminar/golpear/castear/combo debe ser indistinguible en timing. Este es un test de aceptación formal del área.

#26. Qué se vota con la comunidad (resumen)

#Criterios de terminado

Esta área está completa cuando:

1. Decisiones cerradas: las ~22 «⚠️ DECISIÓN PENDIENTE DE PABLO» de este documento tienen respuesta registrada (acá mismo, tachando opciones), y quedó marcado cuáles van a votación comunitaria y cuándo.
2. JSON canónicos generados: balance.json, spells.json (293/293), items.json (4.996), npcs.json (1.404), intervals.json, mapas del slice MVP y tabla de triggers 40/40 mapeada (incluye no-ops documentados), emitidos por el conversor desde ao-org/Recursos sin ediciones manuales.
3. Golden tests de paridad en verde: fórmulas de §4 (impacto, daño, apuñalar, evasión/escudo) y curvas de §2 validadas contra corpus generado del código VB6 de referencia; discrepancias resueltas a favor del canon y documentadas.
4. Test de feel aprobado: grabación lado a lado AO20 vs EL JUEGO (§25) validada por Pablo + al menos 3 veteranos externos: caminar, golpear, castear con palabras y sonido, combo, meditar, morir y resucitar.
5. Matriz de estados implementada y testeada: los 8 estados de §6 con su tabla de stacking, incluyendo «paralizado puede castear Remover» y ceguera/invisibilidad server-side (test específico: un cliente instrumentado NO puede extraer posiciones de invisibles del tráfico).
6. Simulación económica corrida: hoja/notebook con grifos vs drenajes (§15) usando drops reales de npcs.json y precios de items.json, demostrando: (a) costo de reposición del set estándar ≤ 15–20 min de ingreso medio por franja de nivel, (b) sumidero de bendiciones > 40 % del drenaje total proyectado, (c) sin espiral inflacionaria a 90 días simulados.
7. Las quests del MVP diseñadas a nivel implementable: lista final aprobada (10–14), cada una con diálogos, pasos de journal, pistas, encuentros y recompensa-llave especificados; title-card diseñada.
8. Reglas de DC verificadas con test de caos: matar el socket en cada fase (fuera de combate, en PvE, en PvP, muerto-fantasma) produce exactamente los resultados de §22, incluida la restitución automática end-to-end.
9. Canales y escalado bajo carga sintética: con bots de carga, la zona de caza abre/cierra canales en los umbrales definidos, el escalado de spawns responde, y la ciudad jamás se canaliza.
10. Documento de gobernanza publicable: la tabla §26 convertida en la página pública «qué votás y qué no» lista para el lanzamiento.

#Adenda (2026-07-26) — Correr, cansancio y motivos para entrar hoy

Dos pedidos nuevos de Pablo: «que se pueda correr, pero que se canse» y «que genere motivos para que las personas jueguen». Esta adenda los baja a reglas exactas. Extiende §1, §2.4, §7, §18 y §25; reemplaza el umbral único anti-speedhack de §1.2 (pasa a ser por modo) y agrega una fila a la tabla maestra §25. Todo lo demás del cuerpo queda intacto.

#A. Sprint: correr con cansancio

Nota de fidelidad: el AO nunca tuvo sprint — esta es la primera mecánica de movimiento nueva del proyecto. Entra marcada «en observación»: si el test de feel o los veteranos dicen que rompe el laneo, se recalibra o se recorta. Sus números se agregan a la tabla de votables §26 como «calibración de sprint post-beta».

#A.1 Regla base de velocidad

#A.2 Stamina: costo, umbrales y fatiga

La stamina ya existe y ya liga el combate (§2.4: golpes, hechizos y trabajo la consumen; esos costos heredados siguen verbatim). El sprint es una capa nueva sobre la misma barra — correr y pelear compiten por el mismo recurso, y esa tensión es el diseño.

#A.3 Regeneración (tick de 1 s de §7, intacto)

• Hambre o sed en 0 → regen 0 (ya es canon §7). Consecuencia nueva: la comida y el agua pasan a ser pertrechos de PvP (salir a zona roja sin provisiones = quedarse sin piernas). El sumidero de §15.2 se refuerza solo.
• Newbies no sufren hambre/sed (§10) → siempre regeneran: el sprint de onboarding no tiene fricción.

#A.4 Input (propuesta)

• Desktop: mantener Shift (primario). Soltás Shift, volvés a caminar en el próximo tile.
• Doble-toque de dirección: disponible como alternativa, OFF por defecto (dispara sprints accidentales en el micro-movimiento de PvP en grilla); se activa en Opciones (S37 de 01-pantallas).
• Táctil futuro: anillo exterior del joystick virtual = correr (mismo costo e intervalos: la equidad de input de §4.4 aplica al sprint).
• Click-to-move: el A* local (§1.2) NUNCA corre solo; corre únicamente mientras mantengas el modificador. Correr es siempre una decisión consciente de gasto, no un default.

#A.5 Animación

• Clip Running distinto de Walking en el rig low-poly, ciclo sincronizado a 150 ms/tile, blend de transición ≤ 1 frame. Detalle de implementación en 04-cliente; la regla de juego es una: quién corre se tiene que leer a distancia (es información de contrajuego, ver decisión N1).

#A.6 PvP: paridad de escape y anti-abuso

Evidencia: el asesino del full-loot es la persecución sin salida (research/06, regla de oro nº2: anti-blob con «escape con contrajuego»; Outlands: los contrapesos anti-PK son el pedido nº1 de su comunidad; Albion: el 15v1 es la queja top, no el full-loot).

1. Paridad total de velocidad: el sprint es idéntico para todas las clases y razas — sin modificadores de Balance.dat, sin ítems que lo aceleren, jamás. Con costo porcentual (§A.2), perseguidor y perseguido en igualdad de condiciones: la persecución se decide por manejo de stamina, terreno y contrajuego (parálisis, remover, potos), nunca por nivel ni billetera.
2. Anti-sprint-kite: mientras corrés NO podés golpear, castear, tirar proyectiles, ni iniciar comercio/banco. Pociones SÍ (el spam de potos es cultura AO y mantiene viable la fuga; es simétrico para ambos lados).
3. Candado de arranque: iniciar sprint exige 1 s sin acciones hostiles propias (mismo criterio de «hostil» que rompe invisibilidad §6.3: atacar o castear ofensivo). Frenar el sprint es instantáneo y se puede accionar de inmediato. Consecuencia buscada: no se entrelaza sprint entre beats del combo de 800 ms, y el agresor paga el candado, el que reacciona no — leve ventaja estructural al que huye, coherente con los contrapesos anti-PK.
4. Parálisis e inmovilizar cortan el sprint. Estupidez remapea direcciones también corriendo (correr estúpido es una tragedia; fiel al espíritu del estado).
5. Los NPCs no corren (fidelidad §11, la IA no recibe sprint): escapar de mobs corriendo cuesta stamina y el leash de 25 tiles ya capa el kite de NPCs.
6. Los fantasmas no corren: el paseo del fantasma es parte del precio de morir (§8.1).
7. Anti-cheat por construcción: la stamina ajena NO se emite a otros clientes (misma arquitectura que la invisibilidad §6.3). Si la decisión N1 queda en «oculta», no hay nada que revelar en memoria.

#A.7 Filas nuevas de la tabla maestra (extiende §25)

⚠️ DECISIÓN PENDIENTE DE PABLO (N1): ¿stamina del enemigo visible?

• (a) Oculta total: solo tells diegéticos (animación de correr + jadeo al agotarse). Fiel al AO (tampoco ves la HP ajena), premia leer al rival, y con §A.6.7 es anti-cheat por construcción.
• (b) Cualitativa: icono «exhausto» bajo el nombre cuando el rival está < 20 %.
• (c) Barra completa visible.
• Recomendación: (a).

⚠️ DECISIÓN PENDIENTE DE PABLO (N2): ¿sprint gratis en ZONA_SEGURA?

• (a) Cuesta stamina igual en todos lados (consistencia de regla única).
• (b) Sin costo dentro de zona segura (QoL de traslado urbano; en ciudad no hay PvP, el costo no defiende nada — respeto al tiempo adulto).
• Recomendación: (b).

#B. Motivos para entrar hoy

Principio: cada día el juego responde «¿para qué entro HOY?» en la pantalla de login, sin scroll. Consolida el kit de retención (§18), el calendario anti-aburrimiento (00b §2.5) y los sistemas ya diseñados en una sola tabla operable. Se mantiene la regla transversal de §18: nada exige > 45 min/día; los horizontes largos son para el hardcore.

Reglas transversales de la tabla:

1. Todo gancho vive AGREGADO en S33 «Hoy» (una sola pantalla responde la pregunta; S33 ya existe en 01-pantallas) y lo diario se asoma además en S05/S08 para decidir con contexto antes de entrar.
2. Cadencia > tamaño: mejor evento chico todas las semanas que uno enorme por trimestre (00b: «el silencio se lee como abandono»).
3. Nada de la tabla paga poder — solo progresión, cosmético o conveniencia (constitucional, §18).
4. Telemetría por gancho: cada uno emite su evento propio (participación, conversión a sesión, D7 de quienes lo usan) hacia el sistema de evaluación de 00b §2. Un gancho que nadie usa en 60 días se rediseña o se retira.
5. Los ganchos nuevos (misión diaria, evento GM, dungeon del mes, consejo de facción) requieren detalle de UI en 01-pantallas: se agregan allí vía adenda propia si el detalle de S33/tablón no alcanza.

⚠️ DECISIÓN PENDIENTE DE PABLO (N3): consejo de facción electo (sistema chico nuevo).

• (a) Sí: 3 consejeros por facción, electos por temporada entre rangos altos (§9.2); voz destacada —no veto— en los votos §26 y elección temática del evento GM de su facción.
• (b) No: las elecciones quedan solo en clanes (§16).
• Recomendación: (b) al lanzar, (a) cuando las facciones tengan masa — no agrega superficie al MVP.

⚠️ DECISIÓN PENDIENTE DE PABLO (N4): formato del evento GM semanal (costo real de operación).

• (a) Curado y corrido en vivo por staff cada semana (máxima calidad, no escala).
• (b) Semi-automatizado: plantillas de evento (tesoro, invasión menor, quiz) que un GM dispara y modera — sostenible con equipo chico.
• Recomendación: (b), reservando (a) para fechas especiales (aniversario, apertura de zona).

#Criterios de terminado de la adenda (extienden los 10 del cuerpo)

11. Sprint server-authoritative testeado: (a) umbrales por modo rechazan speedhack sintético caminando y corriendo; (b) golpe/cast/proyectil DURANTE sprint rechazados server-side; (c) candado de 1 s verificado contra el combo de 800 ms; (d) test automático de paridad de escape: en persecución simulada con misma fracción de barra, el gap entre perseguidor y perseguido se mantiene constante hasta el agotamiento mutuo.
12. Matriz de winrates con y sin sprint: el sim-core headless (00b §2.1) corre los 12×12 matchups en ambas condiciones; ninguna clase varía su winrate más allá del umbral acordado (propuesta: ±3 pp); desvío mayor → recalibrar antes de la beta.
13. Test de feel del sprint aprobado: grabación de caminar/correr/frenar/pelear revisada por Pablo + 3 veteranos con la pregunta explícita «¿esto rompe el laneo?»; la stamina propia y el estado de fatiga son legibles en la HUD.
14. S33 «Hoy» responde la pregunta: muestra todos los ganchos de la tabla B con countdowns correctos y estado personal; el login (S05/S08) comunica los diarios sin scroll.
15. Cadencia operando: 4 semanas seguidas con criatura del día + misión diaria + tareas + torneo del sábado + evento GM ejecutados sin intervención manual de emergencia, con telemetría por gancho emitiendo.
16. Decisiones N1–N4 respondidas (se suman a las ~22 del cuerpo en el criterio 1).

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

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

• §22 y §8.5 quedan REEMPLAZADOS por la spec única de gracia/restitución de 05 R2 (cierra C1/C2/C3 del informe del crítico). Cambios de números respecto de lo escrito acá: detección de DC 12 s (no 5 s), «en combate» = 15 s únicos (no 30 s), retiro fuera de combate 10 s (no 5 s), linger 45 s PvP / 20 s PvE (no 20 s planos). Lo que ESTE documento aportó y sobrevive íntegro en la síntesis: desagreo de NPCs a los 5 s, solo-los-ya-en-combate pueden seguir dañando, restitución 100 % con clon de lo levantado, clasificador pro-jugador, restitución automática por lag del server. La restitución ahora se entrega por correo in-game (05 R5).
• La adenda A (sprint) sigue siendo la spec de juego; 05 R1 la implementa (flag de modo en el protocolo, validación 205/145 ms, stamina autoritativa, rate-limit Walk 8/s — cierra H1/C9). N1 queda cerrada en (a): la stamina rival es solo postura/animación (correr + jadeo); el valor jamás se emite.
• §9.2 se EXTIENDE con anti-blob general (05 R4): retornos decrecientes de recompensa/honor en gank N≥3 contra 1 sin importar facción (×0,4 / ×0,15 / ×0 según N) y esos kills no suman a rankings (marcados «gank»). El loot no se toca. Cierra la regla de oro nº2 del informe (§3).
• §8 suma TTL de loot en el piso (05 R8): tirado a mano 3 min ciudad / 5 min resto; cadáver con lista 10 min en todas las zonas. Propuesta a ratificar por Economía; valores en config caliente.
• El casillero que §15.4 y S28 mencionan queda especificado en 05 R5 (solo-recepción del sistema, sin mail P2P en MVP).

#Reconciliación (2026-07-26) — sistemas: duelos, casillero, quests canónicas, referidos y balance

Cierra del informe del crítico (90-huecos-y-decisiones.md): H8 (duelos), C22 (semántica de zona Verde), H7 lado reglas-de-juego (casillero), C13 (lista canónica de quests), H12 (referidos) y H6 lado sistemas (tablero de balance). Coordina con la sección anterior («notas desde 05-servidor»): donde 05 ya fijó el canon (gracia R2, schema del casillero R5, anti-blob R4), acá no se re-especifica — se completa la capa de reglas de juego. Donde dice «reemplaza a §X», esta sección manda.

#R-A. Duelos consensuales (nueva §9.4; cierra H8; reemplaza la celda «PvP» de la fila Verde de §8.4)

El duelo es el PvP consensual del juego abierto: sin penas, sin drop, sin muerte. Es la formalización del «agite» pactado — y la razón de ser de la zona Verde.

Flujo completo:

1. Reto: menú contextual sobre el jugador («Retar a duelo») o /duelo <nombre>, a ≤ 10 tiles, ambos vivos y fuera de combate (la definición única T_combat de 05 R2). En ZONA_SEGURA no hay duelos (ver «lugar» abajo).
2. Configuración del reto: apuesta de oro opcional (default 0). El retado ve nombre, clase, nivel y apuesta del retador; 30 s para Aceptar / Rechazar / Rechazar-y-bloquear. Rechazar no genera aviso público (cero presión social del sistema). Anti-spam: máx. 1 reto al mismo jugador por 60 s; toggle «retos de duelo: todos/amigos/nadie» en Opciones.
3. Círculo de duelo: al aceptar se traza un círculo de radio 12 tiles centrado en el punto medio entre ambos, visible para todos (borde en el piso), countdown 3-2-1. No hay restauración previa ni posterior: se pelea con lo que se tiene y como se está (el duelo es callejero; la arena §20 es el formato con loadouts). Pociones, hechizos propios e invocaciones permitidos.
4. Dentro del círculo: el duelo solo cambia la relación entre los DOS duelistas (pueden dañarse sin penas de alineación, sin marca de agresor, sin puntos de facción). Las reglas de la zona contra terceros siguen intactas.
5. Fin del duelo (primera condición que ocurra):
   • Un duelista llega a 1 HP → pierde. El golpe que lo llevaría a 0 lo deja en 1 y termina el duelo: nadie muere — sin fantasma, sin drop, sin bendiciones consumidas. (Regla conservadora y legible; la variante «a muerte sin drop» puede proponerse por poll post-beta, se agrega a la tabla §26.)
   • Salir del círculo > 5 s → abandono (derrota). La UI muestra la barra de abandono.
   • DC de cualquiera → duelo cancelado sin ganador, apuestas devueltas (la gracia de 05 R2 aplica normal; un duelo jamás interactúa con la restitución porque en duelo no se muere ni se dropea).
   • Interferencia: si un tercero daña a un duelista (posible en Amarilla/Roja), duelo cancelado sin ganador, apuestas devueltas. El tercero queda agresor según las reglas normales de la zona.
6. Resultado: anuncio local (consola + globo), entrada en killboard etiquetada «duelo» — no suma frags PvP, ni rating, ni reputación, ni logros de kill (mismo criterio de marcado que el «gank» de 05 R4: visible, no computado). Revancha inmediata permitida 1 vez; después cooldown 60 s.
7. Apuesta: escrow server-side, transacción atómica con filas de ledger (§15.5); el ganador cobra el pozo. La ⚠️ de §20 (apuestas de oro en arena) amplía su alcance a los duelos: es UNA sola decisión de Pablo para toda apuesta de oro PvP. Resolución conservadora mientras tanto: el flujo se implementa completo detrás de flag, apagado al lanzar (coherente con la recomendación (b) de §20); la UI de apuesta no se muestra con el flag apagado.
8. Newbies (≤ 12): pueden duelar (sin drop no hay riesgo; es el PvP-escuela). Los ítems newbie siguen intransferibles (la apuesta es solo oro, y con flag apagado ni eso).
9. Sprint en duelo: reglas de la adenda A intactas (candado 1 s, sin atacar corriendo) — el manejo de stamina ES parte del duelo.

El lugar del duelo en las zonas (cierra C22; la tabla de §8.4 es LA canónica):

• Semántica de colores para pintar el mapa (resuelve la divergencia con 03 A.1 y 00b): la escalera canónica de reglas tiene 4 niveles (Ciudad/Verde/Amarilla/Roja, §8.4); el display usa 3 colores: Ciudad y Verde se pintan VERDES en S18/letreros (ambas son «sin PvP no consentido»), pero son dos filas de regla distintas. Donde 03 A.1 dice «Verde = zona segura (sin PvP)» se lee «sin PvP abierto; duelo consensual sí, fuera de ZONA_SEGURA». Nota para la reconciliación de 03: A.1 adopta estos términos y referencia esta sección.
• Superficie UI (menú contextual, prompt, HUD de duelo, filtro «duelos» del killboard): 01, Reconciliación R4.

#R-B. Casillero del sistema — capa de reglas de juego (nueva §15.6; cierra H7 junto con 05 R5)

El schema, la entrega, el claim transaccional y las expiraciones canónicas ya están en 05 R5 (esta sección no los duplica). Lo que fija 02 como regla de juego:

• Solo-recepción del sistema; sin correo jugador-a-jugador en MVP (decisión de ingeniería conservadora: cero spam/scam/moderación de texto libre nueva; el comercio ya tiene S27/S28 y el chat existe; agregar mail P2P después es aditivo y votable).
• Qué llega: retiros y devoluciones del mercado (S28), restituciones por DC (05 R2 — jamás expiran), recompensas de temporada y de evento otorgadas offline, entregas de GM auditadas, recompensa de referidos (R-D — el enum mail_messages.kind de 05 R5 suma referral_reward; nota de sync para 05).
• Expiración visible como regla de juego: toda fila del casillero muestra su fecha de expiración («expira en N días» / «no expira»); los avisos previos (3 para mercado, según 05 R5) llegan por el propio casillero + badge. Nada expira en silencio: la expiración escribe ledger kind=destroy (sink conocido).
• Retiro del mercado desde cualquier lado: el mercado del MVP es el bazar global (recomendación vigente de §15.4-c), así que el claim del casillero funciona donde estés — esto resuelve la nota abierta de S28 («se retira donde publicaste — decisión de Economía»): en MVP no hay retiro localizado; si post-MVP entran tiendas físicas por ciudad (§15.4-b), el claim de ESOS ítems gana restricción de lugar (aditivo, no rompe nada).
• El casillero es un contenedor más del sistema anti-dupe: cada entrega y claim pasa por el ledger (§15.5).
• Pantalla: S45 en 01, Reconciliación R3 (badge en botonera, estados, móvil).

#R-C. Lista canónica de quests del lanzamiento (reemplaza el alcance de §13.2; cierra C13; aplica la ampliación de 00b)

Tres documentos decían tres cosas (00b «10-15», §13.2 «14», 03 A.1 «27-39»). Canon único, fijado acá:

El lanzamiento sale con 20 quests con nombre al estándar completo de §13.1 + encargos de tablón por zona.

1. Quests con nombre (20): las 14 diseñadas de §13.2 (núcleo Ullathorpe, zonas 1-4 de 03 A.1) + 6 anclas nuevas que cubren el resto de la región (la «meta de lanzamiento ampliada» de 00b §2). Las anclas se diseñan al mismo estándar (≥ 2 de 3 ingredientes, recompensa-llave permanente, title-card) antes de escribir diálogos:

2. Encargos de tablón (sin nombre, no son quests): plantillas livianas (matar N / entregar / recolectar) colgadas del tablón de cada ciudad. Sin title-card, sin recompensa-llave; pagan oro/XP chica y alimentan la misión diaria de la adenda B. El principio de §13.1 («pocas, con nombre, hechas a mano») queda intacto: los encargos son el relleno explícitamente etiquetado como relleno.
3. Lectura de 03 A.1: su columna «Quests» (suma 27-39) se lee como quests con nombre + encargos de tablón; el número canónico de lo con-nombre es 20 y sale de esta tabla. Nota para la reconciliación de 03: A.1 referencia esta sección; ante cualquier divergencia futura, 02 manda (es el dueño de sistemas).
4. XP: la propuesta de §13.1 («la cadena completa ≈ 1-2 niveles») se lee ahora «la cadena completa de 20 ≈ 2-3 niveles de la franja objetivo» — validar en la simulación económica (criterio 6).
5. La ⚠️ de §13.2 se amplía (misma decisión, no una nueva): aprobar las 14 + las 6 anclas (o recortar), y el tono del humor local (#12).

#R-D. Referidos — sistema mínimo (extiende §18; cierra H12)

El growth loop del nicho ES «mandá el link al grupo» (research/04); esto lo instrumenta sin tocar el balance:

• Código de invitación por cuenta (corto, legible, tipo AURUM-XXXX) con link https://<dominio>/?ref=CÓDIGO. Solo cuentas reclamadas generan código.
• Atribución first-touch: el ref se registra al crear la cuenta invitada (S04) y sobrevive el claim. Sin atribución retroactiva; sin cookies de tracking extra (el código viaja en la URL y muere ahí — coherente con la privacidad del proyecto).
• Hito y recompensa: cuando el invitado tiene cuenta reclamada (email verificado) + nivel 10, ambos reciben un cosmético exclusivo de referidos (entregado por casillero §15.6, kind=referral_reward). Nivel 10 porque coincide con el disparador de claim de S05 y es pre-valor-económico (una granja de invitados nivel 10 sin claim no cobra nada). El padrino además acumula hitos acumulativos (3/5/10 invitados acreditados → título/marco/mascota cosmética).
• Anti-abuso: no acredita si las señales de 05 (device/IP/grafo económico, §7/§9.4) correlacionan ambas cuentas como la misma persona; todo el pago es cosmético — jamás oro, poder ni conveniencia (regla transversal de §18 intacta: cero incentivo de granja).
• Telemetría: el código entra al embudo de conversión (00b §2.2); el funnel y su medición son de 07 §7/§12 (nota de sync). Pantalla («Invitá a un amigo» en S44 + overlay in-game): 01, Reconciliación R6.

#R-E. Tablero de balance — el dato que alimenta (cierra H6 lado sistemas)

• La matriz de winrates 12×12 ya existe en dos formas: la simulada (sim-core, criterio 12 de la adenda A) y la real (arena con personaje prestado, §20 — loadouts idénticos = mide clase, no billetera). El tablero público de balance (00b §2.4) publica AMBAS, claramente separadas («simulado» vs «real»).
• El loop se cierra con §0.1: cada poll de nerf (§26) linkea la celda de la matriz que lo motiva — «buff libre, nerf consultado» deja de ser eslogan y pasa a ser un link.
• Endpoint: GET /api/v1/balance/winrates (ya definido en 05 R9). Pantalla y página pública: 01, Reconciliación R7.

#R-F. Correcciones menores de coherencia

• C24 (typo con consecuencia): en la tabla B de la adenda, donde dice «S08 selección de personaje» y «slot de temporada en S08» se lee S07 (S08 es CREACIÓN; la selección es S07). Reemplaza esas celdas.
• C25: el rating de arena es Glicko-2 (§20 manda); 01 corrige sus menciones «ELO» en su propia reconciliación.
• Jefe de la Cripta: el bestiario de 03 A.1 manda — el jefe de la Cripta de los No-Muertos es el Rey Esqueleto; las menciones «Lich» de §13.2 #14 y §21.1 se leen como «el jefe de la Cripta (Rey Esqueleto)». El Liche del Puerto existe y es el jefe de las Catacumbas (ancla #18).
• La tabla §26 (votables) suma: «variante de duelo a muerte sin drop (§9.4)» y «mail jugador-a-jugador (§15.6)» — ambos post-beta, por poll.

#Criterios de terminado de esta reconciliación (extienden los del cuerpo y la adenda)

17. Duelos verificados: reto→aceptación→círculo→fin en las 4 condiciones de cierre (1 HP, abandono, DC, interferencia) con test de caos; un duelo jamás produce muerte, drop, marca de agresor ni entrada computada en rankings; con flag de apuestas apagado, ningún oro se mueve.
18. Casillero end-to-end: restitución de 05 R2 llega al casillero y se reclama; expiración visible en UI coincide con expires_at; expiración escribe ledger kind=destroy; claim parcial con inventario lleno no pierde nada.
19. Quests canónicas: las 20 con nombre implementadas al estándar de §13.1; los encargos de tablón etiquetados como tales en UI; drop-off por quest instrumentado (00b §2.2).
20. Referidos: atribución first-touch verificada de S04 al claim; hito acredita solo con claim + nivel 10; correlación device/IP bloquea la auto-invitación en test sintético.

#Barrido final (2026-07-26)

Última pasada contra el «Estado post-reconciliación» de 90-huecos-y-decisiones.md. Cierra C23 (tesorería de clan), H16 (battlegrounds/tesoros) y H17 (foros UGC). Donde dice «reemplaza a §X», esta sección manda.

#B1. Tesorería de clan en MVP (cierra C23; reemplaza la línea «Tablón de clan + tesorería (depósitos voluntarios, log visible…)» de §16 y la marca «post-MVP» de 01 S24)

C23 era el único conflicto sin dueño de la lista del 90: §16 la incluía, 01 S24 la marcaba post-MVP. Resolución: MVP sí, con spec mínima — el schema de 05 §8.2 ya la tiene lista (clans.vault_container, containers.kind=clan_vault) y sin tesorería el upkeep de clan (decisión nº34) no tiene de dónde pagarse.

• Depósitos libres: cualquier miembro deposita oro o ítems, sin permiso ni tope. Depositar es donar: no genera derecho de retiro (regla legible que mata el «me voy y me llevo lo mío» — el drama clásico).
• Retiros por rango con límite diario: solo los rangos con el permiso «usar tesoro» de la matriz de §16/S24; el líder fija un límite diario de oro por rango (config del clan, default conservador: consejo sí / veterano chico / miembro y recluta 0). Los ítems con instance_id (valiosos) solo los retira el líder o quien tenga permiso explícito de ítems. El líder no tiene límite — pero ver log.
• Log público interno: TODO movimiento (quién, qué, cuánto, cuándo) visible para todos los miembros en S24 — anti-robo por transparencia, no por candados (coherente con la filosofía del log del clan de §16). El log es una vista del ledger filtrada por la bóveda: cero contabilidad paralela.
• Transaccional siempre: cada depósito/retiro es una fila de ledger (§15.5, kinds nuevos en 05-barrido); la bóveda entra a la reconciliación nocturna como cualquier contenedor.
• Sucesión: la bóveda es DEL CLAN, no del líder — elecciones, expulsión del líder o borrado de su cuenta (01 R5.5) no la tocan. Si el clan se disuelve, la bóveda se destruye a ledger (kind=destroy, sink conocido) — anti-«fundo y desarmo clanes para lavar oro».
• El upkeep (decisión nº34, sigue en Pablo) se debita de la bóveda si existe saldo; si no, del líder — el sumidero gana su fuente natural.

#B2. Battlegrounds y tesoros — filas que faltaban en §24 (cierra H16; extiende la tabla de §24)

#B3. Foros in-game: solo-sistema en MVP (cierra H17)

Los tiles de «foro» de los .csm y los tablones heredados quedan como superficie de solo-lectura del sistema en MVP: encargos de tablón (R-C), misión diaria y anuncios (adenda B). Ningún jugador escribe en tablones ni foros in-game — cero superficie nueva de moderación de UGC escrito (coherente con la dotación de 07 R1 y con la misma lógica del casillero sin mail P2P de §15.6). Foros UGC in-game: post-MVP votable — se suma a la tabla §26 («foros in-game de jugadores») junto a las dos filas que ya agregó R-F.

#Criterios de terminado (extienden los anteriores)

21. Tesorería: depósito y retiro respetan permisos y límite diario en test; el log interno coincide 1:1 con el ledger; la disolución del clan destruye la bóveda con fila destroy; un retiro sobre saldo insuficiente falla atómico.