--- name: showcase description: Showcase — Padrão Canônico de Keynote Interativo (Skill Global) allowed-tools: Read, Glob, Grep, Bash --- --- # Showcase — Padrão Canônico de Keynote Interativo (Skill Global) Define e **protege** o formato de showcase do ecossistema IconsAI. **O padrão canônico está DEFINIDO NESTA SKILL** (construções determinísticas abaixo) — NUNCA numa URL viva. (O `aiFuture` é só o 1º caso do formato; já teve logo errado, então **não serve de referência a copiar**.) Toda página showcase nova DEVE nascer com este padrão aplicado — não é opcional, não é decorativo, não se improvisa. > Origem: criada após o tugaai nascer sem o chrome canônico; endurecida depois de um showcase ir ao ar com slides cortando conteúdo. O padrão é um **gate ativo**, não memória passiva. Ver [[feedback-golden-rule-components]] e [[feedback-continuous-learning-gate]]. **Cada regra abaixo aparece UMA vez.** Não duplicar entre seções. --- ## 0. WORKFLOW — ciclo de vida do showcase (CADA FASE TEM COMANDO) > **Showcase não é só spec — é pipeline.** Cada fase abaixo tem um comando concreto e um gate que bloqueia a próxima. Nenhuma fase é opcional. ``` SCAFFOLD → DEVELOP → AUDIT-CSS → AUDIT-FIT → BUILD → DEPLOY → VERIFY ``` | Fase | Comando | Gate (bloqueia se falhar) | |---|---|---| | **SCAFFOLD** | Copiar verbatim: `SlideFrame.tsx` (§6.2.2), `_shared.tsx` Shell (§6.2.3), CSS base (§6.2.1) | Arquivos existem e são idênticos ao canônico | | **DEVELOP** | `npm run dev` — criar slides com `slidePlan` (§6.0) | Cada slide tem `slidePlan` preenchido | | **AUDIT-CSS** | `bash audit-css.sh` (§6.8) | 0 FAIL (padrões proibidos §6.9 ausentes) | | **AUDIT-FIT** | `node scripts/audit-fit.mjs` (§6.7) | `cut ≤ 2px` E `fillArea > 0.75` em TODOS os slides × viewports | | **BUILD** | `npm run build` (inclui `prebuild` = audit-css + valida-skill) | `tsc --noEmit` + `next build` clean | | **DEPLOY** | push to main → GitHub Actions CI/CD | HTML 200 + chunks 200 | | **VERIFY** | `check-canonical-components.sh --showcase` (§17 CLAUDE.md) | Componentes canônicos presentes no HTML | **AUDIT-CSS bloqueia BUILD.** `prebuild` em `package.json` roda `bash audit-css.sh && bash valida-skill.sh` — se qualquer um falhar, `npm run build` nem começa. **AUDIT-FIT bloqueia DEPLOY.** O harness headless (§6.7) mede fillArea e cut em 6 viewports. Não se faz deploy com slide cortado ou palco vazio. **Atualização sistemática — PROPAGAÇÃO OBRIGATÓRIA (LEI):** Quando esta skill muda, **a mudança NÃO ESTÁ CONCLUÍDA até o código real de TODOS os showcases estar em conformidade.** Editar o SKILL.md sem propagar = letra morta. O ciclo completo é: 1. **Editar** esta skill (SKILL.md) 2. **Auditar** cada showcase contra a skill: ```bash # Para cada repo showcase: grep -n 'max(9vh\|max(11vh' app/globals.css # F15: deve ser clamp(), não max() grep -n 'width:52px\|width: 52px' app/globals.css # F16: setas devem ser 44px grep -n 'max-height:700px\|max-height: 700px' app/globals.css # deve existir ``` 3. **Corrigir** todas as divergências no código real (globals.css, audit-css.sh) 4. **Rodar** `bash audit-css.sh` em cada repo — 0 FAIL 5. **Commit + push** com as correcções 6. **Sync mirrors** Obsidian **Sem os passos 2-5, a edição da skill é NULA.** A skill não é um documento isolado — é um gate que só funciona se o código o implementa. ### 0.1 TRIGGERS DE AUDITORIA — skills que o showcase DEVE chamar > **Cada fase do pipeline acima dispara skills de auditoria do ecossistema.** Os triggers abaixo são OBRIGATÓRIOS — não são sugestões. Se uma skill de auditoria falhar, a fase correspondente falha e bloqueia a próxima. | Fase do Pipeline | Skill a disparar | O que verifica | Gate | |---|---|---|---| | **DEVELOP** (pós) | `/skill-design-audit` | Consistência visual, tokens, espaçamento, tipografia, cores do Design System | Nenhum desvio de design crítico | | **DEVELOP** (pós) | `/skill-frontend-normalization` | Next.js patterns, imports, estrutura de componentes, server/client boundaries | 0 violações de normalização | | **DEVELOP** (pós) | `/skill-node-quality` | ESLint clean, Prettier formatado, sem `any`, sem `console.log` em prod | `eslint . --max-warnings 0` + `prettier --check .` | | **AUDIT-CSS** (junto) | `/skill-codebase-sanitizer` | Código morto, imports fantasma, arquivos órfãos, dependências não usadas | 0 artefatos mortos | | **PRE-BUILD** | `/skill-dependency-governance` | Lockfile integrity, zero deps extras, SBOM limpo, sem vulnerabilidades | `npm audit --audit-level=moderate` clean | | **PRE-BUILD** | `/secrets-hygiene` | Sem tokens, chaves ou credenciais no código ou em `.env` commitado | 0 segredos expostos | | **PRE-DEPLOY** | `/quality-finalizer` | Orquestrador — roda lint, types, testes, coverage mínimo, dead code | Todos os checks green | | **PRE-DEPLOY** | `/security-finalizer` | Orquestrador — headers, CSP, deps, secrets, injection surface | Todos os checks green | | **VERIFY** (pós) | `/finalizar` | Master orchestrator — roda quality-finalizer + security-finalizer + validações finais | Gate final antes de considerar concluído | **Ordem de execução dentro de cada fase:** 1. Skills individuais rodam em paralelo dentro da mesma fase 2. Orchestrators (`quality-finalizer`, `security-finalizer`) rodam DEPOIS das skills individuais 3. `/finalizar` roda por ÚLTIMO — é o gate final **Integração no `package.json`:** ```json { "scripts": { "audit:css": "bash audit-css.sh", "audit:design": "echo 'Trigger: /skill-design-audit'", "audit:quality": "echo 'Trigger: /skill-node-quality'", "audit:sanitize": "echo 'Trigger: /skill-codebase-sanitizer'", "audit:deps": "echo 'Trigger: /skill-dependency-governance'", "audit:secrets": "echo 'Trigger: /secrets-hygiene'", "audit:all": "npm run audit:css && npm run audit:design && npm run audit:quality && npm run audit:sanitize && npm run audit:deps && npm run audit:secrets", "prebuild": "bash audit-css.sh && bash valida-skill.sh" } } ``` **Regra dura:** se QUALQUER skill de auditoria reportar falha crítica, o deploy NÃO prossegue. Corrigir primeiro, auditar novamente, só então avançar. ### 0.2 PRE-COMMIT/DEPLOY VALIDATION GATE — verificar TODAS as regras ANTES de commit e deploy (LEI) > **Causa-raiz de retrabalho recorrente:** alterações CSS/TSX vão para produção com violações de showcase (conteúdo cortado pelo footer, palco vazio, elementos fora das faixas) porque o agente comita e deploya sem verificar contra as regras canónicas. O build passa (é só TypeScript/webpack), o deploy passa (é só rsync/restart), mas o CONTEÚDO está errado. **O build e o deploy não verificam regras visuais — o agente TEM de verificar antes.** **REGRA (LEI — INEGOCIÁVEL):** Antes de **CADA commit + deploy** de alteração visual (CSS, TSX de slides, content.ts), o agente DEVE executar a seguinte checklist de verificação. Se QUALQUER item falhar, **corrigir PRIMEIRO, verificar de novo, só então commitar e deployar**. Commitar/deployar sem esta verificação = PROIBIDO. **Checklist PRE-COMMIT/DEPLOY (executar na ordem):** 1. **`bash audit-css.sh`** — 0 FAIL (padrões proibidos §6.9 ausentes). Se falhar, corrigir e repetir. 2. **`bash valida-skill.sh`** — logo canónico, floating button, emoji gate. Se falhar, corrigir e repetir. **Escopo do `valida-skill.sh` (ordem do dono, 28/09/2026):** as verificações de logo leem `app/globals.css` e `app/**/*.tsx` e só valem para showcase ou site Next.js com `app/` na raiz. Repositório que não é showcase (app Python, backend, front em subpasta) não recebe as linhas de logo: o logo não é regra ali. Fica só o gate de emoji, apontado para as pastas reais do front. Copiar este script inteiro para um repositório assim reprova todo commit com `FALHA: span logo-i ausente`. Medido no `youtube`: o hook foi instalado em 19/09/2026 com a cópia do `superadmin` (H-SKILL-01), e em 28/09/2026 nenhum commit passava. Quem propaga o gate adapta a cópia ao repositório de destino. Não copia byte a byte. 3. **`npm run build`** — TypeScript + Next.js clean. Se falhar, corrigir e repetir. 4. **Verificação visual em `npm run dev`** — o agente DEVE abrir/inspecionar CADA slide alterado nas seguintes viewports e confirmar: - **Desktop (1440×800):** conteúdo 100% dentro do palco (zero pixel no header/footer), fillArea adequado, layout correto. - **Short desktop (1280×700):** mesmo check — ESPECIAL ATENÇÃO a conteúdo cortado pelo footer (causa-raiz mais comum). Botões, footers de slide, últimos elementos de coluna DEVEM estar visíveis acima do chrome do footer. - **Mobile (390×844):** layout mobile dedicado, conteúdo visível, chrome no lugar. 5. **Verificação de CUT no bordo inferior (§6.17):** para CADA slide alterado, confirmar que o ÚLTIMO elemento visível (botões, callout, rodapé do conteúdo) está INTEIRAMENTE acima da faixa do footer (`bottom: clamp(68px, 9vh, 100px)`). Se o último elemento é cortado/escondido pelo footer → FALHA. Corrigir (compactar conteúdo, esconder elementos secundários, redistribuir) ANTES de commitar. 6. **Verificação de overflow em media queries:** confirmar que as media queries (`max-width: 768px`, `min-width: 769px and max-height: 700px`) NÃO escondem conteúdo essencial que o utilizador pediu. Se uma query esconde conteúdo essencial, substituir `display: none` por estilos compactos (fontes menores, padding reduzido, line-clamp) — nunca remover conteúdo que foi explicitamente pedido. **Sequência canónica ANTES de git commit:** ```bash bash audit-css.sh # gate 1: padrões proibidos bash valida-skill.sh # gate 2: componentes canónicos npm run build # gate 3: TypeScript + Next.js # gate 4-6: verificação visual manual (agente inspeciona no dev server) ``` **Sequência canónica ANTES de deploy:** ```bash # Todos os gates 1-6 já passaram (pré-commit) bash deploy.sh # deploy # Pós-deploy: verificar na URL pública (§17 CLAUDE.md) ``` **O agente NÃO pode:** - Commitar com `audit-css.sh` falhando - Commitar sem verificar visualmente os slides alterados - Deployar conteúdo que está cortado pelo footer em QUALQUER viewport - Esconder com `display: none` conteúdo que o utilizador pediu explicitamente - Declarar "pronto" sem demonstrar que o conteúdo está visível na URL pública **Violação desta regra = mesma gravidade que dado inventado (§2).** É FALHA crítica, não dívida técnica. --- ## 1. NATUREZA - **Apresentação de slides single-page**, 100% no cliente, **navegação por scroll horizontal com snap** (`scroll-snap-type: x mandatory`). - **Next.js 15 + React 19, TypeScript strict, `output: 'standalone'`**, sob subpath (`basePath`/`assetPrefix` por `NODE_ENV`). **Nunca `output: 'export'` (showcase exige `standalone`).** - **ZERO dependências de runtime além de React/Next.** Sem Framer Motion, GSAP, Three.js, D3, Recharts, Zustand. Toda animação/visualização **à mão**: CSS + `requestAnimationFrame` + Canvas 2D + SVG. Componentes de reveal (`Typewriter`, `WordReveal`, `AnimatedCounter`) e gráficos (SVG/Canvas) também à mão. - **Zero backend em runtime.** Sem `app/api/*`, sem banco, sem LLM, sem `fetch` externo. Tudo estático (a narração é mp3 pré-gerado em build-time). - **Timing** sempre com `performance.now()` + state JS explícito desde o mount. **Proibido** `getAnimations()[0]` / `anims.find(a => a.duration === X)`. - Conteúdo no idioma do projeto; **código em inglês**. --- ## 2. FONTE DE CONTEÚDO (regra dura — DADOS REAIS, NÃO INVENTAR) > **DADOS REAIS, OSTENSIVAMENTE. Esta é a regra mais inegociável da skill.** Todo número, percentual, valor, data e nome num showcase é um **fato verificável de fonte real e citável** — nunca uma estimativa "de cabeça", placeholder, número redondo "pra ilustrar", ou dado plausível inventado. Showcase não é mockup: se um número aparece na tela ou na narração, ele **existe numa fonte real** e a fonte é rastreável. Dado fabricado = **FALHA crítica**, não importa quão bem-acabado pareça. - **Toda afirmação numérica tem fonte real e nomeável** (órgão/estudo/relatório + ano). Sem fonte → o número **não entra**. Na dúvida entre um número "bonito" sem fonte e um número real menos redondo, **sempre o real**. - **Proibido:** inventar, arredondar "pra ficar limpo", interpolar, extrapolar, ou usar placeholder (`XX%`, `~R$ 1 mi`, "cerca de") como se fosse dado final. Número de fonte externa entra **idêntico** ao da fonte. - Quando o showcase é DE uma página/produto existente, localizar o **código-fonte real** dela (no Mac, ex.: `Projects/.../infra`) e usar os componentes/SVGs/textos/dados **verbatim**. - **Rastreabilidade:** cada dado (tela e guião) carrega a fonte — inline, em nota, ou no objeto do slide (§8.1). Auditável slide a slide. - **Mapas = GeoJSON OBRIGATÓRIO.** Todo mapa no showcase DEVE ser alimentado por dados GeoJSON (arquivo `.geojson` local ou API). Mapas estáticos (imagem raster, screenshot, iframe Google Maps) ou geometrias hardcoded em SVG/canvas são PROIBIDOS. Usar biblioteca de rendering (Mapbox GL, Leaflet, D3-geo, deck.gl) com source GeoJSON. A geometria NUNCA é desenhada manualmente — vem SEMPRE de dados estruturados (F17). - Antes de montar: **listar TODAS as seções/atos da fonte e confirmar a lista** com o usuário. --- ## 3. CHROME OBRIGATÓRIO (REGRA DE OURO — IMUTÁVEL) A tela tem **DUAS FAIXAS invioláveis** (HEADER topo + FOOTER base) e o **PALCO** entre elas. Cada elemento tem posição fixa canônica e cada faixa tem **altura definida** (§3.1). NÃO trocar de lado, NÃO improvisar, NÃO pôr nada além do especificado dentro das faixas. ``` ┌─ HEADER · clamp(72px,9vh,100px) ──────────────────────────┐ │ ▬▬▬▬ progress-bar (top:0) │ │ icons.ai «NOME DO PROJETO» Sair│PDF│BR PT EN│Aa│🔊 │ esq · centro · dock DIR ├────────────────────────────────────────────────────────────┤ │ │ │ PALCO — conteúdo do slide │ │ │ ├─ FOOTER · clamp(68px,9vh,100px) ──────────────────────────┤ │ ◀ ▶ icons.ai · © 2026 · MIT/Harvard 01 / 25 │ setas ESQ · marca CENTRO · num DIR └────────────────────────────────────────────────────────────┘ ``` | Elemento | Posição canônica | Classe | Faixa | |---|---|---|---| | **Logo** (`icons.ai`) | topo-esquerdo (`top:3vh; left:4vw`) | `.logo-fixed` | HEADER | | **Nome do projeto** (centro) | topo-**centro** (`top:0; left:50%; translateX(-50%)`) | `.slide-head` > `.slide-head__name` (+ kicker opcional) | HEADER | | **Barra de progresso** | **TOPO** (`top:0; left:0; height:2px`) | `.progress-bar` | HEADER | | **Dock (topo-dir)**: **Sair** (1º, → hub) + **PDF** (2º, exportar documento §8.6) + **idioma** `BR·PT·EN` + **«Aa»** (legenda/leitura) + **áudio** (alto-falante) | topo-**direito** (`top:3vh; right:4vw`) | `.exit-btn` + `.pdf-btn` + dock §8.2/§8.3/§8.6 | HEADER | | **Setas prev+next** | **JUNTAS, inferior-esquerdo** (`left:4vw; bottom:3vh`) | `.slide-nav` > `.slide-nav__btn` | FOOTER | | **Numeração** `NN/TT` | **aresta inferior-direita** (`bottom:3vh; right:4vw`) | `.slide-counter` | FOOTER | | **Marca (centro do footer)**: logo `icons.ai` + linha legal `© 2026 IconsAI · Kendall Square · CIC · Cambridge, MA · MIT · Harvard` | inferior-**centro** (`left:50%; bottom:2vh; translateX(-50%)`) | `.slide-foot` > `.logo-foot` + `.slide-foot__legal` | FOOTER | | **Favicon** | trio i.ai (ver §5) | `app/favicon.ico` + `app/icon.png` + `app/apple-icon.png` | — | ### 3.1 FAIXAS + PALCO + MOLDURA — definição geométrica (DETERMINÍSTICO) A tela = **HEADER** (topo) + **PALCO** (conteúdo) + **FOOTER** (base). As faixas são `position:fixed` (fora do fluxo); o PALCO reserva **exatamente** as alturas delas, então nada some atrás. | Faixa | Altura reservada (FIXA) | Conteúdo — **lista FECHADA, nada além** | |---|---|---| | **HEADER** (topo) | **`clamp(72px, 9vh, 100px)`** | **esq:** logo `icons.ai` (`top:3vh; left:4vw`) · **centro:** **nome do projeto** (`.slide-head`, `top:0; left:50%`) · **dir:** dock (`top:3vh; right:4vw`) = **Sair** + **PDF** + **idioma** + **«Aa»** + **áudio** · + progress-bar (`top:0`). O `72px` limpa o dock (botões ~46px a `top:3vh`); o `100px` impede o chrome de crescer infinitamente em monitores grandes. | | **FOOTER** (base) | **`clamp(68px, 9vh, 100px)`** | **esq:** setas 44×44 (`bottom:3vh; left:4vw`) · **centro:** marca `.slide-foot` = logo `icons.ai` + linha legal `© 2026 IconsAI · Kendall Square · CIC · Cambridge, MA · MIT · Harvard` (`left:50%; bottom:2vh`) · **dir:** numeração (`bottom:3vh; right:4vw`). Reduzido ~20px vs. anterior (`max(11vh,88px)`). | #### PALCO — definição geométrica (LEI) O **PALCO** é o retângulo **exato** entre as faixas: - **Horizontal:** da borda ESQUERDA à borda DIREITA do navegador (100% da viewport width). - **Vertical:** da BASE do HEADER (`clamp(72px,9vh,100px)`) ao TOPO do FOOTER (`clamp(68px,9vh,100px)`). - É o **único** espaço onde conteúdo de slide existe. Nada fora, nada nas faixas. ``` ┌─── HEADER · clamp(72px,9vh,100px) ─────────────────────────────┐ ├────────────────────────────────────────────────────────────────┤ │ PALCO │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ MOLDURA (20px) │ │ │ │ │ │ │ │ ÁREA ÚTIL DO CONTEÚDO │ │ │ │ │ │ │ │ │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ ├────────────────────────────────────────────────────────────────┤ └─── FOOTER · clamp(68px,9vh,100px) ─────────────────────────────┘ ``` #### MOLDURA — respiro visual (LEI) Dentro do Palco existe uma **moldura de 20px** (padding inset nos 4 lados). O conteúdo do slide vive **dentro da moldura**, nunca colado nas bordas do Palco. A moldura é fixa e determinística — não ajustar por slide. ```css .slide-band { /* reserva das faixas — clamp(min, preferred, max) = responsivo com piso E teto */ padding-top: clamp(72px, 9vh, 100px); padding-bottom: clamp(68px, 9vh, 100px); /* footer reduzido ~20px */ } .slide-stage { /* moldura: respiro visual dentro do palco */ padding: 20px; width: 100%; flex: 1; min-height: 0; /* LEI: flex:1, NUNCA height:100% */ box-sizing: border-box; overflow: hidden; /* LEI: clip no limite do palco */ } ``` **Área útil** = Palco menos moldura. Todo layout de conteúdo (§6) opera dentro da área útil. O PALCO reserva as faixas via `.slide-band`; a moldura via `.slide-stage` (filho direto do band). ### 3.2 HEADER E FOOTER SÃO OPACOS (LEI) Header e footer tapam tudo atrás deles. CSS no `globals.css` (já incluído no §4). **As faixas usam o token de tema `var(--bg)` — NUNCA cor hardcoded** (ver §3.3): ```css body::before, body::after { content: ""; position: fixed; left: 0; right: 0; z-index: 80; background: var(--bg); pointer-events: none; } body::before { top: 0; height: clamp(72px, 9vh, 100px); } body::after { bottom: 0; height: clamp(68px, 9vh, 100px); } ``` ### 3.3 TEMA DO DECK — dark (default) OU light (LEI) > **O tema segue a CATEGORIA do produto, como a cor do favicon (§5.2).** Default do ecossistema = **dark** (`--bg: #06080d`). Mas um produto cujo domínio pede fundo claro (ex.: **saúde/médico** — DiscoveryHealth usa branco clínico) usa o **tema light** legitimamente. O que é LEI não é a cor — é a **arquitetura de tokens**: todo o chrome deriva de `:root`, zero cor de fundo hardcoded em faixa/chrome. | Token | Dark (default) | Light (ex.: saúde) | Usado em | |---|---|---|---| | `--bg` | `#06080d` | claro do deck (ex.: `#e4e7ec` / `#f6f8fa`) | faixas opacas `body::before/after`, fundo do deck | | `--white` (texto principal) | `#f0f0f0` | escuro (ex.: `#14181f`) | títulos, `NN` do counter | | `--gray` | `#8a8f98` | cinza médio com contraste ≥3:1 no claro | counter, legal, anotações | | `--dim` | `#2a2e37` | claro neutro | bordas, fios | | accent | cyan `#22d3ee` (ou accent do deck) | accent do domínio (saúde = verde/teal) | progress-bar, hovers, fio de luz | **Regras do tema light (LEI):** - `body` recebe a classe **`theme-light`** — e o logo segue CLAUDE.md §18.1: `.logo-cons` vira **`#111111`** (em dark é `#ffffff`); `i` `#f97316` e `.ai` `#ef4444` **nunca mudam**. - Botões/dock invertem o glass: fundo claro translúcido, borda escura suave — mantendo a MESMA geometria do §4 (posições, tamanhos, ordem são imutáveis; só cor troca via token). - Contraste WCAG ≥ 3:1 para TODO texto do chrome contra o `--bg` claro (§6.13 vale igual). - **F22 continua valendo:** as faixas opacas existem SEMPRE — a verificação é `background: var(--bg)` (sólido), não uma cor específica. - **PROIBIDO:** misturar temas no mesmo deck; hardcodar `#06080d` (ou qualquer bg) direto na faixa; tema light "porque sim" — a escolha deriva do domínio do produto e fica registada no CLAUDE.md do projeto. **INVIOLÁVEL (regra de ouro):** - No **HEADER** existem SÓ esses 3 grupos; no **FOOTER** SÓ esses 3 (setas esq · **marca no centro** · numeração dir). **Nada mais** entra nas faixas — sem menu, breadcrumb, CTA, botão extra, segundo contador, badge, etc. - A **marca no centro do footer** (logo `icons.ai` + `© 2026 IconsAI · Kendall Square · CIC · Cambridge, MA · MIT · Harvard`) é **OBRIGATÓRIA em todo slide**. A linha legal é **fixa** (nomes próprios — igual em BR/PT/EN, não traduz). - O **dock** mora SEMPRE no topo-direito, com **5 controlos na ordem `Sair → PDF → idioma → «Aa» → áudio`** (§8.2/§8.3/§8.6). O **Sair** (1º) leva a `https://iconsai.ai/intelligenceHub` (link explícito, NÃO `history.back()`) — **mesma ação da tecla `Esc`** (§7), inclusive em fullscreen. O **PDF** (2º) dispara `window.print()` para exportar o documento formatado (§8.6). Não mover, não omitir. - O **nome do projeto** fica no **centro do header** (`.slide-head`), `position:fixed`, abaixo da progress-bar — `z-index` menor que logo/dock pra não cobrir. Obrigatório. - Conteúdo do slide **NUNCA** invade as faixas nem a moldura: a redistribuição horizontal (§6.3) + scale-to-fit (§6.5) garantem cabimento 100% na área útil — jamais deixa entrar no header/footer. - Alturas, posições e lista de conteúdo são **fixas e determinísticas** — não ajustar "no olho", não adicionar elemento, não trocar de faixa/lado. - **SEM floating button no showcase.** O floating (CLAUDE.md §18, canto inf-dir) é de páginas comuns/hub — **NÃO entra no deck**: o chrome é lista fechada E ele colidiria com a numeração (também inf-dir). O logo (topo-esq) já leva a `iconsai.ai`. **Showcase é exceção explícita ao §18.** - **Deck em FULLSCREEN imersivo via iframe do hub (canon) — ZERO chrome externo.** Fullscreen do browser **não sobrevive a uma navegação de página** — então, pra manter o deck em fullscreen, o hub o embute num **`

A central de ferramentas do ecossistema.

Acesso ao Tools