Você não precisa decorar um livro para começar a jogar. O Guia da Forja apresenta somente o que é útil agora e deixa as regras específicas para o módulo correto do sistema e da edição.
O Guia ensina conceitos. A Ficha Viva calcula e valida. A Ciel acompanha o usuário. Livros e módulos do sistema são a autoridade para números, progressão e regras.
RPG de mesa é uma história construída em grupo. Você descreve o que seu personagem tenta fazer; o Mestre apresenta o mundo e as consequências; regras e dados entram quando existe uma dúvida que precisa ser resolvida.
O Mestre descreve uma situação.
Você diz o que seu personagem tenta fazer.
Quando necessário, regra e dado definem o resultado.
A história muda com as escolhas do grupo.
É a pessoa que você interpreta dentro da história. A ficha registra aquilo que você precisa consultar durante a aventura.
Apresenta cenas, interpreta o mundo e decide quando uma regra precisa ser aplicada. Ele não precisa saber tudo de memória.
É um encontro de jogo. Uma campanha normalmente é formada por várias sessões ligadas pela mesma história.
Não são usados para tudo. Eles ajudam a resolver incertezas quando o sistema ou o Mestre pedem uma rolagem.
Aprender o vocabulário básico reduz muito a sensação de que a ficha é complicada.
Se aparecer uma palavra que você não conhece, toque em “Perguntar à Ciel”. A explicação deve usar o sistema ativo e evitar despejar regras que ainda não são necessárias.
Começar pelo estilo costuma ser mais fácil do que escolher uma classe olhando apenas nomes. Marque até três coisas que parecem divertidas.
Aqui explicamos a sensação geral de cada classe. Recursos, níveis, números e disponibilidade dependem do sistema, da edição e dos livros habilitados.
Esta etapa não calcula regras. Ela organiza suas escolhas para que a Ficha Viva abra já no módulo correto e a Ciel saiba exatamente onde ajudar.
Escolha o sistema e, quando necessário, a edição. Isso impede que a Ciel misture regras.
Escolha uma prioridade. Isso ajuda a filtrar opções, mas não limita o personagem.
Quando este Guia é aberto dentro da Forja, o botão abaixo prepara a criação real da Ficha Viva, preservando sistema/edição e sem inventar valores mecânicos.
A Forja separa três coisas que costumam se misturar: o que você decide, o que a Ciel explica e o que o ruleset calcula. Assim o iniciante recebe ajuda sem a IA inventar regra ou montar o personagem no lugar dele.
Conceito, estilo, escolhas disponíveis e quem o personagem é.
O que cada etapa significa, quais perguntas ajudam e qual é o próximo passo.
Números, fórmulas, limites, progressão e dependências da edição escolhida.
Escolha uma fase. Eu explico o necessário sem preencher por você.
Se o módulo mecânico da edição ainda não estiver carregado, o Guia pode explicar o conceito, mas não cria automaticamente valores, bônus ou cálculos.
A ficha deixa de ser um grande formulário quando você entende que cada bloco responde a uma pergunta diferente sobre o personagem.
Quando a Ficha Viva calcular um valor, deve mostrar a origem: escolha, atributo, treinamento, nível ou regra que participou da conta. O iniciante aprende sem precisar fazer a conta à mão.
O modo de jogo da Ficha Viva deve ser diferente do modo de criação: leitura rápida, botões claros e recursos do personagem no primeiro plano.
A Ciel deve primeiro identificar o sistema e a ação. Depois aponta o campo da ficha e explica qual valor será usado.
Quando o sistema separar precisão e dano, a interface também deve separar. Isso reduz um dos erros mais comuns de iniciantes.
Vida, Fome, Sangue, espaços de magia, pontos ou outros recursos devem usar o visual próprio do sistema.
Um personagem sem magia não precisa ver uma grande área de conjuração. Cada motor monta sua própria interface.
Quando chega sua vez, você não precisa procurar a ficha inteira. Primeiro diga sua intenção. Depois a Ficha Viva e a Ciel mostram apenas as ações e recursos compatíveis com seu personagem e com o sistema ativo.
“Quero atingir aquele inimigo”, “quero proteger alguém”, “quero investigar a porta”.
A ficha mostra as opções que o personagem realmente possui.
O Mestre ou o motor informa qual teste/rolagem se aplica.
Custos, dano, recursos e efeitos ficam registrados pela ficha.
A Ciel vai orientar o caminho sem inventar números.
Não role por conta própria só porque encontrou um botão ou um dado. Primeiro descreva o que quer fazer; o Mestre e o ruleset definem quando e como resolver.
Mestrar é administrar informação e escolhas, não apresentar um roteiro que os jogadores são obrigados a seguir.
Tenha um ponto de partida, personagens importantes, conflitos e algumas possibilidades reutilizáveis.
Diga o que é perceptível, pergunte o que os jogadores fazem e use regras quando a incerteza importar.
Reaproveite elementos preparados e deixe as escolhas dos jogadores mudarem o caminho.
Pergunte o que funcionou, registre decisões e ajuste a próxima sessão.
Ser um bom Mestre não exige decorar tudo. A Ciel pode localizar a regra correta, mas a decisão narrativa continua sendo sua.
Quando não existe risco, oposição ou consequência relevante, talvez nem seja necessário rolar.
É combinar elementos que você já conhece para responder a algo inesperado.
Se Mestre e jogadores querem experiências diferentes, alinhar expectativas costuma funcionar melhor do que tentar controlar a mesa.
O copiloto ajuda a organizar informação, consultar a fonte correta, estruturar cenas e reagir ao inesperado. Ele não toma o controle da história nem força um resultado.
Quando uma resposta depender de regra, ele consulta o ruleset/livro. Quando depender de julgamento narrativo, oferece opções e deixa a decisão com o Mestre.
A decisão final depende do sistema e da situação da mesa; este quadro é pedagógico, não uma regra universal.
A Forja deve separar ensino, regra publicada, regra da casa e estado atual da ficha. Esta etapa mostra como uma pergunta mecânica será transformada em uma consulta rastreável, sem misturar sistemas ou edições.
Identifica sistema, edição e módulo antes da consulta.
Livro ou catálogo autorizado confirma regra, número e exceção.
Aplica a regra ao personagem e ao estado real da sessão.
Só prevalece quando a mesa registrou explicitamente uma alteração.
Primeiro diga o essencial em linguagem adequada ao usuário.
Mostre a consequência na ficha ou na cena somente se a fonte sustentar.
Exiba sistema, edição, livro/módulo e trecho de referência quando disponível.
Se faltar fonte ou houver versões incompatíveis, pare e sinalize em vez de inventar.
Quando existir fonte carregada, a Ciel responde a partir dela. Quando não existir, ela diz claramente o limite e evita completar a lacuna por memória.
A Biblioteca da Ciel não é uma pasta única com tudo misturado. Cada fonte recebe identidade própria para que a consulta saiba exatamente de qual sistema, edição, capítulo e assunto uma informação veio.
D&D, Vampiro e cada outro RPG mantêm um espaço lógico próprio.
2014, 2024, V5 e outras edições nunca são fundidas automaticamente.
Cada livro, suplemento, catálogo, guia ou regra da casa recebe um identificador.
Trechos são classificados por criação, combate, magia, equipamento, progressão e outros temas.
Ela preserva o catálogo e acrescenta uma matriz de cobertura. Nenhum livro real foi embutido aqui e nenhuma regra mecânica nova foi inventada.
Uma mesma fonte pode alimentar vários assuntos, mas cada trecho recebe uma classificação explícita.
Quando um novo livro for preparado, este manifesto descreve onde ele pertence. O arquivo real continua fora deste protótipo.
Busca somente em fontes mecânicas compatíveis com o ruleset ativo.
Usa o Guia para explicar e pode anexar a fonte mecânica quando houver número ou exceção.
Combina ruleset + estado atual da Ficha Viva, sem transformar estado em regra.
Consulta regra da casa e lore da campanha dentro do escopo daquela mesa.
Se duas edições ou fontes incompatíveis responderem de forma diferente, a Biblioteca marca o conflito. A Ciel deve manter o ruleset ativo e mostrar que existe outra versão, em vez de combinar as duas.
A matriz de cobertura impede respostas mecânicas “confiantes” em áreas ainda não validadas. Cada sistema e edição é acompanhado por assunto, fonte, integração com a Ficha Viva e nível de teste.
Ter um livro no catálogo não significa que toda a edição está coberta. A Ciel só confirma uma mecânica quando o assunto consultado passou pelos portões mínimos de contexto, fonte, cobertura, estado e conflito.
| Assunto | Guia | Regra mecânica | Ficha Viva | Testes | Ciel pode confirmar? |
|---|
Explica de forma pedagógica e marca que número, exceção ou validade precisam de fonte.
Não promove o conteúdo para “verificado”; mantém a resposta como parcial.
Bloqueia a composição automática e mantém o ruleset ativo.
Pode explicar a regra verificada, mas não afirma o valor atual do personagem.
Este painel prioriza o que precisa ser carregado/validado antes de liberar respostas mecânicas.
A v0.8 cria o fluxo de entrada dos livros: registrar a fonte, travar sistema/edição, extrair texto, reconhecer capítulos, classificar assuntos, procurar conflitos e somente então propor atualização de cobertura. A promoção para regra verificada continua exigindo revisão.
Ingerido ≠ verificado. O pipeline pode organizar e indexar o conteúdo, mas não libera sozinho números, fórmulas, custos ou exceções para respostas mecânicas.
Arquivo identificado e checksum calculado.
Sistema e edição não podem ser inferidos silenciosamente de outro livro.
Texto separado do arquivo e locators preservados.
Trechos recebem capítulo, seção e tipo de regra.
Diferenças entre fontes/edições ficam visíveis.
Confirma classificação e autoridade antes de liberar mecânica.
Identidade, edição, autoridade, idioma, checksum e status de revisão.
Cada trecho mantém origem, capítulo, seção, tipo de regra e locator para voltar à fonte.
O sistema sugere quais assuntos ganharam material, mas não marca verified automaticamente.
A extração pode falhar em tabelas, colunas e páginas escaneadas. O relatório registra avisos; fontes com baixa qualidade de extração ficam bloqueadas para promoção mecânica até revisão.
A v0.9 cria a fila de revisão entre a ingestão e a cobertura. O revisor confirma sistema/edição, qualidade da extração, capítulo, classificação e conflitos. Só depois é gerada uma proposta de promoção — nunca uma liberação automática.
Revisado ≠ publicado automaticamente. A revisão produz decisões rastreáveis. A matriz de cobertura só deve mudar após uma promoção explícita e validada.
Escolha um trecho da fila para revisar.
Somente assuntos com contexto travado, trechos revisados, fonte autorizada e nenhum conflito aberto podem entrar na proposta.
Este painel demonstra a revisão usando trechos sintéticos. Na integração real, o conteúdo revisado continua na Biblioteca/índice da Ciel e o Guia recebe apenas metadados, cobertura e locators.
A revisão humana confirma o texto e o contexto. A validação mecânica compara casos de teste rastreáveis com o resultado do motor da ficha. Só depois disso um assunto pode ser proposto como verified.
Fonte revisada + teste aprovado + nenhum conflito aberto. Falhar em qualquer portão mantém a Ciel em modo parcial/conceitual.
Escolha um caso de teste.
O protótipo só propõe `verified` quando todos os casos obrigatórios passam e não existe conflito/bloqueio. A atualização real da Biblioteca continua sendo explícita.
Servem para testar o fluxo de validação sem afirmar nenhuma regra real de D&D, Vampiro ou outro sistema. Os livros e motores reais entram depois.
Esta etapa conecta os testes mecânicos a um registro rastreável de defeitos. Cada divergência recebe sistema, edição, campo afetado, regra esperada, resultado atual, severidade, evidência e plano de correção.
Transformar um teste que falhou em um problema reproduzível, corrigível e retestável. Nenhuma correção é marcada como concluída sem um novo teste aprovado.
Escolha um erro para revisar.
Gera um registro que pode ser levado ao BUILD da Ficha Viva: problema, evidência, arquivos/módulos afetados, correção proposta, teste de regressão e resultado do reteste.
Os erros desta tela são sintéticos e demonstram o fluxo. A v0.15 não modifica o BUILD P nem executa patch no site. A aplicação real deve acontecer somente após reproduzir o defeito no BUILD alvo e preservar backup.
Esta etapa reúne cobertura da Ciel, prontidão mecânica, estrutura da Ficha Viva, testes e erros abertos por sistema/edição. O objetivo é evitar liberar um sistema só porque uma parte isolada parece funcionar.
Os números desta v0.14 usam a matriz e os casos sintéticos do próprio Guia. Eles não são uma auditoria do BUILD P nem afirmam que regras reais de D&D ou Vampiro foram validadas.
| Sistema / edição | Guia | Regras | Ficha | Testes | Erros ativos | Estado |
|---|
Selecione um sistema na tabela para ver o diagnóstico.
Gera um retrato rastreável da prontidão atual. O snapshot informa explicitamente que não aplica patch, não publica ruleset e não substitui teste no BUILD real.
Pronto exige fonte mecânica verificada, Ficha Viva compatível, testes aprovados e nenhum erro bloqueador. Um Guia bem escrito sozinho nunca torna o sistema mecanicamente pronto.
Esta etapa transforma saúde, fontes, testes e erros em uma decisão de homologação por sistema/edição. Ela não publica nada automaticamente: prepara o dossiê que será usado quando auditarmos o BUILD real.
A v0.15 ainda não usa os livros reais do outro chat nem executa testes no BUILD P. Portanto, nenhum sistema deve ser marcado como liberado para produção nesta fase.
| Sistema / edição | Saúde | Evidências | Bloqueadores | Decisão |
|---|
Selecione um sistema para ver os critérios e evidências.
Gera um relatório rastreável com decisão, motivos, evidências faltantes e assinatura de que não houve publicação automática.
A liberação é por sistema e edição. D&D 2014 pode estar pronto enquanto D&D 2024 continua bloqueado, e o mesmo vale para Vampiro Revisada e V5. Nenhuma edição herda automaticamente a homologação de outra.
Esta etapa transforma tudo que foi projetado no Guia em um plano de integração controlado. Ela mostra o alvo lógico de cada componente, suas dependências e a ordem segura de implantação — sem inventar caminhos físicos que ainda não foram auditados no BUILD real.
Todos os caminhos físicos aparecem como unresolved_until_target_audit até o pacote real ser inventariado. Nenhum arquivo do BUILD, banco, Ciel real ou Supabase é alterado por esta versão.
| Componente | Camada | Alvo lógico | Dependências | Risco | Estado |
|---|
Selecione um componente para ver contrato, dados e bloqueadores.
Gera um JSON com os alvos lógicos, dependências, flags e pré-condições. Ele não contém comandos de publicação nem migration destrutiva.
Primeiro infraestrutura e contratos; depois adapters; depois testes em sombra; por último habilitação por sistema + edição. Se um ruleset falhar, os demais não precisam ser desligados.
Aqui o Guia executa cenários sintéticos que atravessam contexto, Ciel, Ficha Viva, ruleset, biblioteca, persistência e retorno à interface. O objetivo é encontrar mistura de edição, perda de contexto e fallbacks perigosos antes de qualquer patch real.
Os adapters desta etapa são mocks determinísticos. Um cenário PASS significa que o contrato projetado se comportou corretamente; não significa que o site publicado já foi integrado.
Execute um cenário para ver cada passagem entre os componentes.
Exporta cenário, passos, bloqueios esperados e resultado. Não contém token, segredo, dado real de usuário ou comando de deploy.
Em testes de segurança, BLOCKED pode ser o resultado correto. Ex.: tentar usar regra 2024 numa ficha travada em 2014 deve ser bloqueado — e o cenário passa justamente por isso.
A Ciel não precisa despejar um manual inteiro. Ela identifica sistema, edição, ficha e etapa atual, explica o necessário e oferece o próximo passo.
Sistema, edição, ruleset, personagem e etapa atual.
Guia para ensinar; livro/motor para regra, número e cálculo.
Explicar melhor, continuar ou abrir o campo correto da ficha.
Esta versão fecha o ciclo de desenvolvimento do Guia. Ela consolida conteúdo pedagógico, contratos da Ciel, biblioteca de fontes, cobertura, ingestão, revisão, validação mecânica, erros, saúde, homologação, mapa de integração e testes simulados — sem publicar alterações no BUILD principal.
v1.0 FINAL significa que o pacote independente do Guia está fechado. A integração com o BUILD publicado continua sendo uma fase separada, com auditoria, backup, feature flags, testes reais e rollback.
Gere um snapshot resumido da entrega. Ele registra explicitamente que nenhuma integração real foi aplicada.