# Perfil Interlude CT0 retail v1 Aplicado em 3 de novembro de 2026 no QA e no principal. A etapa entrega um perfil reproduzível de configuração e corrige a hierarquia carregada das classes. Resultados: https://claude-oficial.site/progresso/retail.html. Nos dois ambientes, as 89 classes passaram com zero divergências; os hashes de progressão, inventários e skills foram preservados. O teste nativo confirmou recusa sem Adena, cobrança de 385 Adena pelo desconto temporal vigente e persistência de saldo/posição. A entrada registrada no navegador principal passou sem erros JavaScript, preservando o nível 2 conquistado pelo fixture. JAR publicado: `95a2c4d18030224c4d790774d817c55f566e1ea8ca5837ff4561e5be5041f746`. Os recibos públicos distinguem os dois ambientes e os limites dessa validação. ## Alterações - A isenção geral de tarifa por nível foi desativada (`MaxFreeTeleportLevel=0`). O servidor continua calculando o custo de cada destino e seus descontos existentes. Tokens, destinos e modalidades especiais não foram reescritos. - Comércio/craft offline, restauração de lojas offline e comando offline foram desativados. O comércio normal com o personagem conectado permanece sob as regras do servidor. - O deslocamento opcional das coordenadas de spawn foi desativado. Os pontos e territórios XML continuam sendo usados; isso não remove a movimentação normal da IA nem certifica geodata. - A lista opcional `FakePlayers.xml` foi desativada. O recurso de fake players já estava desligado na configuração e continua protegido pelo perfil. - Bladedancer passou a apontar para Palus Knight nos metadados; Elemental Master passou a apontar para Elemental Summoner. Ambos já eram os parents da enumeração Java e das árvores de skills. - O carregador `ClassListData` passou a aceitar parent ID 0. Antes, Warrior, Knight e Rogue perdiam a ligação com Human Fighter durante o carregamento. As taxas principais 1×, início no nível 1, Adena/SP iniciais zero e os bloqueios de autolearn, autoloot, premium, autoplay, autopotions, transmogrificação e Vitality são guardas do perfil. Um valor divergente interrompe a preparação; não é substituído silenciosamente. ## Evidência e edição O comportamento alvo é CT0 Interlude de 2007. O espécime privado do cliente é identificado por hashes dos arquivos relevantes, junto da revisão do Mobius e do JAR. O dia exato do patch do fabricante não está autenticado; não se atribui uma data fictícia ao binário. A regra geral de teleporte gratuito por nível aparece na [cópia histórica das notas de Gracia Part 1](https://legacy-lineage2.com/news/gracia_14.html), posterior ao alvo. O uso efetivo do limite foi rastreado em `TeleportHolder.shouldPayFee`/`calculateFee` e reproduzido no realm de QA. A alteração elimina essa conveniência geral, preservando a cobrança nativa. As duas correções XML são concordantes com `PlayerClass`, as árvores de skills e as referências históricas das classes: [Dark Elves](https://legacy-lineage2.com/Knowledge/race_darkelf_changejob.html), [Elves](https://legacy-lineage2.com/Knowledge/race_elf_changejob.html). A correção do ID 0 é um defeito de carregamento verificável no próprio código: zero identifica uma classe válida; somente o valor ausente, -1, indica raiz. ## Decisões sobre dados ainda não certificados Os quatro IDs duplicados em custom foram examinados, não removidos por nome de pasta. As três versões de Shining Bow acrescentam comportamentos de SA que estão ausentes nas declarações base. O DAT original confirma os nomes das SAs e os ataques físico/mágico, mas não comprova todas as fórmulas. Endeavor Potion também contém comportamento adicional. Os dados atuais foram preservados; sua qualificação completa continua no inventário retail. Damascus Tallum Blade mantém a cristalização existente, 2.803. O DAT examinado não fornece a quantidade de cristais e a cópia histórica informa 2.824. A divergência não autoriza uma substituição especulativa. Portanto, este perfil não é uma certificação de todos os atributos, drops, skills, IA, cidades ou geodata do oficial. Essas frentes continuam explicitadas na [auditoria completa](RETAIL.md). ## Validação e publicação O inspetor usa o JAR real e carrega as configurações/`ClassListData`, em um contêiner sem rede e sem banco. Compara todos os 89 parents carregados com a enumeração Java independente: a base apresentou cinco divergências; a versão candidata apresentou zero nos dois ambientes. O JAR preserva o patch anterior de concorrência. A comparação de cada entrada do ZIP permite alterações somente em `ClassListData.class` e sua classe interna; as demais classes permanecem idênticas. O teste de teleportes usa um personagem preparado exclusivamente no QA: 1. Reproduz a entrada no teleporte sem Adena com a configuração antiga. 2. Após a correção, lê o preço do HTML real de Roxxy e confirma a recusa por saldo insuficiente, sem deslocamento ou débito. 3. Prepara somente nesse personagem o valor exato informado pelo servidor. 4. Executa o comando presente no diálogo, confirma o débito nativo e o destino. 5. Reconecta e verifica posição e saldo persistidos. A preparação de posição/dinheiro desse fixture é explícita e não representa progressão conquistada. O custo XML da rota local é 770; o teste aceita o desconto temporal já implementado pelo servidor, sem atribuí-lo como prova independente de fidelidade oficial. Respeita também o intervalo nativo entre bypasses e a margem de teleporte configurada. A implantação recusa realms ocupados, exige backup dos arquivos e do banco, verifica os mounts reais, interrompe a entrada pelo gateway durante a troca e restaura os arquivos se a saúde/validação falhar. Compara hashes ordenados de identidades/classes/níveis/XP/SP, inventários e skills antes/depois. Não contém SQL para editar personagens, conceder itens ou migrar progressão. O principal só é liberado depois de QA e do teste de cobrança passarem com o mesmo JAR. Os recibos públicos omitem contas, cookies, credenciais e os backups. ## Elbera Tools ```text python3 tools/dev/build_retail_profile.py python3 tools/dev/prepare_retail_teleport_test.py node tools/dev/review_retail_teleport.cjs --baseline python3 tools/dev/apply_retail_profile.py --realm qa node tools/dev/review_retail_teleport.cjs python3 tools/dev/apply_retail_profile.py --realm main node tools/dev/review_public_progression.cjs ``` O primeiro comando exige os hashes da base e prepara arquivos privados; não deve ser repetido contra um JAR já atualizado. `--resume-baseline` permite retomar somente o mesmo fixture de QA antes da implantação. O JSON de política fica em `deploy/retail/profile.json`; o patch portátil em `deploy/server-mods/mobius-retail-class-parent.patch`. Cliente original, JARs, SQL, cookies e recibos brutos permanecem fora do Git.