Frontend Intelligence Engine

Veredito executivo

O FIE e tecnicamente viavel e pode gerar muito valor, principalmente para:

• analisar landing pages, sites institucionais, SaaS publicos e documentacoes;
• extrair tokens visuais, componentes recorrentes, hierarquia e padroes de UX;
• criar referencias reutilizaveis para agentes que constroem interfaces;
• montar uma busca semantica de exemplos como "hero premium", "pricing SaaS", "dashboard minimalista" ou "sidebar moderna";
• acelerar discovery visual antes de desenvolver uma tela nova.

Mas a promessa precisa de limites:

• "Qualquer website" so funciona bem para conteudo publico e navegavel sem credenciais.
• Fluxos autenticados, checkout real, dashboards privados e produtos complexos exigem modo assistido, massa de dados fake e credenciais controladas.
• O sistema consegue inferir padroes, mas nao consegue garantir que descobriu todos os estados, modais, erros e microinteracoes sem instrumentacao ou ajuda humana.
• Reproduzir "look and feel" e permitido como aprendizado de padrao; copiar HTML, CSS, assets, textos, marcas ou imagens pode criar risco juridico.
• A saida precisa ser probabilistica, versionada e revisavel. Nao deve ser tratada como fonte absoluta.

Resumo: funciona na pratica se for construido em camadas, com escopo claro, controle juridico e validacao humana nos casos sensiveis. Tentar entregar a versao completa de uma vez tende a virar um sistema caro, lento e inconsistente.

Estrutura recomendada do produto

O FIE deve ser dividido em seis blocos principais:

1. Collector

   • resolve URL ou nome da empresa;
   • abre navegador real com Playwright;
   • coleta paginas, rotas, screenshots, videos, DOM, CSS, rede e assets;
   • executa exploracao interativa basica.

2. Explorer

   • descobre links relevantes, menus, dropdowns, modais, abas e accordions;
   • simula scroll, hover, focus e cliques seguros;
   • mantem uma fronteira de navegacao com limites de profundidade, dominio e budget de tempo.

3. Analyzers

   • dom-analyzer;
   • css-analyzer;
   • token-analyzer;
   • component-analyzer;
   • motion-analyzer;
   • ux-analyzer;
   • performance-analyzer;
   • accessibility-analyzer;
   • framework-detector;
   • asset-analyzer.

4. Knowledge Builder

   • normaliza os achados;
   • cria markdown/JSON estruturado;
   • envia screenshots, trechos de DOM e metadados para um modelo multimodal;
   • gera documentacao interpretativa sem copiar codigo.

5. Vector Search

   • indexa componentes, secoes, paginas e tokens;
   • permite busca semantica por estilo, padrao, componente ou experiencia;
   • retorna referencias com evidencias visuais e metadados.

6. Agent Integration

   • disponibiliza API/SDK para agentes consultarem referencias antes de criar telas;
   • devolve tokens, componentes similares, guidelines e restricoes;
   • inclui regras de nao copia literal.

Arquitetura pratica

3.1 Processos

CLI/API
  |
  v
Job Orchestrator
  |
  +-- Site Resolver
  +-- Browser Worker Pool (Playwright Chromium)
  +-- Artifact Writer
  +-- Analyzer Pipeline
  +-- Knowledge Builder
  +-- Embedding Indexer
  +-- Report Publisher

3.2 Componentes

3.3 Stack recomendada

Pipeline de coleta recomendado

4.1 Entrada

Comandos:

fie collect https://stripe.com
fie collect stripe
fie collect https://site.com --depth 2 --profile marketing
fie collect https://app.demo.com --mode assisted --auth-state auth.json

Se a entrada for nome de empresa, o resolvedor deve:

1. tentar busca em cache;
2. consultar mecanismo de busca ou API propria;
3. validar dominio oficial por titulo, metadados, logo, schema.org e redirects;
4. pedir confirmacao quando houver ambiguidade.

4.2 Preparacao do navegador

• viewport inicial: desktop 1440x900;
• user-agent realista;
• bloqueio opcional de trackers pesados;
• captura de console, network e request failures;
• contextos separados por site;
• timeout global por coleta;
• storage state opcional para login assistido.

4.3 Descoberta de paginas

Comecar por:

• home;
• menu principal;
• footer;
• links com texto: pricing, produto, servicos, docs, blog, ajuda, contato, login, cadastro;
• sitemap.xml e robots.txt quando existirem;
• links internos com alta centralidade.

Limites obrigatorios:

• profundidade maxima;
• numero maximo de paginas;
• apenas mesmo dominio ou subdominios permitidos;
• blacklist de logout, delete, checkout real, payment, destructive actions;
• dedupe por canonical URL e normalizacao de query strings.

4.4 Exploracao interativa

Executar em cada pagina:

• espera de rede e fontes;
• scroll incremental ate o fim;
• hover em nav, cards e botoes;
• focus em inputs;
• abertura de menus, tabs, accordions, drawers e modais;
• preenchimento fake apenas em formularios marcados como seguros;
• captura antes/depois de cada acao.

O explorer deve ser conservador. Ele nao deve:

• enviar formulario real sem modo assistido;
• comprar, reservar, pagar ou cancelar nada;
• clicar em acoes destrutivas;
• contornar paywall, login, captcha ou anti-bot.

O que da para detectar bem

5.1 Design tokens

Funciona bem com CSS computado:

• cores frequentes;
• fontes e pesos;
• escala tipografica;
• spacing aproximado;
• radius;
• sombras;
• gradientes;
• largura de containers;
• breakpoints observados por viewport;
• z-index e overlays.

Limite: tokens inferidos nao sao necessariamente os tokens originais do time de design. Devem ser chamados de tokens observados.

5.2 Componentes

Funciona bem para componentes visiveis e semanticos:

• navbar;
• hero;
• button;
• input;
• card;
• pricing;
• footer;
• modal;
• drawer;
• tabs;
• accordion;
• table;
• sidebar;
• dashboard cards.

Limite: componentes muito customizados ou canvas/WebGL exigem visao multimodal e heuristica. O DOM sozinho nao basta.

5.3 UX e arquitetura da informacao

Funciona bem para inferir:

• CTA principal;
• CTA secundario;
• hierarquia visual;
• organizacao de secoes;
• padrao de navegacao;
• repeticao de componentes;
• mensagens e feedback visual;
• nivel de densidade;
• tom visual.

Limite: motivacao de negocio, funil real, taxa de conversao e intencao do time nao sao observaveis diretamente. Sao inferencias.

5.4 Motion

Funciona parcialmente:

• CSS transitions e animations via computed style e CSSOM;
• Web Animations API via document.getAnimations();
• duracao, delay, easing e propriedades animadas;
• eventos de hover/focus/click que disparam transicoes;
• gravacao de video para revisao.

Limite: GSAP, Framer Motion, Canvas, WebGL, Lottie e scroll-driven animation podem exigir instrumentacao especifica. Nem sempre e possivel recuperar a timeline real apenas pelo DOM.

O que nao funciona 100% automatico

6.1 Login e dashboards privados

Sem credenciais, o FIE so ve a tela publica. Para dashboards, precisa de:

• storageState do Playwright;
• usuario demo;
• seed de dados fake;
• ambiente sandbox;
• lista de rotas permitidas;
• permissao explicita.

6.2 Estados raros

Estados como erro, vazio, sucesso, loading, permissao negada e pagamento recusado nem sempre aparecem naturalmente. Para capturar bem, o sistema precisa:

• mockar APIs;
• interceptar respostas;
• usar fixtures;
• ter modo assistido;
• ou receber cenarios declarativos.

6.3 "Descobrir todos os fluxos"

Descobrir todos os fluxos de um produto e, na pratica, impossivel sem modelo de estado e criterios de parada. O correto e falar em:

• fluxos descobertos;
• fluxos inferidos;
• fluxos nao acessiveis;
• cobertura estimada.

6.4 Sites com protecao anti-bot

Muitos sites usam Cloudflare, Akamai, Datadome, captchas ou bloqueio de automacao. O FIE nao deve ser projetado para burlar protecoes. Ele deve:

• respeitar bloqueios;
• reportar limitacao;
• permitir coleta manual assistida quando houver autorizacao;
• evitar padroes agressivos.

Estrutura da base de conhecimento

Layout recomendado:

knowledge/
  sites/
    stripe.com/
      2026-07-10T12-00-00Z/
        manifest.json
        metadata/
          site.json
          crawl.json
          framework.json
        pages/
          home/
            page.json
            dom.html
            computed-styles.json
            screenshot-full.png
            screenshot-above-fold.png
            video-scroll.mp4
          pricing/
            ...
        components/
          button/
            component.json
            states/
              default.png
              hover.png
              focus.png
          hero/
            component.json
            screenshot.png
        design-system/
          tokens.json
          colors.json
          typography.json
          spacing.json
          shadows.json
          radius.json
          breakpoints.json
        animations/
          timeline.json
          observed-transitions.json
          videos/
        assets/
          logos/
          icons/
          images/
          fonts/
        ux/
          information-architecture.md
          interaction-patterns.md
          heuristics.md
        performance/
          lighthouse.json
          summary.md
        accessibility/
          axe.json
          summary.md
        documentation/
          agent-style-guide.md
          reproduction-guidelines.md
          do-not-copy.md
        embeddings/
          chunks.jsonl

7.1 Manifest

Cada coleta deve ter:

• siteId;
• dominio;
• URL inicial;
• data;
• versao do FIE;
• perfil de coleta;
• viewports usados;
• limites aplicados;
• erros;
• cobertura estimada;
• hash dos artifacts principais.

7.2 Component JSON

Exemplo:

{
  "id": "stripe.com:2026-07-10:component:hero:home:0",
  "type": "hero",
  "page": "home",
  "selectorHint": "main section:nth-of-type(1)",
  "confidence": 0.86,
  "visualDescription": "Hero editorial com headline grande, gradiente suave e CTA primario",
  "tokens": {
    "colors": ["#635bff", "#0a2540"],
    "fontFamily": "Inter-like sans",
    "radius": ["8px", "16px"]
  },
  "states": ["default"],
  "animations": ["fade-in", "translate-y"],
  "doNotCopy": ["text", "logo", "images", "exact-css"]
}

Modelo de dados minimo

Entidades principais:

• Site;
• CrawlRun;
• PageSnapshot;
• ComponentSnapshot;
• DesignTokenSet;
• AnimationObservation;
• Asset;
• AnalyzerFinding;
• KnowledgeDocument;
• EmbeddingChunk;

Campos importantes:

• confidence;
• sourceArtifact;
• viewport;
• capturedAt;
• analyzerVersion;
• legalStatus;
• copyRisk;
• reviewStatus.

Sem esses campos, a base vira um amontoado de prints bonito, mas pouco confiavel.

Busca semantica

A busca deve indexar chunks diferentes:

• pagina inteira;
• secoes;
• componentes;
• tokens;
• padroes de UX;
• animacoes;
• relatorios de acessibilidade/performance.

Consultas esperadas:

• "hero premium para SaaS B2B";
• "pricing elegante com toggle mensal/anual";
• "sidebar densa para dashboard financeiro";
• "cards com glassmorphism sutil";
• "microinteracoes parecidas com Linear";
• "checkout minimalista";
• "landing page com autoridade enterprise".

Resposta ideal:

1. lista de referencias;
2. screenshot;
3. motivo do match;
4. tokens relevantes;
5. comportamento observado;
6. restricoes de uso;
7. prompt/guidance para agente.

Integracao com agentes de UI

Antes de criar uma tela, o agente deve:

1. consultar o FIE com o contexto da tela;
2. receber referencias semelhantes;
3. extrair principios, tokens e padroes;
4. gerar uma proposta nova;
5. checar risco de copia literal;
6. registrar quais referencias influenciaram a decisao.

Regra central:

O agente pode aprender padroes, mas nao pode copiar codigo, assets, marcas, textos, composicoes proprietarias ou uma tela especifica de forma confundivel.

Boa saida para agente:

{
  "intent": "dashboard operacional B2B",
  "recommendedPatterns": [
    "sidebar fixa com grupos curtos",
    "metric tiles no topo",
    "tabela densa com filtros persistentes"
  ],
  "tokens": {
    "surface": "#ffffff",
    "ink": "#111827",
    "radius": "8px",
    "spacingBase": "4px"
  },
  "motion": {
    "duration": "140-220ms",
    "easing": "cubic-bezier(0.2, 0, 0, 1)"
  },
  "avoid": [
    "copiar layout 1:1",
    "usar marcas ou imagens originais",
    "replicar copy proprietaria"
  ]
}

Consideracoes juridicas e eticas

Este ponto e critico. O FIE deve nascer com politica de uso.

11.1 Propriedade intelectual

Permitido:

• estudar padroes gerais;
• extrair tokens aproximados;
• catalogar componentes em alto nivel;
• criar inspiracao nao confundivel.

Evitar:

• copiar CSS/HTML literal;
• baixar e reutilizar imagens, logos, ilustracoes ou icones proprietarios;
• reproduzir identidade visual a ponto de confundir usuarios;
• republicar screenshots sem contexto ou permissao quando sensivel.

11.2 Termos de uso e robots

O FIE deve registrar:

• robots.txt;
• ToS quando possivel;
• status de permissao;
• se a coleta foi publica, assistida ou autorizada;
• escopo permitido.

Robots.txt nao resolve toda a parte juridica, mas e um sinal minimo de respeito.

11.3 Dados pessoais

Screenshots e DOM podem conter PII. Exemplo: dashboard logado, nomes, emails, enderecos, dados financeiros.

Obrigatorio:

• mascaramento de PII;
• storage criptografado quando houver dados sensiveis;
• retencao configuravel;
• permissao explicita para modo autenticado;
• logs sem segredos;
• exclusao por site/run.

Performance, custo e escala

Coletar "tudo" e caro.

Custos principais:

• browser real consome CPU/RAM;
• screenshots full-page consomem storage;
• videos consomem muito storage;
• Lighthouse e lento;
• modelo multimodal custa por imagem/frame;
• embeddings crescem com numero de componentes.

Recomendacao:

• perfis de coleta;
• budgets por run;
• sampling de frames de video;
• dedupe visual por hash perceptual;
• compressao de imagens;
• lifecycle de artifacts pesados;
• fila com concorrencia controlada;
• retry seletivo;
• rate limit por dominio.

Perfis sugeridos:

Roadmap recomendado

Fase 0 - Spike tecnico

Objetivo: provar coleta basica.

Entregas:

• CLI fie collect <url>;
• Playwright abre site e tira screenshot full-page;
• captura DOM renderizado;
• captura CSS computado de elementos principais;
• extrai paleta de cores e fontes observadas;
• gera manifest.json;
• gera report.md.

Fase 1 - MVP util

Objetivo: transformar URL publica em guia visual simples.

Entregas:

• descoberta de paginas por menu/footer/sitemap;
• screenshots por viewport desktop e mobile;
• tokens observados;
• componente basico: nav, hero, card, button, form, footer;
• Axe Core;
• Lighthouse opcional;
• documentacao agent-style-guide.md;
• busca semantica simples com pgvector.

Fase 2 - Interacao e estados

Objetivo: capturar comportamento.

Entregas:

• hover/focus/click seguro;
• tabs, accordion, dropdown, modal;
• screenshots de estados;
• video de scroll;
• timeline inicial de animacoes;
• deteccao de frameworks e bibliotecas de motion.

Fase 3 - Apps autenticados assistidos

Objetivo: analisar dashboards e fluxos protegidos com permissao.

Entregas:

• --auth-state;
• cenarios declarativos;
• mock/intercept de APIs;
• PII masking;
• rotas permitidas;
• relatorio de cobertura.

Fase 4 - Agent-native

Objetivo: agentes consultam FIE automaticamente.

Entregas:

• API de busca;
• SDK/MCP;
• retorno com tokens, referencias, riscos e guidance;
• avaliador anti-copia;
• feedback loop: quais referencias ajudaram no resultado.

Criterios de sucesso

MVP deve ser considerado bom se:

• coleta 10 sites publicos populares sem quebrar;
• encontra pelo menos 70% das paginas principais listadas no menu/footer;
• gera tokens visuais coerentes;
• identifica componentes basicos com confianca aceitavel;
• produz um guia que ajuda um agente a criar uma UI semelhante em qualidade, mas nao copiada;
• registra limitacoes e erros com clareza;
• executa com budget previsivel.

Nao medir sucesso por "capturou tudo". Essa meta e ruim. Medir por:

• cobertura;
• utilidade do guia;
• qualidade da busca;
• reducao de retrabalho do agente;
• seguranca juridica;
• custo por site.

Principais riscos

Decisoes recomendadas agora

1. Nao construir a versao completa primeiro. Comecar pelo MVP de sites publicos: crawl, screenshots, DOM, CSS computado, tokens e guia visual.

2. Nomear corretamente a saida. Usar "tokens observados", "componentes inferidos" e "cobertura estimada". Isso evita falsa precisao.

3. Criar policy engine desde o inicio. Anti-copia, PII, robots, ToS, limites de acao e logs de autorizacao devem existir antes de escalar.

4. Separar artifacts de interpretacao. Screenshot, DOM e CSS sao evidencia. Resumo de IA e interpretacao. Os dois precisam ser armazenados separadamente.

5. Tratar login como modo assistido. Nada de prometer dashboard privado automatico so com URL.

6. Usar arquitetura plugin-based. Motion, component, performance e accessibility devem ser plugins versionados.

7. Adicionar score de confianca. Todo achado importante precisa ter confianca e referencia ao artifact fonte.

Estrutura inicial de repositorio

Sugestao:

fie/
  apps/
    cli/
    api/
    worker/
  packages/
    core/
    browser/
    analyzers/
      dom/
      css/
      tokens/
      components/
      motion/
      ux/
      performance/
      accessibility/
      framework/
    knowledge/
    policy/
    storage/
    search/
    schemas/
  prisma/
  docs/
    architecture.md
    policy.md
    analyzer-contract.md
    mvp.md

Contratos importantes:

• CrawlRun;
• PageSnapshot;
• ComponentSnapshot;
• TokenSet;
• AnalyzerFinding;
• KnowledgeChunk.

Conclusao

O FIE e uma ideia forte e pratica, desde que o produto seja vendido e construido como motor de inteligencia e referencia, nao como copiador de sites.

O melhor caminho e:

1. construir um MVP honesto para sites publicos;
2. gerar artifacts verificaveis;
3. extrair tokens e componentes inferidos;
4. produzir guia para agentes;
5. indexar semanticamente;
6. evoluir para interacoes, motion e modo autenticado assistido.

O ganho real nao esta em "clonar Stripe". Esta em permitir que um agente entenda por que uma interface parece boa, quais padroes visuais e interativos ela usa, e como criar algo novo com qualidade semelhante, sem copiar o original.

Contexto do alvo

URL de referencia:

https://escrital.com.br

Leitura inicial observada:

• site WordPress;
• tema/base Astra;
• construtor Elementor;
• paginas principais: Inicio, Servicos, Diferenciais, Blog, IRPF2026, Contato;
• proposta: contabilidade digital/estrategica em Sao Paulo;
• secoes da home: hero, estatisticas, servicos, escritorio, logos de empresas atendidas, blog, contato, footer e consentimento de cookies;
• imagens em wp-content/uploads, incluindo logo, hero, fotos do escritorio, logos de clientes e thumbs de blog;
• robots.txt permite crawl e aponta para sitemap.

Claude deve confirmar novamente esses fatos durante a implementacao, porque o site pode mudar.

Resultado esperado

Ao final, devem existir:

1. Knowledge run

   • artifacts de coleta;
   • screenshots;
   • videos quando habilitado;
   • DOM renderizado;
   • CSS computado;
   • design tokens observados;
   • manifestos de assets;
   • relatorio de UX/UI;
   • guia para agente.

2. Demo melhorado

   • landing responsiva;
   • visual renovado;
   • copy revisada;
   • imagens autorizadas ou substitutas;
   • CTA WhatsApp/contato;
   • SEO basico;
   • acessibilidade minima;
   • performance aceitavel.

3. Hospedagem

   • subdominio unico example<ID>.clsolucoes.com;
   • website criado no CyberPanel;
   • DNS criado/atualizado no Cloudflare;
   • SSL emitido;
   • validacao HTTP/HTTPS;
   • URL final registrada no relatorio.

Guardrails obrigatorios

3.1 Copia vs inspiracao

Permitido:

• baixar imagens, CSS e HTML como evidencia/artifact privado de analise;
• extrair tokens observados;
• identificar estrutura, componentes e padroes de UX;
• recriar uma landing nova inspirada na qualidade do original;
• usar imagens no demo se houver autorizacao.

Proibido sem autorizacao:

• publicar imagens, logos de terceiros ou fotos do alvo;
• copiar HTML/CSS literal;
• clonar layout 1:1;
• copiar textos completos;
• remover creditos/identidade de terceiros;
• usar marcas de clientes exibidas no site-alvo sem permissao.

3.2 Modos de asset

O pipeline deve aceitar:

ASSET_USE_MODE=reference   # default: baixa para analise, nao publica
ASSET_USE_MODE=authorized  # publica assets coletados, quando houver direito de uso
ASSET_USE_MODE=replace     # troca por imagens geradas/licenciadas/placeholders

Para escrital.com.br, se o cliente/proprietario autorizar uso das imagens, usar authorized. Caso contrario, usar reference na coleta e replace no demo.

3.3 Acoes seguras

Durante crawl:

• nao enviar formularios reais;
• nao contornar login, captcha ou anti-bot;
• nao clicar em pagamento, exclusao, logout ou acoes destrutivas;
• aceitar/fechar cookies apenas para visualizar a pagina;
• respeitar timeout, rate limit e robots.

Variaveis de execucao

Claude deve trabalhar sempre com variaveis explicitas:

export TARGET_URL="https://escrital.com.br"
export TARGET_HOST="escrital.com.br"
export PROJECT_SLUG="escrital"
export RUN_ID="$(date -u +%Y%m%d%H%M%S)"
export ASSET_USE_MODE="reference"
export BASE_DOMAIN="clsolucoes.com"
export PREVIEW_PREFIX="example"
export SERVER_IP="147.93.15.29"

Diretorios sugeridos:

/home/fie/
  runs/
    escrital.com.br/
      <RUN_ID>/
        artifacts/
        knowledge/
        generated/
        reports/

Se o repositorio FIE ficar dentro de /home/corvo, usar:

/home/corvo/fie-runs/escrital.com.br/<RUN_ID>/

Estrutura de projeto recomendada

fie/
  apps/
    cli/
    api/
    worker/
    demo-generator/
  packages/
    browser/
    collector/
    explorer/
    analyzers/
      assets/
      dom/
      css/
      tokens/
      components/
      motion/
      ux/
      performance/
      accessibility/
      framework/
    knowledge/
    policy/
    deploy/
    storage/
    search/
    shared/
  templates/
    landing-modern-accounting/
  docs/
  prisma/

Para um primeiro MVP, Claude pode implementar menos:

fie/
  src/
    cli.ts
    collect/
    analyze/
    generate/
    deploy/
    shared/
  templates/
  package.json

Nao iniciar com arquitetura exagerada se ainda nao existir codigo. Primeiro entregar o fluxo fim a fim.

Etapas de desenvolvimento do 0 ao 100%

Etapa 0 - Preparar repositorio

Objetivo: ter ambiente executavel.

Checklist:

• criar projeto Node.js + TypeScript;
• instalar Playwright, Sharp, Cheerio ou parse5, fast-glob, execa, zod;
• instalar Lighthouse e Axe quando entrar na fase de auditoria;
• configurar ESLint/Prettier;
• criar CLI fie;
• criar runs/ no .gitignore;
• criar schemas Zod para manifests.

Comandos esperados:

npm init -y
npm i playwright sharp zod cheerio fast-glob execa p-limit
npm i -D typescript tsx @types/node
npx playwright install chromium

Definition of Done:

• npm run build passa;
• npx fie --help ou npm run fie -- --help mostra comandos.

Etapa 1 - Resolver alvo

Objetivo: aceitar URL ou nome de empresa.

Para este caso:

fie resolve escrital
fie resolve https://escrital.com.br

Regras:

• se entrada ja for URL, normalizar para https://escrital.com.br/;
• seguir redirects;
• salvar site.json;
• baixar robots.txt;
• baixar sitemap_index.xml quando existir;
• registrar permissao observada.

Artifacts:

metadata/site.json
metadata/robots.txt
metadata/sitemap.xml

Definition of Done:

• TARGET_URL final validado;
• status HTTP 200;
• host e canonical salvos.

Etapa 2 - Coleta Playwright basica

Objetivo: abrir navegador real e capturar a home.

Fluxo:

1. abrir Chromium;
2. criar contexto limpo;
3. acessar TARGET_URL;
4. esperar domcontentloaded;
5. esperar fontes;
6. aceitar/fechar cookies se existir;
7. esperar network idle com timeout;
8. executar scroll progressivo;
9. capturar screenshot full-page;
10. salvar HTML renderizado;
11. salvar texto visivel;
12. salvar console/network errors.

Artifacts:

pages/home/screenshot-full.png
pages/home/screenshot-above-fold.png
pages/home/dom.html
pages/home/text.txt
pages/home/network.json
pages/home/console.json

Definition of Done:

• screenshot full-page existe;
• DOM renderizado existe;
• pagina nao ficou em branco;
• cookie banner nao cobre o conteudo final.

Etapa 3 - Descobrir paginas

Objetivo: encontrar as paginas principais do site.

Fontes:

• menu principal;
• footer;
• sitemap;
• links internos com anchor relevante;
• JSON-LD;
• WordPress REST links.

Para Escrital, priorizar:

/
/servicos/
/diferenciais/
/blog/
/imposto-de-renda-2026/
/contato/
/iso9001/

Regras:

• maximo inicial: 12 paginas;
• mesmo host;
• remover query strings de tracking;
• deduplicar canonical;
• nao coletar admin, wp-login, wp-json como pagina visual;
• blog: coletar index + ate 3 posts recentes.

Artifacts:

metadata/routes.json
metadata/crawl-plan.json

Definition of Done:

• pelo menos home, servicos, diferenciais, blog e contato coletados;
• cada pagina possui screenshot e DOM.

Etapa 4 - Coletar imagens e assets

Objetivo: puxar as imagens do site-alvo com manifesto completo.

Extrair URLs de:

• img[src];
• img[srcset];
• source[srcset];
• video[src], poster;
• link[rel~="icon"];
• meta[property="og:image"];
• JSON-LD image, logo, thumbnailUrl;
• CSS url(...);
• inline style background-image;
• lazy attributes: data-src, data-bg, data-lazy-src.

Normalizar:

• converter URLs relativas para absolutas;
• remover duplicatas;
• preservar query string se alterar arquivo;
• calcular sha256;
• identificar extensao real pelo content-type;
• salvar dimensoes com Sharp quando for imagem.

Estrutura:

artifacts/assets/original/
  images/
  logos/
  icons/
  css/
  fonts/
  videos/
artifacts/assets/optimized/
  images/
asset-manifest.json

Manifest minimo:

{
  "id": "asset_001",
  "sourceUrl": "https://escrital.com.br/wp-content/uploads/2026/01/example.jpeg",
  "localPath": "artifacts/assets/original/images/example.jpeg",
  "contentType": "image/jpeg",
  "sha256": "...",
  "width": 1600,
  "height": 1085,
  "foundIn": ["home"],
  "usageHint": "hero",
  "licenseStatus": "reference",
  "publishAllowed": false
}

Regras de uso no demo:

• ASSET_USE_MODE=reference: baixar e analisar, mas publishAllowed=false;
• ASSET_USE_MODE=authorized: pode publicar no demo;
• ASSET_USE_MODE=replace: criar assets substitutos e publicar apenas os substitutos.

Definition of Done:

• imagens principais do hero/escritorio/blog/logos foram detectadas;
• manifest tem hash, dimensao e origem;
• demo nao referencia URL externa do alvo diretamente;
• demo usa copia local autorizada ou asset substituto.

Etapa 5 - Extrair design tokens observados

Objetivo: aprender a identidade visual do alvo.

Coletar:

• fontes usadas;
• escala tipografica;
• cores frequentes;
• cores de CTA;
• background;
• spacing;
• radius;
• sombras;
• larguras de container;
• breakpoints;
• icones;
• estilo de botao;
• estilo de cards.

Para Escrital, esperar detectar:

• WordPress/Astra/Elementor;
• fontes Google como Montserrat, Lato, Poppins/Figtree dependendo da pagina;
• paleta com azul institucional e tons neutros/cobre;
• CTAs arredondados;
• carrosseis/Swiper/Elementor;
• cookie banner.

Artifacts:

knowledge/design-system/tokens.json
knowledge/design-system/colors.json
knowledge/design-system/typography.json
knowledge/design-system/components-style.json

Definition of Done:

• tokens estao em JSON;
• cada token tem fonte/evidencia;
• tokens nao sao tratados como oficiais, e sim "observados".

Etapa 6 - Catalogar componentes

Objetivo: mapear componentes da interface original.

Componentes esperados:

• navbar desktop;
• navbar mobile;
• hero;
• CTA WhatsApp;
• stats strip;
• cards de servicos;
• galeria do escritorio;
• carrossel de logos;
• lista/carrossel de posts;
• contato;
• footer;
• cookie consent.

Para cada componente:

• screenshot;
• pagina;
• selector hint;
• descricao visual;
• comportamento;
• tokens usados;
• estados capturados;
• score de confianca;
• riscos de copia.

Artifacts:

knowledge/components/navbar/component.json
knowledge/components/hero/component.json
knowledge/components/service-card/component.json
knowledge/components/gallery/component.json

Definition of Done:

• pelo menos 8 componentes catalogados;
• screenshots dos componentes existem;
• cada componente tem descricao e tokens.

Etapa 7 - Motion e interacoes

Objetivo: capturar comportamento visual.

Executar:

• hover em links e botoes;
• abrir menu mobile;
• abrir accordions se existirem;
• navegar carousel quando seguro;
• focus em campos;
• scroll lento e rapido;
• coletar document.getAnimations();
• capturar CSS transition/animation computed styles;
• gravar video curto de scroll da home.

Artifacts:

knowledge/animations/timeline.json
knowledge/animations/observed-transitions.json
artifacts/videos/home-scroll.mp4

Definition of Done:

• animacoes CSS/Elementor visiveis registradas;
• video de scroll existe no perfil deep;
• se nao houver motion relevante, registrar explicitamente.

Etapa 8 - UX/UI analysis

Objetivo: transformar artifacts em conhecimento util.

Gerar:

• arquitetura da informacao;
• hierarquia visual;
• CTA principal/secundario;
• pontos fortes;
• pontos fracos;
• oportunidades de melhoria;
• guia de recriacao sem copia.

Para Escrital, avaliar:

• clareza da proposta acima da dobra;
• densidade dos cards de servicos;
• uso das fotos do escritorio como prova de confianca;
• presenca de credenciais como ISO/CRC;
• visibilidade do contato/WhatsApp;
• performance de carrosseis e plugins;
• consistencia mobile.

Artifacts:

knowledge/ux/information-architecture.md
knowledge/ux/ui-analysis.md
knowledge/documentation/agent-style-guide.md
knowledge/documentation/improvement-plan.md

Definition of Done:

• relatorio aponta melhorias concretas;
• nao recomenda copia literal;
• inclui "o que preservar" e "o que modernizar".

Etapa 9 - Estrategia de melhoria visual

Objetivo: definir como a nova versao sera melhor que a original.

Direcao recomendada para contabilidade B2B:

• visual mais limpo e premium;
• hero com proposta mais objetiva;
• CTA fixo e claro;
• prova social acima da dobra;
• cards de servico mais escaneaveis;
• secao "como funciona" com 3 passos;
• secao de diferenciais com foco em seguranca fiscal, previsibilidade e BPO;
• fotos do escritorio com tratamento editorial;
• blog mais discreto;
• contato final com formulario/WhatsApp;
• performance superior, sem excesso de plugins;
• acessibilidade melhor.

Layout sugerido:

1. header sticky;
2. hero com headline forte, subcopy, CTA e card de metricas;
3. faixa de confianca: 35 anos, 1000+ clientes, ISO, CRC;
4. servicos em cards;
5. "como a Escrital ajuda";
6. escritorio/galeria;
7. diferenciais;
8. posts recentes;
9. CTA final;
10. footer.

Definition of Done:

• wireframe textual aprovado;
• assets definidos como autorizados ou substitutos;
• tokens finais definidos.

Etapa 10 - Gerar demo

Objetivo: criar site estatico melhorado.

Stack recomendada para demo:

• Vite + React + TypeScript;
• CSS modules ou Tailwind;
• lucide-react para icones;
• imagens locais otimizadas;
• build estatico.

Tambem e aceitavel gerar HTML/CSS puro no MVP, desde que:

• seja responsivo;
• tenha CSS limpo;
• nao dependa de CDN externa desnecessaria;
• passe nos testes visuais.

Estrutura:

generated/demo/
  package.json
  src/
  public/
    assets/
  dist/

Regras:

• nao copiar classes do Elementor/Astra;
• nao reaproveitar CSS do alvo;
• nao hotlinkar imagens do alvo;
• usar assets locais autorizados/substitutos;
• copy pode ser inspirada, mas deve ser reescrita;
• incluir meta title/description novos;
• incluir favicon proprio ou autorizado.

Definition of Done:

• npm run build passa;
• dist/index.html existe;
• mobile e desktop sem quebra;
• nenhuma imagem externa de escrital.com.br no HTML final.

Etapa 11 - Gerar subdominio unico

Objetivo: criar example<ID>.clsolucoes.com sem colisao.

Algoritmo:

1. obter lista de websites do CyberPanel:

cyberpanel listWebsitesJson

2. listar pastas locais:

find /home -maxdepth 1 -type d -name 'example*.clsolucoes.com'

3. consultar Cloudflare por registros example* quando houver API;
4. escolher proximo ID numerico livre:

example1.clsolucoes.com
example2.clsolucoes.com
...
example<ID>.clsolucoes.com

5. usar lock para evitar corrida:

flock /tmp/fie-example-domain.lock -c "node scripts/allocate-domain.js"

Regras:

• se example11.clsolucoes.com existir, nao reutilizar;
• se dominio existe em CyberPanel ou Cloudflare, incrementar;
• gravar dominio em reports/deploy.json;
• nunca deletar exemplos antigos automaticamente.

Definition of Done:

• dominio unico reservado;
• deploy.json contem previewDomain.

Etapa 12 - Criar site no CyberPanel

Objetivo: preparar webroot no servidor.

Comando:

cyberpanel createWebsite \
  --package Default \
  --owner admin \
  --domainName "$PREVIEW_DOMAIN" \
  --email [email protected] \
  --php 8.1 \
  --ssl 0 \
  --dkim 0 \
  --openBasedir 1

Validar:

ls -la "/home/$PREVIEW_DOMAIN/public_html"
curl --resolve "$PREVIEW_DOMAIN:80:$SERVER_IP" "http://$PREVIEW_DOMAIN/"

Definition of Done:

• /home/$PREVIEW_DOMAIN/public_html existe;
• servidor responde pagina padrao.

Etapa 13 - Criar DNS no Cloudflare

Objetivo: apontar o subdominio para a VPS.

Usar token Cloudflare existente no servidor quando autorizado. Nao imprimir segredos.

Registro:

Type: A
Name: example<ID>
Content: 147.93.15.29
Proxy: true
TTL: auto

Validar:

dig @1.1.1.1 +short "$PREVIEW_DOMAIN" A
curl -I "https://$PREVIEW_DOMAIN"

Definition of Done:

• DNS responde Cloudflare;
• HTTP/HTTPS chegam no servidor.

Etapa 14 - Emitir SSL

Objetivo: origin com certificado valido.

Comando:

cyberpanel issueSSL --domainName "$PREVIEW_DOMAIN"

Validar origin:

curl -I --resolve "$PREVIEW_DOMAIN:443:$SERVER_IP" "https://$PREVIEW_DOMAIN/"

Definition of Done:

• SSL emitido;
• curl origin HTTPS retorna 200/301 sem certificado self-signed.

Etapa 15 - Publicar build

Objetivo: copiar demo para o webroot.

Passos:

WEBROOT="/home/$PREVIEW_DOMAIN/public_html"
BACKUP="$WEBROOT/index.cyberpanel-default-$RUN_ID.html"

cp "$WEBROOT/index.html" "$BACKUP" || true
rsync -a --delete generated/demo/dist/ "$WEBROOT/"
chown -R "$(stat -c '%U:%G' "/home/$PREVIEW_DOMAIN")" "$WEBROOT"
find "$WEBROOT" -type d -exec chmod 755 {} \;
find "$WEBROOT" -type f -exec chmod 644 {} \;

Validar:

curl -sS "https://$PREVIEW_DOMAIN/" | rg "<title>|Escrital|Contabilidade"
curl -I "https://$PREVIEW_DOMAIN/"

Definition of Done:

• site publicado;
• assets carregam localmente;
• sem pagina padrao do CyberPanel.

Etapa 16 - QA visual e tecnico

Objetivo: garantir que o exemplo esta bom.

Checks obrigatorios:

• Playwright screenshot desktop 1440;
• Playwright screenshot mobile 390;
• links principais funcionam;
• WhatsApp abre;
• formulario, se houver, nao envia para endpoint inexistente sem feedback;
• sem overflow horizontal no mobile;
• Lighthouse ou checagem basica de performance;
• Axe sem erros graves;
• nenhuma URL externa do alvo no HTML final quando ASSET_USE_MODE!=authorized;
• nenhuma imagem quebrada;
• HTTPS OK.

Artifacts:

reports/qa-desktop.png
reports/qa-mobile.png
reports/lighthouse.json
reports/axe.json
reports/final-checklist.md

Definition of Done:

• screenshots aprovados;
• status HTTP 200;
• sem broken images;
• relatorio final criado.

Etapa 17 - Relatorio final

Criar:

reports/FIE-RUN-REPORT.md
reports/deploy.json
reports/asset-rights.md
reports/final-checklist.md

O relatorio deve conter:

• URL alvo;
• data e run id;
• paginas coletadas;
• assets coletados;
• modo de uso de assets;
• melhorias aplicadas;
• dominio publicado;
• comandos principais executados;
• riscos/pendencias;
• proximos passos.

Definition of Done:

• usuario consegue abrir a URL publicada;
• Claude informa exatamente o que foi feito;
• pendencias juridicas/de assets ficam explicitas.

Contratos de CLI esperados

Quando implementado, o fluxo ideal deve ser:

fie collect https://escrital.com.br \
  --profile standard \
  --asset-use reference \
  --run-id "$RUN_ID"

fie analyze "runs/escrital.com.br/$RUN_ID"

fie generate-demo "runs/escrital.com.br/$RUN_ID" \
  --template landing-modern-accounting \
  --asset-use replace

fie deploy-example "runs/escrital.com.br/$RUN_ID" \
  --base-domain clsolucoes.com \
  --prefix example

Atalho fim a fim:

fie run https://escrital.com.br \
  --profile standard \
  --asset-use replace \
  --publish-example

Exemplo de deploy.json

{
  "targetUrl": "https://escrital.com.br",
  "runId": "20260710133000",
  "previewDomain": "example12.clsolucoes.com",
  "webroot": "/home/example12.clsolucoes.com/public_html",
  "serverIp": "147.93.15.29",
  "cloudflare": {
    "zone": "clsolucoes.com",
    "recordType": "A",
    "proxied": true
  },
  "ssl": {
    "provider": "letsencrypt",
    "status": "issued"
  },
  "assetUseMode": "replace",
  "publishedAt": "2026-07-10T13:30:00Z"
}

Prompt operacional para Claude

Use este bloco quando pedir para Claude executar:

Voce e o executor do FIE. Siga o documento
docs/FIE-CLAUDE-RUNBOOK-ESCRITAL.md.

Alvo: https://escrital.com.br
Objetivo: coletar, analisar, recriar uma versao melhorada e publicar em um
subdominio unico example<ID>.clsolucoes.com.

Regras:
- nao copiar HTML/CSS literal;
- nao publicar imagens do alvo sem ASSET_USE_MODE=authorized;
- se nao houver autorizacao explicita, use assets coletados apenas como
  referencia e gere/substitua imagens no demo;
- nao hotlinkar imagens do alvo;
- criar manifest de assets;
- criar relatorio final;
- validar desktop/mobile/HTTPS.

Execute do zero ao deploy e pare apenas se houver bloqueio real.

Checklist resumido 0-100%

• criar/validar projeto FIE;
• resolver https://escrital.com.br;
• coletar robots/sitemap;
• abrir home com Playwright;
• capturar screenshots/DOM/texto/network;
• descobrir paginas principais;
• coletar imagens e assets com manifesto;
• extrair tokens;
• catalogar componentes;
• analisar motion/interacoes;
• gerar UX/UI report;
• definir plano de melhoria;
• gerar demo novo;
• escolher example<ID>.clsolucoes.com livre;
• criar website CyberPanel;
• criar DNS Cloudflare;
• emitir SSL;
• publicar build;
• rodar QA desktop/mobile;
• validar assets e links;
• entregar relatorio e URL final.

Pontos de atencao especificos para Escrital

1. Fotos do escritorio sao valiosas para confianca. Se autorizadas, usar com tratamento melhor: crop consistente, overlay leve, legenda e grid responsivo.
2. Logos de clientes podem ter restricoes. Se nao houver autorizacao, nao publicar no demo; substituir por prova social anonima.
3. Blog deve ser secundario na landing melhorada. Mostrar poucos posts para nao dispersar o CTA.
4. CRC, ISO e encarregado de dados devem ser preservados se forem dados publicos/autorizados, pois aumentam confianca.
5. WhatsApp deve ser CTA principal, mas com alternativa de contato por email e telefone.
6. Performance deve melhorar ao evitar excesso de plugins WordPress no demo.
7. Mobile e prioridade: menu, CTA sticky e cards precisam ficar densos, mas confortaveis.

Criterio final de aceite

O trabalho esta completo quando:

• o FIE gerou artifacts verificaveis do alvo;
• as imagens foram coletadas e classificadas por direito de uso;
• o demo melhorado esta publicado em https://example<ID>.clsolucoes.com;
• o demo nao e clone literal;
• o visual e claramente mais moderno e profissional;
• desktop e mobile foram validados;
• SSL esta funcionando;
• relatorio final explica o que foi coletado, usado, substituido e melhorado.