[pablodz]

Los SDKs Go y Python necesitan instalarse, probarse y publicarse desde sus propios repositorios. Este cambio convierte peru-sdk en el hub de coordinación y elimina las copias locales después de trasladar implementación, contratos y corpus a sus repositorios independientes.

El nuevo verificador consume commits públicos fijados en ecosystem.lock.json: comprueba sus referencias comunes y hashes, construye los paquetes, instala la wheel Python fuera del checkout y ejecuta la suite incluida en el sdist. También descarga el módulo Go desde GitHub, compila un consumidor y ejecuta sus pruebas desde el módulo distribuido. Los artefactos se auditan para detectar archivos de otros SDKs.

PRs del cambio, en orden de fusión:

1. Versiona el corpus común y genera su distribución independiente peru-sdk-conformance#1 — 37 casos sintéticos y manifiesto verificable.
2. Genera modelos por lenguaje con contratos y entradas fijadas peru-sdk-models#1 — contratos, fuentes oficiales y generación por lenguaje.
3. Implementa SDK go nativo con distribución y releases independientes peru-sdk-go#1 — cliente nativo, distribución y release Go.
4. Implementa SDK python nativo con distribución y releases independientes peru-sdk-python#1 — cliente nativo, wheel/sdist y publicación PyPI mediante OIDC.
5. Esta PR — integración de la combinación fijada.

Conservar merge commits en los repositorios nuevos: sus commits completos están fijados en los locks. Los workflows de publicación verifican artefactos antes de publicar y mantienen los permisos en el job de cada SDK. Los builds de revisión producen archivos descargables sin publicar versiones.

Validación realizada: integración completa local con consumo del módulo Go público; pruebas Go con detector de carreras y sin cgo; suite Python desde la wheel instalada y el sdist; comprobación estricta de distribuciones con Twine; CI de los componentes en Linux y Windows. El CI de integración del hub también pasó y conserva el informe y los artefactos descargables.

Alcance: Consulta Integrada SUNAT con transporte HTTP real, autenticación client_credentials, caché de token, importes exactos y errores diferenciados. Las pruebas usan servidores locales y datos sintéticos; no se ha verificado el servicio con credenciales institucionales. RENIEC sigue siendo un proveedor sintético. Emisión UBL, firma y CDR, Java/Maven y TypeScript/npm quedan pendientes. PyPI requiere configurar el Trusted Publisher en la cuenta del proyecto; todavía no hay publicación externa. Los runners son de GitHub: no se ha modificado k3s ni añadido runners al host.