Update README.md

README.md

@@ -739,3 +739,148 @@ sudo systemctl reset-failed k3d-lab-ensure.service
 
 sudo LAB_HOST_IP=192.168.68.61 ./deploy-lab.sh install-autostart
 ```
+
+
+# Corrección v4.4.4: credenciales TLS para Gitea Actions
+
+El error:
+
+```text
+x509: certificate is valid for ... 192.168.68.61 ... not <otro valor>
+```
+
+indica que el secret `K8S_TLS_SERVER_NAME` no coincide con el host usado en
+`K8S_SERVER`.
+
+La versión agrega:
+
+```bash
+./deploy-lab.sh postdeploy-secrets
+```
+
+Este modo:
+
+- recrea el ServiceAccount y RBAC de lectura;
+- regenera token, CA, server y nombre TLS;
+- guarda un kubeconfig persistente de validación;
+- comprueba acceso real a Deployments en `ecommerce`.
+
+Valores esperados para este laboratorio:
+
+```text
+K8S_SERVER=https://192.168.68.61:46421
+K8S_TLS_SERVER_NAME=192.168.68.61
+```
+
+También incluye un `build.yaml` robustecido en:
+
+```text
+repo-patches/apps-registry/.gitea/workflows/build.yaml
+```
+
+El workflow normaliza el secret TLS y detiene la ejecución con un mensaje
+claro cuando no coincide con el host de `K8S_SERVER`.
+
+
+# Corrección v4.4.5: kubeconfig atómico para Gitea Actions
+
+El workflow usa primero el secret único:
+
+```text
+KUBE_CONFIG_DATA
+```
+
+Este secret contiene conjuntamente servidor, CA, `tls-server-name` y token.
+Así se evita mezclar una CA de un clúster anterior con el servidor o token
+actuales. Los cuatro secrets `K8S_*` se conservan únicamente como fallback.
+
+Regeneración:
+
+```bash
+LAB_HOST_IP=192.168.68.61 ./deploy-lab.sh postdeploy-secrets
+```
+
+Luego actualiza en Gitea `KUBE_CONFIG_DATA` con el contenido de:
+
+```text
+/DATA/AppData/k3d-lab/gitea-actions-secrets/KUBE_CONFIG_DATA.txt
+```
+
+El workflow muestra únicamente la huella SHA256 pública de la CA, nunca el
+certificado, token ni contenido del secret.
+
+
+# Corrección v4.4.6: token persistente para Gitea Actions
+
+El modo `postdeploy-secrets` ya no utiliza `kubectl create token`, porque
+ese mecanismo entrega tokens con duración limitada y el API Server puede
+acortar la duración solicitada.
+
+La versión crea y administra:
+
+```text
+ServiceAccount/ecommerce/gitea-postdeploy-validator
+Secret/ecommerce/gitea-postdeploy-validator-token
+```
+
+El Secret es de tipo:
+
+```text
+kubernetes.io/service-account-token
+```
+
+El controlador de Kubernetes genera dentro del Secret:
+
+- `token`;
+- `ca.crt`;
+- `namespace`.
+
+El RBAC continúa siendo de solo lectura sobre Deployments, ReplicaSets y
+Pods del namespace `ecommerce`.
+
+Regeneración:
+
+```bash
+LAB_HOST_IP=192.168.68.61 ./deploy-lab.sh postdeploy-secrets
+```
+
+Después actualiza solamente el secret de Gitea:
+
+```text
+KUBE_CONFIG_DATA
+```
+
+usando:
+
+```text
+/DATA/AppData/k3d-lab/gitea-actions-secrets/KUBE_CONFIG_DATA.txt
+```
+
+El workflow valida que el kubeconfig contenga token y muestra únicamente
+metadatos seguros: ServiceAccount y expiración, sin imprimir el token.
+
+
+# Corrección v4.4.6.1: indentación de build.yaml
+
+El bloque Python usado para leer metadatos del token había quedado en la
+columna 1 del YAML. Eso cerraba prematuramente el bloque:
+
+```yaml
+run: |
+```
+
+La corrección mantiene todo el código Python con la indentación YAML del
+script. Al procesarse `run: |`, Bash recibe nuevamente el código Python
+desde la columna 1.
+
+Archivo corregido:
+
+```text
+repo-patches/apps-registry/.gitea/workflows/build.yaml
+```
+
+También se incluye una copia en la raíz del paquete:
+
+```text
+build.yaml
+```