Tus obras en Ctrl+

Beta 0.1.0-beta.1: disponible para macOS con Apple Silicon. Linux y Windows llegan en una próxima versión.

Instala el asistente con npm i -g @ctrlmas/ctrl (Node ≥20) y ejecuta ctrl. También viene integrado con Ctrl+, donde utiliza Electron y no requiere instalar Node.

1. Ejecuta ctrl desde una terminal.
2. Inicia sesión o regístrate desde el navegador.
3. Selecciona, crea o únete a una organización.
4. Completa el perfil empresarial si eres administrador y todavía falta.
5. Usa Crear nueva, Traer todas, Invitar usuarios, Abrir Ctrl+ o Salir.
6. Al crear una obra, elige la configuración recomendada o personaliza sus módulos.

El asistente guarda las carpetas en Documentos → Ctrl → tu empresa → tu obra y permite abrir una ventana nueva de Ctrl+ desde el menú. Usa los mismos identificadores que tus compañeros. Las carpetas internas y los diarios permiten recuperar una operación interrumpida.

Si tu empresa todavía no tiene un perfil, un administrador completa nombre, RUC opcional, país, moneda y zona horaria antes del menú. Paraguay, guaraníes y Asunción son valores iniciales editables. La personalización de módulos está disponible al crear sin exigir --advanced. Un perfil existente se reutiliza sin preguntas.

Si todavía no perteneces a una empresa, el asistente abre el portal de cuentas. Crea una organización o acepta una invitación y vuelve a la terminal. create-ctrl --manage-org abre la administración de tu organización.

Para descargar todas las obras de tu empresa, ejecuta pull-ctrl o create-ctrl --pull. Al terminar, confirma Instalar y abrir Ctrl+ (o Abrir Ctrl+ si ya está instalado) para abrir una sola ventana con las carpetas de tus obras. Si eliges no abrir, las carpetas quedan listas y puedes usar Abrir Ctrl+ desde el menú. No transfiere el contenido local de archivos compartidos ni mantiene una sincronización continua.

Puedes cancelar con Ctrl+C. Una carpeta ocupada se conserva. Los nombres iguales reciben (2), (3), etc. Una descarga repetida reutiliza una copia completa de la misma versión; una versión distinta se detiene y conserva tus archivos. El índice Documentos/Ctrl/.ctrl/locations.json conserva la ubicación aunque cambien los nombres en el servidor.

Automatización e integración interna

Las opciones anteriores siguen disponibles: [directorio], --name, --obra-name, --obra-code, --org, --workspace, --modules, --api-url, --auth-cli, --yes y --json. Un directorio explícito conserva el control del destino. Sin directorio, el asistente de escritorio utiliza la carpeta Documentos del sistema; si no existe, utiliza Documents dentro de la carpeta personal. --yes, --json y entrada no interactiva no inician sesión ni abren el navegador, editor o instalador. --json tampoco pregunta. Devuelve un único documento sin credenciales. --pull --json devuelve {ok,mode:"pull",results:[{workspaceId,target,status,error?}]}; cualquier fallo produce salida uno.

La aplicación proporciona CTRL_CREATE_NODE, CTRL_CREATE_EDITOR_CLI y CTRL_AUTH_CLI como rutas absolutas de su runtime Electron, app/out/cli.js y helper nativo. El CLI consulta obra-paths --json para obtener Documentos y la carpeta personal. El editor se abre mediante argumentos separados, sin shell, con ELECTRON_RUN_AS_NODE=1. CTRL_CREATE_DOCUMENTS permite usar una carpeta de prueba en el bundle interno.

Las solicitudes HTTP 429 esperan entre uno y 60 segundos y reintentan una sola vez en una sesión interactiva. Ctrl+C cancela la espera. La automatización recibe el error inmediatamente.

Desarrollo: npm run check-types, npm test, npm run build. El paquete público @ctrlmas/ctrl también se distribuye con la aplicación; su publicación estable exige verificar las tres plataformas. Las pruebas locales no verifican instaladores nativos de macOS, Windows o Linux.

Distribución npm y escritorio

Instalación global: npm i -g @ctrlmas/ctrl (Node ≥20). Los aliases son ctrl, ctrl-l, create-ctrl y pull-ctrl; este último antepone --pull. Las dependencias opcionales de versión exacta contienen ctrl-tui y ctrl-auth para macOS, Linux y Windows, en ARM64 y x64. --help y --version no requieren binarios nativos. Linux inicial: Ubuntu 24.04 de escritorio con keyring.

Los scripts prepare-native.mjs, prepare-desktop-archive.mjs y prepare-desktop-manifest.mjs preparan paquetes y registran SHA-256 de archivos reales. El archivo de escritorio usa solo archivos y directorios; el preparador resuelve los symlinks internos de Electron antes de comprimir. El manifiesto permanece vacío hasta que existan artefactos reales verificados.

Instalaciones por usuario: ~/Applications/CtrlPlus, ~/.local/share/ctrl-plus, %LOCALAPPDATA%\Programs\CtrlPlus. Descarga HTTPS, verificación SHA-256, staging y publicación atómica conservan los proyectos ante fallos. Las instalaciones ajenas o incompletas requieren intervención manual; nunca se sobrescriben. Una app sin firma puede requerir que el usuario autorice su apertura desde la seguridad del sistema. La identidad mínima de Ctrl+ (carpeta .ctrl-plus, mutex ctrlplus, protocolo ctrl-plus, bundle tech.ctrlmas.ctrl) no colisiona con Code OSS. Las instalaciones existentes bajo .vscode-oss no se migran solas: conservalas o borralas a mano antes de reinstalar.

Publicar exactamente los archivos verificados, sin reconstruir: primero los assets de Ssrrb/ctrl-releases, después los seis paquetes nativos y finalmente @ctrlmas/ctrl, con npm publish <tarball> --access public. No usar --provenance en publicación local. Detener ante fallo parcial. Antes de cada publicación verificar acceso al scope, repositorio y login, invitación aceptada, réplica idempotente y apertura real en los seis destinos.

freeze-release.mjs exige evidencia de un commit limpio, versiones y hashes previamente registrados, checks por plataforma, contenido de tarballs nativos y manifiesto incluido en el tarball principal. Congela exactamente esos bytes; no reemplaza las pruebas reales ni genera evidencia por sí mismo.

La aceptación visual de la TUI precede al release. El plan de publicación separado vive en wiki/docs/execution/ctrl-npm-release.mdx dentro del workspace de desarrollo. En macOS, node scripts/setup-codesign.mjs prepara una identidad persistente una sola vez. El empaquetado firma el helper y la TUI con ella. Esta firma conserva la identidad del llavero entre builds; Developer ID y notarización siguen pendientes.

Puerta de empaquetado win32-x64

scripts/win32-packaging-gate.mjs arma la imagen ctrl-win32-x64-gate y la ejecuta en un host Docker (--host ssh://desktop). Empaqueta @ctrlmas/ctrl y @ctrlmas/ctrl-win32-x64 y verifica los bytes exactos que se publicarían:

• npm rechaza el paquete nativo en Linux, así que os y cpu son correctos;
• con --force, el payload queda en vendor/x86_64-pc-windows-msvc/bin/;
• ctrl-tui.exe y ctrl-auth.exe son imágenes PE32+ x86_64 reales;
• los cuatro aliases se publican y responden --version sin binarios nativos;
• el tarball principal incluye solo los seis archivos previstos.

node scripts/prepare-native.mjs win32-x64 <ctrl-tui.exe> <ctrl-auth.exe>
node scripts/win32-packaging-gate.mjs --host ssh://desktop

Si el host tiene Docker pero no Node.js (el desktop Linux), docker/win32-x64/run.sh hace el mismo trabajo sin node ni npm locales: empaqueta los tarballs dentro de la imagen node, arma el contexto y construye y ejecuta la puerta.

cd create-ctrl
docker/win32-x64/run.sh --self-test
docker/win32-x64/run.sh --native /ruta/al/win32-x64

Un contenedor Linux comparte el kernel del host, así que no puede ejecutar binarios de Windows: la TUI y el helper nunca corren ahí. Probar la instalación real en Windows sigue exigiendo una máquina Windows. --self-test usa un payload PE sintético para ejercitar la propia puerta mientras esa compilación no exista.