fad4006f60
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
117 lines
5.1 KiB
Markdown
117 lines
5.1 KiB
Markdown
---
|
|
id: "0101"
|
|
title: "dev_console Go binario: /issue /flow /work unificados"
|
|
status: pendiente
|
|
type: app
|
|
domain:
|
|
- meta
|
|
scope: registry-only
|
|
priority: alta
|
|
depends: []
|
|
blocks: []
|
|
related: []
|
|
created: 2026-05-17
|
|
updated: 2026-05-17
|
|
tags: []
|
|
---
|
|
# 0101 — dev_console Go binario: /issue /flow /work unificados
|
|
|
|
**Status:** pendiente
|
|
**Created:** 2026-05-16
|
|
**Type:** app
|
|
**Priority:** alta
|
|
**Domain:** meta
|
|
**Scope:** registry-only
|
|
**Depends:** 0100 (frontmatter migration)
|
|
**Blocks:** 0102 (work dashboard tab consume `dev_console --json`)
|
|
**Related:** 0103 (slash commands llaman al binario)
|
|
|
|
## Problema
|
|
|
|
Issues y flows hoy se gestionan a ojo: `ls dev/issues/`, `grep`, edit manual de tablas en `README.md` / `INDEX.md`. Sin un comando unificado:
|
|
|
|
- No hay `/issue list --domain trading --status pendiente`.
|
|
- No hay `/flow status 0001` que cuente checkboxes + DoD %.
|
|
- No hay vista cross-cutting "que hacer hoy" mezclando issues + flows.
|
|
|
|
Necesitamos un binario unico (`dev_console`) con la misma forma que `fn`: subcomandos consistentes, output texto + `--json`, latencia <200ms.
|
|
|
|
## Objetivo v1
|
|
|
|
App Go en `apps/dev_console/` con subcomandos:
|
|
|
|
### issue
|
|
|
|
| Subcomando | Que hace |
|
|
|---|---|
|
|
| `dev_console issue list [--domain X] [--type Y] [--status Z] [--prio P] [--epic NNNN]` | tabla filtrable + DoD % |
|
|
| `dev_console issue show NNNN` | imprime archivo |
|
|
| `dev_console issue status NNNN` | % acceptance + estado deps (resuelto si todos los `depends` estan `completado`) |
|
|
| `dev_console issue board` | output TUI o tabla columnas pendiente/in-progress/bloqueado/done |
|
|
| `dev_console issue dep NNNN` | arbol bloquea/depende navegable |
|
|
| `dev_console issue roadmap NNNN` | epic + sub-IDs (auto-detecta `NNNNa`, `NNNNb`, ...) |
|
|
| `dev_console issue tag NNNN +X -Y` | mantenimiento tags |
|
|
| `dev_console issue done NNNN` | mueve a `completed/`, valida deps, actualiza README |
|
|
| `dev_console issue stale [--days 30]` | sin update >N dias |
|
|
| `dev_console issue create <slug> --type T --domain D` | scaffold con frontmatter canonico |
|
|
|
|
### flow
|
|
|
|
| Subcomando | Que hace |
|
|
|---|---|
|
|
| `dev_console flow list [--app X] [--pattern P] [--risk R]` | tabla filtrable + DoD % |
|
|
| `dev_console flow create <slug>` | scaffold (rechaza si falta DoD user-facing) |
|
|
| `dev_console flow show NNNN` | imprime archivo |
|
|
| `dev_console flow status NNNN` | Acceptance % + DoD % separados + checks user-facing destacados |
|
|
| `dev_console flow dod NNNN` | solo bloque DoD + checklist live |
|
|
| `dev_console flow trace NNNN` | join `call_monitor.calls` + `data_factory.runs` filtrados por funciones/apps del flow |
|
|
| `dev_console flow user-test NNNN` | abre superficie usuario declarada en DoD (URL, lanza .exe, abre tab) |
|
|
| `dev_console flow run NNNN` | fase 2 — ejecuta steps con `function:` |
|
|
| `dev_console flow chain N M` | declara composicion N -> M |
|
|
| `dev_console flow done NNNN` | exige DoD 100% (incluyendo user-facing) antes de mover |
|
|
|
|
### work (cross-cutting)
|
|
|
|
| Subcomando | Que hace |
|
|
|---|---|
|
|
| `dev_console work today` | top items prio alta + deps satisfechas (issues + flows) |
|
|
| `dev_console work weekly` | review semanal: closed vs planeados (lookup en git log + completed/) |
|
|
| `dev_console work search "texto"` | FTS sobre issues + flows + completed |
|
|
| `dev_console work dashboard` | imprime JSON consumible por tab Work (issue 0102) |
|
|
|
|
## Reglas tecnicas
|
|
|
|
- Go + parser YAML (gopkg.in/yaml.v3) + tabwriter. Sin DB propia — fuente de verdad = archivos `.md`.
|
|
- Cache opcional en `~/.cache/dev_console/index.json` invalidada por mtime.
|
|
- `--json` en TODOS los subcomandos para consumo por dashboards/agentes.
|
|
- Latencia objetivo <200ms en lookup, <500ms en list (71 issues + 7 flows).
|
|
- Build canonico: `CGO_ENABLED=0 go build -tags fts5 -o dev_console .`
|
|
|
|
## Acceptance
|
|
|
|
- [ ] `dev_console issue list --status pendiente` lista los issues abiertos.
|
|
- [ ] `dev_console flow status 0001` muestra Acceptance + DoD + user-facing %.
|
|
- [ ] `dev_console work today` produce lista util (no vacia, no flood).
|
|
- [ ] `dev_console flow done 0001` rechaza si DoD <100%.
|
|
- [ ] Tests con fixtures en `apps/dev_console/testdata/`.
|
|
|
|
## Definition of Done
|
|
|
|
### Generico
|
|
|
|
- [ ] **Repetibilidad**: tests verdes 3x; latencia consistente.
|
|
- [ ] **Observabilidad**: cada invocacion registrada en `call_monitor.calls` (hook PostToolUse Bash detecta `dev_console *`).
|
|
- [ ] **Error-path**: archivo malformado -> mensaje claro + exit code != 0.
|
|
- [ ] **Idempotencia**: `done` 2x sobre mismo issue = 0 cambios la segunda.
|
|
- [ ] **Secrets**: N/A.
|
|
- [ ] **Docs**: `apps/dev_console/app.md` + `README.md` con ejemplos.
|
|
- [ ] **Registry-first**: reusa `parse_yaml_frontmatter_*`, `checklist_count_*`, etc.
|
|
- [ ] **INDEX + status**: issue cerrado.
|
|
|
|
### User-facing
|
|
|
|
- [ ] **User-facing**: usuario teclea `/issue list` en Claude Code o `dev_console issue list` en terminal y ve tabla limpia con prio/domain/status.
|
|
- [ ] **User-facing repeat**: comando responde igual cada vez, sub-segundo, sin reset de estado.
|
|
- [ ] **User-facing onboarding**: `apps/dev_console/app.md` lista comandos canonicos + casos comunes.
|
|
- [ ] **User-facing latencia**: <500ms p95 para list, <200ms para show.
|