adicao de campo played ao firebase no campo das jornadas

app/src/main/java/com/example/vdcscore/ui/gallery/Match.java

@@ -195,4 +195,16 @@ public class Match {
     public void setMatchReportUrl(String matchReportUrl) {
         this.matchReportUrl = matchReportUrl;
     }
+
+    private boolean played;
+
+    @PropertyName("played")
+    public boolean isPlayed() {
+        return played;
+    }
+
+    @PropertyName("played")
+    public void setPlayed(boolean played) {
+        this.played = played;
+    }
 }

docs/05_PROGRESSO_E_ESTADO_ATUAL.md

@@ -137,3 +137,34 @@ As notícias foram promovidas a ecrã principal (Ínicio) da aplicação. A sec
 
 **O que foi removido**
 - O cabeçalho estático no ficheiro `fragment_news.xml` foi removido para promover um design mais nativo e espaçoso.
+
+## Relatório de Intervenção (Preparação de Jogos em Direto - Live Matches)
+
+**Progresso Geral Atualizado**
+Foi implementada a lógica para o Scraper detetar jogos que ainda não foram disputados (sem golos) e prepará-los automaticamente na base de dados para acompanhamento em direto. A estrutura base do jogo é injetada no Firebase de modo a que um árbitro ou gestor possa depois adicionar eventos em tempo real, sem o risco do Scraper apagar o seu trabalho a meio do jogo.
+
+**O que foi criado ou adicionado**
+- Adicionada a extração inicial (usando um `ValueEventListener` com `CountDownLatch`) para obter todas as chaves (IDs de jornada) dos jogos já registados no nó `live_matches`.
+- Adicionada lógica no processo de iteração dos jogos do `StandingsScraper.java` para injetar um objeto JSON preparatório nos jogos futuros. A estrutura inclui o nó `info` (com os nomes, logótipos, estado de agendado, e 0 golos) e o nó de `eventos` com o primeiro texto automático ("Partida iniciada em...").
+
+**O que foi modificado e porquê**
+- O `StandingsScraper.java` foi modificado para suportar o estado de "agendado". Para além de não enviar golos para a classificação nestes jogos, ele avalia ativamente se deve instanciar o jogo no Firebase. O bloqueio anti-overwrite (ler os `existingLiveMatches`) foi criado intencionalmente porque se o Scraper corresse a meio de uma partida, faria reset dos golos para `0` e apagaria as anotações do árbitro.
+
+**O que foi removido**
+- Nada foi removido. Apenas foi expandida a robustez e conectividade do Scraper.
+
+## Relatório de Intervenção (Campo 'played' nas Jornadas)
+
+**Progresso Geral Atualizado**
+Foi implementada a lógica para distinguir entre jogos já realizados e jogos agendados através de um novo campo booleano `played`. Esta melhoria permite à aplicação Android e a outros sistemas identificar rapidamente o estado de cada partida sem necessidade de inferência baseada na presença ou ausência de golos em tempo de execução.
+
+**O que foi criado ou adicionado**
+- Adicionado o campo `played` (booleano) a cada objeto de jogo dentro do nó `jornadas` na Firebase.
+- No projeto Android, foi adicionado o atributo `played` à classe `Match.java` (no package `ui.gallery`), juntamente com os seus getters e setters devidamente anotados com `@PropertyName("played")`.
+
+**O que foi modificado e porquê**
+- **StandingsScraper.java:** Modificado para calcular o valor de `played`. A lógica baseia-se na presença de dados de golos (`homeGoals` / `awayGoals`) retornados pela API da AFAVCD. Se existirem golos registados, o campo é definido como `true`; caso contrário, é `false`.
+- **Match.java (Android):** Atualizado para permitir que a aplicação consuma esta nova propriedade da base de dados, facilitando futuras implementações de UI (ex: esconder scores em jogos não jogados ou aplicar estilos diferenciados).
+
+**O que foi removido**
+- Nenhuma funcionalidade foi removida. Trata-se de um enriquecimento do modelo de dados existente.