From aed7f9ba33d67c37c67bd753c4313a09e86cb192 Mon Sep 17 00:00:00 2001
From: ATM Platform <platform@athleticmap.local>
Date: Wed, 7 Oct 2026 15:26:44 +0000
Subject: [PATCH] cadastro: CronJob diario dos logins (afastados/desligados e
 acesso vencido), 00:20 America/Sao_Paulo

---
 moldes/consolidado/57-cronjob-logins.yaml | 84 +++++++++++++++++++++++
 tenants/acme/57-cronjob-logins.yaml       | 84 +++++++++++++++++++++++
 tenants/demo/57-cronjob-logins.yaml       | 84 +++++++++++++++++++++++
 tenants/escolinha/57-cronjob-logins.yaml  | 84 +++++++++++++++++++++++
 tenants/piloto/57-cronjob-logins.yaml     | 84 +++++++++++++++++++++++
 5 files changed, 420 insertions(+)
 create mode 100644 moldes/consolidado/57-cronjob-logins.yaml
 create mode 100644 tenants/acme/57-cronjob-logins.yaml
 create mode 100644 tenants/demo/57-cronjob-logins.yaml
 create mode 100644 tenants/escolinha/57-cronjob-logins.yaml
 create mode 100644 tenants/piloto/57-cronjob-logins.yaml

diff --git a/moldes/consolidado/57-cronjob-logins.yaml b/moldes/consolidado/57-cronjob-logins.yaml
new file mode 100644
index 0000000..27d52ad
--- /dev/null
+++ b/moldes/consolidado/57-cronjob-logins.yaml
@@ -0,0 +1,84 @@
+# =============================================================================
+# 07/10/2026 — a rotina DIARIA dos logins do app (cadastro, no runtime-core):
+#
+#   1. acompanhante ATIVO com a janela de acesso vencida (acesso_fim ANTES de
+#      hoje, no fuso de Sao Paulo) vira EXPIRADO e perde o login do app dos pais
+#      — o mesmo caminho de quem e marcado EXPIRADO na tela. O que ficou fora de
+#      ATIVO com o login ainda nao desativado (Keycloak fora na hora) e tentado
+#      de novo;
+#   2. funcionario que JA esta AFASTADO/DESLIGADO com login habilitado (gravado
+#      antes da regra de 07/10, ou ligado a um login depois de afastado) tem os
+#      logins desabilitados, com os ids guardados em
+#      funcionario.logins_desabilitados_pela_situacao (voltar a ATIVO reabilita
+#      so esses). Login com atm_admin fica habilitado — so um WARN no log.
+#
+# AGUARDANDO GRAVACAO no molde e nos 4 tenants antigos. Nada aqui foi aplicado.
+#
+# Por que CronJob, e nao @Scheduled: o mesmo motivo do financeiro e da retencao
+# — com mais de uma replica do runtime-core, um agendador no processo rodaria
+# duas vezes. A rotina e idempotente (a segunda rodada nao faz nada), mas uma so
+# e o desenho certo. Pela mesma razao NAO roda na subida do pod: para rodar logo
+# depois do deploy, `kubectl -n <tenant>-prod create job --from=cronjob/cadastro-logins cadastro-logins-agora`.
+#
+# DEPENDE do ConfigMap `financeiro-cron` (55-cronjobs-financeiro.yaml): o mesmo
+# `disparar.sh`, o mesmo client `operacao` e o mesmo Secret
+# `operacao-credentials`. O runtime-core so aceita a rota com token do client
+# `operacao` (SegurancaDoRuntime) — nenhum usuario humano, nem admin.
+#
+# Keycloak fora NAO falha o Job: o endpoint responde 200 com `falhas` > 0 no
+# corpo (e log ERROR no runtime-core), e a rodada seguinte tenta de novo. O Job
+# so falha se o runtime-core nao responder 2xx (rota inexistente = imagem
+# antiga, 401/403 = client errado, 5xx).
+#
+# ANTES DE APLICAR: o runtime-core do tenant tem de estar numa imagem com o
+# endpoint POST /api/cadastro/rotinas/logins (senao 404 e o Job falha todo dia).
+# =============================================================================
+apiVersion: batch/v1
+kind: CronJob
+metadata:
+  name: cadastro-logins
+  namespace: {{TENANT}}-prod
+spec:
+  # 00:20 em Sao Paulo: logo depois da virada do dia (a janela que terminou
+  # ontem expira na primeira hora de hoje), longe do backup (02:30), do resumo
+  # (04:30), da retencao (04:40) e das tarefas do financeiro (:15 e :30).
+  schedule: "20 0 * * *"
+  timeZone: America/Sao_Paulo
+  concurrencyPolicy: Forbid
+  successfulJobsHistoryLimit: 3
+  failedJobsHistoryLimit: 5
+  jobTemplate:
+    spec:
+      activeDeadlineSeconds: 900
+      backoffLimit: 1
+      template:
+        spec:
+          restartPolicy: OnFailure
+          containers:
+            - name: disparar
+              image: docker.io/curlimages/curl:8.9.1
+              imagePullPolicy: Never
+              command: ["/bin/sh", "/script/disparar.sh"]
+              env:
+                - name: KEYCLOAK_URL
+                  value: http://keycloak.plataforma-prod.svc:8080/realms/{{REALM}}/protocol/openid-connect/token
+                - name: ISSUER_HOST
+                  value: auth.athleticmap.com
+                - name: ALVO
+                  value: http://runtime-core/api/cadastro/rotinas/logins
+                - name: CLIENT_SECRET
+                  valueFrom:
+                    secretKeyRef:
+                      name: operacao-credentials
+                      key: client-secret
+              resources:
+                requests: { cpu: 10m, memory: 32Mi }
+                limits: { cpu: 200m, memory: 64Mi }
+              volumeMounts:
+                - name: script
+                  mountPath: /script
+          volumes:
+            - name: script
+              configMap:
+                name: financeiro-cron
+                defaultMode: 0555
diff --git a/tenants/acme/57-cronjob-logins.yaml b/tenants/acme/57-cronjob-logins.yaml
new file mode 100644
index 0000000..0f6ee7b
--- /dev/null
+++ b/tenants/acme/57-cronjob-logins.yaml
@@ -0,0 +1,84 @@
+# =============================================================================
+# 07/10/2026 — a rotina DIARIA dos logins do app (cadastro, no runtime-core):
+#
+#   1. acompanhante ATIVO com a janela de acesso vencida (acesso_fim ANTES de
+#      hoje, no fuso de Sao Paulo) vira EXPIRADO e perde o login do app dos pais
+#      — o mesmo caminho de quem e marcado EXPIRADO na tela. O que ficou fora de
+#      ATIVO com o login ainda nao desativado (Keycloak fora na hora) e tentado
+#      de novo;
+#   2. funcionario que JA esta AFASTADO/DESLIGADO com login habilitado (gravado
+#      antes da regra de 07/10, ou ligado a um login depois de afastado) tem os
+#      logins desabilitados, com os ids guardados em
+#      funcionario.logins_desabilitados_pela_situacao (voltar a ATIVO reabilita
+#      so esses). Login com atm_admin fica habilitado — so um WARN no log.
+#
+# AGUARDANDO GRAVACAO no molde e nos 4 tenants antigos. Nada aqui foi aplicado.
+#
+# Por que CronJob, e nao @Scheduled: o mesmo motivo do financeiro e da retencao
+# — com mais de uma replica do runtime-core, um agendador no processo rodaria
+# duas vezes. A rotina e idempotente (a segunda rodada nao faz nada), mas uma so
+# e o desenho certo. Pela mesma razao NAO roda na subida do pod: para rodar logo
+# depois do deploy, `kubectl -n <tenant>-prod create job --from=cronjob/cadastro-logins cadastro-logins-agora`.
+#
+# DEPENDE do ConfigMap `financeiro-cron` (55-cronjobs-financeiro.yaml): o mesmo
+# `disparar.sh`, o mesmo client `operacao` e o mesmo Secret
+# `operacao-credentials`. O runtime-core so aceita a rota com token do client
+# `operacao` (SegurancaDoRuntime) — nenhum usuario humano, nem admin.
+#
+# Keycloak fora NAO falha o Job: o endpoint responde 200 com `falhas` > 0 no
+# corpo (e log ERROR no runtime-core), e a rodada seguinte tenta de novo. O Job
+# so falha se o runtime-core nao responder 2xx (rota inexistente = imagem
+# antiga, 401/403 = client errado, 5xx).
+#
+# ANTES DE APLICAR: o runtime-core do tenant tem de estar numa imagem com o
+# endpoint POST /api/cadastro/rotinas/logins (senao 404 e o Job falha todo dia).
+# =============================================================================
+apiVersion: batch/v1
+kind: CronJob
+metadata:
+  name: cadastro-logins
+  namespace: acme-prod
+spec:
+  # 00:20 em Sao Paulo: logo depois da virada do dia (a janela que terminou
+  # ontem expira na primeira hora de hoje), longe do backup (02:30), do resumo
+  # (04:30), da retencao (04:40) e das tarefas do financeiro (:15 e :30).
+  schedule: "20 0 * * *"
+  timeZone: America/Sao_Paulo
+  concurrencyPolicy: Forbid
+  successfulJobsHistoryLimit: 3
+  failedJobsHistoryLimit: 5
+  jobTemplate:
+    spec:
+      activeDeadlineSeconds: 900
+      backoffLimit: 1
+      template:
+        spec:
+          restartPolicy: OnFailure
+          containers:
+            - name: disparar
+              image: docker.io/curlimages/curl:8.9.1
+              imagePullPolicy: Never
+              command: ["/bin/sh", "/script/disparar.sh"]
+              env:
+                - name: KEYCLOAK_URL
+                  value: http://keycloak.plataforma-prod.svc:8080/realms/athleticmap-3/protocol/openid-connect/token
+                - name: ISSUER_HOST
+                  value: auth.athleticmap.com
+                - name: ALVO
+                  value: http://runtime-core/api/cadastro/rotinas/logins
+                - name: CLIENT_SECRET
+                  valueFrom:
+                    secretKeyRef:
+                      name: operacao-credentials
+                      key: client-secret
+              resources:
+                requests: { cpu: 10m, memory: 32Mi }
+                limits: { cpu: 200m, memory: 64Mi }
+              volumeMounts:
+                - name: script
+                  mountPath: /script
+          volumes:
+            - name: script
+              configMap:
+                name: financeiro-cron
+                defaultMode: 0555
diff --git a/tenants/demo/57-cronjob-logins.yaml b/tenants/demo/57-cronjob-logins.yaml
new file mode 100644
index 0000000..d04abda
--- /dev/null
+++ b/tenants/demo/57-cronjob-logins.yaml
@@ -0,0 +1,84 @@
+# =============================================================================
+# 07/10/2026 — a rotina DIARIA dos logins do app (cadastro, no runtime-core):
+#
+#   1. acompanhante ATIVO com a janela de acesso vencida (acesso_fim ANTES de
+#      hoje, no fuso de Sao Paulo) vira EXPIRADO e perde o login do app dos pais
+#      — o mesmo caminho de quem e marcado EXPIRADO na tela. O que ficou fora de
+#      ATIVO com o login ainda nao desativado (Keycloak fora na hora) e tentado
+#      de novo;
+#   2. funcionario que JA esta AFASTADO/DESLIGADO com login habilitado (gravado
+#      antes da regra de 07/10, ou ligado a um login depois de afastado) tem os
+#      logins desabilitados, com os ids guardados em
+#      funcionario.logins_desabilitados_pela_situacao (voltar a ATIVO reabilita
+#      so esses). Login com atm_admin fica habilitado — so um WARN no log.
+#
+# AGUARDANDO GRAVACAO no molde e nos 4 tenants antigos. Nada aqui foi aplicado.
+#
+# Por que CronJob, e nao @Scheduled: o mesmo motivo do financeiro e da retencao
+# — com mais de uma replica do runtime-core, um agendador no processo rodaria
+# duas vezes. A rotina e idempotente (a segunda rodada nao faz nada), mas uma so
+# e o desenho certo. Pela mesma razao NAO roda na subida do pod: para rodar logo
+# depois do deploy, `kubectl -n <tenant>-prod create job --from=cronjob/cadastro-logins cadastro-logins-agora`.
+#
+# DEPENDE do ConfigMap `financeiro-cron` (55-cronjobs-financeiro.yaml): o mesmo
+# `disparar.sh`, o mesmo client `operacao` e o mesmo Secret
+# `operacao-credentials`. O runtime-core so aceita a rota com token do client
+# `operacao` (SegurancaDoRuntime) — nenhum usuario humano, nem admin.
+#
+# Keycloak fora NAO falha o Job: o endpoint responde 200 com `falhas` > 0 no
+# corpo (e log ERROR no runtime-core), e a rodada seguinte tenta de novo. O Job
+# so falha se o runtime-core nao responder 2xx (rota inexistente = imagem
+# antiga, 401/403 = client errado, 5xx).
+#
+# ANTES DE APLICAR: o runtime-core do tenant tem de estar numa imagem com o
+# endpoint POST /api/cadastro/rotinas/logins (senao 404 e o Job falha todo dia).
+# =============================================================================
+apiVersion: batch/v1
+kind: CronJob
+metadata:
+  name: cadastro-logins
+  namespace: demo-prod
+spec:
+  # 00:20 em Sao Paulo: logo depois da virada do dia (a janela que terminou
+  # ontem expira na primeira hora de hoje), longe do backup (02:30), do resumo
+  # (04:30), da retencao (04:40) e das tarefas do financeiro (:15 e :30).
+  schedule: "20 0 * * *"
+  timeZone: America/Sao_Paulo
+  concurrencyPolicy: Forbid
+  successfulJobsHistoryLimit: 3
+  failedJobsHistoryLimit: 5
+  jobTemplate:
+    spec:
+      activeDeadlineSeconds: 900
+      backoffLimit: 1
+      template:
+        spec:
+          restartPolicy: OnFailure
+          containers:
+            - name: disparar
+              image: docker.io/curlimages/curl:8.9.1
+              imagePullPolicy: Never
+              command: ["/bin/sh", "/script/disparar.sh"]
+              env:
+                - name: KEYCLOAK_URL
+                  value: http://keycloak.plataforma-prod.svc:8080/realms/athleticmap-2/protocol/openid-connect/token
+                - name: ISSUER_HOST
+                  value: auth.athleticmap.com
+                - name: ALVO
+                  value: http://runtime-core/api/cadastro/rotinas/logins
+                - name: CLIENT_SECRET
+                  valueFrom:
+                    secretKeyRef:
+                      name: operacao-credentials
+                      key: client-secret
+              resources:
+                requests: { cpu: 10m, memory: 32Mi }
+                limits: { cpu: 200m, memory: 64Mi }
+              volumeMounts:
+                - name: script
+                  mountPath: /script
+          volumes:
+            - name: script
+              configMap:
+                name: financeiro-cron
+                defaultMode: 0555
diff --git a/tenants/escolinha/57-cronjob-logins.yaml b/tenants/escolinha/57-cronjob-logins.yaml
new file mode 100644
index 0000000..6f7c22d
--- /dev/null
+++ b/tenants/escolinha/57-cronjob-logins.yaml
@@ -0,0 +1,84 @@
+# =============================================================================
+# 07/10/2026 — a rotina DIARIA dos logins do app (cadastro, no runtime-core):
+#
+#   1. acompanhante ATIVO com a janela de acesso vencida (acesso_fim ANTES de
+#      hoje, no fuso de Sao Paulo) vira EXPIRADO e perde o login do app dos pais
+#      — o mesmo caminho de quem e marcado EXPIRADO na tela. O que ficou fora de
+#      ATIVO com o login ainda nao desativado (Keycloak fora na hora) e tentado
+#      de novo;
+#   2. funcionario que JA esta AFASTADO/DESLIGADO com login habilitado (gravado
+#      antes da regra de 07/10, ou ligado a um login depois de afastado) tem os
+#      logins desabilitados, com os ids guardados em
+#      funcionario.logins_desabilitados_pela_situacao (voltar a ATIVO reabilita
+#      so esses). Login com atm_admin fica habilitado — so um WARN no log.
+#
+# AGUARDANDO GRAVACAO no molde e nos 4 tenants antigos. Nada aqui foi aplicado.
+#
+# Por que CronJob, e nao @Scheduled: o mesmo motivo do financeiro e da retencao
+# — com mais de uma replica do runtime-core, um agendador no processo rodaria
+# duas vezes. A rotina e idempotente (a segunda rodada nao faz nada), mas uma so
+# e o desenho certo. Pela mesma razao NAO roda na subida do pod: para rodar logo
+# depois do deploy, `kubectl -n <tenant>-prod create job --from=cronjob/cadastro-logins cadastro-logins-agora`.
+#
+# DEPENDE do ConfigMap `financeiro-cron` (55-cronjobs-financeiro.yaml): o mesmo
+# `disparar.sh`, o mesmo client `operacao` e o mesmo Secret
+# `operacao-credentials`. O runtime-core so aceita a rota com token do client
+# `operacao` (SegurancaDoRuntime) — nenhum usuario humano, nem admin.
+#
+# Keycloak fora NAO falha o Job: o endpoint responde 200 com `falhas` > 0 no
+# corpo (e log ERROR no runtime-core), e a rodada seguinte tenta de novo. O Job
+# so falha se o runtime-core nao responder 2xx (rota inexistente = imagem
+# antiga, 401/403 = client errado, 5xx).
+#
+# ANTES DE APLICAR: o runtime-core do tenant tem de estar numa imagem com o
+# endpoint POST /api/cadastro/rotinas/logins (senao 404 e o Job falha todo dia).
+# =============================================================================
+apiVersion: batch/v1
+kind: CronJob
+metadata:
+  name: cadastro-logins
+  namespace: escolinha-prod
+spec:
+  # 00:20 em Sao Paulo: logo depois da virada do dia (a janela que terminou
+  # ontem expira na primeira hora de hoje), longe do backup (02:30), do resumo
+  # (04:30), da retencao (04:40) e das tarefas do financeiro (:15 e :30).
+  schedule: "20 0 * * *"
+  timeZone: America/Sao_Paulo
+  concurrencyPolicy: Forbid
+  successfulJobsHistoryLimit: 3
+  failedJobsHistoryLimit: 5
+  jobTemplate:
+    spec:
+      activeDeadlineSeconds: 900
+      backoffLimit: 1
+      template:
+        spec:
+          restartPolicy: OnFailure
+          containers:
+            - name: disparar
+              image: docker.io/curlimages/curl:8.9.1
+              imagePullPolicy: Never
+              command: ["/bin/sh", "/script/disparar.sh"]
+              env:
+                - name: KEYCLOAK_URL
+                  value: http://keycloak.plataforma-prod.svc:8080/realms/athleticmap-4/protocol/openid-connect/token
+                - name: ISSUER_HOST
+                  value: auth.athleticmap.com
+                - name: ALVO
+                  value: http://runtime-core/api/cadastro/rotinas/logins
+                - name: CLIENT_SECRET
+                  valueFrom:
+                    secretKeyRef:
+                      name: operacao-credentials
+                      key: client-secret
+              resources:
+                requests: { cpu: 10m, memory: 32Mi }
+                limits: { cpu: 200m, memory: 64Mi }
+              volumeMounts:
+                - name: script
+                  mountPath: /script
+          volumes:
+            - name: script
+              configMap:
+                name: financeiro-cron
+                defaultMode: 0555
diff --git a/tenants/piloto/57-cronjob-logins.yaml b/tenants/piloto/57-cronjob-logins.yaml
new file mode 100644
index 0000000..fe1f783
--- /dev/null
+++ b/tenants/piloto/57-cronjob-logins.yaml
@@ -0,0 +1,84 @@
+# =============================================================================
+# 07/10/2026 — a rotina DIARIA dos logins do app (cadastro, no runtime-core):
+#
+#   1. acompanhante ATIVO com a janela de acesso vencida (acesso_fim ANTES de
+#      hoje, no fuso de Sao Paulo) vira EXPIRADO e perde o login do app dos pais
+#      — o mesmo caminho de quem e marcado EXPIRADO na tela. O que ficou fora de
+#      ATIVO com o login ainda nao desativado (Keycloak fora na hora) e tentado
+#      de novo;
+#   2. funcionario que JA esta AFASTADO/DESLIGADO com login habilitado (gravado
+#      antes da regra de 07/10, ou ligado a um login depois de afastado) tem os
+#      logins desabilitados, com os ids guardados em
+#      funcionario.logins_desabilitados_pela_situacao (voltar a ATIVO reabilita
+#      so esses). Login com atm_admin fica habilitado — so um WARN no log.
+#
+# AGUARDANDO GRAVACAO no molde e nos 4 tenants antigos. Nada aqui foi aplicado.
+#
+# Por que CronJob, e nao @Scheduled: o mesmo motivo do financeiro e da retencao
+# — com mais de uma replica do runtime-core, um agendador no processo rodaria
+# duas vezes. A rotina e idempotente (a segunda rodada nao faz nada), mas uma so
+# e o desenho certo. Pela mesma razao NAO roda na subida do pod: para rodar logo
+# depois do deploy, `kubectl -n <tenant>-prod create job --from=cronjob/cadastro-logins cadastro-logins-agora`.
+#
+# DEPENDE do ConfigMap `financeiro-cron` (55-cronjobs-financeiro.yaml): o mesmo
+# `disparar.sh`, o mesmo client `operacao` e o mesmo Secret
+# `operacao-credentials`. O runtime-core so aceita a rota com token do client
+# `operacao` (SegurancaDoRuntime) — nenhum usuario humano, nem admin.
+#
+# Keycloak fora NAO falha o Job: o endpoint responde 200 com `falhas` > 0 no
+# corpo (e log ERROR no runtime-core), e a rodada seguinte tenta de novo. O Job
+# so falha se o runtime-core nao responder 2xx (rota inexistente = imagem
+# antiga, 401/403 = client errado, 5xx).
+#
+# ANTES DE APLICAR: o runtime-core do tenant tem de estar numa imagem com o
+# endpoint POST /api/cadastro/rotinas/logins (senao 404 e o Job falha todo dia).
+# =============================================================================
+apiVersion: batch/v1
+kind: CronJob
+metadata:
+  name: cadastro-logins
+  namespace: piloto-prod
+spec:
+  # 00:20 em Sao Paulo: logo depois da virada do dia (a janela que terminou
+  # ontem expira na primeira hora de hoje), longe do backup (02:30), do resumo
+  # (04:30), da retencao (04:40) e das tarefas do financeiro (:15 e :30).
+  schedule: "20 0 * * *"
+  timeZone: America/Sao_Paulo
+  concurrencyPolicy: Forbid
+  successfulJobsHistoryLimit: 3
+  failedJobsHistoryLimit: 5
+  jobTemplate:
+    spec:
+      activeDeadlineSeconds: 900
+      backoffLimit: 1
+      template:
+        spec:
+          restartPolicy: OnFailure
+          containers:
+            - name: disparar
+              image: docker.io/curlimages/curl:8.9.1
+              imagePullPolicy: Never
+              command: ["/bin/sh", "/script/disparar.sh"]
+              env:
+                - name: KEYCLOAK_URL
+                  value: http://keycloak.plataforma-prod.svc:8080/realms/athleticmap-1/protocol/openid-connect/token
+                - name: ISSUER_HOST
+                  value: auth.athleticmap.com
+                - name: ALVO
+                  value: http://runtime-core/api/cadastro/rotinas/logins
+                - name: CLIENT_SECRET
+                  valueFrom:
+                    secretKeyRef:
+                      name: operacao-credentials
+                      key: client-secret
+              resources:
+                requests: { cpu: 10m, memory: 32Mi }
+                limits: { cpu: 200m, memory: 64Mi }
+              volumeMounts:
+                - name: script
+                  mountPath: /script
+          volumes:
+            - name: script
+              configMap:
+                name: financeiro-cron
+                defaultMode: 0555