# ENTREPLANO Arquitetura — contrato de briefing de teste

## Finalidade e fontes de conteúdo

`site.json`, versão `1.1.0`, é a fonte canônica de textos, catálogo, categorias, CTAs, campos, estados e regras. `brand.json` define identidade, voz, dados narrativos e decisões fictícias em `assumptions`. `copy.md` reproduz integralmente ambos os JSONs. A versão identifica este contrato próprio, não um schema universal. Os schemas de payload e registro são JSON Schema Draft 2020-12, em `interest.payloadSchema` e `interest.recordSchema`.

ENTREPLANO Arquitetura é uma marca fictícia de portfólio. Casa do Intervalo e Casa em Camadas são estudos residenciais; Sala Contínua é de interiores; Ponto de Encontro é comercial. Não há obra executada, cliente, endereço de obra, área, ano de execução, preço, orçamento, resultado, prêmio ou qualificação alegados. Não há equipe nominal, CAU ou RRT inventados. Endereço e horário do estúdio são narrativos e explicitamente ilustrativos. WhatsApp, telefone comercial, e-mail e Maps são `null`; não renderizar contato externo a partir desses valores.

A conversão `architecture_brief` registra somente um briefing inicial de TESTE. Não inicia projeto, visita, agenda, contratação, cálculo técnico, orçamento ou comunicação com o visitante. A descrição de escopo e processo serve para explicar relações entre uso, espaço e decisões; não substitui levantamento ou documentação de um projeto real.

## Portfólio, páginas e mídia

Âncoras da landing: `inicio`, `projetos`, `escopo`, `processo`, `estudio`, `duvidas`, `briefing`, `primeiro-passo`, `privacidade`. `sections` contém seis seções centrais; hero, CTA final e privacidade fornecem as demais âncoras. `projects` e `faq` são coleções referenciadas por `contentRef`, não seções adicionais. `locationRef` e `hoursRef` apontam para `brand.json`.

| ID do estudo | Categoria/tipo | Slug e rota estática | Mídia |
| --- | --- | --- | --- |
| `casa-intervalo` | `residencial` | `/projetos/casa-do-intervalo/` | `entreplano-casa-intervalo` |
| `casa-camadas` | `residencial` | `/projetos/casa-em-camadas/` | `entreplano-casa-camadas` |
| `sala-continua` | `interiores` | `/projetos/sala-continua/` | `entreplano-sala-continua` |
| `ponto-encontro` | `comercial` | `/projetos/ponto-de-encontro/` | `entreplano-ponto-encontro` |

Cada detalhe contém introdução, intenção, luz, circulação e materialidade, legenda, limite conceitual e CTAs. Gerar as quatro páginas estaticamente, usando `projects[].detail`; não depender de parâmetros ou JavaScript para ler o estudo. Header em detalhes usa links de âncoras prefixados por `/`, como `/#escopo`, preservando as ações de conversão descritas abaixo. A galeria filtra `categoryId` por `all|residencial|interiores|comercial`; tags são descritivas, não novos enums do briefing. Sem JavaScript, mostrar todos os cartões e seus links. Um filtro não muda seleção do formulário. Contagens da galeria se referem a estudos, nunca a obras realizadas.

Quatro imagens próprias correspondem aos quatro estudos. Os IDs de mídia são referências de conteúdo, não prova de arquivo disponível. Não copiar fotografias, plantas, fachadas, textos ou edifícios identificáveis das referências profissionais. Hero usa o mesmo `projectId` e `mediaId` de Casa do Intervalo. Detalhes reutilizam a imagem do respectivo estudo. Recortes e ampliações mantêm a mesma identidade espacial; não sugerem outro ambiente, outra obra ou uma galeria documental. Texto fica em HTML, não gravado nas imagens. Falta de mídia mostra `ui.imageUnavailable`, sem substituição por obra de terceiros. Conteúdo não fixa paleta, layout ou direção visual.

`page.demoBanner` deve permanecer legível em landing, detalhes e `/demo`, sem cobrir controles. Projetos, footer e formulário reforçam ficção em seus próprios textos. Não repetir mensagens diagnósticas em toda seção. Os campos `ui`, `labels`, `states`, `help` e `error` contêm textos públicos humanos; regras técnicas e schemas não são helpers.

## CTA e pré-seleção

CTA na landing: `href:#briefing`, `action:open_brief`. CTA de estudo define `projectId` e `projectType` compatíveis; genérico usa ambos `null` e preserva a seleção atual. Nunca converter `null` de CTA genérico em Não sei. Não sei é uma escolha explícita.

Em detalhe, o CTA liga a `/?project=ID#briefing`, com ID do catálogo e nenhuma PII. Ler `project` uma única vez na inicialização; aceitar somente um valor exato do catálogo. Parâmetro vazio, repetido ou desconhecido não altera seleção e anuncia `invalidReference`; remover o parâmetro com `history.replaceState` mantendo `#briefing`, sem reconstruir a URL com dados do formulário. Parâmetro válido preseleciona referência e tipo apenas quando o estado permitir; consumir e remover o parâmetro para que edição posterior não seja sobrescrita em rerender. Não serializar nome, telefone, tokens ou estado pendente em URLs. Ao restaurar pendência, seu payload e destino imutáveis prevalecem sobre qualquer query; não aplicar pré-seleção depois da reconciliação sem novo acionamento.

Mudar tipo conserva referência somente se compatível. Trocar para outro tipo ou Não sei limpa `projectId` e anuncia `referenceRemoved`. Escolher tipo manualmente não infere estudo. Remover referência mantém o tipo. CTA de outro estudo compatível pode trocar referência antes de iniciar operação. Foco vai para `briefing_heading`, distinto do ID da seção. Um link conserva destino útil sem JS e nunca simula envio.

## Guard síncrono e coordenação

Toda operação de criação, reconciliação, cancelamento, exclusão ou limpeza começa verificando o guard e pendências, e adquirindo um guard síncrono compartilhado (por exemplo, `useRef`), antes de validação assíncrona, SHA-256, Web Lock ou rede. Um `setState` de loading e botões desabilitados não bastam: handlers de cartões, CTAs genéricos, referência, edição, voltar, novo teste, fallback e troca de modo/destino também consultam o guard. A verificação e aquisição devem acontecer antes de qualquer `await`, inclusive a espera por `navigator.locks.request`.

Capturar um snapshot normalizado e imutável. Enquanto espera o lock, mostrar `waitingLock` e impedir alterações. Dentro do lock `entreplanoDemo:architecture-briefs:v1`, reler registros, ledger e pending; abortar mutação conflitante. Liberar guard em `finally` após concluir ou instalar bloqueio durável de pending. Esse bloqueio continua depois de liberar a trava temporária e após reload. Uma operação inválida sem efeito pode liberar guard e devolver edição. Navegação comum e leitura dos estudos continuam permitidas; navegar não altera o teste.

Eventos `storage` atualizam lista, contagens e bloqueios entre abas. Sem Web Locks, anunciar `noWebLocks`, reler e deduplicar antes de escrever e recomendar uma única aba; não alegar atomicidade equivalente. Guard protege a operação na instância; não substitui lock, ledger e verificação de persistência. Após cancelamento/destruição do componente, não liberar pending desconhecido nem alterar o snapshot.

## Campos e payload normalizado

Payload possui exatamente dez propriedades, todas obrigatórias no objeto e nesta ordem para fingerprint. Campos opcionais da interface aparecem como `null`; extras são rejeitados. Não coagir tipos, booleanos, enums ou índices de seleção.

| Campo | Regra |
| --- | --- |
| `schemaVersion` | String constante `1.1.0`. |
| `brandId` | String constante `entreplano-arquitetura-demo`. |
| `requestId` | UUID v4 minúsculo gerado uma vez por tentativa. |
| `kind` | String constante `architecture_brief`. |
| `projectType` | `residencial`, `interiores`, `comercial` ou `nao_sei`; escolha obrigatória. |
| `stage` | `explorando`, `organizando`, `definindo_escopo` ou `null`; escolha opcional. |
| `projectId` | ID do catálogo ou `null`; se presente, tipo deve coincidir com `projects[].projectType`. Não sei exige `null`. |
| `name` | String fictícia, trim → NFC → 2 a 80 pontos de código. |
| `phone` | String fictícia: limite bruto de 20 pontos de código antes de remover caracteres; resultado com 10 ou 11 dígitos ASCII. |
| `demoAcknowledged` | Booleano constante `true`; checkbox desmarcado por padrão. |

```json
{"schemaVersion":"1.1.0","brandId":"entreplano-arquitetura-demo","requestId":"123e4567-e89b-42d3-a456-426614174000","kind":"architecture_brief","projectType":"residencial","stage":null,"projectId":"casa-intervalo","name":"Pessoa de teste","phone":"00000000000","demoAcknowledged":true}
```

Nome: verificar tipo, rejeitar controles Unicode Cc e substitutos isolados antes de trim, normalizar NFC e medir com `Array.from(value).length`, não unidades UTF-16 ou bytes. Nome já normalizado não pode exceder o limite. Sem quebras de linha. Telefone: verificar tipo, controles, substitutos e comprimento bruto antes de remover tudo fora de `[0-9]`; validar `^[0-9]{10,11}$`. Não converter dígitos de outras escritas, adicionar `55`, truncar ou validar titularidade. `00000000000` é um exemplo de teste aceito, não contato. O limite bruto é de entrada no cliente; servidor recebe somente telefone normalizado e revalida seu padrão. Servidor revalida tipos, constantes, enums, trim/NFC, pontos de código e compatibilidade da referência. Schema não substitui essas verificações semânticas.

Não há cidade, endereço exato, relato livre, arquivo, documento, CPF, e-mail, orçamento numérico, medida, cálculo ou campo condicional adicional. Etapa não abre novos campos. Busca da gestão não entra no payload. Catálogo autorizado do servidor contém os IDs e tipos do contrato; nunca aceitar catálogo, nomes ou categorias enviados pelo cliente como fonte de verdade.

## Registro, ledger e armazenamento local

Modo padrão `demo_local`. Registros: `entreplanoDemo:architecture-briefs:v1`; intenção pendente: mesmo namespace com `:pending`; ledger: mesmo namespace com `:ledger`. Não acessar ou limpar dados de outros portfólios. Registros são array de objetos válidos por `interest.recordSchema`: payload completo mais `recordId`, `createdAt`, `status`, `cancelledAt`, `mode`. `recordId` é UUID vinculado permanentemente à tentativa e diferente de `requestId`. Timestamp ISO-8601 UTC. `received` exige `cancelledAt:null`; `cancelled` exige timestamp. Modos `demo_local|demo_remote`. Sem tokens ou capabilities nos registros.

Local: validar → guard síncrono → snapshot → lock → reler → preservar intenção/ledger → escrever registro → reler/validar → finalizar ledger → confirmar. A ordem do guard precede qualquer trabalho assíncrono; a validação síncrona pode ocorrer dentro dele. Ledger guarda marca, nonce, fingerprint, estado e resultado/ponteiro. Permite recuperar interrupção entre as escritas sem criar outra linha. Mesmo nonce/payload devolve resultado anterior; mesmo nonce/payload diferente é conflito sem mutação. Não deduplicar por nome ou telefone. Cancelamento não pode ser revertido por replay de criação; exclusão individual deixa tombstone no ledger.

Sucesso só após escrita e releitura válida; falha preserva campos, identificador e recuperação. JSON inválido ou schema corrompido não é sobrescrito silenciosamente. Pending ilegível bloqueia mutações e limpeza até recuperação verificável. Sem pending, limpeza confirmada pode remover registros e ledger exclusivamente locais; não remove prova de tentativa remota não resolvida. Limpeza encerra o histórico exclusivamente local e sua proteção contra replay; retries antigos não podem ser agendados após reset. Reset não envia exclusão remota nem recria registros apagados.

## Revisão, estados e gestão

Fluxo: dados → validação → revisão → operação → resultado confirmado. Revisão apresenta tipo, etapa (Sem informação), referência (Sem estudo de referência), nome/telefone fictícios e destino. `invalid` preserva campos e mostra resumo de erros. `loading`, `waitingLock`, `pending` e `reconciling` nunca mostram sucesso. `successLocal` e `successRemote` exigem persistência verificável; resultado cancelado usa `cancelled`, sem nova recepção. `rejected` só aparece com prova terminal de não aceitação; resposta insuficiente usa `unverifiedRejection`. Confirmação remota com falha de cache usa `remoteAcceptedLocalCacheError` e continua bloqueada até recuperação consistente.

`/demo` mostra registros válidos deste navegador. Métricas globais: total, recebidos, cancelados. Contagem por tipo inclui recebidos de todo o conjunto válido, os quatro tipos e zeros. Filtros de tipo, status, etapa, referência e busca combinam com AND e mudam somente a lista/contagem filtrada. `all` é sem filtro; `unset` representa `null` e não é enum do payload. Busca compara nome fictício ou código com trim, NFC e comparação sem distinção de maiúsculas/minúsculas, até 80 pontos de código. Não pesquisar ou persistir telefone na busca. Base vazia e filtro sem resultados têm textos distintos.

Não exibir receita, ocupação, agenda, clientes, áreas de obra ou projetos executados. Consulta remota administrativa é uma visão privada separada; não somar cópia local e registro remoto. A demo local não possui autenticação comercial e não deve receber dados reais.

Cancelar exige confirmação; recebido muda para cancelado com timestamp. Repetição é idempotente; cancelado não volta a recebido. Excluir cópia e limpar exigem confirmação e afetam apenas storage local. Nenhuma dessas ações é permitida durante guard ou pending de criação/cancelamento/exclusão. Exclusão local de cópia remota conserva proteção de replay e não chama exclusão remota automaticamente. Exclusão remota exige admin, confirmação e ledger durável preservado. Não existe limpeza remota pública em lote.

Navegação, projetos e FAQ devem funcionar sem JS. O formulário usa `ui.noJavascript` sem simular envio. Erros associados aos campos e a resumo; loading e resultado anunciados em região viva. Foco visível, controles com rótulos, estados identificados por texto e diálogos com retorno de foco. Não injetar conteúdo de payload como HTML.

## GAS opcional: destino e autorização

`PUBLIC_DEMO_GAS_ENDPOINT` começa vazio e `integration.gasEndpoint` é `""`. Configurar URL não prova serviço ativo. Remoto exige endpoint efetivo visível, escolha explícita de modo, aceite de demo, opt-in remoto separado desmarcado por padrão e autorização válida. Opt-in é condição da UI, não propriedade do payload. Alterar modo/destino antes de uma tentativa invalida opt-in anterior; durante pending é proibido. Não enviar automaticamente nem migrar registros locais. Sem endpoint, remoto indisponível e local acessível.

POST direto com JSON em `Content-Type:text/plain;charset=UTF-8`; não criar proxy extra. Resposta deve ser legível e validada no navegador. `no-cors`, corpo opaco, timeout, HTML, falha de parse ou HTTP 200 isolado deixam resultado desconhecido. CORS, Origin e Content-Type não são autorização; não alegar CORS arbitrariamente configurável no GAS. Health positivo não comprova criação, idempotência ou persistência externa.

Único `doGet` público: `?op=health` retorna exatamente `{ok,schemaVersion,brandId}`, sem PII, IDs, contagens, catálogo pessoal ou disponibilidade. Operações privadas via `doPost` autenticado. Envelope exato `{op,authToken,payload}`; extras são rejeitados. Token de usuário/admin e capability de cancelamento somente em RAM, nunca URL, storage, export, log, ZIP ou variável `PUBLIC_*`. Segredos de servidor em Script Properties ou armazenamento privado. Reload pede nova autorização, preservando intenção. Remover autorização da página não elimina pending.

Corpo máximo 8.192 bytes UTF-8; token/capability não vazios até 512 pontos de código, sem controles ou substitutos. Fingerprint com 64 caracteres hex minúsculos; UUIDs de tentativa/operação v4 minúsculos. Revalidar payload no servidor e neutralizar interpretação de fórmula em células Sheets ao gravar strings, preservando a representação canônica para comparação. Rate limit, retenção, rotação/revogação e permissões de usuário/admin pertencem ao operador. Autorização não depende apenas de UUID ou conhecimento da URL. Não registrar PII ou segredos em logs. O contrato não certifica segurança ou autenticação comercial.

## Operações e respostas

| Operação | Campos exatos em payload | Autoridade |
| --- | --- | --- |
| `register_brief` | Dez campos de `interest.payloadSchema` | Usuário autorizado |
| `request_status` | `brandId,requestId,fingerprint` | Dono da tentativa ou admin |
| `cancel_record` | `brandId,requestId,recordId,operationId,cancelCapability` | Dono autorizado com capability, ou admin com capability privada |
| `list_records` | `brandId` | Admin |
| `delete_record` | `brandId,recordId,operationId` | Admin e confirmação |

`operationId` é UUID estável por cancelamento/exclusão; retry usa o mesmo, nunca outro alvo. Capability vincula marca, tentativa e registro. Servidor calcula fingerprint da criação; cancelamento/status usam o original. Todas as respostas privadas incluem `schemaVersion,brandId,op,ok,outcome`. `outcome` é `received|cancelled|pending|rejected`. Criação/status também incluem `requestId,fingerprint`; cancelamento/exclusão incluem `operationId,recordId`. Validar correspondência exata com a operação e tentativa esperadas, incluindo payload completo do registro normalizado e seus metadados. `ok:true` sozinho não confirma nada.

Criação/status accepted retornam `ok:true,outcome:received,record` válido após persistência verificada, com `record.status:received`. Resultado já cancelado retorna `outcome:cancelled,record.status:cancelled`; não ressuscitar. Capability só em resposta privada, recuperável por status autorizado após reload e guardada em RAM. Pending retorna `ok:false,outcome:pending`. Resultado inválido mantém unknown, sem assumir rejeição.

Listagem admin concluída: `ok:true,outcome:received,records:[...]`; received significa leitura concluída, não novos briefings. Validar todos os registros, não converter falha em lista vazia. Exclusão admin concluída: `ok:true,outcome:cancelled,deleted:true,recordId,operationId`; esse outcome encerra a operação, não cria briefing cancelado. Ledger conserva tombstone. Status de tentativa anteriormente aceita e excluída retorna `outcome:cancelled,deleted:true,accepted:true`, IDs e fingerprint correspondentes, sem PII do registro removido. Interface confirma exclusão e nunca oferece fallback de não aceitação.

Rejeição definitiva de criação exige `ok:false,outcome:rejected,definitive:true,accepted:false,tombstoned:true`, código `VALIDATION|UNAUTHORIZED|NONCE_CONFLICT|REJECTED_FINAL`, marca/requestId/fingerprint correspondentes e ausência comprovada de registro dessa tentativa. Tombstone gravado antes da resposta. Sem essa prova, pending permanece. Falta de autorização, conflito com outro fingerprint ou not-found isolado não encerram a tentativa original. Um conflito não autoriza tombstone que destrua nonce já aceito ou pendente com outro payload. Rejeição sem identidade válida explica erro de entrada, mas não prova terminalidade de intenção enviada.

## Fingerprint, intenção durável e reconciliação

Normalizar e validar → gerar requestId uma vez → serializar JSON em ordem `integration.contract.payloadFields`, com null explícito e sem espaços → UTF-8 → SHA-256 hex minúsculo. Excluir credenciais, opt-in e metadados. Antes da primeira rede, gravar e reler intenção:

```text
{schemaVersion,brandId,op:"register_brief",requestId,fingerprint,payload,
 mode:"demo_remote",endpoint,state:"pending",createdAt}
```

Payload, destino e identidade imutáveis; não iniciar rede sem intenção preservada. Reload, fechamento, retry e timeout conservam nonce. Pending bloqueia editar, nova tentativa, CTAs que alteram seleção, referência, reset, delete, mudança de modo/endpoint e fallback. Pending ilegível nunca é apagado para destravar. Reconciliar com POST status autorizado ou repetir criação com os mesmos dados/nonce. Not-found sozinho mantém pending porque requisição anterior ainda pode concluir.

Servidor usa `LockService.getScriptLock()` com espera limitada e liberação em `finally`. Sob lock: ler ledger durável por marca+nonce → comparar fingerprint → gravar intenção antes do efeito → procurar registro por chave única → escrever no máximo uma vez → verificar registro → finalizar ledger antes de responder. Sheets não tem transação multiaba; recuperação repara interrupção entre linha e ledger pelo mesmo vínculo, sem duplicação. Ledger não pode ser só cache/RAM. Mesmo nonce/dados devolve resultado anterior; dados diferentes são conflito sem mutação. Rejeição terminal impede aceitação tardia; exclusão impede replay; cancelamento impede reativação. Retenção conserva proteções enquanto retries/replays forem possíveis.

Após received/cancelled verificado, atualizar e reler cópia/ledger local antes de encerrar pending. Se cache falhar após aceitação remota, usar `remoteAcceptedLocalCacheError`, recuperar o mesmo registro e manter bloqueio; nunca criar novo. Deleted terminal remove cópia com ledger preservado e sem fallback. Rejeição validada não é sucesso: conservar tombstone e resolver intenção. Só depois oferecer escolha explícita de novo teste local, com NOVO nonce e ledger próprio, ou novo envio corrigido. Nunca transformar nonce rejeitado em recebido.

Cancelamento remoto prepara e relê `{schemaVersion,brandId,op:"cancel_record",requestId,recordId,operationId,fingerprint,mode,endpoint,state,createdAt}`, sem capability/token. Resultado desconhecido preserva status anterior e bloqueia mutações. Reload recupera capability por status privado e repete o mesmo operationId. Ledger de operação associa marca+operationId a tentativa/registro e conserva resultado. Exclusão remota usa intenção equivalente `op:delete_record`, com requestId/fingerprint vinculados ao registro conhecido na intenção e operationId estável; seu payload de rede segue a tabela. Não reutilizar operationId nem apagar ledger com registro.

## Downloads e limites

Recursos em `resources.links` possuem `enabled:false`. Regra: `enabled && arquivoExisteNoBuild`. Não exibir botão ativo para arquivo ausente ou desabilitado. Fonte ZIP, Code.gs, guia e contrato são recursos demonstrativos; não incluem storage, credenciais ou dados e não comprovam endpoint ativo. O código-fonte inclui somente artefatos públicos necessários, nunca segredos.

Este contrato descreve comportamento requerido; não atesta execução de GAS, persistência Sheets, entrega de mensagens, prontidão comercial, conformidade ampla ou prestação profissional. Uso real exige identidade/registro verificáveis, escopo verdadeiro, responsabilidade técnica cabível, conteúdo autorizado e avaliação específica. Não preencher esses requisitos com números fictícios.

## Referências primárias e limites editoriais

- [CAU/BR — Resolução 75/2014](https://transparencia.caubr.gov.br/resolucao75/): arts. 1–3 e 11–13 tratam de identificação de responsáveis, título/registro e atividades em comunicação pública. **Inferência editorial:** não apresentar conceitos fictícios como obras de profissionais habilitados, nem inventar identificação para preencher exigências de uma operação real. Não é parecer de conformidade.
- [CAU/BR — base normativa de fiscalização](https://caubr.gov.br/fiscalizacao/base-normativa/resolucoes/): inclui referências à Resolução 75 (peças publicitárias) e 91 (RRT). **Limite:** índice e leitura documental não certificam integralmente vigência/aplicação em situação individual; não atribuir habilitação à marca.
- [CAU/BR — perguntas frequentes sobre RRT](https://transparencia.caubr.gov.br/perguntas-frequentes-registro-de-responsabilidade-tecnica-rrt/): relaciona o registro a atividades técnicas de arquitetura e urbanismo. **Inferência:** separar briefing de teste e estudo visual de documentação/serviço técnico real; não emitir nem simular RRT.
- [CAU/BR — súmulas e deliberações da CEP](https://transparencia.caubr.gov.br/sumulascep/): o índice de busca recupera referência a anteprojeto de revisão da Resolução 75 na Deliberação 24/2024. **Limite:** proposta de revisão não foi tratada como norma substitutiva. A pesquisa oficial não localizou ato de substituição; isso não prova inexistência ou atualização integral.
- [Studio MK27 — catálogo residencial oficial](https://mk27.com/category/houses/): página acessível organiza estudos/obras por categoria e links individuais; navegação também distingue interiores e comercial. **Inferência editorial:** catálogo primeiro e detalhe por estudo, sem importar nomes, imagens, geometria, prêmios, autores, claims ou textos. A navegação sustenta organização, não validação de qualidade ou DNA visual da ENTREPLANO.
- [Jacobsen Arquitetura — página oficial de projeto](https://jacobsenarquitetura.com/projetos/sede-do-campo-olimpico-de-golfe/): conteúdo oficial recuperado pelo índice de busca distingue ficha, autoria e narrativa sobre programa e circulação. **Inferência editorial:** explicar intenção e percurso separadamente. **Limite de acesso:** abertura direta retornou HTTP 403; conteúdo indexado pode estar defasado. Não houve captura DOM nem apropriação do projeto, paisagem, forma, ficha técnica ou imagens. Não reutilizar a forma descrita nessa obra nos estudos fictícios.

URLs pertencem às entidades e autores. Não indicam parceria, endosso, equivalência entre estúdios ou direitos sobre materiais. As inferências são decisões editoriais, não uma análise de conformidade. A pesquisa não fixa direção visual. Conteúdo e conceitos próprios permanecem descritos em `brand.assumptions`.