Quatro empresas, um só produto.

1 · O mapa

O caminho de um projeto, do edital à prestação de contas

Cada etapa é um módulo com dono. O proponente não sabe nem precisa saber que quatro empresas trabalham por trás: para ele, é um sistema só.

2 · A ideia central

Ninguém constrói o sistema inteiro: cada empresa entrega pacotes

Cada empresa trabalha no próprio GitHub ou GitLab e publica o seu módulo como pacote npm num registry privado, o Verdaccio. Um app hospedeiro, a plataforma-fapesb, instala os pacotes e monta o site inteiro. As APIs de cada empresa rodam como serviços separados.

Os pacotes

Passo a passo: publicar o seu módulo

1. Crie o pacote no seu próprio Git, a partir do modelo oficial de layer do Nuxt.

   # cria um layer com a pasta .playground para rodar sozinho
   bunx nuxi@latest init -t layer fapesb-submissao-web

2. Desenvolva isolado. bun run dev sobe o módulo na pasta .playground, com o @fapesb/ui instalado. Você não precisa do código das outras empresas.
3. Aponte o escopo @fapesb para o Verdaccio. O token fica no cofre do CI, nunca no Git.

   # bunfig.toml
   [install.scopes]
   "@fapesb" = { token = "$FAPESB_NPM_TOKEN", url = "https://pacotes.<domínio-da-plataforma>/" }

4. Garanta a qualidade: bun check, bun test, lint e testes de acessibilidade passam no CI.
5. Publique por tag. Crie a tag v0.3.0; o CI roda bun publish e o pacote vai para o Verdaccio.
6. Peça a atualização no app hospedeiro. Um PR em plataforma-fapesb sobe a versão no package.json. Ele vai para a homologação integrada e, na review da sprint, para produção.

Regras para o pacote do seu módulo (para não brigar com os outros)

E se alguma empresa preferir Next (React) em vez de Nuxt?

Resposta curta: os pacotes comuns continuam funcionando, mas a montagem muda. Uma Nuxt Layer só entra num app Nuxt. Com Next na mesa, cada módulo vira um app próprio, e um proxy junta todos no mesmo domínio.

Recomendação: um framework só para todos é o caminho mais simples (KISS). Mesmo assim, o shell do @fapesb/ui (cabeçalho, menu, rodapé e login) nasce em Web Components. É pouca coisa, e com isso o modelo misto fica possível sem refazer o pacote. A escolha do framework é decisão do comitê (critério A12).

# config.yaml do Verdaccio — quem lê e quem publica
packages:
  '@fapesb/ui':          { access: $authenticated, publish: zfuture }
  '@fapesb/submissao':   { access: $authenticated, publish: zfuture }
  '@fapesb/contratacao': { access: $authenticated, publish: myappnow }
  '@fapesb/prestacao':   { access: $authenticated, publish: mtm }
  '@fapesb/contratos':   { access: $authenticated, publish: ci-contratos }
  '**':                  { access: $all, proxy: npmjs }   # o resto vem do npm público, com cache
uplinks:
  npmjs: { url: https://registry.npmjs.org/ }

3 · Governança

Autonomia dentro do módulo, acordo nas fronteiras

A regra-mãe é simples. O que só afeta o seu módulo, a sua empresa decide. O que afeta outra empresa passa pelo Comitê de Arquitetura, com uma pessoa de cada empresa.

Quando a mudança vai ao comitê? Basta um critério

O A9 tem base direta no Termo de Outorga, que manda "cumprir o disposto na Lei nº 13.709" (LGPD) R1 p.68 · §6.2.33.1.

O caminho de uma mudança

4 · Identidade

Um login para tudo: o Keycloak da FAPESB

A MTM configura o Realm FAPESB. Cada módulo é um client dele. O Keycloak diz quem é a pessoa e quais perfis ela tem; o que cada perfil pode fazer é decisão de cada módulo.

Fundamento: as soluções devem "observar os requisitos de segurança, proteção de dados e conformidade tecnológica" R2 p.5-6 · §4.4.

5 · Integração

Contrato antes de código

Módulos de empresas diferentes conversam só por API, com JSON. O contrato é escrito e aprovado antes da implementação, e nenhum módulo acessa o banco de outro. O edital pede "Arquitetura baseada em microsserviços e integração via API RESTful" R1 p.57 · Anexo 3 §2.2.

// Recusa com descrição: o sistema de origem corrige e reenvia
{
  "type": "https://plataforma.fapesb.ba.gov.br/erros/prestacao/campo-fora-do-catalogo",
  "title": "Campo não previsto no catálogo",
  "status": 422,
  "detail": "O bloco 3 não aceita o campo 'patente_depositada'. Atualize o catálogo por RFC (A3).",
  "codigo": "PRESTACAO_BLOCO_CAMPO_FORA_DO_CATALOGO",
  "correlation_id": "01JC..."
}

6 · Identidade visual

A cara do governo, em Sass, num pacote só

Usamos o Padrão Digital de Governo (DSGov). Ele é escrito em Sass (SCSS), sem Bootstrap nem Tailwind, por isso todo estilo da plataforma é Sass: assim reaproveitamos direto as variáveis, funções e mixins do governo. A acessibilidade é exigência do edital: "Compatibilidade com padrões de acessibilidade e usabilidade institucional (ex: e-MAG)" R1 p.58 · Anexo 3 §2.2.

Como se escreve um componente

<style lang="scss" scoped>
@use "@fapesb/ui/scss" as govbr;           // ponte para os mixins e funções do DSGov

.submissao-cartao {
  padding: var(--spacing-scale-2x);        // sempre token, nunca valor solto
  font-size: var(--font-size-scale-up-01);
  border: var(--surface-width-sm) solid var(--border-color);

  &__titulo { font-weight: var(--font-weight-semi-bold); }
  &:focus-visible { @include govbr.focus; }   // foco acessível do próprio DSGov
}
</style>

7 · Stack

TypeScript em primeiro lugar, Python só para IA

O edital diz que Python é a "principal linguagem para IA e NLP" e pede "Node.js e Vue.js/React.js para frontend" R1 p.57 · Anexo 3 §2.2. O resto da plataforma é TypeScript, de ponta a ponta.

// tsconfig.json base — testado com bun check e Node 24
{ "compilerOptions": {
    "target": "ES2024", "module": "NodeNext", "moduleResolution": "NodeNext",
    "strict": true, "noUncheckedIndexedAccess": true, "exactOptionalPropertyTypes": true,
    "verbatimModuleSyntax": true, "erasableSyntaxOnly": true,   // sem enum: o Node 24 executa o .ts direto
    "allowImportingTsExtensions": true, "noEmit": true } }
// package.json precisa de "type": "module" — sem isso o bun check acusa TS1295 (testado)

Banco com alta disponibilidade

8 · Nomes, URLs e slugs

A mesma coisa tem o mesmo nome em todo lugar

Em time grande, nome é metade da documentação. O código vai para a FAPESB, que vai mantê-lo R1 p.58 · Anexo 3 §2.3.2; nomes iguais em todos os módulos tornam tudo legível para quem chegar depois.

9 · Metodologia

O mesmo ritmo nas quatro empresas

O edital pede "Princípios da metodologia ágil (Scrum)" e "DevOps e CI/CD com versionamento Git" R1 p.57 · Anexo 3 §2.2. Com quatro empresas, o que evita surpresa é a sprint nas mesmas datas e uma demonstração conjunta a cada duas semanas.

Princípios de código: o básico bem feito

Fica de fora, de propósito: Clean Architecture em camadas, DDD tático completo e padrão de projeto aplicado por obrigação.

10 · Trilha de estudo

Do básico ao avançado, no seu ritmo

Quatro níveis, na ordem em que você vai precisar. Marque o que já estudou: o progresso fica salvo neste navegador. PT indica material em português.

11 · Para decidir

Decisões e pendências

Propostas para o comitê. Cada uma vira um ADR depois de aprovada.

Pendências que precisam de dono

Fontes

• Edital FAPESB nº 027/2025, Rodada 1: PDF oficial (78 p.) · página do edital. As citações "R1 p.N" abrem o PDF na página N.
• Edital FAPESB nº 017/2026, Rodada 2: PDF oficial (100 p.).
• Documentos da MTM Tecnologia, versão 4 (05/11/2026): cadastro e autenticação integrados; visão geral dos dados da prestação de contas; estrutura de formulários dos editais.
• Portaria SECOM-MCOM nº 7.508/2022 (Padrão Digital de Governo): legislação do gov.br · Manual de Aplicação de Marcas do Governo da Bahia.