18 · Rotinas

eng/dev-db.sh up                  # banco de desenvolvimento
docker compose up -d keycloak     # http://localhost:8088 (admin/admin), realms de dev importados
<rodar app dona do schema>        # roda as migrations
<rodar demais apps>

Ou tudo em container: docker compose up --build. Usuários: um por perfil, listados em docs/acesso/<app>.md. Fim: cada aplicação responde /up e aceita login de cada perfil.

Detalhe em 09.

1. Mantenedor: no repositório do design system, na tag da versão, roda o atualizador dela (node design-system/atualizar/atualizar.mjs --alvo=<raiz da stack>), que substitui por inteiro vendor/hibex/ e a skill .claude/skills/hibex-ui/ e não faz commit;
2. Agente: /opsx:propose design-system-X-Y-Z lendo o CHANGELOG.md entre as versões;
3. Apply: trocas do "Para os produtos", hibex-pendente atendidos, verificador sem erro, capturas das telas afetadas, regressão E2E;
4. Fim: vendor/hibex/VERSAO na versão nova, pedidos.md atualizado.

Mesmo desenho do design system, com o arquivo ARQUITETURA no lugar de VERSAO:

1. Mantenedor: decide adotar arquitetura-vX.Y.Z;
2. Agente: /opsx:propose arquitetura-X-Y-Z lendo o "Para as stacks" do CHANGELOG.md deste repositório, entre a versão do ARQUITETURA e a nova;
3. Apply: copia docs/decisoes/organizacao/ da versão nova (ORGs novas ou substituídas), revê as ADRs que cumpriam uma ORG substituída, ajusta AGENTS.md, eng/, CI, guias;
4. Fim: ARQUITETURA na versão nova.

Versão maior de dependência central (framework, banco, runtime) é change.

1. Copiar docs/decisoes/template.md para ADR-NNNN-slug-no-imperativo.md (o próximo número da stack); se a decisão valeria para toda stack, é pedido para a arquitetura virar ORG, em docs/decisoes/pedidos-a-arquitetura.md;
2. Status proposta; as ORGs que cumpre; contexto, decisão, alternativas, consequências;
3. Linha no índice docs/decisoes/README.md;
4. Mantenedor aceita (ou pede ajuste). Revisão de ADR aceita: linha "Revisão" ou nova ADR que a substitui.

1. Change do OpenSpec (acesso é comportamento);
2. eng/auth/provision.sh: permissões, perfis, grupos;
3. eng/auth/dev-realms.sh → conferir o diff dos exports; usuário de exemplo para perfil novo;
4. Código: conferir a permissão na rota; teste de rota;
5. docs/acesso/<app>.md: tabelas, matriz, histórico;
6. E2E: caso do perfil no agrupamento identidade;
7. Instruções para o mantenedor rodar o provision.sh no Keycloak real.

Checklist completo no guia nova-aplicacao.md do modelo.

1. Mantenedor pede o lote;
2. Agente monta build/pedidos-design-system/<AAAA-MM-DD>/ (LEIA-ME + uma pasta por pedido, pedido.md no formato do design system, evidências das capturas);
3. Agente roda node vendor/hibex/pedir.mjs <lote> e corrige os erros;
4. Mantenedor envia o zip;
5. Números voltam → pedidos.md e hibex-pendente: NNNN <assunto>.

1. Mantenedor copia um dump real para a estação;
2. Banco local descartável; eng/backup/restore-db.sh <dump> --confirmar dentro de um container da mesma imagem do backup (cada armazenamento com dados tem o seu restore-<armazenamento>.sh, testado do mesmo jeito);
3. Sobe a aplicação dona do schema na mesma versão da produção; confere /up e um login;
4. Registra a data no guia de backup.

O guia de backup da stack é um roteiro de copiar e colar. Nele, cada comando vem completo, e a pasta de destino é criada antes da cópia (mkdir -p antes do scp). Quando um comando pede uma senha, o roteiro diz o nome do segredo no Bitwarden, nunca o valor. E toda variável que ele manda exportar vem com o comando que a obtém. O primeiro teste segue o roteiro ao pé da letra, e o que faltou volta para o guia na mesma hora.