Scaffold: fonte, contrato e versionamento

De onde vem

Toda aplicação parte de um modelo-base atualizado, nunca de uma cópia antiga guardada em algum lugar. A fonte padrão é o modelo oficial da plataforma; uma organização também pode apontar para um modelo próprio. O caminho é idêntico nos dois casos: buscar a versão mais recente publicada.

Por que a versão importa: evitar que a aplicação nasça quebrada

A plataforma sabe até qual versão do modelo-base ela consegue suportar. Se o modelo apontado exige uma versão mais nova do que a plataforma sabe lidar, a criação da aplicação é recusada — porque recusar é melhor do que entregar uma aplicação que nasce quebrada.

A ordem que evita um problema maior

Quando a plataforma amplia sua capacidade de suporte, ela sempre faz isso antes de publicar a versão correspondente do modelo-base — nunca depois. A ordem inversa quebraria a criação de aplicações novas para a organização inteira, até a plataforma se atualizar. Foi uma decisão revista depois de medir o custo real de cada ordem: a alternativa parecia mais coerente no papel, mas custava a criação de aplicações da organização inteira sempre que colidisse.

O que cada avanço de versão trouxe

Login desde o nascimento

A partir de uma certa versão, toda aplicação nasce já com a camada de login integrada, e passa a exigir a configuração de acesso correspondente. Isso só foi possível porque a plataforma já garantia entregar essa configuração automaticamente nos dois ambientes em que a aplicação roda — incluindo a capacidade de trocar a credencial de acesso sem invalidar, por engano, sessões que já estavam abertas.

Uma aplicação também vira uma capacidade programável

Numa versão seguinte, a mesma aplicação passou a poder ser usada não só pela tela, como também por chamada direta e por um agente — com a mesma regra de acesso valendo nos três caminhos, sem exigir uma identidade separada para cada um.

A aplicação passa a se descrever para um cliente de MCP qualquer (14/08/2026)

O avanço mais recente (contrato 5) não muda nenhuma regra de acesso nem inventa uma verificação nova — o que faltava era só a descoberta: um jeito padrão de um cliente que não conhece o VolundOS de antemão achar sozinho onde pedir autorização para falar com a aplicação. Ver o detalhe em Provedor OIDC para Apps.

Vale a mesma ordem de sempre: a plataforma já aceitava o contrato 5 antes de ele ser publicado no modelo-base, para nenhuma aplicação nova nascer rejeitada durante a transição.

A aplicação passa a saber quem ela é (16/08/2026, contrato 6)

A descoberta do contrato 5 levava um cliente de MCP externo até a porta da aplicação e parava ali: com o token em mãos, a aplicação respondia 401. A verificação exigia que o token tivesse sido obtido pelo cliente da própria aplicação — o que nunca é o caso de um cliente de MCP que se registrou sozinho. O contrato 6 não muda nenhum claim; muda o que a aplicação compara com o quê: ela passa a receber a própria identidade (quarta variável de ambiente, ao lado do trio de login) e a exigir que o token tenha sido emitido para ela, em vez de conferir se foi obtido pelo seu próprio cliente. Detalhe completo em Provedor OIDC para Apps.

Mesma ordem de sempre: a plataforma já injetava essa variável antes da release v6.0.0 do modelo-base sair, para nenhuma aplicação nova nascer sem ela. Aplicações publicadas antes do contrato 6 não recebem o conserto automaticamente — só ao serem recriadas.

O que ainda está por vir

Uma aplicação declarar formalmente o que ela expõe, e essa declaração ser usada para catalogá-la e para ser consumida por outros agentes, ainda está em desenvolvimento.

Onde fazer isso

• Apontar um modelo-base próprio para a organização: nas configurações de infraestrutura.