- Split the single flat package into cli/changes/checkin/history/update/ settings/actions/roots by responsibility, mirroring how larger VCS integrations (e.g. git4idea) are organized. - Translate all comments and user-facing strings to English; trim narrative/session-referential comments down to concise explanations of non-obvious behavior only. - Add a Gradle Wrapper for CI use; build.gradle.kts now falls back to downloading a matching IntelliJ IDEA build when no local ideLocalPath is configured (moved out of the versioned gradle.properties into ~/.gradle/gradle.properties, since it is machine-specific). - Add LICENSE (GPLv3), a plugin icon (light/dark), a fuller <description> and <vendor> with contact info, and rename the plugin from 'Game of Trees (got) VCS' to 'Got' per Marketplace naming guidelines. - Rewrite README.md in English: what the plugin does, how each feature maps to a got command, building, contributing, and releasing. - Add .github/workflows/release.yml: on any v* tag, build, verify, create a GitHub Release with the plugin ZIP, and publish to JetBrains Marketplace once a PUBLISH_TOKEN secret is configured.

Se evaluó implementar el diálogo nativo de Push (Ctrl+Shift+K) vía PushSupport, pero requiere Repository/RepositoryManager completos (GotRepository, GotPushSource/Target/Pusher/OutgoingCommitsProvider, etc.) -- tamaño comparable a todo el resto del plugin junto, con APIs sin documentar que habría que descubrir a los tumbos. Se optó por un AnAction simple: 'got send' (sin argumentos, usa 'origin' y la rama actual por defecto) corrido en background sobre las raíces got del proyecto, con el resultado reportado vía notificación. Cubre el caso de uso real sin esa complejidad. Registrado en el grupo Vcs.Operations.Popup, junto a las demás acciones de VCS.

<description> era obligatorio para gradle verifyPlugin (fallaba con 'Invalid plugin descriptor'). Además, GotVcsRootChecker.isRoot(String) está marcado 'scheduled for removal' en la plataforma 261/262 (confirmado con el Plugin Verifier real, no solo un warning de compilación) -- se sobreescribe isRoot(VirtualFile) en su lugar, la sobrecarga moderna.

GotSettingsState (PersistentStateComponent, gotvcs.xml) persiste dos rutas: binario got y SSH_AUTH_SOCK. GotConfigurable expone un panel con un file chooser para el binario y un campo de texto para el socket, registrado como applicationConfigurable bajo el grupo 'vcs'. GotCommandLineWrapper.binaryPath()/sshAuthSock() ahora consultan estos settings primero; si están vacíos (default), caen a la misma detección automática de antes (/run/current-system/sw/bin/got o PATH; System.getenv o el socket fijo de gpg-agent). Esto reemplaza los hardcodes de ruta que quedaron marcados como deuda desde la Fase 1, y da una forma real de resolver a mano el problema de SSH_AUTH_SOCK=null encontrado hoy si vuelve a pasar en otra sesión de IntelliJ.

Confirmado con 'got log flake.lock' en terminal: got devuelve cada commit una sola vez, así que la duplicación era enteramente nuestra. El fix anterior seguía duplicando porque llamaba TANTO session.appendRevision(revision) COMO partner.acceptRevision(revision) para la misma revisión -- partner.acceptRevision() ya actualiza esa misma sesión (la que se le pasó a reportCreatedEmptySession) por su cuenta, así que ambas llamadas terminaban agregando la revisión dos veces a la misma lista. Se quita el appendRevision manual; solo partner.acceptRevision() por entrada.

Reportado en vivo: cada commit aparecía duplicado en el panel de Show History. Causa: 'Show History' usa reportAppendableHistory(), no createSessionFor() -- pero reportAppendableHistory() llamaba a createSessionFor() para obtener una sesión YA POBLADA con todos los commits, se la pasaba a reportCreatedEmptySession() (que espera una sesión realmente vacía) y encima recorría cada revisión llamando acceptRevision() de nuevo: cada commit terminaba contado dos veces. Fix: reportAppendableHistory() ahora resuelve raíz/ruta con un helper compartido (resolveRootAndPath, antes duplicado con createSessionFor), construye la sesión con una lista vacía, y agrega cada revisión una sola vez vía session.appendRevision() + partner.acceptRevision(). Esto también explica por qué el 'Unknown error' de README.md nunca había quedado logueado: el logging que se agregó antes vivía en createSessionFor(), un método que este camino real (reportAppendableHistory) ni siquiera invocaba. Ahora tiene su propio logging con stack trace completo para diagnosticar si el fallo persiste.

Reportado en vivo tras arreglar el SSH: Update Project mostraba un archivo creado falso '/nixdots/eady up-to-date'. got update imprime texto libre ('Already up-to-date') cuando no hay nada que traer, sin el patrón 'código + 2 espacios + path' de las líneas de estado reales. El filtro anterior solo descartaba líneas que empezaran con espacio, y 'Already...' empieza con 'A' -- que además coincide con un código de estado válido -- así que se parseaba como code='A', path='eady up-to-date' (substring(3) de 'Already up-to-date'). Fix: exigir que las posiciones 1 y 2 sean espacios antes de tratar la línea como una entrada de estado. También se quita el -v de got fetch (era solo diagnóstico temporal, ya no aportaba nada una vez identificado el problema real de SSH_AUTH_SOCK).

Confirmado en vivo con el diagnóstico anterior: [SSH_AUTH_SOCK=null] en el mensaje de error. No era un problema de GeneralCommandLine ni de su snapshot de entorno -- System.getenv("SSH_AUTH_SOCK") es null en el proceso de IntelliJ mismo esa sesión (depende de cómo Hyprland lo haya lanzado). Ningún override dentro del plugin puede inventar un valor que no existe en el proceso. Fix: sshAuthSock() cae a la ruta fija del socket ssh de gpg-agent (/run/user/1000/gnupg/S.gpg-agent.ssh, uid 1000, único usuario de esta máquina) cuando System.getenv() no lo tiene, verificando que el archivo exista antes de usarlo. Mismo patrón que ya se usa para la ruta del binario got -- deuda pendiente de hacer configurable en la Fase 6.

'got fetch -v' no aportó líneas de debug adicionales de ssh (confirmado reproduciendo el mismo -v sin SSH_AUTH_SOCK desde una shell normal: sale idéntico, sin más detalle) -- ese camino de diagnóstico no sirve para este fallo en particular. Se refuerza el fix anterior: en vez de solo sobreescribir SSH_AUTH_SOCK sobre el snapshot de entorno CONSOLE (cacheado por la plataforma), se fuerza ParentEnvironmentType.SYSTEM para que GeneralCommandLine use System.getenv() completo como base -- el mismo entorno que ya se confirmó correcto vía /proc/<pid>/environ del proceso de IntelliJ. Además, el mensaje de VcsException ahora incluye el valor real de SSH_AUTH_SOCK visto por la JVM en el momento del fallo, para confirmar en vivo sin más rondas de adivinar si el valor que llega al subproceso es el correcto.

El fix anterior (forzar SSH_AUTH_SOCK) no resolvió 'Permission denied (publickey)' desde el plugin; peor aún, el usuario reporta que la YubiKey ni siquiera se activa (a diferencia de antes del fix, cuando sí reproducía el mismo error). Se agrega -v a got fetch, que got reenvía a ssh(1), para capturar en el mensaje de error qué identidades intenta ssh y si realmente consulta el agente. Sin esto no hay forma de saber por qué el subproceso no llega ni a pedir la firma a la llave.

Reportado en vivo: 'Update Project' fallaba con 'Permission denied (publickey)' contra el remoto por SSH, pese a que el gpg-agent (soporte ssh, clave de YubiKey) funciona perfecto desde una shell normal. Confirmado: el proceso de IntelliJ SÍ tiene el SSH_AUTH_SOCK correcto (verificado leyendo /proc/<pid>/environ), pero GeneralCommandLine usa por defecto un snapshot de entorno cacheado por la plataforma (EnvironmentUtil), no el entorno real del proceso -- ese snapshot no coincidía. Fix: se copia explícitamente SSH_AUTH_SOCK desde System.getenv() al entorno del subproceso antes de cada invocación. También: 'Show History' reportó 'Unknown error' sin rastro en el log de IntelliJ (ninguna excepción nuestra debería dar mensaje null). GotVcsHistoryProvider.createSessionFor() ahora loggea el stack trace completo de cualquier excepción no-VcsException y la envuelve con un mensaje no nulo, para poder diagnosticar la próxima vez que ocurra en vivo -- no se pudo reproducir el fallo original con 'got log' desde terminal (salió limpio), así que sigue pendiente de reproducir.

GotVcsHistoryProvider + GotVcsHistorySession + GotFileRevision exponen 'got log' en el diálogo nativo de 'Show History': parsea el formato verbose por defecto (bloques separados por líneas de guiones, 'commit <hash>', 'from:', 'date:', mensaje indentado) y usa 'got cat -c <hash> -P <path>' para cargar el contenido de cada revisión bajo demanda. GotUpdateEnvironment implementa 'Update Project': por cada raíz seleccionada corre 'got fetch' (best-effort, got.conf puede no tener remoto) seguido de 'got update', parseando sus códigos de estado (U/G/C/D/A/!/#) a los FileGroup estándar de IntelliJ. GotCommandLineWrapper gana log/fetch/update/catAt (cat contra un commit arbitrario, no solo :base).

CheckinEnvironment.commit() tiene 3 sobrecargas con implementación default que se encadenan: la de 2 argumentos delega en la de CommitContext, que delega en la de NullableFunction, que devuelve null (no-op). Confirmado con javap -c sobre la interfaz real de la plataforma (261): la plataforma invoca directamente la sobrecarga con CommitContext al hacer 'Commit' desde la UI, no la de 2 argumentos. Como solo se había sobreescrito la de 2 argumentos, el pipeline de commit de IntelliJ terminaba llamando al no-op por defecto: reportaba 'checkinSuccessful' (sin excepciones) sin que 'got commit' se ejecutara nunca. Reportado en vivo por el usuario: el diff se veía bien, no había errores, pero got log no mostraba ningún commit nuevo. Fix: se sobreescribe también la sobrecarga con CommitContext, y ambas delegan a la misma lógica (doCommit).

GotContentRevision.getRevisionNumber() ejecutaba 'got info' de forma síncrona; el renderer del árbol de Commit y el título del diff nativo la invocan directamente desde el hilo de UI (EDT), que IntelliJ prohíbe para I/O bloqueante (OSProcessHandler#checkEdtAndReadAction). Reportado en vivo: no rompía el commit en sí (confirmado con 'got log' en /nixdots), pero inundaba el log del IDE con excepciones en cada repintado del panel de Commit. Fix: revisionNumber ahora se resuelve una sola vez fuera del EDT, por quien construye la instancia -- GotChangeProvider lo resuelve una vez por raíz (no por archivo) dentro de getChanges(), y GotDiffProvider.createFileContent() reusa el revisionNumber que ya recibe como parámetro. getRevisionNumber() pasa a ser una simple lectura de campo, sin I/O.

GotCheckinEnvironment.commit() no usa 'got stage': commitea exactamente los paths seleccionados en el panel de Commit vía 'got commit -m msg <paths>', agrupados por raíz got. También implementa scheduleUnversionedFilesForAddition ('got add') y scheduleMissingFileForDeletion ('got remove -f') para los flujos de añadir/eliminar desde la UI. GotRollbackEnvironment.rollbackChanges()/rollbackMissingFileDeletion() ejecutan 'got revert -R' sobre los paths afectados; got revert ya restaura tanto modificaciones como archivos borrados o añadidos localmente, así que ambos casos comparten la misma implementación. GotCommandLineWrapper gana commit/add/remove/revert.

GotRevisionNumber envuelve el hash del commit base ('got info'). Nuevo GotDiffProvider resuelve la raíz VCS y ruta relativa de un archivo vía ProjectLevelVcsManager, y usa GotContentRevision (got cat -c :base) como contenido de referencia para el line-status-tracker y las acciones de diff nativas. GotContentRevision ahora reporta el hash real en vez de VcsRevisionNumber.NULL. Por ahora solo compara contra el commit base del work tree; comparar contra revisiones históricas queda para la Fase 5 (historial).

- nixpkgs.gradle (8.14.4) no alcanza el mínimo de Gradle 9.0.0 que exige el plugin org.jetbrains.intellij.platform 2.18.1; el devShell ahora usa gradle_9 (9.5.1). - com.intellij.modules.vcs es un módulo bundleado, no un plugin: bundledPlugin(...) -> bundledModule(...). - processUnversionedFile espera FilePath, no VirtualFile; LocallyDeletedChange tiene un solo argumento (FilePath). Ignora .intellijPlatform/ (caché del Gradle plugin, análogo a .gradle/). 'nix develop -c gradle buildPlugin' genera build/distributions/gotvcs-intellij-0.1.0.zip.

GotCommandLineWrapper centraliza la ejecución de got (GeneralCommandLine + ExecUtil) y parsea 'got status' (formato XY path). GotChangeProvider mapea los códigos de estado a FileStatus y reporta al ChangelistBuilder. GotContentRevision expone el contenido base ('got cat -c :base -P') como beforeRevision, para que el preview de diff del panel de Commit funcione.

Detecta carpetas .got/ como raíces de VCS y expone el nombre 'got' en Settings > Version Control. Sin funcionalidad de status/diff/commit todavía.