Aceptación de una versión
Ejecuta todos los controles sobre el commit y el artefacto que se van a publicar. Las definiciones de CI y
los resultados históricos no demuestran que una nueva versión haya superado los controles. Registra el commit,
el SHA-256 del artefacto, la plataforma, el comando y el resultado en validation.md.
- [ ] Las pruebas del espacio de trabajo Rust, el formato y Clippy sin advertencias se superan.
- [ ] La recuperación cubre chino y varias palabras clave, desplazamientos de fragmentos, exclusión de contenido privado y credenciales, colisiones de ID de seis caracteres, invalidación de caché, bloqueo, revocación o cambios de origen durante operaciones en curso y restricciones de divulgación exclusivamente en el dispositivo. Verifica la inferencia local de EmbeddingGemma y los hashes de archivos del modelo, el comportamiento del proxy y los reintentos y la validación de citas de las respuestas. Registra si se probaron los endpoints reales de modelos de clientes.
- [ ] El análisis, el formato y las pruebas de widgets de Flutter se superan.
- [ ] Los trabajos de correo y firma de aplicaciones se superan con identidades sintéticas: verificación y descifrado S/MIME y OpenPGP, verificación de APK firmados y un AAB firmado real comprobado por la canalización de publicación. Comprueba la vinculación entre vista previa y aprobación, la limpieza tras fallos y los espacios de trabajo de credenciales accesibles solo por el propietario en cada plataforma de escritorio.
- [ ] En macOS, valida la firma de iOS con una identidad Apple desechable, un perfil y derechos coincidentes, incluido el orden de los frameworks, la limpieza del Llavero y la instalación en dispositivos. No consideres la compilación en Windows como prueba de firma de iOS.
- [ ] Las pruebas de regresión de sustitución y copia de secretos de Wiki se superan en core, CLI/IPC, FFI y Flutter. Verifica los fallos atómicos, la conservación de los mapeos de edición, la resolución del valor actual, la denegación de MCP y el manejo de bloqueo y segundo plano con datos sintéticos.
- [ ] Se comprueba la entrega real al portapapeles en cada plataforma distribuida, incluida la disponibilidad de auxiliares de Linux y la entrega al sistema operativo móvil. Las pruebas que simulan el portapapeles por sí solas no satisfacen este control. Comprueba la sincronización y recuperación de referencias a secretos con clientes actualizados y documenta la incompatibilidad con clientes antiguos en las notas de la versión.
- [ ] La prueba de humo nativa de Android se supera después de recompilar FFI, seguida de una recompilación
normal del APK y la verificación con
scripts/verify-apk-native.py. - [ ] Las comprobaciones de Xcode y del simulador de iOS se superan con la biblioteca nativa y el complemento AppAuth.
- [ ] El hardware Android ARM64 y un dispositivo iOS físico superan las comprobaciones de bloqueo y segundo plano, persistencia del almacenamiento seguro y recuperación.
- [ ] Los registros nativos y de escritorio reales de OneDrive y Google Drive completan las pruebas de consentimiento, renovación, cierre de sesión, convergencia entre dos dispositivos, reintento sin conexión y revocación. Utiliza cuentas en la nube desechables y registros sintéticos. Registra las combinaciones de cliente y plataforma; no extrapoles un resultado OAuth de iOS a Android.
- [ ] Los resultados de las pruebas de rendimiento de almacenamiento cumplen el tamaño de biblioteca admitido previsto.
- [ ] Los hallazgos de una revisión independiente de criptografía y seguridad de la aplicación y de las pruebas de penetración se resuelven o son aceptados explícitamente por el responsable de la versión.
- [ ] La verificación de artefactos firmados y un simulacro independiente de copia de seguridad y recuperación se superan.
El flujo de trabajo Validate compila los clientes nativos Android e iOS y ejecuta sus
pruebas de humo. Build signed Android release es un flujo de trabajo manual sobre el
entorno release. Configura ANDROID_KEYSTORE_BASE64, ANDROID_KEY_ALIAS,
ANDROID_KEY_PASSWORD y ANDROID_STORE_PASSWORD como secretos del entorno. El flujo
falla si no hay credenciales, verifica la firma del APK y la cadena de bibliotecas nativas,
y carga el APK junto con su suma de comprobación como artefacto del flujo de trabajo. No publica en
una tienda. Revisa el resultado de Validate del commit de origen antes de ejecutarlo.
Para versiones preliminares de Windows, confirma el código fuente y ejecuta
pwsh -File scripts/package-windows.ps1 desde un equipo Windows x86_64 MSVC.
El script recompila el espacio de trabajo Rust y empaqueta la CLI, la bandeja, el relay, la DLL FFI y la biblioteca de importación,
la cabecera C, los archivos README, seguridad y licencia de la raíz y todos los archivos versionados de docs/,
conservando la estructura de directorios. El archivo comprimido, BUILD-INFO.json (commit de origen
y hashes de cada archivo), memories.example.toml y SHA256SUMS se escriben en dist/vVERSION/.
Verifica el contenido del archivo y los hashes antes de cargar los cuatro archivos en la
GitHub Release correspondiente. Los directorios de salida existentes nunca se sobrescriben.
En macOS, bash scripts/package-macos.sh compila la arquitectura del equipo y crea
una aplicación Memories.app sin firmar, un paquete CLI/relay/FFI, la documentación completa y las licencias de fuentes.
En Linux, bash scripts/build-linux.sh compila el destino GNU nativo x86_64/aarch64;
--debug selecciona una compilación de desarrollo. Desde una copia de trabajo limpia y confirmada,
bash scripts/package-linux.sh crea un .tar.gz con CLI/relay/FFI, la cabecera
C, la documentación versionada y las licencias en dist/vVERSION-linux-ARCH/, junto con
BUILD-INFO.json, memories.example.toml y SHA256SUMS. Verifica los hashes, los permisos de
ejecución Unix y las dependencias de ejecución en la distribución glibc/OpenSSL
prevista. Linux utiliza la WebUI y no tiene un paquete de bandeja nativo.
El flujo de trabajo manual Build desktop packages ejecuta comprobaciones de Linux/Windows/macOS y carga
estos paquetes como artefactos del flujo de trabajo; no publica una GitHub Release.
Antes de distribuir compilaciones de escritorio, verifica el inicio, las acciones del menú y la salida de la bandeja y
la representación de la WebUI en el sistema operativo distribuido, y prueba el rechazo de tokens y Origin, la caducidad
por inactividad pasiva, la eliminación de detalles al bloquearse o perder conexión y los cambios reales de estado del daemon.
La distribución de iOS requiere un equipo Apple, certificado y perfil y configuración de
aprovisionamiento en macOS. Este repositorio no incluye credenciales ni cuentas de desarrollador.
Las compilaciones de distribución con funciones de nube también requieren los ID de cliente de la plataforma y los
esquemas de devolución de llamada registrados de cloud-authorization.md; la compilación genérica de CI
no contiene un registro de cliente OAuth.