feat(jobs): Jobs.1 client — DA expandido + 7 DA_Job assets organizados por tier

* UZMMOJobDataAsset (Source/ZMMOJobs/Public/) ganha 3 campos novos
  espelhando o JobDef do server:
    - Tier             (EZMMOJobTier)
    - ParentClassId    (int32)
    - AllowedWeapons   (TArray<EZMMOWeaponType>)

* Novo header ZMMOJobTypes.h com 2 UENUM(BlueprintType):
    - EZMMOJobTier      (6 valores: Beginner..Mastery)
    - EZMMOWeaponType   (19 valores: Fist..Gun)
  Todos com UMETA(DisplayName="pt-BR") pro Editor mostrar nomes
  amigaveis em dropdowns. Ordem casa byte-a-byte com EJobTier/
  EWeaponType do server (necessario pq snapshot carrega tier u8 + mask).

* 7 DA_Job_*.uasset criados via MCP Python, organizados por tier:
    Content/ZMMO/Data/Jobs/Beginner/
      DA_Job_Novice    (ClassId=0, AllowedWeapons=[Fist,Dagger])
    Content/ZMMO/Data/Jobs/Vocation/
      DA_Job_Warrior   (ClassId=1, 8 armas: Sword+Spear+Axe variations)
      DA_Job_Arcanist  (ClassId=2, 5 armas: Staff+Book)
      DA_Job_Ranger    (ClassId=3, 5 armas: Bow+Musical+Whip)
      DA_Job_Artisan   (ClassId=4, 5 armas: Sword1H+Mace1H+Axe1H)
      DA_Job_Rogue     (ClassId=5, 5 armas: Sword1H+Bow+Katar)
      DA_Job_Devout    (ClassId=6, 5 armas: Mace+Staff1H+Knuckle)
  ParentClassId=0 (Novice) em todas Vocacoes. Tier=Vocation.
  JobIcon/Sound/Anim ficam None — preencher conforme arte for produzida.

  ZMMOJobsSubsystem busca por classe (GetAssetsByClass), entao a
  reorganizacao em subpastas NAO requer mudanca em .cpp/.h.

* ZMMOAttributeTypes.h: comentario de opcode 1200 -> 1500 (espelha
  refactor Open-Closed do server ranges; valores wire format mudaram).

Boot esperado: [ZMMOJobsSubsystem] Initialize: 7 job(s) carregados.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

ARQUITETURA.md

@@ -9,7 +9,7 @@
 
 > **Extensões da arquitetura** (documentos normativos paralelos, escopo específico):
 > - [`ARQUITETURA_SERVER_SELECT.md`](ARQUITETURA_SERVER_SELECT.md) — Server Select, lista de mundos, handoff CharServer↔WorldServer, multi-region, queue, Valkey. Roadmap em 7 fases.
-> - [`ARQUITETURA_CHARACTER_MODEL.md`](ARQUITETURA_CHARACTER_MODEL.md) — Stats primários (STR/AGI/VIT/INT/DEX/LUK), classes (Aprendiz → especializações), fórmulas de stats derivados (ATK/MATK/DEF/...), `jobs.yml` data-driven, stat allocation server-side. Espelha rathena.
+> - [`ARQUITETURA_CHARACTER_MODEL.md`](ARQUITETURA_CHARACTER_MODEL.md) — Stats primários (STR/AGI/VIT/INT/DEX/LUK), classes (Novato → especializações), fórmulas de stats derivados (ATK/MATK/DEF/...), `jobs.yml` data-driven, stat allocation server-side. Espelha rathena.
 
 > **Sumário de mudanças (2026-05-11):** adicionada secção de **temas sazonais
 > de UI** (`UI/Themes/`), com tutorial §4.7, regra de "no hard ref a textura

ARQUITETURA_CHARACTER_MODEL.md

@@ -6,7 +6,7 @@
 
 ## Context
 
-O ZMMO usa modelo de atributos estilo Ragnarok Online — 6 stats primários que o jogador aloca pontos (STR/AGI/VIT/INT/DEX/LUK), com stats derivados calculados a partir deles + level + classe + equip. Jogador nasce **Aprendiz** (Novice) e especializa em outras classes ao chegar a critérios (job level + quest de mudança).
+O ZMMO usa modelo de atributos estilo Ragnarok Online — 6 stats primários que o jogador aloca pontos (STR/AGI/VIT/INT/DEX/LUK), com stats derivados calculados a partir deles + level + classe + equip. Jogador nasce **Novato** (Novice) e especializa em outras classes ao chegar a critérios (job level + quest de mudança).
 
 Este doc fixa:
 1. O que persiste no MySQL (CharServer) vs o que vive em memória (WorldServer).
@@ -58,10 +58,10 @@ Padrão rathena: `db/re/job_stats.yml` carregado no boot. Hot-reloadable.
 
 | Componente | Quem decide | Quem persiste |
 |---|---|---|
-| Criar char (stats iniciais, class=Aprendiz) | CharServer (valida) | CharServer → MySQL |
+| Criar char (stats iniciais, class=Novato) | CharServer (valida) | CharServer → MySQL |
 | Stat allocation (gastar `status_point` em STR/etc.) | CharServer **ou** WorldServer | CharServer → MySQL (via writeback) |
 | Subir de level / ganhar EXP | WorldServer (kill mob, quest) | WorldServer → writeback → CharServer → MySQL |
-| Mudar classe (Aprendiz → Espadachim) | WorldServer (cumpre quest) | WorldServer → writeback → CharServer → MySQL |
+| Mudar classe (Novato → Espadachim) | WorldServer (cumpre quest) | WorldServer → writeback → CharServer → MySQL |
 | Recalcular ATK/MATK/DEF/etc. | WorldServer (memória, toda hora) | NÃO persiste |
 | Casting de skill | WorldServer | NÃO persiste (efêmero) |
 | Resultado de skill (HP perdido, item dropado) | WorldServer | WorldServer → writeback |
@@ -260,7 +260,7 @@ version: 1
 jobs:
   - id: 0
     name: Novice              # nome técnico (inglês, estável)
-    display_name_ptbr: Aprendiz
+    display_name_ptbr: Novato
     parent_job: null
     max_base_level: 99
     max_job_level: 10
@@ -322,7 +322,7 @@ jobs:
 
 ## 5. Fluxos
 
-### 5.1 Criação de personagem (Aprendiz)
+### 5.1 Criação de personagem (Novato)
 
 ```
 Cliente → C_CHAR_CREATE { name, world_id, class_id=NOVICE, appearance }
@@ -342,7 +342,7 @@ CharServer:
   4. → S_CHAR_CREATE_OK
 ```
 
-**Nota:** o player **sempre** nasce Aprendiz. Outras classes só via job change in-game (Fase pós-Fase 3).
+**Nota:** o player **sempre** nasce Novato. Outras classes só via job change in-game (Fase pós-Fase 3).
 
 ### 5.2 Stat allocation (após level up)
 
@@ -377,7 +377,7 @@ WorldServer (em kill mob / complete quest):
 
 Mesmo padrão pra job_exp/job_level (com skill_point em vez de status_point).
 
-### 5.4 Job change (Aprendiz → Espadachim, etc.)
+### 5.4 Job change (Novato → Espadachim, etc.)
 
 ```
 WorldServer (player cumpriu quest):
@@ -571,13 +571,13 @@ Audit log entries (Fase 3 do ServerSelect doc): toda mudança de zeny>1000, leve
 
 ## 8. Roadmap de implementação
 
-### Fase A — Schema + criação de char Aprendiz (parte da Fase 1 do ServerSelect)
+### Fase A — Schema + criação de char Novato (parte da Fase 1 do ServerSelect)
 
 - Schema `characters` com todos os campos (já especificado no `ARQUITETURA_SERVER_SELECT.md`).
-- `jobs.yml` apenas com `Novice` (Aprendiz) — outras classes ficam pra B.
+- `jobs.yml` apenas com `Novice` (Novato) — outras classes ficam pra B.
 - CharServer carrega `jobs.yml` no boot.
 - `C_CHAR_CREATE` valida `class_id == NOVICE` e usa defaults do yml.
-- Cliente UI: tela de criação com nome + appearance (sem stat allocation aqui — Aprendiz nasce com todos os stats=1).
+- Cliente UI: tela de criação com nome + appearance (sem stat allocation aqui — Novato nasce com todos os stats=1).
 
 ### Fase B — Classes adicionais + job change
 
@@ -628,7 +628,7 @@ Audit log entries (Fase 3 do ServerSelect doc): toda mudança de zeny>1000, leve
 1. **Stats primários flat** na tabela `characters` (str/agi/vit/int/dex/luk + level/exp + hp/sp/max_hp/max_sp + status_point/skill_point + zeny + class_id). **Sem entidade separada.**
 2. **Stats derivados NUNCA persistidos** — sempre recalculados em runtime no WorldServer (`StatusCalc::ComputeAll`).
 3. **Jobs data-driven** via `Server/ZeusCharServer/data/jobs.yml` (versionado no git, hot-reloadable). `characters.class_id` é lookup lógico.
-4. **Player nasce Aprendiz** (`class_id=NOVICE`); especialização via quest in-game (Fase B).
+4. **Player nasce Novato** (`class_id=NOVICE`); especialização via quest in-game (Fase B).
 5. **Stat allocation acontece no WorldServer** (não CharServer). Validação `cost = (s-1)/10 + 2` server-side.
 6. **Anti-cheat:** toda mudança de estado é server-authoritative. Cliente apenas renderiza.
 7. **Fórmulas espelham rathena** (`status_calc_pc_` em `src/map/status.cpp:4996`) — adapta valores pra balanceamento Zeus depois.

ARQUITETURA_SERVER_SELECT.md

@@ -311,11 +311,11 @@ ALTER TABLE characters
 **Notas:**
 - `world_id` é nullable (sem chars em prod hoje — evita downtime futuro). Validação no service: novos chars devem ter `world_id`.
 - Estrutura flat segue rathena (`.bases/rathena/rathena-master/sql-files/main.sql:209-296`) — padrão da indústria emuladora. Sem entidade `character_stats` separada (1:1 FK seria JOIN inútil).
-- Defaults vêm da row Aprendiz no `jobs.yml` (ver doc Character Model).
+- Defaults vêm da row Novato no `jobs.yml` (ver doc Character Model).
 - **Stats derivados (ATK/MATK/DEF/MDEF/hit/flee/crit/aspd) NÃO entram aqui** — são sempre recalculados em runtime no WorldServer via fórmulas. Persistir é bug fest (esquece atualizar quando muda equip/buff/level).
 - `version` (optimistic locking) usado em writeback da Fase 3.
 
-> **Para o detalhamento do modelo de personagem** (stats primários vs derivados, fórmulas de ATK/MATK/DEF, jobs.yml, stat allocation, leveling curve, classes Aprendiz → especialização), ver doc dedicado [`ARQUITETURA_CHARACTER_MODEL.md`](ARQUITETURA_CHARACTER_MODEL.md).
+> **Para o detalhamento do modelo de personagem** (stats primários vs derivados, fórmulas de ATK/MATK/DEF, jobs.yml, stat allocation, leveling curve, classes Novato → especialização), ver doc dedicado [`ARQUITETURA_CHARACTER_MODEL.md`](ARQUITETURA_CHARACTER_MODEL.md).
 
 ### Schema Valkey (Fase 2+)
 

Source/ZMMOAttributes/Public/ZMMOAttributeTypes.h

@@ -5,7 +5,7 @@
 
 /**
  *  Snapshot completo dos atributos do char vindo do server via
- *  S_ATTRIBUTE_SNAPSHOT_FULL (opcode 1200).
+ *  S_ATTRIBUTE_SNAPSHOT_FULL (opcode 1500).
  *
  *  Cliente NUNCA recalcula derivados — apenas exibe o que recebe. Os campos
  *  HP/MaxHp/SP/MaxSp ja sao os "efetivos" (base + equip + buff somados no

Source/ZMMOJobs/Public/ZMMOJobDataAsset.h

@@ -2,6 +2,7 @@
 
 #include "CoreMinimal.h"
 #include "Engine/DataAsset.h"
+#include "ZMMOJobTypes.h"
 #include "ZMMOJobDataAsset.generated.h"
 
 class UTexture2D;
@@ -39,11 +40,28 @@ public:
 	UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Zeus|Job")
 	FString TechnicalName;
 
-	/// Nome localizado exibido na UI (pt-BR no projeto base). Ex: "Aprendiz".
+	/// Nome localizado exibido na UI (pt-BR no projeto base). Ex: "Novato".
 	/// Pode usar FText Localization tables pra multi-idioma futuro.
 	UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Zeus|Job")
 	FText DisplayName;
 
+	/// Tier hierarquico — espelha `JobDef::tier` do server. UI usa pra agrupar
+	/// jobs (ex: lista de Vocacoes possiveis quando promovendo Novato).
+	UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Zeus|Job")
+	EZMMOJobTier Tier = EZMMOJobTier::Beginner;
+
+	/// ClassId do parent na arvore de promocao. 0 = sem parent (Novato eh root).
+	/// Espelha `JobDef::parentJobId` do server. UI usa pra filtrar destinos
+	/// possiveis ao mostrar painel de promocao.
+	UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Zeus|Job")
+	int32 ParentClassId = 0;
+
+	/// Lista de armas que o job pode equipar. Espelha `JobDef::allowedWeaponsMask`
+	/// do server (mas como TArray pra editor visual em vez de bitmask cru).
+	/// Inventory UI usa pra hint "nao pode equipar" + filtro de catalogo.
+	UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Zeus|Job")
+	TArray<EZMMOWeaponType> AllowedWeapons;
+
 	/// Icone do job — usado em StatusWindow, CharacterCard, JobChangeUI.
 	/// Soft ptr: nao carrega ate alguem chamar LoadSynchronous() ou async load.
 	UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Zeus|Job|Assets")

Source/ZMMOJobs/Public/ZMMOJobTypes.h

@@ -0,0 +1,57 @@
+#pragma once
+
+#include "CoreMinimal.h"
+#include "ZMMOJobTypes.generated.h"
+
+/**
+ *  Tier hierarquico de um job. Espelha `EJobTier` do server em
+ *  `Server/.../JobsSystem/Public/JobTypes.hpp`. Valores TEM que bater
+ *  byte-a-byte com a enum do server porque o snapshot pode carregar
+ *  tier como uint8 no futuro.
+ *
+ *  Renascer (RO pre-renewal): char no Tier 2 (Specialization) que cumpre
+ *  condicao volta pra Tier 3 (RebornBeginner) com bonus permanente,
+ *  abrindo path paralelo RebornVocation → Mastery (coroa final).
+ */
+UENUM(BlueprintType)
+enum class EZMMOJobTier : uint8
+{
+	Beginner        = 0  UMETA(DisplayName = "Iniciante"),
+	Vocation        = 1  UMETA(DisplayName = "Vocacao"),
+	Specialization  = 2  UMETA(DisplayName = "Especializacao"),
+	RebornBeginner  = 3  UMETA(DisplayName = "Iniciante Renascido"),
+	RebornVocation  = 4  UMETA(DisplayName = "Vocacao Renascida"),
+	Mastery         = 5  UMETA(DisplayName = "Mestria"),
+};
+
+/**
+ *  Tipos de arma. Espelha `EWeaponType` do server. Usado em `AllowedWeapons`
+ *  do DA pra UI (filtrar items equipaveis) + validacao server-side futura
+ *  quando InventorySystem entrar.
+ *
+ *  Ordem TEM que bater com server porque o bitmask `allowedWeaponsMask` no
+ *  JobDef usa bit N = EWeaponType(N).
+ */
+UENUM(BlueprintType)
+enum class EZMMOWeaponType : uint8
+{
+	Fist     = 0   UMETA(DisplayName = "Punho"),
+	Dagger   = 1   UMETA(DisplayName = "Adaga"),
+	Sword1H  = 2   UMETA(DisplayName = "Espada 1M"),
+	Sword2H  = 3   UMETA(DisplayName = "Espada 2M"),
+	Spear1H  = 4   UMETA(DisplayName = "Lanca 1M"),
+	Spear2H  = 5   UMETA(DisplayName = "Lanca 2M"),
+	Axe1H    = 6   UMETA(DisplayName = "Machado 1M"),
+	Axe2H    = 7   UMETA(DisplayName = "Machado 2M"),
+	Mace1H   = 8   UMETA(DisplayName = "Maca 1M"),
+	Mace2H   = 9   UMETA(DisplayName = "Maca 2M"),
+	Staff1H  = 10  UMETA(DisplayName = "Cajado 1M"),
+	Staff2H  = 11  UMETA(DisplayName = "Cajado 2M"),
+	Bow      = 12  UMETA(DisplayName = "Arco"),
+	Knuckle  = 13  UMETA(DisplayName = "Soqueira"),
+	Musical  = 14  UMETA(DisplayName = "Instrumento Musical"),
+	Whip     = 15  UMETA(DisplayName = "Chicote"),
+	Book     = 16  UMETA(DisplayName = "Livro"),
+	Katar    = 17  UMETA(DisplayName = "Katar"),
+	Gun      = 18  UMETA(DisplayName = "Arma de Fogo"),
+};