fn_registry/dev/issues/0103-taxonomy-and-slash-commands.md

id, title, status, type, domain, scope, priority, depends, blocks, related, created, updated, tags

id	title	status	type	domain	scope	priority	depends	blocks	related	created	updated	tags
0103	Taxonomia + slash commands /issue /flow /work	pendiente	feature	meta	registry-only	alta				2026-05-17	2026-05-17

0103 — Taxonomia + slash commands /issue /flow /work

Status: pendiente Created: 2026-05-16 Type: feature Priority: alta Domain: meta Scope: registry-only Depends: 0100 (frontmatter ya canonico), 0101 (dev_console binary) Blocks: 0102 (work dashboard usa los slash desde la tab) Related: todos los issues + flows

Problema

Sin taxonomia formal, todo issue/flow se mezcla en un saco. dev_console (issue 0101) necesita un schema concreto para filtros: que dominios existen, que tipos son validos, que estados, que scopes. Y los slash commands /issue * / /flow * / /work * necesitan existir como archivos en .claude/commands/ para que Claude Code los reconozca.

Objetivo

A) Taxonomia documentada

Crear dev/TAXONOMY.md con la lista canonica:

Dominios (allowlist):

meta, cpp-stack, kanban, trading, gamedev, osint, data-ingest,
registry-quality, notify, imagegen, apps-infra, dev-ux, deploy,
frontend, mcp, browser, telemetry, docs

Tipos:

app | feature | bugfix | refactor | chore | docs | spike | epic | infra | planning

Estados:

pendiente | in-progress | bloqueado | completado | deferred

Scopes:

registry-only | app-scoped | multi-app | cross-stack

Prioridades:

alta | media | baja

Flow patterns:

smoke-cron | prod-data | event-driven | manual-deep | gitops | realtime-loop

B) Slash commands

Crear .claude/commands/issue.md, flow.md, work.md. Cada uno con frontmatter que define tool: Bash + un command: que llama a dev_console <subcomando> "$ARGS". Mientras 0101 no este listo: stub que avisa.

# .claude/commands/issue.md
---
description: Gestiona issues del registry (list, show, status, board, done, ...)
allowed-tools: [Bash]
---

Usage: /issue <subcomando> [args]

Subcomandos:
- list [--domain X] [--status Y] [--prio P]
- show NNNN
- status NNNN
- board
- dep NNNN
- roadmap NNNN
- tag NNNN +X -Y
- done NNNN
- stale [--days N]
- create <slug> --type T --domain D

Run:
!`./apps/dev_console/dev_console issue $ARGUMENTS`

C) Aplicar tags retroactivos

Pipeline tag_existing_issues_bash_pipelines que, basado en heuristicas (nombre del archivo, contenido), propone domain y scope para los 71 issues. Output: lista para review humano (no escribe sin confirmacion).

Heuristicas iniciales:

• cpp-* -> domain cpp-stack
• kanban-* -> domain kanban
• trading-* -> domain trading
• gamedev-* -> domain gamedev
• osint-*, odr-* -> domain osint
• cpp-app-*, apps-*, init-*-app -> scope app-scoped
• roadmap en el title -> type epic

Acceptance

• dev/TAXONOMY.md creado con todas las listas + descripcion 1-frase por valor.
• .claude/commands/{issue,flow,work}.md existen y son visibles a Claude Code.
• fn doctor issues (subcomando de 0100) valida domain y scope contra la allowlist.
• Pipeline de tags retroactivos corre + produce reporte.
• >=80% de los 71 issues quedan clasificados sin intervencion humana.

Definition of Done

Generico

• Repetibilidad: pipeline + slash commands estables; no varian salida.
• Observabilidad: cada slash command pasa por hook PostToolUse -> call_monitor.calls.
• Error-path: dominio invalido -> error claro + sugerencia ("did you mean ...?").
• Idempotencia: pipeline 2x = 0 cambios despues de primera pasada.
• Secrets: N/A.
• Docs: TAXONOMY referenciado desde .claude/rules/INDEX.md.
• Registry-first: pipeline reusa parsers existentes.
• INDEX + status: issue cerrado.

User-facing

• User-facing: usuario teclea /issue list --domain trading en Claude Code y ve los 10 sub-issues del roadmap trading.
• User-facing repeat: comandos disponibles desde cualquier sesion, no estado por sesion.
• User-facing onboarding: .claude/commands/issue.md autodescribe los subcomandos (Claude Code los muestra al tipear /issue + tab).
• User-facing latencia: <500ms por slash command.