VXerys/brand-from-codebase

Marca a partir do código-fonte

Visão geral

O repositório do produto é a única fonte de verdade da marca. Um kit de marca é extraído uma vez em marketing-videos/<marca>/brand.md, cada valor carrega sua origem arquivo:linha, e o arquivo registra o commit do repositório no qual foi lido para que possa ser atualizado em vez de relido.

Contrato brand.md

Escreva estas seções, nesta ordem. Cada valor termina com sua origem como (caminho:linha).

1. Fontes: caminhos de repositórios, branch, git rev-parse --short HEAD por repositório, data de extração e um bloco legível por máquina por repositório que o gate G1 lê para detectar um kit desatualizado:

   ```refresh
   repo: <repositorio-produto>
   ref: HEAD
   commit: c8fb26e
   paths: src/data/content.ts src/app/globals.css public/brand
   ```
   

   repo é o nome da pasta em D:\Projects. Um repositório que não é git usa mtime: <data ISO> em vez de ref e commit.
2. Identidade: nome, posicionamento em uma linha, slogan, tom (cite o arquivo de cópia, não parafraseie).
3. Tokens de cor: primeiro tokens de marca semântica (--color-brand-*, primary, AppColors.primary), depois tokens de suporte. Uma tabela por superfície quando diferirem: landing vs app.
4. Tipografia: por superfície. Fontes de landing frequentemente diferem das fontes do app; verifique tanto o layout raiz quanto qualquer fonts.ts de seção.
5. Logotipos e imagens: caminhos de arquivo, se são renders reais do produto ou fotos de banco de imagens (fotos de banco nunca devem ser apresentadas como usuários reais) e seu arquivo de licença ou crédito.
6. Afirmações permitidas: funcionalidades, modos, preços, rótulos de CTA, URLs, contato. Cada uma é uma citação direta com origem. Marque dados de amostra como SAMPLE (renders com números fictícios) para que um vídeo os rotule como "Contoh".
7. Afirmações proibidas: qualquer coisa que pareça plausível, mas não tenha origem: contagens de usuários, receita, avaliações, depoimentos, logotipos de parceiros, "terpercaya", "#1".
8. Alvos de captura: URLs de produção e staging, rotas que valem a pena capturar, pastas de screenshots do app, URL da Play Store.
9. Ambiguidades: tokens duplicados ou conflitantes, cópia que difere entre site e app, valores que um briefing em outro lugar usa e que o código contradiz. Liste-os para o usuário; nunca resolva silenciosamente.

Lista de verificação de extração

O que procurar	Lugares típicos
Cópia, CTAs, preços	src/data/content.ts, src/content/*.ts, componentes de seção de landing, RELEASE_NOTES.md, docs/features/
Tokens web	globals.css @theme / :root, tailwind.config.*, palette.ts
Tokens Flutter	lib/core/constants/app_colors.dart, app_text_styles.dart, pubspec.yaml fontes
Fontes	app/layout.tsx (next/font), seção fonts.ts, pubspec.yaml
Logotipos	public/brand/, docs/brand/, assets/icons/brand/
URLs	grep -rn "https://<dominio-da-marca>" em src/, metadataBase, site.ts, páginas de termos

Pesquise por um valor antes de declará-lo ausente: grep o domínio, o texto do CTA e o nome do token em todo o src/.

Pule .env*, .mcp.json, google-services.json, keystores e qualquer chave ou token. Nunca copie seus valores para o brand.md.

Quando o repositório fonte não está disponível (sessões na nuvem)

O gate G1 reporta brand_repo_absent como informação e o G2 verifica cada afirmação contra as citações exatas no brand.md em vez do repositório (claim_verified_brand_kit). Isso só funciona quando o brand.md cita a cópia literalmente com caminho:linha, portanto extraia citações literalmente, nunca parafraseadas. Para atualizar o brand.md, o repositório é necessário: faça isso no laptop ou adicione o repositório do produto à sessão na nuvem e aponte MV_PROJECTS_ROOT para sua pasta pai.

Regra de atualização

O gate G1 executa git -C <repo> log --oneline <commit>..<ref> -- <paths> para cada bloco de refresh e falha com brand_stale quando algo mudou. Para corrigir, releia apenas os arquivos alterados, atualize suas linhas e atualize commit no bloco. Repositórios não git são comparados pela data de modificação do arquivo em relação a mtime.

Capturando UI real

Superfície do produto	Método
Site ao vivo	Captura de site HyperFrames a partir da URL de produção (a rota product-launch-video faz isso); staging apenas quando o usuário disser que a funcionalidade não foi lançada
Servidor dev local	Apenas quando o usuário solicitar uma tela não lançada; rotule como não lançada no briefing
App Flutter	Screenshots reais existentes (site screens/, assets da Play Store) ou screenshots do emulador, colocados em um quadro de dispositivo
Pequenos elementos animados (botão CTA, cartão de estatística)	Reconstruídos como HTML com os tokens do brand.md; nunca invente uma tela que não existe

Referências de afirmações do storyboard

Cada afirmação na tela no STORYBOARD.md carrega sua origem no brand.md, por exemplo "Biaya layanan 2%" (<repositorio-produto>/src/data/content.ts:212). Uma afirmação sem origem é cortada do storyboard, não suavizada.

Erros comuns

• Pegar o primeiro azul marinho encontrado (--navy-main) em vez do token de marca semântica (--color-brand-navy). Prefira nomes semânticos e liste o outro como ambiguidade.
• Usar fontes do app para um vídeo de landing page, ou o contrário.
• Declarar uma URL "não encontrada" após verificar um único arquivo.
• Mostrar fotos de banco de imagens como se fossem clientes.