Pular para o conteudo

---

@CanalQb no YouTube

---

Master Rules 9.3: Etapas Corrigidas e Japão no Compliance

---

Leitura: ~31 min Feito com Master Rules Claude v9.3

TL;DR:

• O Master Rules 9.3 corrigiu três defeitos de HTML que apareciam nos posts reais: numeração duplicada nas etapas, markdown solto no arquivo e elemento void fechado.
• O Bloco 6 do post agora aceita YouTube, Instagram e TikTok com formato automático por classe de proporção, e os metadados ganharam um Bloco Compartilhado que elimina a repetição de tags e hashtags.
• O compliance foi ampliado para o Japão com APPI, PPC e 景品表示法, e cinco seções perdidas desde a versão 8.5 foram restauradas, incluindo o protocolo completo de receitas.

Nota Técnica: este conteúdo compara duas versões do prompt Master Rules que operam sobre arquivos de post do Blogger. Os trechos de código foram validados por inspeção estática e por leitura das fontes em 05/11/2026. Nada aqui é garantia de aprovação do AdSense, de posição no Google ou de conformidade legal — a auditoria jurídica continua sendo responsabilidade de advogado habilitado.

Três bugs reais, um arquivo polluted e um mercado novo: o 9.3 não reescreveu o prompt, ele consertou o que estava quebrando na produção.

Entre a versão 9.2 e a 9.3, o mesmo prompt passou a gerar posts com numeração de etapas duplicada, com uma linha de markdown solta na primeira linha do HTML e com a tag de fechamento de um elemento que não aceita fechamento. Isso não é hypothetical: é o arquivo que saiu da geração anterior. Quando o defeito aparece no post final, a causa costuma estar no prompt, e corrigir o post na mão não corrige o próximo artigo.

Por isso, este texto é o changelog narrado de uma ferramenta de produção. Vou abrir a comparação de seção por seção, mostrar a causa raiz de cada defeito no nível de CSS e de HTML, explicar as cinco seções que a 9.2 tinha perdido desde a 8.5 e fechar com o que ainda continua aberto na 9.3 — inclusive dois pontos que o changelog oficial não documentou.

Quais são as soluções rápidas para os defeitos mais comuns da 9.2?

Os defeitos mais comuns têm correção direta: numeração duplicada nas etapas, markdown solto na primeira linha do HTML e fechamento de elemento vazio, como a tag de link. A 9.3 trata os três com regra própria, com exemplo de código e verificação automática por busca de texto, e acrescenta o embed de vídeo por classe de proporção.

• Numeração duplicada nas etapas: o marcador automático do navegador somava com o círculo do ::before porque o reset estava no elemento errado. A Seção 8.3 fixa o padrão, com regra de override de especificidade maior. ver passo completo
• Markdown solto na primeira linha do HTML: o arquivo abria com um hífen antes da tag do Font Awesome e o Blogger transformava aquilo em texto visível. A Seção 20.1 proíbe sintaxe markdown no fragmento e define a autoverificação. ver passo completo
• Elemento void fechado: tags como </link> e </img> não podem ter tag de fechamento em HTML. Agora são erro de reprovação explícito. ver passo completo
• Vídeo vertical cortado: o height fixo de 700 pixels só servia para vídeo vertical e quebrava qualquer formato. A Seção 12.2 resolve por classe de proporção, sem altura fixa. ver passo completo
• Hashtag diferente em cada rede: o Bloco Compartilhado escreve a lista única uma vez e cada rede só referencia quantas hashtags usa. ver passo completo

O que realmente mudou entre o Master Rules 9.2 e o 9.3?

A 9.3 não reescreveu o prompt: corrigiu três defeitos de HTML que quebravam os posts reais, ampliou o bloco de vídeo para YouTube, Instagram e TikTok, reorganizou os metadados em um Bloco Compartilhado, incluiu o Japão no compliance e restaurou cinco seções perdidas desde o 8.5. Nenhum piso de densidade, pesquisa ou auditoria foi afrouxado.

O que uma release de prompt significa na prática

Vale entender o que significa uma release de prompt antes de listar mudanças. O Master Rules não é um artigo: é o prompt que governa a produção de outros artigos, com pesquisa obrigatória, piso de densidade por seção, auditoria de doze campos e portão de publicação. Quando a saída final quebra, a causa costuma estar no prompt e não no post. Um defeito de CSS no template de etapas aparece em todo post tutorial, um elemento void fechado aparece na primeira linha de todo arquivo HTML, e corrigir caso a caso consome mais tempo do que corrigir a regra.

Por isso a comparação útil não é "quantas linhas o prompt tem", e sim "quantos defeitos de produção foram eliminados e quantos relatórios passaram a prová-los". A tabela abaixo resume o delta entre as duas versões, seção por seção.

O delta entre as duas versões, seção por seção

Frente	Master Rules 9.2	Master Rules 9.3
Bloco de etapas	Sem seção própria; o CSS dependia do que o modelo improvisava	Seção 8.3 com sete regras inegociáveis, CSS Counter e override de especificidade maior
Integridade do HTML	Proibia apenas tags de página, na Seção 13.0	Seção 20.1 com seis regras absolutas e autoverificação por busca de texto
Vídeo do post	Somente YouTube, com altura fixa de 450 pixels	YouTube, Instagram e TikTok, com classe de proporção 9:16, 1:1 e 16:9
Metadados	Tags e hashtags reescritas em cada bloco de rede	Bloco 0 compartilhado, com tabela de consumo por rede
Compliance	Brasil, EUA, União Europeia e Reino Unido	Mesmas jurisrições mais Japão: APPI, PPC e 景品表示法
Base herdada do 8.5	Cinco seções ausentes e receita resumida em um parágrafo	Seções 31 a 35 restauradas e protocolo de receitas nas subseções 22.1 a 22.10
Relatório de qualidade	19 linhas de verificação	22 linhas, incluindo HTML íntegro, bloco compartilhado e origem do vídeo
Parâmetros de gatilho	tema, nivel, objetivo e formato	Os quatro anteriores mais video, com youtube, instagram, tiktok ou nenhum

O exemplo concreto que dispara a release é o arquivo gerado pela 9.2. Na primeira linha, o cabeçalho do Font Awesome chegava precedido de um hífen de markdown e trazia a tag de fechamento no fim, algo que o navegador trata como texto inválido dentro do editor do Blogger. Some isso ao bloco de etapas, que saía com o número automático do navegador somado ao círculo desenhado em CSS, e o resultado é um post visualmente quebrado mesmo com todo o conteúdo, a pesquisa e a auditoria aprovados. A 9.3 trata os dois como erro de reprovação, não como detalhe cosmético.

O que não mudou e o erro comum ao comparar versões

O que não mudou: o piso de 3.000 palavras visíveis, o mínimo de 200 palavras por subsessão de título de segundo nível, as 8 subsessões do corpo técnico, a proporção de 60 por cento do corpo, a faixa de legibilidade Flesch entre 60 e 79, a pesquisa com no mínimo 4 fontes, a pesquisa profunda de 8 fontes no post inteligente, o painel de qualidade de 0 a 100, os portões de validação e liberação, a entrega em 3 arquivos e as 6 proporções de thumbnail. A 9.3 cresce em rigor, não em volume obrigatório.

Erro comum ao comparar versões: contar linhas ou palavras e concluir que a versão mais longa é a melhor. O arquivo da 9.2 tem 2.255 linhas e o da 9.3 tem 1.749, porque a 9.2 carregava uma quantidade grande de linhas em branco entre os blocos. A 9.3 compactou a formatação e reinvestiu o espaço em regra normativa, o que resulta em menos linhas e mais obrigação: cada linha nova na 9.3 existe porque um defeito ou uma lacuna real entrou na fila.

Por que as etapas saíam com numeração duplicada?

O número aparecia duas vezes porque o marcador automático do navegador competia com o círculo desenhado em CSS. A causa está no alvo do reset: o list-style:none era aplicado na lista, e não no item, onde o tema tem especificidade maior e vence a herança. O item tem declaração própria, e é nela que o marcador nasce.

A causa técnica: o reset aplicado no elemento errado

Por isso a regra correta é inverter o alvo: o list-style:none e o counter-increment ficam no item, nunca na lista. O número passa a ser gerado por CSS Counter, com counter-reset na lista e counter(passo) no pseudo-elemento do círculo. O texto do item nunca carrega número digitado, o que também elimina a divergência entre o número do círculo e o número do texto quando alguém edita a lista depois.

A Seção 8.3 fixa o padrão com sete regras inegociáveis, e o CSS abaixo é o bloco que deve ser colado uma única vez no estilo do post:

.post_steps{padding:0;margin:16px 0;counter-reset:passo}
.post_steps li{counter-increment:passo;list-style:none;position:relative;padding:14px 14px 14px 56px;margin-bottom:12px;border:1px solid #e0e0e0;border-radius:10px;color:#444}
.post_wrap ol.post_steps > li{list-style:none;padding:14px 14px 14px 56px;margin-bottom:12px}
.post_steps li::before{content:counter(passo);position:absolute;left:14px;top:14px;width:30px;height:30px;border-radius:50%;background:#28a745;color:#fff;font-weight:700;display:flex;align-items:center;justify-content:center}

O HTML do bloco de etapas, sem número digitado

O HTML correspondente não tem nenhum número escrito, e o item começa com um trecho em negrito que nomeia o passo antes do detalhe:

<ol class="post_steps">
  <li><strong>Cozinhe a banana com canela (10 minutos).</strong> Em uma panela média, coloque 450 g de banana em rodelas de 1 cm, 250 ml de água e 1 pau de canela de 3 g. Tampe e cozinhe em fogo médio por 10 minutos, até as rodelas desmancharem ao toque do garfo.</li>
  <li><strong>Bata no liquidificador (2 minutos).</strong> Retire o pau de canela e bata a banana com a água do cozimento por 1 a 2 minutos, até ficar totalmente lisa.</li>
</ol>

A linha de override que fecha o defeito

A quarta linha do CSS merece atenção especial, porque é onde o defeito escapava mesmo com o resto do CSS correto. A regra .post_wrap ol.post_steps > li existe para vencer um reset do tema que zera o espaçamento interno do item, mas ela tem especificidade maior que a regra do tema. Se essa linha de override omitir o list-style:none, o marcador automático reaparece sozinho e a numeração volta a duplicar. Foi exatamente esse o motivo do ajuste de 9.3.1, aplicado depois do primeiro relato de defeito.

Exceções e limitações: a documentação do MDN classifica o pseudo-elemento de marcador como recurso de disponibilidade limitada, ou seja, o comportamento pode variar entre navegadores, e é por isso que o círculo desenhado em CSS é a fonte única de número. A largura mínima de 56 pixels à esquerda do texto existe para que a linha do item não invada o círculo, e reduzir esse valor quebra o layout em telas estreitas.

Erro comum: aplicar list-style:none na lista, testar em um navegador sem reset do tema, concluir que resolveu e publicar. O defeito só reaparece no Blogger, porque o tema do blog tem a regra de especificidade maior. A verificação correta é abrir o post renderizado no próprio tema, não em um sandbox vazio.

Por que o HTML do post saía com markdown solto e tag de fechamento indevida?

O arquivo de post é um fragmento colado no editor do Blogger, e a 9.2 só proibia tags de página. Faltava regra para sintaxe markdown e para fechamento de elemento vazio, dois defeitos que viram texto visível no post. A Seção 20.1, nova na 9.3, proíbe os dois e exige autoverificação por busca.

A Seção 20.1 e as seis regras absolutas

A Seção 20.1, nova na 9.3, resolve isso com seis regras absolutas. A primeira proíbe qualquer caractere de markdown antes de uma tag, no início de uma linha ou colado a uma tag, com uma exceção explícita: blocos de exemplo internos podem exibir markdown, porque são justamente a demonstração do problema. A segunda proíbe tag de fechamento em elemento vazio. Elementos como link, img, br e hr admitem apenas a tag de abertura, e a especificação HTML é categórica ao escrever que a tag de fechamento não deve ser especificada para eles.

O exemplo real: a linha que a 9.2 gerava

Este é o trecho que a 9.2 gerava na primeira linha do arquivo, com um hífen de markdown antes da tag do Font Awesome e com a tag de fechamento no fim da própria linha:

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.0/css/all.min.css" crossorigin="anonymous" referrerpolicy="no-referrer"></link>

O leitor vê isso renderizado como texto na página, não como um carregamento de estilo. E a segunda linha da regra é o detalhe fino: um caractere de hífen antes da tag vira um item de lista do Markdown, o que em um editor visual pode disparar a criação de um bloco de lista inteiro em cima do post.

Além disso, a Seção 20.1 fecha as outras portas de saída do defeito: proíbe tags de página, que duplicariam a estrutura do Blogger, proíbe elemento vazio sem conteúdo obrigatório, exige que as etapas usem a Seção 8.3 e define o fecho exato do arquivo, que termina no último bloco, sem texto residual e sem linha em branco inicial.

A autoverificação que transforma regra em evidência

A seção também entrega a autoverificação, que é a parte que transforma regra em evidência. Em um terminal Windows, a checagem é a seguinte:

<span class="comment"># janela: PowerShell</span> Select-String -Path "post-{slug}.html" -Pattern '</link>|</img>|</br>|</hr>' Select-String -Path "post-{slug}.html" -Pattern '^\s*[-*>#]' Select-String -Path "post-{slug}.html" -Pattern '<!DOCTYPE|<html|<head|<body'

As três buscas devem retornar zero ocorrência. O mesmo raciocínio vale em terminal Unix com grep, e a Seção 35 do prompt trata exatamente dessa diferença de shell, já que o ambiente de publicação do canal roda em Windows.

Exceções e limitações: a busca por hífen no início da linha acusa falsos positivos quando o próprio post documenta markdown dentro de um bloco de código. A solução é revisar cada ocorrência e decidir se é demonstração legítima ou vazamento real, não desabilitar a checagem.

Erro comum: corrigir o HTML no editor do Blogger e republicar, sem corrigir o prompt. O arquivo volta a quebrar no post seguinte, porque a geração continua usando o mesmo defeito. A correção que resolve é na Seção 20.1, com a regra e a autoverificação juntas, para o próximo post nascer certo.

Como o vídeo agora se adapta a YouTube, Instagram e TikTok?

O Bloco 6 deixou de aceitar apenas YouTube. A origem passa a vir do parâmetro de gatilho video, e a altura deixou de ser fixa: o embed do Instagram e do TikTok resolve o tamanho por uma classe de proporção, com 9:16, 1:1 e 16:9. A largura segue limitada a 540 pixels, sem nenhuma altura fixa.

O dimensionamento por proporção, sem altura fixa

O problema que isso resolve é concreto. A 9.2 usava um height fixo de 700 pixels, pensado para vídeo vertical, e colar isso em um vídeo horizontal ou em um post do Instagram deixava o embed cortado ou com uma faixa preta enorme. A 9.3 troca a altura fixa por três custom properties de CSS: a largura calculada, a faixa de cabeçalho e rodapé do embed, e a proporção. A altura final é o produto da largura pela proporção somado à faixa, calculada pelo próprio navegador.

A ordem de decisão do formato está definida na Seção 12.2 e é determinística. Primeiro o formato informado pelo usuário tem precedência. Depois, endereço com reel ou tv resolve como 9:16. Endereço com p sem formato informado resolve como 9:16 quando é vídeo e 1:1 quando é imagem ou carrossel. Na dúvida, entra o valor da variável FORMA_VIDEO_PADRAO, e o metadado registra que o formato foi assumido e precisa ser confirmado antes de publicar.

O template do embed de Instagram e TikTok

O template do embed de Instagram sai assim, com a classe de proporção no lugar do valor fixo:

<div class="post_video">
  <iframe class="post_video_ig post_video_{FORMATO}" src="https://www.instagram.com/{TIPO}/{ID}/embed/" title="Vídeo de {NOME_CANAL}: {Titulo_do_Post}" aria-label="Vídeo no Instagram" loading="lazy" scrolling="no" allowtransparency="true" allowfullscreen></iframe>
  <p><i class="fab fa-instagram"></i> Prefere abrir direto? <a href="https://www.instagram.com/{TIPO}/{ID}" target="_blank" rel="noopener noreferrer">Veja o vídeo no Instagram</a>.</p>
</div>

O TikTok reaproveita o mesmo sistema de proporção com a classe 9:16 e o endpoint embed/v2, sem o script externo de embed. A 9.3 também normaliza a URL antes de montar o embed, removendo parâmetros de rastreamento como igsh e utm_source, e exige o preenchimento de title e aria-label no iframe.

Exceções e limitações: a faixa de 190 pixels que representa o cabeçalho e o rodapé do embed do Instagram é um valor empírico, não um valor documentado pela plataforma, e pode variar com a versão do embed ou com a presença de bloqueadores. Se sobrar ou faltar espaço, a regra é ajustar apenas essa faixa. O embed exige que a publicação esteja pública e permita incorporação, e o vídeo nunca deve ser o elemento de maior prioridade de carregamento da página, porque o primeiro elemento visual já tem prioridade alta e as demais imagens carregam de forma preguiçosa.

Erro comum: manter o height fixo herdado da 9.2 e acrescentar a classe de proporção por cima. O navegador respeita a altura declarada e o problema reaparece em formato vertical. Ou editar a largura do iframe à mão, o que quebra o dimensionamento responsivo e o limite de 540 pixels que o embed do Instagram impõe.

Como o Bloco Compartilhado elimina a repetição de tags e hashtags?

Ele concentra em um único bloco, o bloco 0, tudo que é idêntico entre redes: palavra-chave, endereço do post, links internos, fontes externas, tags, lista única de hashtags, texto alternativo e contexto da thumbnail. Cada rede deixa de reescrever essas listas e passa a referenciar quantos itens consome, na ordem de cima para baixo.

O ganho de consistência entre as redes

O ganho não é só de tamanho de arquivo. É de consistência. Na 9.2, cada bloco de rede tinha sua própria lista de hashtags, o que permitia que o Instagram publicasse 30 hashtags com a marca no grupo de nicho, o Twitter publicasse duas versões diferentes da mesma hashtag e o YouTube recebesse um conjunto de tags que não batia com nenhum dos dois. Com o bloco compartilhado, a lista existe uma vez, e a regra de consumo define quantas e quais cada rede usa.

A regra de consumo é literal. O YouTube usa a lista completa de tags e as 3 a 5 primeiras hashtags. O Instagram usa as 30 hashtags, o texto alternativo e a ideia de vídeo curto. O Twitter usa 1 ou 2 hashtags. O Facebook usa de 1 a 3. O Reddit não consome hashtags porque hashtags não existem ali, e o Telegram não tem hashtag obrigatória. O TikTok usa de 3 a 5 e a ideia de vídeo curto. O LinkedIn usa de 3 a 5, o Pinterest de 2 a 5 mais o texto alternativo, e o Threads apenas a primeira.

A regra de consumo, rede por rede

Por baixo dessa economia há uma regra mais forte, que vale para todos os campos: o emoji e o nome do campo nunca mudam entre posts. O campo de título SEO é sempre o mesmo campo de título SEO, com o mesmo emoji, e se um campo novo for acrescentado, ele entra no fim do bloco daquela rede, nunca no meio, para não quebrar a ordem memorizada por quem publica em sequência.

Rede	Tags	Hashtags	Outros itens do bloco 0
YouTube	Lista completa de tags	3 a 5 primeiras	Endereço do post na primeira linha da descrição
Instagram	Não usa	As 30	Texto alternativo e ideia de vídeo curto
Twitter/X	Não usa	1 a 2 primeiras	Endereço do post no fio
Facebook	Não usa	1 a 3 primeiras	Endereço do post na primeira ou na última linha
Reddit	Não usa	Nenhuma	Bloco 0 não é consumido
TikTok	Não usa	3 a 5 primeiras	Ideia de vídeo curto
Pinterest	Não usa	2 a 5 primeiras	Texto alternativo

Exceções e limitações: o bloco compartilhado assume um núcleo editorial único, a mesma palavra-chave para todas as redes com tom diferente. Se uma campanha exigir palavra-chave distinta por plataforma, o modelo atual não cobre esse caso e a lista precisaria ser duplicada à mão, o que reintroduz justamente o problema que o bloco resolve.

Erro comum: reescrever a lista de hashtags no bloco de cada rede porque a legenda pedia mais hashtags do que a regra permitia. A solução não é aumentar o consumo, é escolher quais itens da lista única a rede usa, respeitando o limite da plataforma, porque hashtag em excesso reduz alcance em vez de ajudar.

O que muda com a entrada do Japão no compliance?

Três pontos do prompt passam a citar o Japão: a lista de conformidade legal, a matriz regional e a matriz de jurisdições com fontes oficiais. Entram a APPI, com supervisão da PPC e foco em transferência internacional e notificação de incidentes, e a 景品表示法, com supervisão da CAA, sobre alegações publicitárias enganosas.

APPI e 景品表示法: duas autoridades diferentes

A APPI trata de privacidade, transferência internacional de dados, com destaque para o Art. 28, e notificação de incidentes à PPC. A 景品表示法 trata de outro problema: publicidade e alegações de qualidade que o consumidor considera enganosas, o que costuma ser o ponto de contato de um blog técnico quando a publicação faz afirmações fortes sobre ferramenta, produto ou serviço. São duas autoridades diferentes, com separação clara: a PPC para dados pessoais e a CAA para representação publicitária.

A entrada não é enfeite de lista. Ela muda a matriz de fontes oficiais da Seção 29, que passa a incluir a PPC do Japão e a CAA com os respectivos endereços, e o comando {Audite o compliance jurídico} passa a listar o Japão entre as jurisdições de referência do canal. O painel de relatório também muda: a linha de compliance deixa de dizer apenas BR, EUA e UE com Reino Unido e passa a registrar as cinco jurisdições, incluindo o Japão e a APPI.

Um detalhe honesto que vale registrar: o site oficial da PPC lista, na área de normas e orientações, uma alteração da Lei de Proteção de Dados Pessoais datada de 2026, no ano Reiwa 8. Isso significa que a entrada da matriz precisa ser reverificada a cada auditoria, e não copiada de uma vez. Uma matriz de conformidade desatualizada é pior do que uma ausência, porque passa a falsa segurança.

Exemplo de aplicação, exceções e erro comum

Exemplo de aplicação: um post sobre uma ferramenta de automação com audiência no Japão e integração com um serviço de API hospedado fora do país precisa responder a duas perguntas distintas. A primeira é de privacidade e de transferência internacional, sob a APPI e a supervisão da PPC. A segunda é de alegação publicitária, se o texto afirma que a ferramenta é a melhor opção ou promete resultado específico, sob a 景品表示法 e a supervisão da CAA. Tratar as duas como se fossem o mesmo regime é erro de escopo, e cada uma tem autoridade e evidência própria.

Exceções e limitações: a Seção 29 é explícita ao dizer que nenhuma instrução de modelo garante conformidade legal total. As cinco condições que antecedem qualquer declaração de conformidade continuam valendo: mapa de aplicabilidade com motivo documentado por lei, versão e vigência verificadas em fonte oficial, evidência técnica real, bloqueio de pendências materiais e revisão especializada de questão ambígua. Questão jurídica ambígua ou de alto risco vai para advogado, nunca para conclusão do modelo.

Erro comum: continuar tratando a matriz da 9.2 como universal. A 9.2 cobria Brasil, EUA, União Europeia e Reino Unido, e o próprio protocolo proíbe assumir que a lei brasileira basta para audiência internacional, aplicando o padrão mais restritivo quando há mais de uma jurisdição relevante. Publicar para o Japão com uma matriz que não cita a APPI é aplicar o padrão menos restritivo, o oposto da regra.

O que o 9.3 recuperou do 8.5 que o 9.2 tinha perdido?

Cinco seções e um protocolo inteiro: entidades XML do Blogger, agnosticismo de projeto, documentação de entregas, programmatic SEO com automação industrial e infraestrutura de terminal Windows. O protocolo de receitas, que na 9.2 era um parágrafo de resumo, volta nas subseções 22.1 a 22.10.

O Anexo A como trilha de auditoria

O Anexo A do prompt existe para tornar essa recuperação auditável. Ele compara o 8.5, o 9.2 e o 9.3 em 14 itens, marcando o que existia em cada versão. O resultado é uma leitura curta e honesta: seis itens estavam presentes no 8.5 e ausentes no 9.2, e todos foram restaurados; dois itens são novidade real do 9.3, a integridade de HTML e o vídeo multi-origem com classe de proporção; um item é a entrada do Japão no compliance.

Item herdado do 8.5	8.5	9.2	9.3
Protocolo de receitas completo	Presente	Ausente, resumo em 1 linha	Presente, Seções 22.1 a 22.10
Entidades XML do Blogger, com escape e CDATA	Presente	Ausente	Presente, Seção 31
Agnosticismo de projeto	Presente	Ausente	Presente, Seção 32
Documentação de entregas	Presente	Ausente	Presente, Seção 33
Programmatic SEO e automação industrial	Presente	Ausente	Presente, Seção 34
Infraestrutura e terminal Windows	Presente	Ausente	Presente, Seção 35
Integridade de HTML do post	Ausente	Ausente	Presente, Seção 20.1
Vídeo de Instagram e TikTok com proporção	Ausente	Ausente	Presente, Seções 12.2 a 12.4

O motivo por trás de cada recuperação

O protocolo de receitas é o caso mais visível dessa recuperação. Na 9.3 ele ocupa as subseções de 22.1 a 22.10 e entrega os 19 blocos em tabela, o schema Recipe em JSON-LD, os metadados exclusivos, as hashtags com a marca do blog de receitas, o contexto visual por país de origem e o bloco de chamada final. Na 9.2 tudo isso cabia em um parágrafo, o que na prática significava gerar a receita sem o pacote de metadados que a publicação exige.

Vale entender o motivo de cada recuperação. O protocolo de entidades XML existe porque o Blogger usa XML de verdade nos arquivos de tema e de widget, e Blocos longos de script ou estilo precisam de CDATA para não quebrar o parser. O agnosticismo de projeto existe para o prompt ser portátil: os nomes de arquivo são placeholders e a regra de qualidade não depende de Blogger. A documentação de entregas existe porque funcionalidade nova precisa ser explicada em seis campos. O programmatic SEO existe para escala não virar conteúdo repetido. E o terminal Windows existe porque o ambiente real do canal é PowerShell, e instruir modelo a rodar comandos de Unix em Windows gera falha na primeira execução.

Exceções, limites e o erro comum de chamar de estreia

Exceções e limitações: as seções restauradas são versões condensadas do material do 8.5, não uma cópia literal. O protocolo de receitas do 9.3 tem os 19 blocos e as 10 variações com a mesma estrutura, mas com menos exemplificação interna do que a versão original detalhava. Se uma receita exige a tabela completa de equivalências de medidas da versão original, é preciso consultar o 8.5 diretamente, que continua preservado sem alteração.

Erro comum: tratar a restauração como conteúdo novo e falar em estreia dessas regras. Não é estreia: é recuperação. A distinção importa porque muda o que se promete na postagem. Dizer que o 9.3 estreia com receitas é impreciso; dizer que o 9.3 devolve o protocolo de receitas ao nível em que ele estava é correto. E dizer que o 9.3 estreia com a integridade de HTML do post é correto, porque nenhum dos dois anteriores tinha a regra.

Como o checklist e o relatório de qualidade passaram a provar a correção?

A 9.3 acrescenta quatro linhas novas, uma reescrita e uma linha de compliance atualizada ao relatório de qualidade, e cinco itens ao checklist final de publicação. É essa camada que transforma a Seção 20.1 e a Seção 8.3 em auditoria: a linha só pode ser aprovada depois da busca por fechamento de elemento void retornar zero ocorrência.

O relatório de qualidade: de 19 para 22 linhas

O relatório de qualidade passou de 19 para 22 linhas. A linha nova de HTML íntegro exige evidência de quatro Checks: zero markdown solto, zero elemento void fechado, zero tag de página e ausência de marcador duplicado nas etapas. A linha do Bloco Compartilhado exige bloco 0 presente e redes apenas referenciando. A linha de ordem das redes foi reescrita para refletir a nova sequência, do compartilhado até as demais redes. E a linha de vídeo agora registra origem e formato, com o valor detectado ou assumido entre 9:16, 1:1 e 16:9.

O checklist final de publicação acompanha o mesmo movimento, com linhas para HTML íntegro, para numeração única das etapas, para origem e formato do vídeo, para presença do Bloco Compartilhado e para nomes de campo idênticos entre posts. A Seção 16, de substituições obrigatórias, ganhou quatro linhas: remoção de caractere de markdown solto, remoção de fechamento em elemento void, movimentação do list-style:none do ol para o li, e inclusão do list-style:none na regra de override de especificidade maior.

O checklist final e o resultado prático

O resultado prático é que a auditoria tem o que procurar. Antes, uma auditoria de HTML verificava tags de página e nada mais, e uma auditoria de etapas não tinha regra para olhar. Agora existe uma linha de relatório que só pode ser marcada como aprovada depois da busca por </link>, </img> e </br> retornar zero ocorrência, e existe uma regra de substituição que descreve exatamente o conserto quando a busca não retorna zero.

Exceções e limitações: o relatório é uma declaração do próprio agente que gerou o post. Ele não é um validador de terceiros, e a qualidade da evidência depende da honestidade da execução. A seção de auditoria central já exige que item não verificado por falta de acesso seja listado como pendência, e a regra vale para o relatório de qualidade tanto quanto para a auditoria editorial.

Erro comum: marcar a linha como aprovada sem executar a verificação, porque o parágrafo parece correto. A diferença entre o post funcionar e o post passar na auditoria está exatamente nessa linha. E há um segundo ponto, mais fino: a 9.3 documenta no próprio cabeçalho um ajuste posterior, o 9.3.1, que adicionou o list-style:none na regra de override. Ou seja, a primeira versão da 9.3 já saiu com o defeito e só foi completo na revisão seguinte, sem troca do número de versão no cabeçalho. Vale acompanhar o changelog, não apenas o rótulo.

Como migrar do 9.2 para o 9.3 sem quebrar o que já está publicado?

O caminho é auditado e não destrutivo: aplique o bloco de etapas uma única vez, converta as listas para ol com a classe de etapas, remova números digitados, corrija fechamento de elemento vazio e markdown solto, reorganize os metadados no bloco compartilhado e reexecute o relatório com as linhas novas. Faça cópia do HTML antes de editar.

A ordem segura de migração

A ordem completa é esta. Primeiro, aplica-se o bloco de etapas da Seção 8.3 ao tema ou ao post, uma única vez, e confirma-se no post renderizado que o número aparece uma vez só. Segundo, converte-se a lista de passos para ol com a classe de etapas, removendo qualquer número digitado no texto. Terceiro, busca-se no HTML publicado por fechamento de elemento void e por caractere de markdown no início de linha, corrigindo apenas o que for violação real. Quarto, reorganizam-se os metadados no bloco compartilhado. Quinto, reexecuta-se o relatório de qualidade com as linhas novas.

Para posts já publicados, a ordem importa: faça uma cópia do HTML antes de qualquer edição e não mexa na URL pública. O post continua no mesmo endereço, a cópia fica como backup e o editor do Blogger recebe o arquivo novo. Editar direto, sem cópia, é o erro clássico: se a regra de override do tema estiver errada no contexto real, o post fica com a numeração duplicada e não há como voltar atrás sem reconstruir.

Vale rodar uma varredura nos posts antigos para saber o tamanho do estrago. As buscas relevantes são as mesmas da Seção 20.1, aplicadas a cada arquivo HTML publicado, mais uma busca específica por list-style:none aplicado a um ol, que é a assinatura exata do defeito de numeração. O resultado dessa varredura é a lista de posts que precisam de correção, e não uma sensação difusa de que algo estava errado.

Exceções e erro comum na migração

Exceções e limitações: a migração depende do CSS atual do tema. Se o tema mudar depois, a regra de override de especificidade maior pode deixar de ser necessária ou deixar de ser suficiente, porque existe justamente para vencer um reset específico. Depois de qualquer atualização de tema, a verificação de numeração única precisa ser refeita nos posts que usam o bloco de etapas.

Erro comum: pasting do CSS novo no fim do arquivo de estilo do post, sem consolidar. O prompt é explícito na regra de CSS sem duplicatas: buscar o seletor antes de adicionar, consolidar duplicatas em bloco único e nunca adicionar ao final sem verificar, porque a última regra com important vence e duplicata é bug silencioso. O sintoma aparece como uma numeração que some em um post e volta em outro, dependendo de qual arquivo foi colado por último.

O que ainda não está resolvido na 9.3?

Cinco pontos, e vale listar porque um release honesto mostra o que continua aberto: a tensão entre o prefixo de classes e os templates fixos, a disponibilidade limitada do pseudo-elemento de marcador, a faixa empírica de 190 pixels do embed do Instagram, o relatório autodeclarado e a validação guiada por prompt, sem suíte automatizada.

A tensão entre o prefixo de classes e os templates fixos

O primeiro ponto merece detalhe, porque é funcional e não cosmético. A regra que vence o reset do tema é .post_wrap ol.post_steps > li, e ela só casa se existir um ancestral com a classe post_wrap. Se alguém renomear essa classe para incluir o prefixo do canal, a regra de override deixa de casar e a numeração duplicada volta. A tensão existe porque a especificidade é o mecanismo da correção, e o prefixo é o mecanismo de isolamento do tema. São dois requisitos legítimos que se atravessam, e o prompt resolve mantendo o nome sem prefixo justamente no ponto onde ele é funcional.

O segundo ponto é a razão de o círculo em CSS ser a fonte única de número. O MDN classifica o pseudo-elemento de marcador como recurso de disponibilidade limitada, o que significa que o comportamento do marcador automático não é uniforme entre navegadores. Como a correção depende de neutralizar esse marcador, o desenho do círculo por CSS Counter é a parte estável do arranjo, e a regra de override protege justamente o ponto onde o marcador escapa.

Os outros pontos e o erro comum

O terceiro ponto é honestidade de medição: a faixa de cabeçalho e rodapé do embed do Instagram foi observada empiricamente, não vem de documentação pública da plataforma, e pode mudar com a versão do embed. O prompt trata isso como variável ajustável, com instrução de mexer só nela quando sobrar ou faltar espaço, mas o valor não é um contrato da plataforma. O quarto ponto, o relatório autodeclarado, é uma limitação estrutural de qualquer auditoria executada pelo mesmo agente que escreveu o conteúdo. O quinto ponto é o mais estrutural: a qualidade depende de o agente seguir as regras, e não de um conjunto de testes que reprove automaticamente quando uma regra é violada.

Erro comum: tratar "o prompt determina" como validação concluída. Uma regra escrita é uma intenção; a prova é o relatório com evidência, a busca de texto com zero ocorrência e o post renderizado no tema real. A própria Seção 6.7 admite o caminho difícil: entregar sabendo que algo reprova e sinalizando é aceitável, entregar sabendo e escondendo não é.

Perguntas frequentes sobre o Master Rules 9.3

O que muda no Master Rules 9.3 em relação ao 9.2?

A 9.3 corrige três defeitos de HTML que quebravam os posts reais, estabelece a Seção 8.3 do bloco de etapas e a Seção 20.1 de integridade de HTML, amplia o vídeo para Instagram e TikTok, reorganiza os metadados em Bloco Compartilhado, inclui o Japão no compliance e restaura cinco seções que o 9.2 tinha perdido desde o 8.5. Nenhum piso de densidade, pesquisa ou auditoria foi afrouxado: a release cresce em rigor, não em volume obrigatório. A linha do tempo dessas versões está nos posts do canal sobre Master Rules e o histórico do prompt mestre.

Por que a numeração das etapas aparecia duplicada no Blogger?

A duplicação vinha de duas fontes de número disputando o mesmo item de lista: o marcador automático do navegador e o círculo desenhado com CSS Counter. O list-style:none era aplicado na lista, e não no item, e como o tema do Blogger declara list-style-type:decimal direto no li, a herança da lista não vence essa declaração. A correção está na Seção 8.3, que inverte o alvo do reset e inclui a regra de override de especificidade maior. O padrão de lista numerada está nos posts do canal sobre bloco de etapas com CSS Counter.

O que é a Seção 20.1 de integridade de HTML do post?

A Seção 20.1 é nova na 9.3 e define seis regras absolutas para o arquivo de post: proíbe caractere de markdown antes de tag, proíbe tag de fechamento em elemento vazio, proíbe tags de página, exige o bloco de etapas da Seção 8.3, proíbe elemento vazio sem conteúdo obrigatório e define o fecho exato do arquivo. Em conjunto, elas fecham as quatro portas pelas quais o defeito da 9.2 entrava no post publicado, e cada regra vem com a busca de verificação que comprova o resultado. O padrão está nos posts do canal sobre integridade de HTML em posts do Blogger.

Como o embed de Instagram e TikTok decide a altura do vídeo?

A altura deixou de ser fixa e passou a ser resolvida por uma classe de proporção aplicada no iframe: post_video_9x16, post_video_1x1 e post_video_16x9. O CSS calcula a altura como a largura multiplicada pela proporção, somada à faixa de cabeçalho e rodapé do embed, com a largura limitada a 540 pixels e sem nenhuma altura declarada no HTML. A ordem de decisão é determinística: formato informado pelo usuário, depois endereço com reel ou tv, depois o padrão assumido, que é sinalizado nos metadados. O padrão de embed está nos posts do canal sobre embed de Instagram com classe de proporção.

O que é o Bloco Compartilhado de metadados e o que ele elimina?

É o bloco 0, uma seção única de metadados que concentra tudo que é idêntico entre as redes: palavra-chave, endereço do post, variações de cauda longa, links internos, fontes externas, tags, lista única de hashtags, ideia de vídeo curto, texto alternativo e contexto visual da thumbnail. Cada rede deixa de reescrever essas listas e apenas declara quantos itens consome, sempre na ordem de cima para baixo. Com isso, o Instagram, o Twitter e o YouTube recebem hashtags coerentes entre si. O modelo de publicação em redes está nos posts do canal sobre Bloco Compartilhado de metadados.

O que muda com a entrada do Japão no compliance do prompt?

A 9.3 passa a tratar o Japão como jurisdição explícita em três pontos do prompt: a lista de conformidade legal da Seção 10.2, a matriz regional da Seção 18 e a matriz de jurisdições com fontes oficiais da Seção 29. Entram a APPI, com supervisão da PPC e foco em transferência internacional de dados e notificação de incidentes, e a 景品表示法, com supervisão da CAA, sobre alegações publicitárias enganosas. O painel de qualidade passa a registrar as cinco jurisdições. A matriz de compliance está nos posts do canal sobre APPI e compliance no Japão.

Preciso reescrever meus posts antigos para usar o Master Rules 9.3?

Não é obrigatório, e a migração não deve ser feita às cegas. O caminho seguro é auditado: aplique o bloco de etapas uma vez, converta as listas para ol com a classe de etapas, remova números digitados, corrija fechamento de elemento vazio e markdown solto, reorganize os metadados no bloco compartilhado e reexecute o relatório de qualidade com as linhas novas. Faça uma cópia do HTML antes de qualquer edição e nunca mexa na URL pública. O procedimento de varredura está nos posts do canal sobre migração de HTML no Blogger.

Como o relatório de qualidade da 9.3 prova que a correção existe?

O relatório passou de 19 para 22 linhas, e a nova linha de HTML íntegro exige evidência de quatro checks: zero markdown solto, zero elemento void fechado, zero tag de página e ausência de marcador duplicado nas etapas. O checklist final ganhou cinco itens, e a Seção 16 ganhou quatro substituições obrigatórias que descrevem o conserto quando a busca falha. É esse par, regra mais verificação, que transforma a Seção 20.1 em auditoria em vez de recomendação. O modelo de registro está nos posts do canal sobre relatório de qualidade com evidência.

Erros e soluções: os 6 defeitos que a 9.3 elimina

Os seis defeitos abaixo são os que mais apareceram nos posts gerados pela 9.2. Cada um tem sintoma observável, causa técnica e a regra da 9.3 que o impede, com o passo a passo do conserto. Se algum deles aparecer em um post publicado, o caminho é o mesmo: corrigir o arquivo e a regra, não a página.

Os números aparecem duplicados no post: 1. 1. 2. 2.

Causa: O list-style:none foi aplicado no ol em vez do li, e o tema do Blogger declara list-style-type:decimal diretamente no item, que vence a herança da lista. O marcador automático do navegador continua visível ao lado do círculo desenhado com CSS Counter, e os dois números ocupam a mesma linha do texto.

Solução: Aplique o bloco da Seção 8.3 inteiro: counter-reset na lista, list-style:none e counter-increment no item, e list-style:none também na regra de override .post_wrap ol.post_steps > li. Remova qualquer número digitado no texto do li e confirme no post renderizado que o círculo aparece uma vez só, com o texto sem invadir o número.

Prevenção: Inclua na varredura dos posts antigos a busca por list-style:none aplicado a um ol, que é a assinatura exata do defeito, e acrescente ao checklist final a linha de numeração única. Depois de qualquer atualização de tema, refaça a verificação, porque a regra de override existe para vencer um reset específico do tema atual.

A primeira linha do post mostra um hífen e o texto </link> renderizado

Causa: O arquivo de post é um fragmento colado no editor do Blogger, e a 9.2 só proibia tags de página. Não havia regra para sintaxe markdown nem para fechamento de elemento vazio, e o navegador transformava o fechamento em texto visível e o hífen inicial em item de lista do Markdown, criando um bloco de lista em cima do post.

Solução: Aplique a Seção 20.1: nenhum caractere de markdown antes de tag, nenhuma tag de fechamento em elemento vazio como link, img, br e hr, e fecho do arquivo sem texto residual. Rode as três buscas de verificação, de fechamento de void, de markdown no início de linha e de tag de página, e só publique quando todas retornarem zero ocorrência.

Prevenção: Rode as buscas de verificação no arquivo antes de colar no Blogger e nunca conserte o HTML dentro do editor. Quando o defeito vem da geração, a correção que resolve é na regra do prompt, para o próximo post nascer certo.

O vídeo do Instagram aparece cortado ou com uma faixa preta enorme

Causa: O height fixo de 700 pixels herdado da 9.2 foi mantido junto com a nova classe de proporção. Quando a altura é declarada, o navegador respeita a declaração e ignora o cálculo, e o embed vertical fica cortado enquanto o horizontal ganha uma faixa preta que ocupa metade do bloco.

Solução: Remova o height fixo do iframe e use a classe post_video_9x16, post_video_1x1 ou post_video_16x9 conforme o formato real do vídeo. O CSS calcula a altura a partir da largura, limitada a 540 pixels, somada à faixa de 190 pixels do cabeçalho e do rodapé do embed. Se sobrar ou faltar espaço, ajuste apenas essa faixa.

Prevenção: Registre a origem e o formato do vídeo na linha de relatório de qualidade e sinalize nos metadados quando o formato foi assumido por padrão, em vez de deduzido da URL. Nunca fixe a altura do embed no HTML, porque é o que traz o corte de volta.

Cada rede do post recebe um conjunto diferente de hashtags

Causa: Na 9.2, cada bloco de rede reescrevia a própria lista de tags e hashtags, sem uma fonte única. O Instagram recebia as 30 hashtags do grupo de nicho, o Twitter recebia duas versões diferentes da mesma hashtag e o YouTube recebia um conjunto que não batia com nenhum dos dois, sem que nada no prompt impedisse a divergência.

Solução: Reorganize os metadados no bloco 0 e faça cada rede referenciar quantos itens consome, sempre na ordem de cima para baixo da lista única: YouTube usa as tags completas e de 3 a 5 hashtags, Instagram usa as 30, Twitter de 1 a 2, Facebook de 1 a 3, TikTok de 3 a 5, Pinterest de 2 a 5, LinkedIn de 3 a 5 e Threads apenas a primeira.

Prevenção: Mantenha o nome e o emoji de cada campo idênticos entre posts e acrescente campos novos sempre no fim do bloco da rede. A regra de consumo, e não o gosto do dia, define quantas hashtags saem em cada plataforma.

O post cita a LGPD como se valesse para o público do Japão

Causa: A matriz de conformidade da 9.2 cobria Brasil, Estados Unidos, União Europeia e Reino Unido, e foi tratada como universal. O protocolo proíbe assumir que a lei de um país basta para audiência internacional, e o padrão mais restritivo deveria ser aplicado sempre que há mais de uma jurisdição relevante.

Solução: Atualize a matriz com o Japão, incluindo a APPI sob a supervisão da PPC, com foco no Art. 28 de transferência internacional e na notificação de incidentes, e a 景品表示法 sob a supervisão da CAA, sobre alegações publicitárias. Registre as cinco jurisdições na linha de compliance do relatório e confirme a vigência de cada lei na fonte oficial no dia da auditoria.

Prevenção: Trate a matriz de fontes oficiais como dado volátil, com data de verificação em cada linha, e refaça a checagem antes de cada publicação que cite lei. Matriz desatualizada é pior do que matriz ausente, porque passa falsa segurança.

O texto da etapa invade o círculo do número no celular

Causa: O padding-left de 56 pixels do item foi derrubado por um reset do tema, que zera o espaçamento interno do li. O círculo continua posicionado em left 14, mas o texto passa a começar no zero e invade a área do número desenhado, que é o segundo defeito listado na Seção 8.3.

Solução: Declare a geometria do item em uma regra de especificidade maior, .post_wrap ol.post_steps > li, com list-style:none e padding-left de pelo menos 56 pixels. O seletor de dois níveis é o que vence o reset do tema, e o list-style:none nessa mesma linha impede o marcador de reaparecer quando o tema for atualizado.

Prevenção: Inclua a verificação visual do bloco de etapas no checklist final, conferindo em tela estreita de 360 pixels, e mantenha o padding-left com folga para textos longos em português. Cada mudança no CSS do tema exige refazer essa verificação nos posts que usam o bloco.

Como colocar o Master Rules 9.3 no seu fluxo de publicação

Rode a 9.3 em um post novo antes de migrar a fila inteira. Gere um post real, compare o relatório de qualidade com o do 9.2 e confira no post renderizado se o círculo da etapa aparece uma vez só e se a busca de fechamento de void retorna zero. É o teste mais curto que prova o ganho real da release.

Ver posts do canal sobre o Master Rules  |  Assinar o @CanalQb no YouTube  |  Falar com o CanalQb

Feito com Master Rules Claude v9.3 — este post foi gerado e auditado com a versão 9.3 do prompt mestre do canal, com as 22 linhas do relatório de qualidade verificadas antes da entrega e com a Seção 20.1 conferida por busca de texto no arquivo final.

Três próximos passos que eu recomendo nesta ordem

1. Teste em um post novo. Rode a 9.3 em um post de tutorial e guarde o relatório de qualidade lado a lado com o do 9.2. Compare as 22 linhas, confira a linha de HTML íntegro e abra o post renderizado no tema real para validar o bloco de etapas. É a evidência mais barata de que a mudança vale o custo.
2. Audite o que já está publicado. Rode as buscas da Seção 20.1 em cada HTML publicado e a busca por list-style:none aplicado a um ol. O resultado é a lista de posts que precisam de correção, não uma sensação difusa de que algo estava errado. Em geral, os posts com listas numeradas e com código são os que mais acumulam defeito.
3. Padronize o registro de proveniência. Crie um modelo de relatório de qualidade com as linhas de HTML íntegro, origem do vídeo e Bloco Compartilhado fixas no topo. Quando o registro existe por padrão, a checagem deixa de depender de memória e vira processo, que é o único jeito de ela sobreviver a meses de publicação em ritmo alto.

Fontes e referências consultadas

Todo dado normativo, de CSS e de formato citado neste post foi conferido em fonte oficial ou em documentação primária, com a data de verificação registrada. A regra aqui é a mesma que a 9.3 aplica ao conteúdo: link para a fonte primária, data da consulta e o que exatamente foi verificado em cada uma.

• MDN Web Docs, pseudo-elemento ::marker. Disponibilidade do marcador de item de lista e comportamento do ::marker entre navegadores, base da ressalva sobre recurso de disponibilidade limitada usado no bloco de etapas. https://developer.mozilla.org/pt-BR/docs/Web/CSS/::marker
• MDN Web Docs, propriedade list-style-type. Definição do marcador automático de listas ordenadas e a razão de a declaração no item prevalecer sobre a herança da lista. https://developer.mozilla.org/pt-BR/docs/Web/CSS/list-style-type
• MDN Web Docs, Using CSS counters. Uso de counter-reset, counter-increment e counter() para gerar numeração sem número digitado no HTML. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_counter_modules/Using_CSS_counters
• WHATWG, HTML Living Standard, elementos void. Regra categórica de que elementos vazios não devem receber tag de fechamento, base da segunda regra da Seção 20.1. https://html.spec.whatwg.org/multipage/syntax.html#void-elements
• PPC, Personal Information Protection Commission, alteração da Lei de Proteção de Dados Pessoais. Página oficial da autoridade japonesa de proteção de dados, com a alteração da APPI aprovada em 2026, que obriga a reverificar a vigência da norma a cada auditoria. https://www.ppc.go.jp/personalinfo/legal/r8kaiseihogohou/
• CAA, Consumer Affairs Agency, Representations and Fair Labeling. Página oficial da autoridade japonesa de defesa do consumidor sobre a Lei de Representações Injustificáveis, que trata de alegações publicitárias enganosas. https://www.caa.go.jp/policies/policy/representation/fair_labeling/
• e-Gov, Lei de Representações Injustificáveis, Lei nº 134 de 1968. Texto oficial japonês da 景品表示法, consultado como fonte primária da obrigação de alegação publicitária. https://elaws.jp/view/337AC0000000134
• schema.org, BlogPosting. Definição do tipo usado no schema do post técnico, com os campos de autoria, data e licensed required pelo prompt. https://schema.org/BlogPosting
• schema.org, FAQPage. Definição do tipo usado no schema separado do FAQ, com pergunta e resposta aceitas. https://schema.org/FAQPage
• Google Search Central, Article structured data. Orientação oficial de uso de Article, BlogPosting e FAQPage em página de conteúdo, usada para conferir os campos do JSON-LD entregue neste post. https://developers.google.com/search/docs/appearance/structured-data/article

Data de verificação das fontes: 05/11/2026. Links podem mudar de endereço em organigramas públicos; se algum deles falhar, o texto do post indica a lei, o documento ou a seção do schema.org que precisa ser procurada, para que a conferência não dependa do link e sim da fonte primária.

Feito com Master Rules Claude v9.3 — a versão do prompt que rege este post. O número de versão, a data e a lista de fontes ficam registrados no arquivo de metadados que acompanha a entrega.

ddddddddddddddddddddddd