Repository navigation
Hotfix abyssan2.0.5 - #96
Merged
Merged
Conversation
La tabla Capacidades y el listado de operaciones afirmaban que hoy existe stage por archivo + hunk + línea. En realidad el adaptador DDD solo expone stageFile / stageAll / unstageFile; los únicos hunks del backend son para parseo de conflictos 3-way. La fila Fase 2 del roadmap también se marcó como Parcial porque hereda la misma deuda. - README Capacidades: «Archivo + hunk + línea» → «Archivo completo + stage-all», con hunk/línea como pendiente de 4.x en la columna Identidad. - README operaciones: aclarar que «hunks» solo cubre el parseo de conflictos y declarar explícitamente que stage por hunk/línea no está en API ni UI. - README roadmap: Fase 2 pasa a «Parcial — hunk/línea pendiente».
Antes el h2 de ModalEncabezado usaba `truncate`, así que «Fusionar feature/pagos» se recortaba a «Fusionar featu…» en el ancho útil de 290 px (dialog md con icono + botón X). Ahora envuelve a dos líneas con `wrap-anywhere line-clamp-2` y conserva el tooltip `title=` como accesibilidad adicional. Además, cada confirmación con preview (merge, reset, cherry-pick, revert) ahora puede inyectar un subtítulo contextual que indica dirección o alcance: - merge: feature/pagos → main - reset: main → abc1234 (hard) - cherry-pick: aplicar abc1234 sobre main - revert: revertir abc1234 en main La lógica está extraída a `subtituloConfirmacion.ts` como funciones puras, con tests Vitest que cubren casos nominales, iguales y fallbacks por entradas vacías. ModalConfirmacion mantiene el subtítulo genérico de fallback cuando no se pasa uno específico. Rebase aún no pasa por preview; cuando se añada quedará trivial sumar un helper análogo.
… fuera de scroll En el modal de reset hard, el bloque Cambios puede ocupar varias líneas (commits y archivos del alcance). Con el orden anterior Explicación → Cambios → Riesgos, los riesgos quedaban debajo del scroll y el usuario veía primero el campo «Escribe «RESET» para confirmar» sin haber visto que la operación descarta cambios locales. Ahora el orden es Explicación → Riesgos → Cambios, con el campo de confirmación siempre al final (sin cambios en ModalConfirmacion). El orden se declara en `ordenSeccionesPreview.ts` como constante `ORDEN_SECCIONES_PREVIEW` consumida por el componente al renderizar, para que un reordenado accidental en la UI falle los tests. Se suma un icono `Info` al bloque Explicación para equilibrar visualmente con los otros dos encabezados (que ya tenían icono). Vitest cubre: Explicación primero, Riesgos antes de Cambios, cardinalidad (exactamente tres secciones) y helper `posicionSeccion`.
`packageManager: pnpm@11.25.0` exige Node 22.13+. El repo ya corre Node 22 en CI (`actions/setup-node` con `node-version: 22`) y en las imágenes (`node:22-alpine`), pero `engines.node` ponía `">=20"` y el README anunciaba «Node 20 LTS o superior». Con Node 20 limpio, Corepack falla al activar pnpm 11. Cambios: - `package.json`: `engines.node: ">=22.13.0"` y nuevo `engines.pnpm: ">=11.25.0"` para que `pnpm install` falle temprano con mensaje claro si alguien prueba con un Node viejo. - `README.md`: tabla Requisitos ahora dice Node 22.13+ y pnpm 11.25.0 vía Corepack, con una nota que explica por qué están acoplados. - `docs/wiki/Instalacion-y-configuracion.md`: la columna Evidencia ya no afirma que CI usa Node 20 (es 22) ni que falta el campo `engines`; menciona explícitamente la dependencia pnpm 11 ↔ Node 22.13. - `docs/wiki/Home.md`: añade una fila Runtime con el `engines.node` real y aclara que `packageManager` y Corepack son la fuente de verdad. No se tocan Dockerfiles ni CI porque ya ejecutaban Node 22 y pnpm 11.25.0. Queda documentado que la restricción fuerte es Node ≥ 22.13.
La tabla usaba dos columnas Hoy/Identidad que mezclaban cosas ya
verificables en main con cosas por hacer. Ahora cada capacidad vive en
su propia fila con un estado explícito, basado en el código real:
Hecho → presente en API y UI, con tests cuando aplica.
Parcial → parte del flujo cableado, parte pendiente (p. ej. highlight
del grafo en modo aprendizaje, rebase).
Pendiente→ no existe en API ni UI (blame, worktrees, stage hunk/línea,
rebase interactivo, preview rebase/force-push).
Se reclasifican como Hecho capacidades que estaban en main desde
septiembre y la tabla tenía como pendientes:
- Preview no mutante de merge (clon temporal) con conflictos.
- `merge-base` + comparar A…B vía `BranchCompareModal`.
- HEAD con ahead/behind en el grafo (`semantica-grafo.ts`).
- Journal persistente con recuperación de reset vía `refs/abyssan/recovery/`.
- `OperationManager` async para push/pull/fetch con progreso vía WS.
- Rate limit, token de instancia, auditoría JSONL.
El listado «Operaciones Git disponibles en API hoy» también se limpió:
quita blame y rebase interactivo (no están), incluye amend,
rename-branch, delete-branch y los cuatro endpoints de preview.
Se matiza Fase 2 (hunk/línea, blame, tabs y rebase visual siguen
pendientes) y Fase 4 (preview, journal, explain y seguridad en código;
highlight de grafo parcial).
scripts/crear-repo-demo.mjs genera bajo `PROJECTS_ROOT` un repositorio de ejemplo listo para QA, capturas y onboarding de 1 minuto. Zero deps: usa git del PATH vía `execFileSync` (sin shell), nunca `exec`. Contenido del repo generado: - 20 commits en `main` con fechas escalonadas (`GIT_AUTHOR_DATE`/ `GIT_COMMITTER_DATE`) para que el grafo sea legible en capturas. - Rama `feature/pagos` fusionada en `main` con `--no-ff` (merge-commit real, no fast-forward). - Rama `fix/choca-con-main` que modifica `src/core/tenant.js` de otra manera que el commit 20 → preview de merge detecta conflicto. - Dos tags anotados: `v0.1.0` sobre el merge-commit y `v0.2.0` sobre `HEAD` de `main`. - Al terminar: `CHANGELOG.md` staged y `README.md` modificado sin stage, para que el panel de Staging muestre ambas secciones. Seguridad: - Exige `PROJECTS_ROOT` definido y existente; falla si no. - Rechaza nombres con `/`, `\` o `..` para no escapar de la raíz. - Valida con `resolve()` que el destino quede dentro de `realpath(PROJECTS_ROOT)` antes de crear nada. - `--force` es la única forma de sobreescribir un repo existente. Integración: - `package.json` expone `pnpm demo:repo`. - README documenta el comando y lo que genera en «Repo de demostración» dentro de Inicio rápido.
El modal de preview estaba limitado a `max-h-64` (256 px) y perdía la visibilidad conjunta de Explicación + Riesgos cuando el merge tocaba muchos archivos. Dos ajustes: 1. Altura adaptable: `max-h-[min(60vh,28rem)]`. En pantallas de 800 px de alto se usan hasta 480 px (recortado por el tope de 448 px); en pantallas más bajas se mantiene proporcional. Antes se perdían 50 % del alto útil disponible. 2. Cambios colapsable: Cuando `archivosAfectados.length > UMBRAL_COLAPSAR_CAMBIOS` (= 5), la sección Cambios arranca contraída con un botón `aria-expanded` + `aria-controls` que lista cuántos elementos quedarían al desplegar («Mostrar 8 archivos · 3 commits»). Explicación y Riesgos quedan visibles sin scroll. El usuario expande con un gesto explícito. La lógica de ¿colapsar? y la etiqueta del botón viven en el helper puro `colapsarCambios.ts`, con tests Vitest que cubren umbral, plural/singular y casos vacíos.
El README mostraba un único `layout.svg` marcado explícitamente como «esquema de producto (no es una captura)». Ahora: 1. assets/capturas/*.svg Dos placeholders estilizados con el tema oscuro: `grafo.svg` y `preview-merge.svg`. Siguen siendo pre-capturas, pero el README los referencia como ilustraciones del repo demo, no como esquema inventado. El esquema SVG original queda en `<details>` como referencia visual. 2. apps/web/scripts/capturar-pantallas.mjs Script Playwright que, con `pnpm dev` y el repo demo creados, abre Chromium headless a 1280×800, selecciona el repo, captura el grafo y después abre el preview no mutante de merge `fix/choca-con-main → main` (que fuerza conflicto reproducible). Al terminar cancela el modal: ninguna mutación sobre el repo. Expone variables de entorno para apuntar a otro repo, rama u origen. 3. apps/web/package.json `playwright: ^1.56.0` como devDependency y script `pnpm --filter @abyssan/web capturas`. `.npmrc` tiene `ignore-scripts=true`, así que el binario Chromium se instala con `pnpm --filter @abyssan/web exec playwright install chromium` (una sola vez). 4. README «Capturas reales» Documenta el flujo completo (demo:repo → dev → playwright install → capturas) y el swap `.svg → .png` cuando se generen las capturas reales. Tabla de variables de entorno del script. Lockfile regenerado por `pnpm install` para incluir Playwright.
…nd error handling Introduces a new test suite for cicloOperacionAuditoria, covering various scenarios including: - Asynchronous fetch operations with controlled fetch adapter. - Immediate rejection handling for invalid remote URLs. - Operation state management and journal entry verification. - Ensures proper WebSocket event emissions during operation cycles. Additionally, refactors the App component to improve state management and introduces a new utility for constructing graph intelligence, enhancing the overall application structure.
Trivy image (PR #96) falla HIGH en undici@6.28.0 embebido en pnpm 11.25.0 bajo COREPACK_HOME. Eso no está en el lockfile de Abyssan ni en el proceso que sirve la API (`node dist/index.js`). Mismo criterio que IMG-NPM-01: omitir la herramienta de toolchain para que el scan siga bloqueando el árbol de la aplicación y Alpine.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.