Aqui está a lição mais meta do curso inteiro: esta própria página foi feita pelo visual-teach. Cada lição que você leu — o visual neutro-quente, o toggle de modo escuro, os demos ao vivo, a camada Simples-depois-Técnico, as versões em inglês e em português do Brasil — saiu de um motor que transforma um tópico num curso HTML interativo e autocontido. E o motor não rodou sozinho: o loop que você vem aprendendo trata um curso visual-teach finalizado como um entregável — o seu Course Gate — para que a mesma disciplina LEARN → ANALYZE → EXECUTE → VERIFY que entrega código também entregue o ensino sobre ele. Esta lição abre o motor e deixa você operar suas partes.
A maioria das ferramentas que "explicam" algo te entrega um paredão de texto. O visual-teach faz algo diferente: você dá um tópico a ele, e ele produz um pequeno site que ensina aquele tópico — um conjunto de páginas HTML que abrem com um duplo-clique, não precisam de internet e deixam o leitor cutucar as ideias em vez de só ler sobre elas.
Cada página é feita pela mesma receita. Há uma camada em linguagem simples e amigável que qualquer pessoa consegue acompanhar, e uma camada técnica dobrada atrás de um toggle para o leitor que quer o detalhe exato. Há diagramas desenhados como vetores, para que fiquem nítidos e se recolorizem sozinhos no modo escuro. Há demos ao vivo — pequenos simuladores, animações, sliders, slide decks — que transformam uma frase em algo que você opera. E o conjunto todo é entregue em dois idiomas por padrão: inglês e português do Brasil.
O truque que mantém tudo junto é um único shell compartilhado. A barra do topo, a navegação lateral, as cores, as fontes, o botão de modo escuro — tudo isso é byte a byte idêntico em toda página. Só o meio, a lição em si, muda. Assim um curso de 14 lições parece um produto único e consistente, não 14 páginas feitas à mão que vão se distanciando.
Pense nisso como uma revista impressa com um estilo editorial rígido. Todo artigo fica na mesma grade, mesmo cabeçalho, mesmas fontes, mesma mobília de página — então o leitor nunca precisa reaprender a ler. Os autores só preenchem o poço do artigo; o template garante o resto. O visual-teach é esse estilo editorial, só que os "artigos" são interativos e o template é imposto em código. Onde a analogia quebra: o template de uma revista é uma sugestão que um designer pode sobrescrever discretamente; aqui o shell é copiado ao pé da letra e qualquer divergência entre duas páginas é tratada como defeito.
Toda página é um único arquivo .html com CSS inline, SVG inline e JS puro inline — zero requisições externas. Sem CDN, sem web font, sem <img>, sem raster data:. É isso que torna um curso abrível a partir de file://, enviável como anexo de e-mail, arquivável e seguro de ler num avião. O custo é disciplina: nada de framework, nada de passo de build, e cada diagrama desenhado como vetor à mão.
Um curso é um hub (index.html), uma pasta de lições (lessons/0001…), uma página de galeria opcional e os exemplares de demo brutos. O inglês vive na raiz; cada tradução espelha a árvore inteira sob seu código (pt/index.html, pt/lessons/…) com os mesmos nomes de arquivo. O seletor .vc-lang lista exatamente os idiomas que existem, e nunca aponta para um link morto.
O visual-teach destila duas coisas ao mesmo tempo: a lição narrativa (lida uma vez) e um documento de referência durável (retornado vez após vez — folhas de cola, glossários, fluxogramas). O arquivo de pedagogia chama o documento de referência de "a metade durável" — a parte que a maioria do ensino esquece. As páginas por lição deste curso funcionam também como essa referência.
Você passou doze lições num loop que entrega trabalho: ele aprende o estado real, analisa a lacuna, executa uma unidade delimitada e verifica o resultado num boundary real antes de decidir o que fazer em seguida. O visual-teach é onde esse loop paga um segundo dividendo. Quando um trabalho fica pronto, o loop não te entrega só o artefato — ele também pode te entregar o ensino sobre ele, gerado como um curso visual-teach completo. Esse entregável é o Course Gate do loop.
Então este curso não é um projeto paralelo aparafusado no loop. Ele é uma saída do loop. O mesmo motor que provou que o código funciona também produziu a lição que explica como ele funciona — e é exatamente por isso que "o motor que construiu este curso" é mais do que um slogan.
Pense num laboratório de pesquisa. O experimento é o trabalho; o artigo publicado é como o conhecimento sobrevive além das pessoas que o conduziram. Um laboratório que nunca registra seus resultados os perde. O Course Gate é o passo de registro tornado automático — o loop termina o experimento e arquiva o artigo na mesma execução. Onde quebra: um artigo é prosa somente-leitura; um curso visual-teach é interativo e re-testável, mais perto de um artigo que você pode rodar.
No vocabulário do loop um gate é uma verificação que você não pode pular. O Proof Gate prova que o artefato funciona num boundary real; o Course Gate prova que o conhecimento foi capturado e é ensinável. Ambos são entregáveis da mesma execução, então "a gente entregou mas nunca documentou" deixa de ser possível por construção.
Gerar o curso não é uma tarefa braçal humana. Sob o loop, um executor constrói cada lição e um validador independente a confere contra a meta — o único papel do humano é a observabilidade (ler o log, a revisão, o status). O Course Gate herda exatamente isso: um curso é produzido e verificado sem uma pessoa escrevendo HTML à mão.
Antes das partes, o todo. Um curso visual-teach são quatro tipos de coisa conectados. Leia a folha de cima a baixo; cada caixa diz o que é e onde mora no disco.
pt/.O hub (index.html) é construído a partir de assets/index-template.html e é a única página que agrupa lições por Módulo. As lições são construídas a partir de assets/lesson-template.html. Os exemplares de demo sob assets/demos/NN-slug.html não são entregues ao leitor — são a fonte de onde você extrai markup, CSS e JS ao preencher uma lição. A galeria é um índice opcional dos demos ao vivo.
PT-BR não é um toggle de tradução dentro de um arquivo; é uma árvore de diretórios paralela. pt/lessons/0013-visual-teach.html é o mesmo arquivo que o inglês com <html lang="pt-BR">, o .cur trocado em .vc-lang, a profundidade dos links relativos corrigida, e só a prosa traduzida — nunca o código, os comandos ou os identificadores.
A regra mais importante do motor também é a mais simples: as partes da página que não são a lição são copiadas exatamente iguais em toda página. Os tokens de cor, os estilos base, a step-bar do topo com seu botão de modo escuro e seletor de idioma, a navegação lateral, a wizard nav de baixo, o rodapé e o JavaScript compartilhado — tudo isso é um bloco de bytes, repetido ao pé da letra.
Só dois espaços são próprios de uma lição: um lugar para o CSS extra da lição (a estilização dos seus demos) e um lugar para o JavaScript da lição (a fiação desses demos). Todo o resto é proibido. Se você precisasse de um novo componente compartilhado, você o adicionaria ao template para que todas as páginas o recebessem — você nunca o estilizaria numa página só.
Pense numa rede de cafés. Entre em qualquer filial e o balcão, o cardápio na parede, os tamanhos de copo e a sinalização são idênticos — só as ofertas do dia mudam. Você pede sem pensar porque o layout nunca se mexe. O shell é essa montagem fixa; a lição é a oferta do dia. Onde quebra: um gerente de café pode repintar uma parede; aqui a montagem é imposta byte a byte, e duas filiais que diferissem seriam um bug.
assets/lesson-template.html — os dois espaços, ao pé da letra
/* ===== BEGIN SHARED SHELL (byte-identical across all pages) ===== */ /* … tokens, base CSS, stepbar, nav … copy verbatim, never edit per page … */ /* ===== END SHARED SHELL ===== */ /* ===== LESSON-SPECIFIC (only this lesson's demo CSS goes here) ===== */ .d05_btn { background: var(--btn-bg); /* uses shared tokens → dark mode for free */ } /* ===== END LESSON-SPECIFIC ===== */
Se cada página escreve seu próprio cabeçalho à mão, as páginas divergem: um padding aqui, uma cor ali, um link de nav desatualizado em outro lugar. Ao exigir o shell como um bloco copiado, um curso de qualquer tamanho tem exatamente um cabeçalho, um rodapé, uma nav, um conjunto de tokens e um motor de tema. Auditar é trivial — faça o diff de duas páginas quaisquer e só o corpo da lição e seu CSS/JS devem diferir.
O shell entrega dois blocos :root: a paleta clara e um override :root[data-theme="dark"] que redefine os mesmos nomes de variável. Como todo componente (e os demos desta lição) lê var(--token) e nunca um hex chumbado, virar um atributo no <html> re-tematiza a página inteira. Um script de pré-pintura no <head> aplica o tema salvo ou o preferido do SO antes da primeira pintura, então não há flash claro.
Cada demo extraído prefixa todo id, classe, marker de SVG e busca no DOM com uma tag única (esta lição usa d05_, d07_, d08_, d09_, d10_, d15_, d19_). É isso que permite cinco ou sete demos independentes coexistirem numa página sem uma única colisão.
Como um tópico de fato vira um curso finalizado? Clique por este deck para ver o formato disso em dois minutos — uma ideia por slide. Depois, os dois próximos demos deixam você assistir o pipeline rodar e conduzir uma única lição por ele.
Um slide deck é o tipo de demo certo quando o trabalho é "captar o formato de um tópico inteiro antes do detalhe". Cada slide carrega exatamente uma ideia em tipografia grande, então o leitor nunca equilibra dois pensamentos de uma vez. O motor é uma função go(index) limitada a [0, n-1] que alterna o slide atual, preenche a barra de progresso, sincroniza a trilha de pontos e desabilita Anterior/Próximo nas pontas — setas do teclado incluídas, com o movimento respeitando prefers-reduced-motion.
Scaffold copia o template (shell intacto, corpo um marcador). Fill substitui o marcador, adiciona o CSS do demo ao único espaço de CSS e a fiação ao único espaço de JS. Mirror produz o gêmeo pt/. Verify é o Proof Gate para o ensino: abra o arquivo, faça o diff do shell, exercite os demos, resolva cada link — nunca afirme "deveria funcionar".
Um deck te diz os passos; uma animação mostra a ordem. Aperte Play para mandar uma lição pelo pipeline, Step para avançar um momento, ou Reset para recomeçar. Observe o token viajar: do scaffold ao fill, depois um espelho se abre para o gêmeo PT, e então o verify o prova antes de entregar.
Pronto. Aperte Reproduzir ou Avançar para mandar uma lição pelo pipeline.
Cinco fases ordenadas — scaffold, fill, mirror, verify, ship — movem um motor em JS puro. Cada passo interpola a posição do token com requestAnimationFrame e uma curva ease-in-out; o momento do espelho gera um segundo token que se abre para baixo até o gêmeo PT. Não há <video>, nem GIF, nem biblioteca, então ele avança, reproduz e reinicia de forma determinística e respeita prefers-reduced-motion saltando em vez de interpolar.
Um diagrama estático responde "o que está conectado". Esta animação responde "em que ordem, e onde o gêmeo PT se ramifica". Recorra à animação só quando a sequência é a lição — caso contrário um estático com rótulos custa menos e lê mais rápido.
Agora você conduz. Uma lição percorre um conjunto fixo de estados, e o ponto todo é que você não pode pular: você não pode entregar uma lição que nunca foi verificada, e uma página que falha na verificação volta para ser corrigida, não para frente. Aperte um evento e observe o estado destacado se mover; os botões ficam cinza no instante em que um movimento não é permitido de onde você está.
O nó preenchido em clay é onde esta lição está agora. Nós esmaecidos são inalcançáveis daqui.
Estado atual
SCAFFOLD
Uma cópia do template com o shell intacto e um marcador FILL onde o corpo entra. Nada ensinado ainda.
Transições permitidas
Log de eventos
Tudo que o protótipo faz é movido por esta tabela. Os botões a leem para decidir o que habilitar; apertar um consulta machine[state][event] e move para lá. Os movimentos ilegais — entregar antes de verificar, espelhar antes de preencher — simplesmente não existem na tabela, então não podem ser feitos. VERIFIED só pode ship; um verify que falha roteia para NEEDSFIX, cujo único caminho à frente é voltar para FILLED para ser repreenchida e reverificada. Esse é o Proof Gate expresso como uma máquina de estados.
const machine = { SCAFFOLD: { fill: 'FILLED' }, FILLED: { mirror: 'MIRRORED' }, MIRRORED: { verify: 'VERIFIED', fail: 'NEEDSFIX' }, NEEDSFIX: { refill: 'FILLED' }, VERIFIED: { ship: 'SHIPPED' }, SHIPPED: {} // terminal — the course gate is satisfied };
O que torna uma lição viva em vez de uma página de texto é o demo. O visual-teach entrega 20 tipos de demo prontos — pequenos widgets autocontidos que você copia e refia. São uma paleta, não uma checklist: uma ideia simples pode usar um; uma lição rica (como esta) empilha sete. Eles se dividem em um punhado de famílias pelo trabalho de ensino que cada um faz.
E aqui está a própria família "ajustar toggles", tornada ao vivo — o tipo de demo 19. Estes são justamente os interruptores que decidem com o que um curso é entregue. Vire-os e observe os avisos: algumas escolhas dependem de outras.
Status do build
Para cada momento de uma lição você nomeia o trabalho de ensino em uma frase — explicar como funciona, comparar opções, mostrar um processo no tempo, ler estado, ensinar pela falha, resumir, deixar conduzir, ajustar controles — liste dois ou três tipos candidatos, escolha o que melhor encaixa com uma razão de uma linha e nomeie o vice que você rejeitou. Um curso completo exercita a maioria ou todos os vinte; reusar um widget a cada momento é um cheiro ruim.
Os interruptores acima são o tipo de demo 19. Cada toggle lê uma pequena tabela de regras: desligar autocontido permite um CDN mas quebra o uso offline; desligar o espelho PT deixa o link de idioma órfão; desligar os demos rebaixa a camada de habilidades para somente-conhecimento. O painel revela essas consequências ao vivo — exatamente o que este tipo de demo ensina: um toggle nunca é livre de efeitos colaterais.
Todo diagrama que você viu neste curso é desenhado à mão como um SVG inline — formas vetoriais escritas na página, nunca um arquivo de imagem. É por isso que eles ficam nítidos como navalha em qualquer tamanho e por que se recolorizam quando você vira para o modo escuro. Há uma paleta rígida para que leiam tanto no marfim claro quanto no fundo quase-preto. Toque numa amostra abaixo para destacar uma regra dessa paleta no exemplo trabalhado.
Pense num diagrama de vista explodida num manual de móveis: cada painel e parafuso desenhado no lugar com uma linha até o nome dele. Você não o lê — você vê onde cada peça vai. Uma folha SVG é isso, mas também obedece a uma disciplina de cor para que nunca desapareça numa página escura.
Nenhuma amostra selecionada não esmaece nada — escolha uma para destacá-la, ou "Mostrar tudo" para reiniciar.
var(), no SVGAs custom properties do CSS não resolvem de forma confiável dentro de atributos de apresentação do SVG (fill="…", stroke="…") entre renderizadores, então os diagramas usam os hexes literais do meio da paleta — clay #D97757, olive #788C5D, sky #5C7CA3, rust #B04A3F, gray #87867F. Cada um lê tanto na superfície marfim quanto na quase-preta. As caixas são fill="none" para que a superfície tematizada da página apareça atrás; o único preenchimento branco permitido é um glifo sobre um chip de cor saturada.
Todo <svg> carrega role="img" e um aria-label que lê o diagrama inteiro como uma frase, então um usuário de leitor de tela recebe o mesmo conteúdo. Um único <marker> de seta é definido uma vez por SVG e reusado. Onde um diagrama anima, ele honra prefers-reduced-motion.
O visual neutro-quente em que você vem lendo não é improvisado por página — é um pequeno design system: um conjunto fixo de cores e tamanhos nomeados (os tokens) dos quais toda página bebe. Ninguém escreve um hex cru como #D97757 na lição; escreve o nome --clay. Mude o valor do nome uma vez e todo botão, título e borda se atualizam juntos — e esse é exatamente o mecanismo que torna o modo escuro uma virada de uma linha.
Pense numa cozinha com potes rotulados. Ninguém pega de um saco sem rótulo torcendo para que seja açúcar — vai ao pote que diz "Açúcar". Tokens são os rótulos; a regra é sempre vá ao pote, nunca ao saco cru. Onde quebra: o conteúdo de um pote é fixo, mas o valor de um token é trocado por inteiro pelo tema — o mesmo rótulo, um açúcar diferente no escuro.
Agora torne concreto. Escolha um intuito e um tamanho — o botão de preview é estilizado só a partir de tokens, e o readout de código mostra os tokens exatos em jogo. É exatamente assim que um componente orientado a tokens se comporta: troque os valores, o componente re-renderiza, sem CSS novo.
Intuito
Tamanho
.btn { }
Duas camadas importam. Tokens primitivos são valores crus (--clay: #D97757). Tokens semânticos os apelidam por papel (--btn-bg: var(--clay)). Os componentes consomem só os semânticos, então re-tematizar significa reapontar um alias, nunca tocar no componente. O botão de preview não carrega classe por intuito — cada controle escreve as custom properties semânticas no seu style inline, e uma regra .d05_dsbtn as lê com var().
/* primitive scale */ --clay: #D97757; --clay-d: #B85C3E; --olive: #788C5D; --rust: #B04A3F; /* dark mode redefines the SAME names → every var() flips */ :root[data-theme="dark"] { --clay: #E08A6B; --ivory: #1A1917; /* … */ }
Uma única lição precisa servir a dois leitores muito diferentes: alguém encontrando a ideia pela primeira vez, e alguém que quer o comando exato e o caso de borda. O visual-teach não escolhe um — ele empilha os dois. A camada Simples está sempre visível e deve contar a história inteira por conta própria. A camada Técnica fica dobrada atrás de um toggle, então o detalhe preciso está a um clique para o leitor que opta por ele — e invisível para quem não opta. Todo botão "Mostrar o detalhe técnico" nesta página é esse mecanismo. (Há também um controle "Expandir tudo" no topo que os abre juntos.)
Pense nas etiquetas de museu. O grande texto de parede dá a todos a história em uma frase; o cartãozinho ao lado da peça adiciona a data, a técnica e a procedência para quem quiser. Ninguém é forçado a ler o cartãozinho, e ninguém que o queira é privado dele. Onde quebra: um museu imprime os dois estaticamente; aqui o cartãozinho é recolhível, então o leitor casual nem se distrai com ele.
A regra que o motor impõe: oculte todo painel técnico e a camada Simples ainda precisa fazer sentido e alcançar a única vitória da lição. Se não alcança, a camada Simples está incompleta. Introduza o termo depois da ideia — "a coisa que decide para onde sua requisição vai … isso se chama load balancer" — para que o jargão seja conquistado, não presumido. Frases curtas, uma ideia cada, segunda pessoa, presente.
Cada toggle é um <button class="tech-toggle" aria-expanded> cujo irmão seguinte é um painel .technical; clicar vira aria-expanded e alterna .open. O #expandAll no nível da página abre ou fecha todos de uma vez e fica em sincronia. Essa fiação vive no JS compartilhado, então toda lição a ganha de graça — esta lição não escreveu uma linha dela.
Juntando os fios, eis o contrato que todo curso visual-teach cumpre sem ninguém pedir. Ele abre com um duplo-clique sem internet. Ele carrega o shell byte a byte idêntico em toda página. O modo escuro funciona e lembra sua escolha. Ele entrega inglês e português do Brasil juntos — nunca inglês com links PT mortos. Todo diagrama é vetor seguro no escuro. Toda lição começa pela camada Simples e mostra código ou comandos reais com um jeito de chegar até eles. E não há nenhuma atribuição a IA em lugar algum — o artefato se sustenta sozinho.
Pense no kit de segurança padrão de um carro. Você não marca uma caixinha para cintos, airbags e espelhos — eles vêm de fábrica por lei em todo modelo. Esses padrões são o kit padrão do visual-teach: não extras opcionais que você lembra de adicionar, mas a base sem a qual um curso não pode ser entregue.
Nenhuma dessas escolhas é decoração. O visual-teach é construído sobre uma teoria específica de como as pessoas de fato aprendem, e três ideias movem quase toda decisão na página.
Primeiro, aprender precisa de três coisas diferentes: conhecimento (fatos, tirados de fontes confiáveis, nunca inventados), habilidades (construídas só fazendo — é por isso que os demos existem) e sabedoria (julgamento, conquistado pela prática real numa comunidade). Uma lição pondera essas coisas de modo diferente dependendo do tópico.
Segundo, há uma diferença entre fluência e força de armazenamento. Reler algo faz parecer familiar — isso é fluência, e ela esvanece rápido. A memória durável — a força de armazenamento — é construída por recuperação (lembrar a partir de uma página em branco), espaçamento (revisitar ao longo do tempo) e intercalação (misturar ideias relacionadas). Essa é toda a razão de este curso ensinar cada ideia central de várias formas — uma analogia, um diagrama, um demo ao vivo, um exemplo trabalhado e uma verificação — e retestá-la.
Terceiro, a zona de desenvolvimento proximal: encontre o leitor logo além do que ele já sabe — nem tão fácil que entedie, nem tão difícil que sobrecarregue. Para conhecimento puro, a dificuldade é a inimiga (ela devora a memória de trabalho que você precisa para entender); para habilidades, um pouco de dificuldade é a ferramenta que fixa.
Pense em aprender a dirigir. Ler o manual é conhecimento; parece progresso, mas você não dirige a partir dele. A habilidade vem só do tempo ao volante com feedback instantâneo — saiu da faixa, o instrutor fala agora, não semana que vem. E um bom instrutor te mantém logo além do confortável: a lição de hoje é um pouco mais difícil que a de ontem, nunca uma rodovia no primeiro dia.
Então aqui está a própria prática de recuperação — a verificação rápida do tipo de demo 15. Lembre primeiro, depois revele. Escolha a resposta em que você acredita antes de clicar; o feedback é imediato. (Toda opção tem o mesmo comprimento, então a formatação não entrega nada.)
Q1 Por que o curso ensina uma ideia de várias formas diferentes?
Q2 O que a camada Simples precisa fazer inteiramente por si só?
Q3 Para conhecimento puro (não habilidade), a dificuldade ao aprender é…
Mini-glossário
Toda opção num quiz tem a mesma contagem de palavras — idealmente a mesma contagem de caracteres — para que a opção mais longa e mais qualificada nunca entregue a resposta. Os distratores são plausíveis e batem com um equívoco real, o que ensina mais do que uma opção obviamente errada. O feedback é imediato (o loop apertado que as habilidades precisam), e "Tentar de novo" deixa o leitor espaçar a recuperação.
A divisão importa: na camada de conhecimento, a dificuldade é removida (prosa clara, uma ideia por frase) porque a memória de trabalho é minúscula e você quer gastá-la entendendo. Na camada de habilidades — os demos e o quiz — um pouco de dificuldade desejável (lembrar antes de revelar, conduzir a máquina você mesmo) é exatamente o que converte fluência em força de armazenamento.
Tudo nesta lição veio de um punhado de arquivos reais. Aqui está onde eles moram e como abri-los, para que o motor não seja uma caixa-preta.
~/.claude/skills/visual-teach/ — o motor
# the one shell every page copies, byte-for-byte assets/lesson-template.html # BEGIN/END SHARED SHELL + two fill slots assets/index-template.html # the hub, grouped by Module # the 20 copyable demo exemplars (lift markup + CSS + JS) assets/demos/05-design-system.html assets/demos/07-prototype-animation.html assets/demos/08-prototype-interaction.html assets/demos/09-slide-deck.html assets/demos/10-svg-illustrations.html assets/demos/19-editor-feature-flags.html assets/demos/15-research-concept-explainer.html # the four reference files that govern the build references/build-guide.md # shell, tokens, nav, i18n, the verify checklist references/demo-catalog.md # the 20 types + the debate procedure references/svg-patterns.md # dark-safe inline-SVG rules references/teaching-language.md # Simple-layer + analogy + quiz design references/pedagogy.md # knowledge/skills/wisdom · fluency vs storage · ZPD
# every reference and demo exemplar ls ~/.claude/skills/visual-teach/references/ ls ~/.claude/skills/visual-teach/assets/demos/ # the two fill slots in the shared shell grep -n "LESSON-SPECIFIC" ~/.claude/skills/visual-teach/assets/lesson-template.html
# the hub and a lesson — open from file://, no server needed open ~/courses/loop-engineering/index.html open ~/courses/loop-engineering/lessons/0013-visual-teach.html # confirm zero external requests (no http/https/cdn references) grep -nE "https?://(?!.*w3\.org)" ~/courses/loop-engineering/lessons/0013-visual-teach.html || echo "self-contained ✓"
Faça o scaffold a partir de lesson-template.html (shell intacto, corpo um marcador <!-- FILL -->), substitua o marcador pelo conteúdo, jogue o CSS de cada demo extraído no único espaço de CSS LESSON-SPECIFIC e a fiação dele no único espaço de JS LESSON-SPECIFIC, dê namespace a todo id/classe/marker por demo, depois espelhe em pt/ e verifique abrindo os dois. Esse é precisamente o pipeline que você assistiu e conduziu acima.