ci.yml

name: CI (build & test)

# AR-04 — automated quality gates for the .NET backend and the React/Vite frontend.
# The backend job stands up a PostgreSQL service so the WebApplicationFactory integration
# tests (LV-10) actually run instead of skipping, closing the gap that let the LV-04..07
# bug class reach only manual testing.

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

permissions:
  contents: read

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  backend:
    name: Backend (build + test)
    runs-on: ubuntu-latest

    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_DB: evolith_tracker
          POSTGRES_USER: evolith
          POSTGRES_PASSWORD: localdev
        ports:
          - 5432:5432
        options: >-
          --health-cmd "pg_isready -U evolith -d evolith_tracker"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 10

    env:
      # Matches the default connection the app + *LiveTests / integration tests expect,
      # so the DB-availability probe passes and the integration tests run for real.
      EVOLITH_TRACKER_DB: "Host=localhost;Port=5432;Database=evolith_tracker;Username=evolith;Password=localdev"
      ConnectionStrings__DefaultConnection: "Host=localhost;Port=5432;Database=evolith_tracker;Username=evolith;Password=localdev"
      # TenantProjectionDbContext (DS-07) reads MasterDataDb; unset it defaults to
      # localhost/user "postgres" and auth fails. Share the CI Postgres like local.
      ConnectionStrings__MasterDataDb: "Host=localhost;Port=5432;Database=evolith_tracker;Username=evolith;Password=localdev"
      DOTNET_NOLOGO: "true"
      DOTNET_CLI_TELEMETRY_OPTOUT: "true"

    defaults:
      run:
        working-directory: src/apps/tracker-api

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "10.0.x"

      - name: Restore
        run: dotnet restore Tracker.sln

      - name: Build (0 warnings enforced)
        run: dotnet build Tracker.sln --no-restore -c Release -warnaserror

      - name: Apply EF Core migrations
        run: |
          dotnet tool install --global dotnet-ef
          export PATH="$PATH:$HOME/.dotnet/tools"
          # Two DbContexts exist (DS-07 added TenantProjectionDbContext for the
          # MasterData tenant-projection schema). `database update` is ambiguous
          # without --context. Pass --connection explicitly so both apply against
          # the CI Postgres regardless of design-time config resolution (the
          # TenantProjection context otherwise falls back to localhost/postgres).
          CI_CONN="Host=localhost;Port=5432;Database=evolith_tracker;Username=evolith;Password=localdev"
          for ctx in TrackerDbContext TenantProjectionDbContext; do
            dotnet ef database update \
              --context "$ctx" \
              --connection "$CI_CONN" \
              --project Tracker.Infrastructure \
              --startup-project Tracker.Presentation \
              --configuration Release
          done

      - name: Test
        # GT-588 — se EXCLUYE la categoria `Interop`, que necesita el CLI del Core construido.
        # Corre en su propio job (`transparency-interop`), que si lo aporta. Sin esta exclusion,
        # este job seria rojo; con el `return` silencioso que tenia antes, era verde sin comprobar
        # nada, que es peor.
        run: dotnet test Tracker.sln --no-build -c Release --filter "Category!=Interop" --logger "trx;LogFileName=test-results.trx"

      - name: Smoke — la aplicacion arranca LIMPIA contra Postgres
        # Anadido tras la regresion del 2026-07-19: el filtro global por tenant de CD-27
        # rompio el despachador del outbox de intake y estuvo horas en `main` sin que nada lo
        # viera. CI aplicaba migraciones pero NUNCA ARRANCABA LA APLICACION, y el SQL crudo
        # no se interpreta hasta que hay un motor real detras.
        #
        # El script no se conforma con que responda: durante todo aquel fallo `/health` daba
        # 200 mientras el despachador reventaba en cada ciclo. Observa el LOG, y observa el
        # tiempo suficiente para que los procesos de fondo completen varias vueltas.
        working-directory: .
        env:
          SMOKE_CONFIG: Release
          SMOKE_OBSERVE_SECONDS: "25"
        run: bash .harness/scripts/smoke-app.sh

      - name: Upload test results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: backend-test-results
          path: src/apps/tracker-api/**/TestResults/*.trx
          if-no-files-found: ignore

  # GT-588 — la unica prueba de que el firmante C# y el verificador TypeScript producen y leen los
  # MISMOS bytes. Entre ambos hay JSON canonico, CBOR determinista, cabeceras COSE y un arbol de
  # Merkle: cuatro capas donde un solo byte de diferencia lo rompe todo, y ninguna de ellas se
  # comprueba comparando estructuras C# contra estructuras C#.
  #
  # Va en su propio job porque necesita construir el CLI del Core, que es caro y no tiene por que
  # frenar al resto. Y MUERDE: los tests fallan —no se saltan— cuando no encuentran el CLI, porque
  # una prueba de interoperabilidad que pasa sin la otra mitad presente reporta como verificado algo
  # que nadie miro.
  transparency-interop:
    name: Transparency interop (C# firma · TypeScript verifica)
    runs-on: ubuntu-latest

    env:
      DOTNET_NOLOGO: "true"
      DOTNET_CLI_TELEMETRY_OPTOUT: "true"

    steps:
      - name: Checkout Tracker
        uses: actions/checkout@v4
        with:
          path: tracker

      - name: Checkout Evolith Core
        uses: actions/checkout@v4
        with:
          repository: beyondnetcode/evolith_arch32
          token: ${{ secrets.CORE_REPO_TOKEN }}
          path: core

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "npm"
          cache-dependency-path: core/package-lock.json

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "10.0.x"

      - name: Build the Core CLI (the verifier)
        working-directory: core
        run: |
          npm ci
          npm run build

      - name: Verify the CLI exposes `audit verify`
        working-directory: core
        run: |
          set -euo pipefail
          # Se comprueba ANTES de correr los tests para que un CLI construido pero sin el comando
          # de un mensaje claro, en vez de un fallo de proceso dentro de una asercion.
          test -f src/sdk/cli/dist/main.js
          node src/sdk/cli/dist/main.js audit verify --help > /dev/null

      - name: Cross-language interop tests
        working-directory: tracker/src/apps/tracker-api
        env:
          EVOLITH_CLI_MAIN: ${{ github.workspace }}/core/src/sdk/cli/dist/main.js
        run: dotnet test Tracker.sln --filter "Category=Interop" --logger "trx;LogFileName=interop-results.trx"

  frontend:
    name: Frontend (lint + typecheck + build)
    runs-on: ubuntu-latest

    defaults:
      run:
        working-directory: src

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          cache: "npm"
          cache-dependency-path: src/package-lock.json

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npx nx lint tracker-web

      - name: Typecheck
        run: npx nx typecheck tracker-web

      - name: Build
        run: npx nx build tracker-web


  gap-registry:
    name: Gap registry coherence
    runs-on: ubuntu-latest

    # Deliberadamente SIN filtro `paths`: corre en todo PR. El desorden que vigila no lo
    # introduce quien edita los ficheros del registro, sino quien CIERRA un item y actualiza
    # la fila del board olvidando la ficha — un cambio que casi siempre viene acompanado de
    # codigo. Filtrar por rutas dejaria fuera justo el caso que motivo este guardian.
    #
    # Falla el build a proposito. Un registro de gobernanza que miente sobre que esta hecho
    # dirige mal las decisiones de la semana siguiente, y un guardian que solo avisa se
    # ignora. El job tarda segundos y no necesita ni base de datos ni SDK.
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Board y catalogo deben contar lo mismo
        run: python3 .harness/scripts/check-gap-registry.py

      # GT-435 — hasta el 2026-08-02 este repositorio publicaba TRES Dockerfiles y CERO
      # imagenes: ningun workflow los construia, mientras los charts referenciaban
      # `evolith-tracker-api:0.0.1`, `...-web:0.0.1` y `evolith-tracker-gateway:local`, este
      # ultimo un tag que ningun registro puede servir. El camino de despliegue no estaba sin
      # probar: estaba sin cablear. Nada habia tirado nunca de esas imagenes, asi que ningun
      # CI en verde podia revelarlo.
      - name: Los charts piden imagenes que este repositorio produce
        run: node .harness/scripts/check-deployable-images.mjs

      # El paso anterior contrasta ademas el REGISTRO, la tercera superficie, anadida el
      # 2026-08-01: board y catalogo llevaban sincronizados desde que existe el guard y
      # nadie miraba el registro, que comparte el mismo espacio de ids. De los 34 ids
      # comunes, CINCO se contradecian. Estas pruebas son negativas: comprueban que el
      # contraste se pone rojo cuando debe, no que exista.
      - name: Self-tests for the board/registro contrast
        run: python3 .harness/scripts/check-gap-registry.test.py

      # Las fichas del board recogen hallazgos de auditoria y nada las vuelve a
      # contrastar con el codigo, asi que envejecen en silencio mientras siguen
      # dirigiendo prioridades. El 2026-08-01 se encontraron CINCO reclamando trabajo ya
      # hecho. Este guard re-comprueba las afirmaciones que una maquina puede falsar.
      #
      # No lee la prosa de las filas, a proposito: el `50-validate-gap-claim` del Core ya
      # probo esa via, produjo nueve atribuciones falsas en un dia y enseno a los autores
      # a borrar frases verdaderas. Aqui solo se comprueba lo que alguien escribio como
      # DATO en `falsifiable-claims.json`.
      - name: Board claims still hold against the code
        run: node .harness/scripts/check-falsifiable-claims.mjs

      - name: Self-tests for the falsifiable-claim guard
        run: node --test .harness/scripts/check-falsifiable-claims.test.mjs