docs(issues): 4 issues de deuda detectada lateral en 0121a
Origen: fn-recopilador design-e2e descubrio 6 bugs durante el design
de propuestas e2e_checks. Agrupados en 4 issues:
- 0124 EPIC dag_engine cleanup (registry.db huerfana + Mantine drift
+ --migrate-only flag — 3 sub-tareas)
- 0125 deploy_server: anadir --db a cmdServe
- 0126 pipeline_launcher: aplicar migracion 003_logs
- 0127 docker_tui: go.work path absoluto rompe portabilidad
Todos relacionados con 0121a. Pueden ser candidatos a /autonomous-task
o /autopilot dependiendo del scope.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,57 @@
|
||||
---
|
||||
id: "0124"
|
||||
title: "EPIC: dag_engine cleanup (registry.db huerfana + Mantine drift + --migrate-only)"
|
||||
status: pendiente
|
||||
type: epic
|
||||
domain:
|
||||
- apps-infra
|
||||
scope: app
|
||||
priority: media
|
||||
depends: []
|
||||
blocks: []
|
||||
related:
|
||||
- "0121a"
|
||||
created: 2026-05-19
|
||||
updated: 2026-05-19
|
||||
tags: [dag_engine, cleanup, technical-debt]
|
||||
---
|
||||
|
||||
# 0124 — dag_engine cleanup
|
||||
|
||||
Origen: detectado lateral durante `fn-recopilador design-e2e apps/dag_engine` en issue 0121a.
|
||||
|
||||
## Sub-tareas
|
||||
|
||||
### 0124a — Borrar `registry.db` huerfana en `apps/dag_engine/`
|
||||
|
||||
Archivo `apps/dag_engine/registry.db` (262 KB) viola `db_locations.md` ("registry.db SOLO en raiz"). Ya fue borrado el 2026-05-16 y reaparecio — investigar como se regenera (probable bug en path resolution de un test/CLI subcmd o un launcher).
|
||||
|
||||
Acceptance:
|
||||
- [ ] Borrar `apps/dag_engine/registry.db`.
|
||||
- [ ] Identificar y arreglar el origen (grep el codigo de dag_engine por paths relativos a registry.db sin `FN_REGISTRY_ROOT`).
|
||||
- [ ] Test idempotente: borrar + ejecutar dag_engine + verificar que NO reaparece.
|
||||
|
||||
### 0124b — Arreglar `pnpm build` del frontend (Mantine API drift)
|
||||
|
||||
Errores en `StepTimeline.tsx:49` + `main.tsx:1`. Probable culpa: actualizacion de Mantine v9 que cambio API. Bloquea `dag_engine` frontend embebido (`//go:embed all:frontend/dist`).
|
||||
|
||||
Acceptance:
|
||||
- [ ] `cd apps/dag_engine/frontend && pnpm install --frozen-lockfile && pnpm build` exit 0.
|
||||
- [ ] `dist/` se regenera + es embebible por el backend Go.
|
||||
- [ ] Bumpar version del app via `/version`.
|
||||
|
||||
### 0124c — Añadir flag `--migrate-only` al binario
|
||||
|
||||
Permite gate idempotente de migrations en `e2e_checks` sin usar `list` como proxy. Tambien util para deploys.
|
||||
|
||||
Acceptance:
|
||||
- [ ] `./dag_engine --migrate-only --db /tmp/x.db` aplica migrations + exit 0 + NO arranca server ni jobs.
|
||||
- [ ] Idempotente (segunda invocacion no falla).
|
||||
- [ ] Documentado en `app.md` (`subcommands:` block o equivalente).
|
||||
|
||||
## DoD epic
|
||||
|
||||
- 3 sub-tareas cerradas con sus tests verdes.
|
||||
- `fn doctor` sobre dag_engine devuelve verde.
|
||||
- Bump version (`/version apps/dag_engine minor`).
|
||||
- Propuesta `dag_engine.yaml` del issue 0121a actualizada: promover `build_frontend` de warning a critical + reemplazar proxy `list` por `--migrate-only` en check `migrations_apply`.
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
id: "0125"
|
||||
title: "deploy_server: anadir flag --db a cmdServe"
|
||||
status: pendiente
|
||||
type: bugfix
|
||||
domain:
|
||||
- deploy
|
||||
scope: app
|
||||
priority: media
|
||||
depends: []
|
||||
blocks: []
|
||||
related:
|
||||
- "0121a"
|
||||
created: 2026-05-19
|
||||
updated: 2026-05-19
|
||||
tags: [deploy_server, cli, idempotency]
|
||||
---
|
||||
|
||||
# 0125 — deploy_server `--db` flag
|
||||
|
||||
Origen: detectado lateral por `fn-recopilador design-e2e apps/deploy_server` en 0121a.
|
||||
|
||||
## Problema
|
||||
|
||||
`cmdServe` en `apps/deploy_server/server.go` solo expone `--port`. No hay forma de pasar BD efimera para tests/e2e — el server siempre abre `operations.db` del cwd. Esto rompe idempotencia de `smoke` checks (mezcla datos test con prod).
|
||||
|
||||
## Decision
|
||||
|
||||
Anadir flag `--db PATH` a `cmdServe`. Default = `operations.db` del cwd (compatibilidad). Cuando se pasa, el server abre la BD apuntada.
|
||||
|
||||
## Tareas
|
||||
|
||||
1. Editar `apps/deploy_server/server.go` — parse `--db` en `cmdServe`.
|
||||
2. Pasar el path a la apertura de SQLite.
|
||||
3. Verificar que migraciones aplican igual sobre BD efimera.
|
||||
4. Actualizar propuesta 0121a `deploy_server.yaml` removiendo gotcha del check `smoke`.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- [ ] `./deploy_server serve --port 9190 --db /tmp/x.db` abre BD en `/tmp/x.db` y aplica migraciones idempotente.
|
||||
- [ ] Sin `--db`, comportamiento actual preservado.
|
||||
- [ ] `smoke` check del 0121a pasa con `/tmp/deploy_server_e2e.db`.
|
||||
|
||||
## DoD
|
||||
|
||||
- **Donde**: terminal (`./deploy_server serve --help`).
|
||||
- **Latencia**: cambio no afecta latencia runtime.
|
||||
- **Onboarding**: "Para e2e/tests de deploy_server pasa `--db /tmp/...`."
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
id: "0126"
|
||||
title: "pipeline_launcher: aplicar migracion 003_logs a operations.db"
|
||||
status: pendiente
|
||||
type: bugfix
|
||||
domain:
|
||||
- apps-infra
|
||||
scope: app
|
||||
priority: baja
|
||||
depends: []
|
||||
blocks: []
|
||||
related:
|
||||
- "0121a"
|
||||
created: 2026-05-19
|
||||
updated: 2026-05-19
|
||||
tags: [pipeline_launcher, migrations, db]
|
||||
---
|
||||
|
||||
# 0126 — pipeline_launcher migracion 003_logs
|
||||
|
||||
Origen: detectado lateral por `fn-recopilador design-e2e apps/pipeline_launcher` en 0121a.
|
||||
|
||||
## Problema
|
||||
|
||||
`apps/pipeline_launcher/operations.db` tiene migraciones 001+002 aplicadas pero falta 003_logs (definida en `fn_operations/migrations/003_logs.sql`). La tabla `logs` no existe → cualquier feature futuro de logging in-app falla silencioso.
|
||||
|
||||
Investigacion necesaria: por que no aplico? Probable que pipeline_launcher use version vieja del codigo `fn_operations` o tenga su propio applier que no lee la migracion 003.
|
||||
|
||||
## Decision
|
||||
|
||||
1. Diagnosticar por que 003 no aplico (busca `applyMigrations` en codigo de pipeline_launcher o si usa la libreria `fn_operations`).
|
||||
2. Aplicar 003 a la BD existente preservando datos.
|
||||
3. Si pipeline_launcher tiene applier custom, hacerlo consumir las migraciones del registry padre via `embed.FS`.
|
||||
|
||||
## Tareas
|
||||
|
||||
1. Inspeccionar `apps/pipeline_launcher/{main.go, db.go, store.go}` para localizar applier.
|
||||
2. Aplicar `003_logs.sql` manualmente: `sqlite3 apps/pipeline_launcher/operations.db < fn_operations/migrations/003_logs.sql`.
|
||||
3. Si custom applier: refactor para consumir migraciones del padre.
|
||||
4. Verificar con `PRAGMA table_info(logs);` que la tabla existe.
|
||||
5. Actualizar propuesta 0121a `pipeline_launcher.yaml` removiendo check `ops_schema_complete` (ya no aplica).
|
||||
|
||||
## Acceptance
|
||||
|
||||
- [ ] `sqlite3 apps/pipeline_launcher/operations.db "PRAGMA table_info(logs);"` devuelve columnas esperadas.
|
||||
- [ ] Reaplicar 003 sobre BD ya migrada NO falla (idempotente — `CREATE TABLE IF NOT EXISTS`).
|
||||
- [ ] Tests de pipeline_launcher pasan (si existen).
|
||||
|
||||
## DoD
|
||||
|
||||
- **Donde**: sqlite3 introspeccion + log de la app si tiene.
|
||||
- **Latencia**: invisible al usuario.
|
||||
- **Onboarding**: "Si una app tiene operations.db, las migraciones del registry padre se aplican al arrancar — verificar con `PRAGMA table_info`."
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
id: "0127"
|
||||
title: "docker_tui: go.work con path absoluto rompe portabilidad"
|
||||
status: pendiente
|
||||
type: bugfix
|
||||
domain:
|
||||
- apps-infra
|
||||
- dev-ux
|
||||
scope: app
|
||||
priority: media
|
||||
depends: []
|
||||
blocks: []
|
||||
related:
|
||||
- "0121a"
|
||||
created: 2026-05-19
|
||||
updated: 2026-05-19
|
||||
tags: [docker_tui, go.work, portability, devfactory]
|
||||
---
|
||||
|
||||
# 0127 — docker_tui go.work path absoluto
|
||||
|
||||
Origen: detectado lateral por `fn-recopilador design-e2e apps/docker_tui` en 0121a.
|
||||
|
||||
## Problema
|
||||
|
||||
`apps/docker_tui/go.work` declara:
|
||||
|
||||
```
|
||||
replace github.com/lucasdataproyects/devfactory => /home/lucas/.local_agentes/backend
|
||||
```
|
||||
|
||||
Path absoluto especifico de la maquina del autor. En otra maquina (PC secundario, CI, otro user) → `go build` falla con "directory does not exist". Hace la app no portable y bloquea cualquier `e2e_check` automatizado fuera del PC original.
|
||||
|
||||
## Decision
|
||||
|
||||
Opciones (decidir al implementar):
|
||||
|
||||
1. **Publicar `devfactory` en Gitea** (`dataforge/devfactory` o repo privado) y eliminar el replace. Mas trabajo pero solucion definitiva.
|
||||
2. **GOFLAGS condicional**: documentar que el replace solo activa si la env var `DEVFACTORY_LOCAL_PATH` esta seteada (custom shell wrapper que genera `go.work` on-demand). Pragmatic pero fragil.
|
||||
3. **Vendoring**: `go mod vendor` y commitear `vendor/`. Aumenta tamano del repo.
|
||||
4. **Replace por path relativo** si devfactory vive como sub-repo del registry (no es el caso hoy).
|
||||
|
||||
Recomendado: opcion 1 (publicar) si devfactory es estable; opcion 2 si esta en desarrollo activo y queda local.
|
||||
|
||||
## Tareas
|
||||
|
||||
1. Decidir opcion (consultar a humano).
|
||||
2. Si opcion 1: crear repo `dataforge/devfactory`, publicar codigo, actualizar `go.work` con import path Gitea + cleanup del replace.
|
||||
3. Si opcion 2: implementar wrapper + documentar en `app.md`.
|
||||
4. Verificar build en PC distinto al original.
|
||||
5. Actualizar propuesta 0121a `docker_tui.yaml` promoviendo check `build` de warning a critical.
|
||||
|
||||
## Acceptance
|
||||
|
||||
- [ ] `cd apps/docker_tui && go build` exit 0 en cualquier maquina sin paths absolutos custom.
|
||||
- [ ] `e2e_checks` del 0121a actualizado.
|
||||
- [ ] Documentado en `app.md` (build prerequisites).
|
||||
|
||||
## DoD
|
||||
|
||||
- **Donde**: build limpio en PC secundario (aurgi-pc, home-wsl, otro).
|
||||
- **Latencia**: pnpm/go install al primer build.
|
||||
- **Onboarding**: "Para clonar y compilar docker_tui en PC nuevo, basta `go build`. Si necesitas devfactory local, ver `app.md`."
|
||||
Reference in New Issue
Block a user