mxrb 0.1.2 → 0.1.4

data/docs/pt-BR/project-structure.md

@@ -2,8 +2,18 @@
 
 **Português** · [English](../en-US/project-structure.md) · [Deutsch](../de-DE/project-structure.md)
 
-A árvore produzida por `mxrb export` separa políticas globais, comportamento
-dos módulos, unidades nativas preservadas e assets:
+`mxrb export` possui dois modos explícitos. `--mode mendix` é o padrão e mantém
+a árvore Mendix em DSL por camadas. `--mode ruby` cria uma aplicação Ruby
+convencional e executável com frontend React + Vite.
+
+## Modo Mendix
+
+```sh
+bundle exec mxrb export App.mpr app-source --mode mendix
+```
+
+Essa árvore separa políticas globais, comportamento dos módulos, unidades
+nativas preservadas e assets:
 
 ```text
 project.rb
@@ -29,4 +39,189 @@ manifesto são gravadas.
 A estrutura suporta Ruby para um Mendix novo, Ruby sobre baseline exportado,
 Mendix para Ruby editável e Mendix → Ruby → Mendix estruturalmente equivalente.
 
+## Modo Ruby
+
+O modo Ruby também pode começar sem um projeto Mendix existente:
+
+```sh
+bundle exec mxrb init CustomerPortal --mode ruby
+cd CustomerPortal
+bundle install
+npm install --prefix frontend
+bundle exec mxrb run .
+```
+
+Esse comando cria diretamente a aplicação convencional com `app/models`,
+`app/dtos`, `app/services`, `app/pages` e React + Vite. Um baseline Mendix
+reversível fica isolado em `.mxrb`; ele não determina a organização do código
+que será editado. Para materializar o projeto atual em um MPR:
+
+```sh
+bundle exec mxrb generate project.rb build/CustomerPortal.mpr
+```
+
+Models Ruby novos viram entidades, DTOs viram entidades non-persistent e as
+declarações bidirecionais são sincronizadas no MPR. Código Ruby ou React sem
+representação Mendix nativa permanece incorporado com checksum e reaparece
+intacto no próximo export. A compilação falha explicitamente quando uma mudança
+estrutural não pode ser representada, evitando conversão parcial silenciosa.
+
+Para converter um MPR que já existe, use:
+
+```sh
+bundle exec mxrb export App.mpr app-ruby --mode ruby
+```
+
+```text
+app/
+  models/
+  dtos/
+  services/
+  pages/
+config/application.rb
+frontend/
+  package.json
+  vite.config.ts
+  tsconfig.json
+  src/{main.tsx,App.tsx,types.ts,nanoflows.ts,app.css}
+project.rb
+.mxrb/
+  ruby-app.json
+  runtime/App.mpr
+  mendix/
+```
+
+Entidades persistentes viram records. Entidades non-persistent viram classes
+DTO e sempre usam o sufixo `_dto.rb`, evitando nomes ambíguos como `_2.rb`.
+Services são classes Ruby comuns e inicialmente delegam ao interpretador nativo
+em Ruby puro. Pages expõem metadados nativos ao frontend React + TypeScript.
+O export gera `types.ts` a partir de entidades, enumerações, páginas, widgets,
+contextos, efeitos e contratos de API; `npm run typecheck` integra o build Vite.
+
+Instale as dependências Ruby e do frontend uma vez e depois suba os dois
+processos com um único comando:
+
+```sh
+bundle install
+npm install --prefix frontend
+bundle exec mxrb run .
+```
+
+`mxrb run` supervisiona a API JSON Ruby em loopback, servida pelo Puma 8, e o
+servidor Vite. O Vite
+encaminha `/api` para Ruby. Use `--server-port` para a porta do backend e
+`--client-port` para a porta do frontend. `--no-frontend` inicia somente a API.
+Os nomes antigos `--api-port` e `--port` continuam como aliases compatíveis.
+`--no-progress` é global e opcional; apenas oculta a saída de progresso.
+
+Duas stacks opcionais adicionam convenções Ruby conhecidas sem alterar o modo
+Ruby padrão:
+
+```sh
+bundle exec mxrb init ServiceDesk --mode ruby --flymetothemoon
+bundle exec mxrb export App.mpr app-rails --mode ruby --onrails
+```
+
+`--flymetothemoon` adiciona Sinatra, Puma, ActiveRecord, Rake e RSpec.
+`--onrails` adiciona Rails, Puma, ActiveRecord e RSpec. Ambas mantêm React +
+Vite como frontend integrado da aplicação e usam o mesmo comando
+`mxrb run .`. As migrations do ActiveRecord controlam apenas tabelas Ruby; o
+manifesto MXRB continua autoritativo para o domain model Mendix e seus
+round-trips.
+
+## Diagrama do domain model no browser
+
+Abra os domain models de um ou mais módulos Mendix em um diagrama ER inspirado
+no DBeaver:
+
+```sh
+bundle exec mxrb diagram-er App.mpr --module Sales
+bundle exec mxrb diagram-er App.mpr --module Sales --module Billing \
+  --output build/App-layout.mpr
+```
+
+A barra lateral permite selecionar vários módulos ao mesmo tempo e mostra as
+associações entre eles. A página também oferece busca de entidades,
+posicionamento por drag-and-drop, zoom, ajuste à tela, auto-organização, grade,
+visibilidade de atributos, rotas de relacionamento e pontos de origem/destino
+arrastáveis. Entidades persistentes são azuis, DTOs/non-persistent amarelos e
+OQL views verdes. **Salvar layout no MPR** grava as posições e os pontos das
+associações locais nos campos Mendix nativos; âncoras cross-module, que não têm
+campo BSON nativo, ficam em metadados visuais isolados do MXRB na mesma cópia
+segura. A cópia padrão é `App.domain-layout.mpr`; para substituir uma saída
+existente é necessário `--force`.
+
+**Exportar PNG** baixa uma imagem em alta resolução dos módulos selecionados,
+respeitando as cores, a exibição de atributos e as rotas. A exportação não modifica
+o MPR; salve o layout separadamente quando as posições precisarem sobreviver ao
+round-trip.
+
+O modo direto continua disponível e ocupa o terminal até `Ctrl+C`. Para manter o
+editor ER em segundo plano, use o lifecycle gerenciado, que preserva a cópia de
+layout ao parar e nunca edita nem remove o MPR de origem:
+
+```sh
+bundle exec mxrb diagram-er up App.mpr --module Sales
+bundle exec mxrb diagram-er status App.mpr
+bundle exec mxrb diagram-er down App.mpr
+bundle exec mxrb diagram-er up App.mpr       # retoma a mesma cópia
+bundle exec mxrb diagram-er destroy App.mpr --yes
+```
+
+`destroy` para o servidor e remove somente a cópia e os conteúdos externos que
+esse lifecycle criou. O controle usa um endpoint privado autenticado em loopback;
+estado e token ficam em arquivos locais com permissões restritas.
+
+A interface do editor é implementada em React + TypeScript e consome somente as
+APIs do servidor Ruby. O bundle Vite é compilado em `lib/mxrb/web_ui`, incluído
+na gem e servido localmente; portanto Node.js não é necessário para usar o
+editor instalado e nenhum CDN é acessado. Para desenvolver a interface, use
+`npm install`, `npm run typecheck` e `npm run build` em `frontend/modeler`.
+ER, UML, OQL e o backend genérico de `--mode ruby` compartilham o mesmo
+adaptador Puma embutido. `puma ~> 8.0` é dependência direta do MXRB e traz
+`nio4r ~> 2.0` transitivamente; WEBrick não faz parte da pilha HTTP.
+
+## Diagramas UML
+
+UML é uma implementação adicional e independente do editor ER. Ela usa a porta
+4569 e não altera o layout do domain model. O viewer reúne diagramas de classe,
+atividade de microflows e sequência de chamadas, renderizados com Mermaid:
+
+O mesmo servidor publica `http://127.0.0.1:4569/modeler`, um catálogo visual
+React + TypeScript para módulos, páginas, microflows e nanoflows, navegação,
+segurança, integrações e configurações. Essa primeira superfície ampliada é
+somente leitura; mutações continuam bloqueadas até terem validação e roundtrip
+fail-closed equivalentes ao editor ER.
+
+```sh
+bundle exec mxrb uml App.mpr
+bundle exec mxrb uml App.mpr --export=class --module Sales
+bundle exec mxrb uml App.mpr --export=activity \
+  --microflow=Sales.CreateOrder --format=plantuml
+bundle exec mxrb uml App.mpr --export=sequence \
+  --root=Sales.CreateOrder --depth=3
+bundle exec mxrb uml App.mpr --export=sequence --module=Sales
+```
+
+Sem `--export`, o comando abre o viewer unificado em
+`http://127.0.0.1:4569`. A exportação textual usa Mermaid por padrão; selecione
+PlantUML com `--format=plantuml`. Diagramas de sequência aceitam uma raiz com
+profundidade limitada ou todas as chamadas internas de um módulo. O viewer usa
+o mesmo workspace React + TypeScript; Mermaid é empacotado localmente para que a
+renderização também funcione offline.
+
+## Transições de versão e round-trips
+
+Os dois modos mantêm IDs estáveis do Mendix e o baseline nativo completo usado
+em upgrades, downgrades e round-trips repetidos. No modo Ruby, declarações de
+models/DTOs são compiladas de volta no MPR. Os corpos Ruby dos services e os
+fontes React são armazenados com SHA-256 em uma tabela MXRB dentro do MPR; uma
+nova exportação `--mode ruby` restaura exatamente os arquivos editados.
+
+O comportamento Mendix nativo continua autoritativo para construções que ainda
+não possuem compilador semântico Ruby → Mendix. O manifesto de cobertura deixa
+esse estado explícito em vez de alegar uma conversão silenciosa. O código
+Ruby/React preservado sobrevive ao round-trip mesmo sem representação direta no
+Studio Pro.
+
 [Voltar ao índice](README.md)

data/docs/pt-BR/runtime-ruby.md

@@ -0,0 +1,108 @@
+# Runtime sem Java
+
+O modo Ruby executa o backend sem iniciar o Mendix Runtime Java. Ao abrir uma
+aplicação exportada, o MXRB migra automaticamente um banco SQLite por ambiente,
+abre o interpretador de microflows, registra lifecycle hooks, aplica segurança e
+inicia os scheduled events.
+
+```text
+config/environments/
+├── development.env
+├── qa.env
+├── staging.env
+└── production.env
+```
+
+A precedência é `ENV do processo > config/environments/<ambiente>.env >
+.env.<ambiente> > .env`. Selecione o perfil com `--environment qa` ou
+`MXRB_ENV=qa`. `mxrb env . --environment qa` lista somente nomes de chaves e
+fontes; valores nunca são impressos.
+
+```bash
+mxrb run . --environment qa
+mxrb test App.mpr smoke.rb --native --environment qa
+```
+
+Cada perfil usa, por padrão, `.mxrb/runtime/<ambiente>.sqlite3`. O schema deriva
+de entidades, atributos, associações e system members; mudanças aditivas são
+aplicadas de forma idempotente e mudanças incompatíveis usam rebuild
+transacional. Entidades não persistentes continuam somente em memória.
+
+A API Ruby oferece login e tokens bearer, sessão, schema, navigation, pages,
+microflows, CRUD e published REST. Regras de página/microflow, access rules de
+entidade, direitos por member e o subconjunto seguro de XPath são verificados em
+cada requisição. Credenciais vêm de `MXRB_USERS_JSON` e `MXRB_AUTH_TOKENS`; use
+arquivos locais ignorados pelo Git ou o secret manager do deployment.
+
+Scheduled events usam o scheduler stdlib do MXRB, com intervalos de minuto,
+hora e dia, prevenção de overlap e encerramento supervisionado. Falhas ficam
+disponíveis no scheduler e não derrubam silenciosamente o servidor. Zonas IANA,
+como `America/Boa_Vista`, usam `tzinfo`, inclusive nas transições de horário de
+verão. Zonas desconhecidas geram erro em vez de cair silenciosamente para UTC;
+`UTC`, `local` e offsets numéricos como `-04:00` também são aceitos.
+
+Sessões e coordenação do scheduler usam por padrão o SQLite nativo compartilhado
+`.mxrb/runtime/<ambiente>-shared.sqlite3`, sem serviço externo. Múltiplas
+instâncias devem apontar `MXRB_SHARED_STORE_PATH` para o mesmo arquivo. Claims
+idempotentes por evento/janela e leases de sobreposição renovados por heartbeat
+são atômicos; um claim inacabado pode ser retomado após a expiração. O lease
+padrão é de 300 segundos e pode ser alterado com `MXRB_SCHEDULER_LEASE_TTL`.
+Use `:memory:`, `memory` ou `local` para ativar explicitamente o modo por processo.
+
+Java Custom Actions não iniciam uma JVM. Cada ação permitida deve ter um adapter
+Ruby explícito, registrado pelo nome qualificado em `config/adapters.rb`:
+
+```ruby
+Mxrb::RubyApp::Registry.register_java_custom_action('Pedidos.CalcularTotal') do |arguments|
+  Calculador.call(
+    itens: arguments.fetch('Itens'),
+    desconto: arguments.fetch('Desconto')
+  )
+end
+```
+
+As chaves são os nomes dos parâmetros no modelo Mendix. Valores básicos são
+avaliados no contexto do microflow; referências de entidade, microflow e
+mappings são entregues como nomes qualificados. O retorno alimenta a variável
+de resultado apenas quando `UseReturnVariable` está ativo (ou no formato legado
+que declara somente `ResultVariableName`). Uma ação sem registro falha fechado
+com seu nome e a instrução de registro; não há descoberta de classes, execução
+de JAR nem fallback para a JVM. REST, app services, SOAP, mappings e geração de
+documentos continuam usando os adapters Ruby por tipo. O frontend permanece
+JavaScript/React no navegador, servido pelo backend Ruby sem Runtime Java.
+
+## Certificação Ruby → Mendix → Ruby
+
+O cenário reproduzível de certificação fica em
+[`spec/fixtures/flymetothemoon/project.rb`](../../spec/fixtures/flymetothemoon/project.rb).
+Ele modela em Ruby clientes, produtos, pedidos e itens, incluindo enumeração,
+índices, associações, microflows, nanoflow, scheduled event e uma página com
+data grid. O teste
+[`spec/flymetothemoon_roundtrip_spec.rb`](../../spec/flymetothemoon_roundtrip_spec.rb)
+verifica estes casos de uso:
+
+- gerar e validar um MPR Mendix 11.12.1 a partir da DSL Ruby;
+- exportar pelo CLI real com `--mode ruby --flymetothemoon`;
+- garantir que o preset contenha Sinatra, Puma, ActiveRecord e RSpec, sem
+  arquivos Java, JAR ou bytecode;
+- executar criação, contagem, decisão, CRUD e metadados de página no Runtime
+  Ruby com SQLite;
+- recompilar sem alterações e comparar o MPR estruturalmente com a origem;
+- adicionar um atributo e substituir um microflow por Ruby idiomático;
+- exportar novamente e provar que código Ruby e modelo Mendix sobrevivem a um
+  segundo round-trip estruturalmente idêntico.
+
+Execute o caso isolado com:
+
+```bash
+bundle exec rspec spec/flymetothemoon_roundtrip_spec.rb
+```
+
+Para interfaces geradas, o cenário declarativo
+[`spec/fixtures/frontend_browser/sudoku_full_flow.json`](../../spec/fixtures/frontend_browser/sudoku_full_flow.json)
+é executado pelo runner `script/frontend_browser_acceptance` em Chromium real.
+Ele cobre as posições 73 e 74 do tabuleiro, seleção, preenchimento e troca entre
+Easy, Medium e Hard. Cada clique crítico aguarda a cadeia POST do microflow + GET
+da associação e deve concluir em até 250 ms. A consulta da galeria é filtrada no
+SQLite pelo contexto; objetos carregados pela associação inversa preservam o
+vínculo quando somente atributos são salvos.

data/docs/pt-BR/runtime-schema-migrations.md

@@ -0,0 +1,40 @@
+# Migrações do schema do runtime Ruby
+
+`Mxrb::Runtime::SchemaMigrator` identifica entidades, atributos e associações pelo GUID de
+armazenamento Mendix. Renomear um artefato mantendo o GUID preserva a tabela ou coluna e os
+dados existentes.
+
+## Política segura
+
+- Criação de tabela e adição de atributo opcional são automáticas e idempotentes.
+- Atributos `required` são criados como `NOT NULL`.
+- Tornar um atributo existente obrigatório reconstrói a tabela dentro de uma transação. Se
+  houver `NULL`, a migração usa o valor default declarado; sem default, ela é recusada.
+- Adicionar um atributo obrigatório a uma tabela populada exige default. Em tabela vazia, a
+  migração pode reconstruir o schema sem backfill.
+- Alterações compatíveis preservam os dados e as linhas das associações.
+- Remover entidade, atributo ou associação é considerado destrutivo. Por padrão a migração
+  lança `Mxrb::Runtime::UnsafeSchemaMigrationError`, com os itens em `error.changes`, e não
+  altera o banco.
+- Depois de backup e revisão do plano, a limpeza pode ser autorizada explicitamente com
+  `allow_destructive: true`. Somente tabelas e colunas registradas nos metadados do MXRB são
+  removidas; tabelas externas não são inferidas nem apagadas.
+
+Aplicações Ruby exportadas mantêm essa opção desligada. Para uma execução controlada após o
+backup, configure `MXRB_ALLOW_DESTRUCTIVE_MIGRATIONS=true` no perfil de ambiente. Qualquer
+outro valor, inclusive variável ausente, mantém o modo fail-closed.
+
+```ruby
+database = SQLite3::Database.new('runtime.sqlite3')
+migrator = Mxrb::Runtime::SchemaMigrator.new(
+  project,
+  database: database,
+  allow_destructive: true
+)
+result = migrator.migrate!
+puts migrator.migration_plan.changes
+```
+
+DDL, cópia de dados, atualização dos metadados e limpeza destrutiva pertencem à mesma
+transação SQLite. Qualquer violação de `NOT NULL`, unicidade ou outro erro reverte a migração
+inteira.

data/docs/pt-BR/validation-matrix.md

@@ -2,7 +2,7 @@
 
 **Português** · [English](../en-US/validation-matrix.md) · [Deutsch](../de-DE/validation-matrix.md)
 
-Última atualização: 5 de agosto de 2026.
+Última atualização: 11 de agosto de 2026.
 
 O pipeline validado é:
 
@@ -21,6 +21,22 @@ Os originais nunca são modificados.
 | TreeviewDemo | 5.21.4 | v1 | passou |
 | GridViewPlayground | 6.10.8 | v1 | passou |
 
+Em 11 de agosto, `script/validate_matrix` repetiu a matriz com **6/6 passes**:
+1.506 units, 1.734 artefatos e 3.388 referências em 16,381 s.
+
+## Inventário adicional local
+
+`script/certify_mprs --cycles 2 --repair-hashes` certificou outros sete MPRs
+em 14 roundtrips consecutivos: **7/7 passes**, 2.799 units, 3.238 artefatos e
+4.819 referências. Foram cobertos LearnNow, SLATaskApp, SLATaskAppNative,
+MyFirstModule, CourseManager, RubyBridgeSandbox e VetClinic.
+
+SLATaskApp tinha um hash de conteúdo obsoleto e RubyBridgeSandbox tinha dois.
+O gate reparou somente `Unit.ContentsHash` em cópias temporárias, registrou os
+UUIDs alterados e preservou os bytes BSON originais. Os arquivos-fonte não
+foram modificados. O segundo roundtrip também detectou e corrigiu tipos de
+widgets nativos desserializados como strings.
+
 ## Cobertura profunda editável
 
 O comparador cobre metadados, segurança, árvore de units, entidades, access
@@ -55,6 +71,27 @@ todo metamodelo Mendix. Encodings `.mxunit` desconhecidos são rejeitados em vez
 de adivinhados. A validação exata do 5.21 em Studio Pro/Windows continua sendo
 um limite explícito.
 
+## Certificação de widgets
+
+`script/certify_widgets --browser-report REPORT.json App.mpr` é o gate para
+widgets do compilador web nativo e Marketplace realmente usados. Ele exige,
+em conjunto:
+
+- compilação sem fallback de todas as páginas e layouts web;
+- resolução de cada ID pluggable para um `.mjs` dentro de MPK, com SHA-256;
+- materialização do modelo e build Rspack nativo da versão Mendix;
+- relatório Chromium aprovado, sem exceção/fallback visível, declarando todos
+  os IDs e tipos de widget exercitados pelo cenário.
+
+Importar um MPK ou concluir o bundle isoladamente não certifica comportamento.
+Widgets que exigem datasource, atributo ou posição específica — por exemplo,
+filtros dentro de Data Grid/Gallery — só passam quando o cenário os exercita
+nesse contexto válido. Pacotes futuros ou ainda não exercitados falham como
+evidência ausente, em vez de herdarem uma promessa genérica de compatibilidade.
+O frontend React/TypeScript de `--mode ruby` tem uma trilha separada: seu
+relatório Chromium certifica os widgets sem afirmar que os componentes
+pluggable equivalentes também passaram no Runtime Mendix.
+
 ## Índice semântico
 
 Os seis MPRs produziram **1.778 artefatos** e **3.387 referências**. Consultas
@@ -63,9 +100,9 @@ sem MDL.
 
 ## Avaliações, cobertura e runtime
 
-- 1.039 exemplos, zero falhas;
-- 100% das linhas: 17.224/17.224;
-- 100% dos branches: 6.811/6.811;
+- 1.329 exemplos, zero falhas;
+- 100% das linhas: 23.771/23.771;
+- 100% dos branches: 9.704/9.704;
 - avaliação Sudoku: 7/7 checks;
 - testes funcionais Sudoku: 3/3 localmente em 34,16 s;
 - testes funcionais Sudoku: 3/3 no Docker em 39,52 s.
@@ -80,7 +117,7 @@ e logout real. Os scaffolds `page --chain` também materializam e passam
 preflight nos três caminhos suportados; `page --template` foi exercitado em
 Runtime para dashboard e formulário vertical com CSS computado auditado.
 
-`script/validate_matrix` repetiu os seis round-trips, 1.506 units, em 14,760 s.
+`script/validate_matrix` repetiu os seis round-trips, 1.506 units, em 16,381 s.
 `script/benchmark` mediu o pipeline Sudoku completo em 6,8463 s. O fuzzing
 determinístico cobre 250 documentos BSON aninhados e 50 arquivos `.mxunit`
 atômicos, inclusive valores binários.

data/docs/pt-BR/writing.md

@@ -5,6 +5,12 @@
 `mxrb generate` avalia uma definição Ruby e cria ou atualiza o MPR. Nomes
 Mendix são chaves estáveis, portanto reaplicar a definição não duplica units.
 
+Operações demoradas exibem progresso em `stderr` quando executadas em um
+terminal interativo. Quando o total é conhecido, o MXRB mostra barra e
+porcentagem; operações externas sem total confiável mostram spinner e tempo
+decorrido. Pipes, redirecionamentos e saídas `--json` permanecem limpos. Use
+`--no-progress` ou `MXRB_PROGRESS=0` para desativar explicitamente.
+
 Para iniciar em uma pasta vazia:
 
 ```sh
@@ -122,6 +128,28 @@ usam `bson_binary`. Alterações nesse Ruby sobrepõem o baseline antes das escr
 tipadas. Corpos de flow possuem `body_fingerprint`: o grafo nativo é reutilizado
 quando o Ruby não mudou e regenerado após uma edição.
 
+Export mappings, import mappings e JSON structures são materializados por
+módulo em `infrastructure/mappings/{exports,imports,json_structures}`. Esses
+arquivos mantêm `UnitID` e container/pasta originais, podem editar toda a
+estrutura profunda em Ruby e têm precedência sobre o baseline durante o
+`generate`.
+
+Serviços REST, OData e web services publicados são exportados para
+`infrastructure/endpoints`; recursos, operações, métodos HTTP, paths,
+parâmetros e referências a microflows permanecem no mesmo arquivo Ruby.
+Serviços consumidos são roteados para `infrastructure/integrations`, enquanto
+message definitions e XML schemas ficam em `infrastructure/mappings`.
+
+O Domain Model exportado separa entidades persistentes em `domain/entities`,
+DTOs/non-persistent em `domain/dtos` e entidades de OQL View em
+`domain/oql_views`. O arquivo da OQL View também contém seu
+`DomainModels$ViewEntitySourceDocument`, portanto a consulta `Oql` pode ser
+editada no mesmo Ruby sem perder a referência da entidade. Datasets OQL ficam
+em `application/queries/datasets`; enumerations e constants ficam em
+`domain/enumerations` e `domain/constants`. Scheduled events ficam em
+`application/jobs/scheduled_events`. O `domain/model.rb` e o
+`application/application.rb` carregam automaticamente todas essas categorias.
+
 A DSL cobre criação/alteração/retrieve/commit/delete, chamadas de microflow,
 Java, JavaScript, nanoflow e app service, páginas, REST, listas, decisões,
 loops, eventos de erro e rescue.