MÓDULO 1.2

🧪 Ambiente de desenvolvimento

Prepare um ambiente seguro, observável e compatível com a natureza experimental da especificação.

6

Tópicos

3h

Carga

Builder

Nível

Laboratório

Tipo

0 de 60%
1

Ative um contexto seguro

O que é: A interface ModelContext é definida para SecureContext; HTTPS e localhost são a base mínima do laboratório.

Por que aprender: O teste correto separa ausência da API, configuração experimental e falha real do código.

Código localentrada observável Feature detectcontrato explícito Fallbackresultado verificável

Conceito aplicado

O contrato deve ser compreensível por quem usa, testável por quem desenvolve e limitado por quem opera. A ferramenta não substitui autorização, validação nem experiência visual.

const seguro = window.isSecureContext;
const webmcp = typeof document.modelContext !== 'undefined';
console.table({ seguro, webmcp });

Dica prática

Copie o exemplo, rode primeiro com dados locais e só depois conecte o backend. Mantenha logs sem dados pessoais e provoque pelo menos uma falha.

Checklist operacional

O objetivo da ferramenta cabe em uma frase.
A entrada inválida produz um erro compreensível.
O efeito aparece na interface para a pessoa.
O caminho manual funciona sem WebMCP.
Indo mais fundo: evidência mínima

Guarde a entrada usada, o estado anterior, o resultado devolvido e a alteração visível da página.

Anote também o comportamento sem suporte, durante cancelamento e diante de uma resposta não autorizada do backend.

Conceitos-chave

01

HTTPS em produção

02

localhost no laboratório

03

flag pode variar

04

origem importa

2

Monte Vite e Node sem acoplamento

O que é: Vite oferece servidor local e módulos ES; Node executa a automação do projeto, não a API WebMCP do documento.

Por que aprender: A separação permite desenvolver o site em qualquer browser e ativar WebMCP apenas por enhancement progressivo.

✓ Faça

  • ✓ Declare Node para tooling de forma observável.
  • ✓ Preserve Vite serve a página no fluxo manual.
  • ✓ Teste o resultado e o cancelamento.

✗ Evite

  • ✗ Esconder efeitos atrás de descrições vagas.
  • ✗ Confiar na tool como autorização.
  • ✗ Remover o fallback da interface.

Conceito aplicado

O contrato deve ser compreensível por quem usa, testável por quem desenvolve e limitado por quem opera. A ferramenta não substitui autorização, validação nem experiência visual.

npm create vite@latest webmcp-lab -- --template vanilla
cd webmcp-lab
npm install
npm run dev

Dica prática

Copie o exemplo, rode primeiro com dados locais e só depois conecte o backend. Mantenha logs sem dados pessoais e provoque pelo menos uma falha.

Checklist operacional

O objetivo da ferramenta cabe em uma frase.
A entrada inválida produz um erro compreensível.
O efeito aparece na interface para a pessoa.
O caminho manual funciona sem WebMCP.
Indo mais fundo: evidência mínima

Guarde a entrada usada, o estado anterior, o resultado devolvido e a alteração visível da página.

Anote também o comportamento sem suporte, durante cancelamento e diante de uma resposta não autorizada do backend.

Conceitos-chave

01

Node para tooling

02

Vite serve a página

03

API vive no Document

04

build não decide suporte

3

Implemente feature detection e fallback

O que é: Feature detection pergunta pela capacidade real no momento do uso, sem confiar em user-agent ou versão fixa.

Por que aprender: Como o draft muda, detectar a superfície disponível é mais durável do que codificar uma lista de navegadores.

1

Defina o contrato

Nome, descrição, entrada, resultado e limites ficam explícitos antes da implementação.

2

Observe a execução

Registre entrada, estado visível, cancelamento e saída sem expor dados sensíveis.

3

Verifique a evidência

A tool só está pronta quando o efeito e o retorno podem ser reproduzidos.

Conceito aplicado

O contrato deve ser compreensível por quem usa, testável por quem desenvolve e limitado por quem opera. A ferramenta não substitui autorização, validação nem experiência visual.

const modelContext = document.modelContext;
if (!modelContext) {
  habilitarFluxoManual();
  mostrarAviso('WebMCP indisponível; use o formulário.');
} else {
  registrarFerramentas(modelContext);
}

Dica prática

Copie o exemplo, rode primeiro com dados locais e só depois conecte o backend. Mantenha logs sem dados pessoais e provoque pelo menos uma falha.

Checklist operacional

O objetivo da ferramenta cabe em uma frase.
A entrada inválida produz um erro compreensível.
O efeito aparece na interface para a pessoa.
O caminho manual funciona sem WebMCP.
Indo mais fundo: evidência mínima

Guarde a entrada usada, o estado anterior, o resultado devolvido e a alteração visível da página.

Anote também o comportamento sem suporte, durante cancelamento e diante de uma resposta não autorizada do backend.

Conceitos-chave

01

teste a propriedade

02

fallback é funcional

03

mensagem é honesta

04

sem sniffing

4

Inspecione tools e eventos

O que é: DevTools, console e um inspector local ajudam a observar registro, troca de catálogo, entrada e resultado.

Por que aprender: Sem evidência, é fácil confundir uma tool bem registrada com uma tool realmente segura e utilizável.

💡 Teste de realidade

Implemente este tópico com um caminho feliz, uma entrada inválida e um cancelamento. Registre o que a pessoa viu e o que o agente recebeu.

Conceito aplicado

O contrato deve ser compreensível por quem usa, testável por quem desenvolve e limitado por quem opera. A ferramenta não substitui autorização, validação nem experiência visual.

document.modelContext?.addEventListener('toolchange', () => {
  console.info('[WebMCP] catálogo alterado');
});

Dica prática

Copie o exemplo, rode primeiro com dados locais e só depois conecte o backend. Mantenha logs sem dados pessoais e provoque pelo menos uma falha.

Checklist operacional

O objetivo da ferramenta cabe em uma frase.
A entrada inválida produz um erro compreensível.
O efeito aparece na interface para a pessoa.
O caminho manual funciona sem WebMCP.
Indo mais fundo: evidência mínima

Guarde a entrada usada, o estado anterior, o resultado devolvido e a alteração visível da página.

Anote também o comportamento sem suporte, durante cancelamento e diante de uma resposta não autorizada do backend.

Conceitos-chave

01

console estruturado

02

toolchange observável

03

inputs de teste

04

resultado capturado

5

Use types e polyfills com limites

O que é: Tipos ajudam o editor e um polyfill pode simular a superfície para testes, mas nenhum deles prova suporte nativo do agente no navegador.

Por que aprender: Distinguir simulação de implementação impede falsos positivos no relatório de prontidão.

✓ Faça

  • ✓ Declare types não executam de forma observável.
  • ✓ Preserve polyfill simula no fluxo manual.
  • ✓ Teste o resultado e o cancelamento.

✗ Evite

  • ✗ Esconder efeitos atrás de descrições vagas.
  • ✗ Confiar na tool como autorização.
  • ✗ Remover o fallback da interface.

Conceito aplicado

O contrato deve ser compreensível por quem usa, testável por quem desenvolve e limitado por quem opera. A ferramenta não substitui autorização, validação nem experiência visual.

const modo = document.modelContext
  ? 'nativo-ou-experimental'
  : window.__WEBMCP_POLYFILL__
    ? 'simulado'
    : 'fallback';

Dica prática

Copie o exemplo, rode primeiro com dados locais e só depois conecte o backend. Mantenha logs sem dados pessoais e provoque pelo menos uma falha.

Checklist operacional

O objetivo da ferramenta cabe em uma frase.
A entrada inválida produz um erro compreensível.
O efeito aparece na interface para a pessoa.
O caminho manual funciona sem WebMCP.
Indo mais fundo: evidência mínima

Guarde a entrada usada, o estado anterior, o resultado devolvido e a alteração visível da página.

Anote também o comportamento sem suporte, durante cancelamento e diante de uma resposta não autorizada do backend.

Conceitos-chave

01

types não executam

02

polyfill simula

03

nativo é diferente

04

registre o modo

6

Publique uma matriz de compatibilidade

O que é: A matriz registra navegador, canal, flag, contexto seguro, data e resultado do teste.

Por que aprender: Uma API experimental exige rastreabilidade; “funciona aqui” não basta para uma equipe ou para produção.

💡 Teste de realidade

Implemente este tópico com um caminho feliz, uma entrada inválida e um cancelamento. Registre o que a pessoa viu e o que o agente recebeu.

Conceito aplicado

O contrato deve ser compreensível por quem usa, testável por quem desenvolve e limitado por quem opera. A ferramenta não substitui autorização, validação nem experiência visual.

| Ambiente | Secure | API | Registro | Fallback |
| Chrome teste | sim | sim | passa | passa |
| Navegador comum | sim | não | n/a | passa |

Dica prática

Copie o exemplo, rode primeiro com dados locais e só depois conecte o backend. Mantenha logs sem dados pessoais e provoque pelo menos uma falha.

Checklist operacional

O objetivo da ferramenta cabe em uma frase.
A entrada inválida produz um erro compreensível.
O efeito aparece na interface para a pessoa.
O caminho manual funciona sem WebMCP.
Indo mais fundo: evidência mínima

Guarde a entrada usada, o estado anterior, o resultado devolvido e a alteração visível da página.

Anote também o comportamento sem suporte, durante cancelamento e diante de uma resposta não autorizada do backend.

Conceitos-chave

01

data do teste

02

versão e canal

03

flag documentada

04

fallback verificado

📦 Entrega do módulo

Criar uma página que detecta document.modelContext, informa o suporte e preserva um fluxo manual completo.

Critério de aceite

A entrega funciona com suporte WebMCP e mantém o caminho manual quando a API não existe.

Evidência

Inclua código, cenário testado, resultado observado e uma limitação conhecida.

Fontes técnicas