ci: dual-publish docs to github pages and vercel

.github/workflows/mkdocs.yml

@@ -3,38 +3,81 @@ on:
   push:
     branches:
       - main
+  pull_request:
+
+# Least privilege at the top; the pages job re-grants what it needs.
 permissions:
-  contents: write
-  id-token: write
-  pages: write
+  contents: read
+
+concurrency:
+  group: docs-${{ github.ref }}
+  cancel-in-progress: true
+
 jobs:
   build:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
-      - name: Configure Git Credentials
-        run: |
-          git config user.name github-actions[bot]
-          git config user.email 41898282+github-actions[bot]@users.noreply.github.com
       - uses: actions/setup-python@v5
         with:
-          python-version: 3.12
+          python-version: '3.12'
       - run: pip install mkdocs-material mkdocs-static-i18n
-      - run: mkdocs build
-      - run: cd /home/runner/work/docs/docs/site && tar --dereference -cvf "/home/runner/work/_temp/artifact.tar" .
+      # --strict fails the build on broken internal links. The docs use
+      # relative .md cross-links, so this is the gate that keeps them honest.
+      - run: mkdocs build --strict
+      # tar --dereference is what preserves the hidden .well-known directory.
+      # Both deploy jobs consume this one artifact, so the two origins cannot drift.
+      - name: Package site
+        run: |
+          mkdir -p /tmp/pages
+          tar --dereference -cf /tmp/pages/artifact.tar -C site .
       - uses: actions/upload-artifact@v4
         with:
           name: github-pages
-          path: /home/runner/work/_temp/artifact.tar
+          path: /tmp/pages/artifact.tar
           retention-days: 1
           if-no-files-found: error
-          compression-level: 6
-          overwrite: false
-          include-hidden-files: false
-      - uses: actions/deploy-pages@v4
+
+  deploy-pages:
+    needs: build
+    if: github.event_name == 'push'
+    runs-on: ubuntu-latest
+    permissions:
+      pages: write
+      id-token: write
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    steps:
+      - id: deployment
+        uses: actions/deploy-pages@v4
         with:
-          timeout: 600000
-          error_count: 10
-          reporting_interval: 5000
           artifact_name: github-pages
-          preview: false
+
+  deploy-vercel:
+    needs: build
+    # Fork PRs cannot receive secrets, so skip rather than fail. They still get
+    # the build job above as validation. pull_request_target is deliberately
+    # NOT used: it would expose the Vercel token to untrusted PR code.
+    if: >-
+      github.event_name == 'push' ||
+      github.event.pull_request.head.repo.full_name == github.repository
+    runs-on: ubuntu-latest
+    env:
+      VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
+      VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/download-artifact@v4
+        with:
+          name: github-pages
+          path: /tmp/pages
+      - run: npm install --global vercel@latest
+      - name: Package for Vercel
+        run: scripts/build-vercel-output.sh /tmp/pages/artifact.tar
+      - name: Deploy (production)
+        if: github.event_name == 'push'
+        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}
+      - name: Deploy (preview)
+        if: github.event_name == 'pull_request'
+        run: vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }}

.gitignore

@@ -17,9 +17,13 @@ dist/
 .devcontainer/
 smartcontract/.vscode/settings.json
 site/
+.venv/
+.vercel/
 
 .DS_Store
 **/.DS_Store
 
 __pycache__/
 **/__pycache__/
+.vercel
+.env*

docs/Validator Multicast Connection.es.md

@@ -1,14 +1,16 @@
-# Conexión Multicast para Validadores
-!!! warning "This translation was generated using artificial intelligence and has not been reviewed by a human translator. It may contain inaccuracies or errors and should not be relied upon."
+---
+description: Configure un validador conectado para publicar leader shreds en el feed multicast de DoubleZero edge.
+---
 
+# Conexión Multicast del Validador
 !!! warning "Al conectarme a DoubleZero acepto los [Términos de Servicio de DoubleZero](https://doublezero.xyz/terms-protocol)"
 
-!!! note inline end "Empresas de trading y negocios"
-    Si opera una empresa de trading o un negocio que desea suscribirse al feed, registre su interés para obtener más información [aquí](https://doublezero.xyz/edge-form).
+!!! note inline end "Firmas de trading y empresas"
+    Si opera una firma de trading o empresa que desea suscribirse al feed, por favor registre su interés para obtener más información [aquí](https://doublezero.xyz/edge-form).
 
-Si aún no está conectado a DoubleZero, complete la documentación de [Configuración](setup.md) y de conexión de validador [Mainnet-Beta](DZ%20Mainnet-beta%20Connection.md).
+Si aún no está conectado a DoubleZero, por favor complete la documentación de [Configuración](<setup.md>) y de conexión del validador a [Mainnet-Beta](<DZ Mainnet-beta Connection.md>).
 
-Si es un validador ya conectado a DoubleZero, puede continuar con esta guía.
+Si es un validador que ya está conectado a DoubleZero, puede continuar con esta guía.
 
 ## 1. Configuración del Cliente
 
@@ -18,7 +20,7 @@ Si es un validador ya conectado a DoubleZero, puede continuar con esta guía.
 
     Puede enviar a Jito y al grupo `edge-solana-shreds` al mismo tiempo.
 
-    Ejemplo:
+    ejemplo:
 
     ```json
     #!/bin/bash
@@ -31,7 +33,7 @@ Si es un validador ya conectado a DoubleZero, puede continuar con esta guía.
     ```
 
 2. Reinicie su validador.
-3. Conéctese al grupo de multicast de DoubleZero `edge-solana-shreds` como publicador: `doublezero connect ibrl && doublezero connect multicast --publish edge-solana-shreds`
+3. Conéctese al grupo multicast de DoubleZero `edge-solana-shreds` como publicador: `doublezero connect ibrl && doublezero connect multicast --publish edge-solana-shreds`
 
 ### Frankendancer
 
@@ -43,49 +45,68 @@ Si es un validador ya conectado a DoubleZero, puede continuar con esta guía.
     ```
 
 2. Reinicie su validador.
-3. Conéctese al grupo de multicast de DoubleZero `edge-solana-shreds` como publicador: `doublezero connect ibrl && doublezero connect multicast --publish edge-solana-shreds`
+3. Conéctese al grupo multicast de DoubleZero `edge-solana-shreds` como publicador: `doublezero connect ibrl && doublezero connect multicast --publish edge-solana-shreds`
 
-## 2. Confirmar que está publicando shreds de líder
+## 2. Confirme que está publicando leader shreds
 
-Una vez conectado, puede verificar [este panel](https://data.doublezero.xyz/dz/publisher-check) para confirmar que está publicando shreds. No verá la confirmación hasta que haya publicado shreds de líder para al menos un slot.
+Una vez que esté conectado, puede verificar [este panel](https://data.doublezero.xyz/dz/publisher-check) para confirmar que está publicando shreds. No verá la confirmación hasta después de haber publicado leader shreds durante al menos un slot.
 
-## 3. Recompensas para Validadores
+## Endpoints Multicast (IP vs Puerto)
 
-Por cada época en que los validadores publiquen shreds de líder, serán recompensados proporcionalmente por su contribución según las suscripciones. Los detalles de este sistema serán anunciados y detallados en una fecha posterior.
+Para el tráfico de shreds, la **dirección IP** selecciona el feed multicast y el **puerto** selecciona el servicio UDP.  
+Todos los feeds a continuación usan el puerto UDP `7733`.
+
+Puede descubrir las IPs de grupo actuales con:
+
+```bash
+doublezero multicast group list
+```
+
+- `edge-solana-shreds` (leader): `233.84.178.1:7733`
+- `edge-solana-retrans-eu`: `233.84.178.12:7733`
+- `edge-solana-retrans-apac`: `233.84.178.13:7733`
+- `edge-solana-retrans-amer`: `233.84.178.14:7733`
+
+Para referencias de API y endpoints de datos legibles por máquina, consulte [https://data.doublezero.xyz/api/v1/docs](https://data.doublezero.xyz/api/v1/docs).
+
+## 3. Recompensas del Validador
+
+Por cada época en la que los validadores publiquen leader shreds, serán recompensados proporcionalmente por su contribución basándose en las suscripciones. Los detalles específicos de este sistema serán anunciados y detallados en una fecha posterior.
 
 ## Solución de Problemas
 
-### No se publican shreds de líder:
+### No se Publican Leader Shreds:
 
 La causa más común de no transmitir shreds es la versión del cliente:
 
 Debe estar ejecutando Jito-Agave 3.1.9+, JitoBam 3.1.9+, Frankendancer o Harmonic 3.1.11+. Otras versiones de cliente no funcionarán.
 
 ### Retransmisión:
 
-1. Una causa común de retransmisión de shreds es una configuración simple. Es posible que tenga habilitado el flag para enviar shreds de retransmisión en su script de inicio; deberá deshabilitarlo.
+1. Una causa común de retransmisión de shreds es una configuración simple. Es posible que tenga habilitada la flag para enviar shreds de retransmisión en su script de inicio; deberá deshabilitarla.
+
+    La flag a eliminar en Jito-Agave es: `--shred-retransmit-receiver-address`.
 
-    El flag que debe eliminar en Jito-Agave es: `--shred-retransmit-receiver-address`.
+1. Revise el [panel de publicadores](https://data.doublezero.xyz/dz/publisher-check) y vea si tiene shreds retransmitidos. En la tabla, observe la columna **No Retransmit Shreds**—una X roja significa que está retransmitiendo.
 
-1. Revise el [panel de publicadores](https://data.doublezero.xyz/dz/publisher-check) y compruebe si tiene shreds retransmitidos. En la tabla, observe la columna **No Retransmit Shreds**—una X roja significa que está retransmitiendo.
+    !!! note "vista por época"
+        Tenga en cuenta que hay diferentes ventanas de tiempo para ver el panel de publicadores. Si ve retransmisión en la **vista de 2 épocas**, pero ha realizado un cambio reciente, intente cambiar a la vista de **slot reciente**.
 
-    !!! note "Vista de época"
-        Tenga en cuenta que hay diferentes ventanas de tiempo para ver el panel de publicadores. Si ve retransmisión en la **vista de 2 épocas**, pero realizó un cambio reciente, intente cambiar a la vista de **slot reciente**.
 
     ![Panel de verificación de publicadores](images/publisher-check-dashboard.png)
 
 2. Encuentre la IP de su cliente y busque su usuario en [DoubleZero Data](https://data.doublezero.xyz/dz/users).
 
     ![Usuarios de DoubleZero Data](images/doublezero-data-users.png)
 
-3. Haga clic en **Multicast** para abrir su vista de multicast.
+3. Haga clic en **Multicast** para abrir su vista multicast.
 
-    La captura de pantalla a continuación muestra: **Retransmitiendo** (indeseable) tráfico saliente constante sin patrón de slot de líder.
+    La captura de pantalla a continuación muestra: **Retransmitiendo** (no deseado) tráfico saliente constante sin patrón de leader-slot.
 
     ![Vista multicast del usuario - ejemplo de retransmisión](images/user-multicast-view-retransmit.png)
 
-    La captura de pantalla a continuación muestra: **Saludable** (publicando solo shreds de líder) tráfico saliente en picos, conocido como patrón de diente de sierra, que se alinea con sus slots de líder.
+    La captura de pantalla a continuación muestra: **Saludable** (publicando solo leader shreds) tráfico saliente en picos, conocido como patrón de diente de sierra, que se alinean con sus leader slots.
 
     ![Vista multicast del usuario - ejemplo de publicador saludable](images/user-multicast-view-healthy.png)
 
-El gráfico muestra si está enviando solo shreds de líder. Los picos de tráfico deben alinearse con cuando tiene un slot de líder. Cuando no tiene un slot de líder, no debe haber tráfico. Si está retransmitiendo, verá un flujo constante de tráfico en lugar de picos alineados con slots.
+El gráfico muestra si está enviando solo leader shreds. Los picos de tráfico deben alinearse con el momento en que tiene un leader slot. Cuando no tiene un leader slot, no debería haber tráfico. Si está retransmitiendo, verá un flujo constante de tráfico en lugar de picos alineados con los slots.