OASIS_MOBILE/AUTOMATIZACION/STATUS_2026-05-15.md
oasis-bot 0576a5df73 docs(automatizacion): status 2026-05-15 — setup inicial server + APK 0.7.6 publicada manual
- Estructura /home/capitansito/oasis-auto/ creada en hacksito.com
- Keystore nuevo generado (alias oasis), antiguo perdido (password olvidada)
- Dependencias build instaladas: openjdk-17, apktool 2.7.0, apksigner 0.9, zipalign
- APK 0.7.6-20260515 subida manual a 0asis.net/downloads/, symlink latest.apk
- 2 botones verde neón en index.html: DOWNLOAD APK + MOBILE SOURCE
- Pipeline auto NO activo: pendiente resolver método de build sin APK base

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-15 22:40:47 +02:00

4.9 KiB

Estado de la automatización — 2026-05-15

Resumen

Setup inicial en hacksito.com (/home/capitansito/oasis-auto/). APK 0.7.6 manual publicada en 0asis.net/downloads/latest.apk. Pipeline automático NO está activo todavía (falta resolver método de build).

Lo que YA funciona

Infraestructura (server hacksito.com)

  • /home/capitansito/oasis-auto/ — workspace con subdirs:
    • mobile/ — clone de gitea.laenre.net/hacklab/OASIS_MOBILE, configurado con identidad oasis-bot <bot@laenre.net> para commits automáticos. .git/config con chmod 600 (contiene credenciales gitea embebidas en URL).
    • secrets/ — chmod 700.
      • oasis-release-key.jks — keystore NUEVO generado el 2026-05-15 (alias oasis, validez 10000 días, SHA-256 fingerprint 17:DD:F8:B7:...). El antiguo se perdió porque se olvidó la password.
      • keystore.pass — chmod 600, contiene la password del keystore nuevo.
    • scripts/, prompts/, reports/, apks/, upstream-snapshots/, logs/ — vacíos, pendientes de F1.
  • /var/www/0asis.net/downloads/ — público.
    • oasis-v0.7.6-20260515-pruebas.apk (138 MB, build manual subida por scp desde ransomsito)
    • latest.apk → symlink al anterior

Dependencias instaladas (sistema)

  • openjdk-17-jdk-headless 17.0.17
  • apktool 2.7.0-dirty
  • apksigner 0.9
  • zipalign
  • keytool (viene con JDK)

Web 0asis.net

  • 2 botones en verde neón añadidos en index.html sección gs-more-links (después de EXPLORE MORE):
    • DOWNLOAD APK/downloads/latest.apk
    • MOBILE SOURCE → repo gitea
  • CSS añadido en styles.css: clase .gs-link-btn-green con el tono neón rgba(57,255,20,...).

Lo que QUEDA pendiente

Decisión bloqueante: método de build APK

El doc original (CONTEXT/cambio_apk_repack.txt) propone método quirúrgico con APK base como molde (oasis-v0.6.8.apk, 55 MB original sin modificar):

  1. cp APK base → tmp
  2. zip -d META-INF (firma vieja)
  3. crear nuevo assets/nodejs-project.zip desde nodejs-project/
  4. zip -0 (STORED) reemplazar el zip dentro del APK
  5. zipalign -p 4
  6. apksigner sign

El usuario NO quiere usar APK base como molde.

Alternativas estudiadas pero no implementadas:

  • apktool b: el repo NO tiene apktool.yml (requerido). Y el doc del propio user dice "no usar apktool b" por riesgo de comprimir resources.arsc mal → "App not installed" en Android 7+. Apktool 2.7 modernos lo manejan correctamente pero está sin verificar.
  • Custom zip script en Python (pendiente): el repo NO es output de apktool d (AndroidManifest.xml es binario, sin smali/, res/ con nombres acortados) — es un unzip directo del APK. Por tanto se podría reempaquetar con zipfile de Python aplicando compresión per-archivo según las reglas del doc línea 99-106:
    • STORED: resources.arsc, assets/dexopt/*, assets/nodejs-project.zip
    • DEFLATED: el resto (classes.dex, lib/*.so, AndroidManifest.xml, res/*, kotlin/*)
  • Stripear de META-INF/ los archivos de firma (MANIFEST.MF, OASIS.SF, OASIS.RSA) antes de firmar — los 33 .version SÍ se mantienen.

Decisión a tomar próxima sesión: implementar el custom zip script en Python y validar con apksigner verify + instalación real en device.

Tareas pendientes (orden)

  1. Resolver build APK — escribir build-apk.py o equivalente, probar contra el código actual del repo, comparar APK resultante con la 0.7.6-20260515 manual (apksigner verify, listado de zip).
  2. Escribir scripts scout/merger/builder — bash + prompts claude headless.
  3. Test pipeline end-to-end manual — simular un sync de epsylon.
  4. Configurar cron sábados 03:000 3 * * 6 /home/capitansito/oasis-auto/scripts/oasis-pipeline.sh.
  5. Notificación de fallo — log + posible notificación email/Telegram (opcional).

Decisiones del usuario ya tomadas

  • Política REVIEW: SALTARSE (solo SAFE se aplica, REVIEW se loggea pero no toca).
  • Push automático directo a main en gitea (sin rama auto-merge).
  • Cron semanal sábados 03:00.
  • NO usar API key Anthropic de pago: el cron invoca claude -p con la sesión existente.
  • NO crear git remote upstream hacia epsylon — usar snapshot por tarball (curl github.com/epsylon/oasis/archive/main.tar.gz).

Seguridad — pendiente de limpiar

  • CONTEXT/cambio_apk_repack.txt línea 20 expone password del keystore antiguo (oasis123). Ya no se usa (nuevo keystore generado) pero queda en histórico de gitea. Considerar redactar y commit.

Cómo retomar

  1. Conectarte por SSH a capitansito@hacksito.com.
  2. Verificar estado: ls /home/capitansito/oasis-auto/ y ls /var/www/0asis.net/downloads/.
  3. Empezar por el script Python de build (/home/capitansito/oasis-auto/scripts/build-apk.py).
  4. Validar resultado: apksigner verify oasis-test.apk debe decir "Verifies" + instalación real en device.
  5. Si pasa, seguir con scout/merger.