fn_registry/dev/issues/0100-issues-frontmatter-migration.md

0100 — Migrar frontmatter inline a YAML canonico en dev/issues/

Status: pendiente Created: 2026-05-16 Type: chore Priority: alta Domain: registry-quality Scope: registry-only Depends: — Blocks: 0102 (work dashboard tab necesita filtros frontmatter) Related: 0103 (taxonomia + slash commands)

Problema

Hoy los 71 archivos dev/issues/*.md declaran metadata como markdown inline:

# 0099 — datahub app (launcher central)

**Status:** pendiente
**Created:** 2026-05-16
**Type:** app
**Priority:** alta
**Depends:** 0096 — DONE
**Blocks:** —

Imposible filtrar/agrupar sin parsers ad-hoc por linea. Issues antiguos (0027-0070) ni siquiera tienen Type ni Priority. Resultado: /issue list no existe; humano lee README.md (tabla manual) que se queda obsoleta.

Objetivo

Frontmatter YAML canonico al inicio de cada issue, igual modelo que dev/flows/. Mantener el contenido humano intacto debajo.

---
id: 0099
title: datahub app launcher central
status: pendiente              # pendiente | in-progress | bloqueado | completado | deferred
type: app                       # app | feature | bugfix | refactor | chore | docs | spike | epic | infra
domain: [apps-infra, cpp-stack]
scope: app-scoped               # registry-only | app-scoped | multi-app | cross-stack
priority: alta                  # alta | media | baja
depends: [0096]
blocks: []
related: [0095, 0097]
created: 2026-05-16
updated: 2026-05-16
tags: []
---

# 0099 — datahub app launcher central

(cuerpo original sin tocar)

Pipeline propuesto

migrate_issues_frontmatter_bash_pipelines (o python, lo que encaje mejor). Idempotente.

1. Para cada dev/issues/*.md:
   • Si ya tiene frontmatter YAML (--- en linea 1): merge campos faltantes solo, no sobreescribe.
   • Si no: parsea las lineas **Key:** value debajo del H1, extrae a YAML.
   • Si Type / Priority ausentes: deja vacios + log warning para revision manual.
   • domain y scope se infieren con heuristica por nombre/contenido (ej. cpp-* -> cpp-stack, kanban-* -> kanban, trading-* -> trading).
2. Backup en dev/issues/.backup_pre_0100/ antes de cualquier escritura.
3. Output final: tabla de issues sin clasificar para review humano.

Dominios canonicos (allowlist)

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

Cualquier issue con domain: fuera de esta lista hace fallar el indexer.

Acceptance

• Pipeline existe en bash/functions/pipelines/ o python/functions/pipelines/.
• 71 issues migrados sin perder contenido (diff vs backup solo en cabecera).
• dev/issues/README.md ya no es fuente de verdad — se genera desde frontmatter via subcomando /issue list o cron diario.
• Issues completados en dev/issues/completed/ tambien migrados.
• fn doctor issues (subcomando nuevo) reporta issues sin Type/Priority/Domain/Scope.
• Pipeline idempotente (segunda corrida = 0 cambios).

Definition of Done

Generico

• Repetibilidad: pipeline corre N veces sin diff.
• Observabilidad: log de campos inferidos vs por defecto.
• Error-path: archivo malformado -> skip + log + exit code != 0.
• Idempotencia: archivo ya migrado -> 0 cambios.
• Secrets: N/A.
• Docs: README de dev/issues/ actualizado para apuntar al frontmatter.
• Registry-first: pipeline reusa parse_yaml_frontmatter_* (crear si no existe).
• INDEX + status: issue cerrado + movido a completed/.

User-facing

• User-facing: tras correr el pipeline, head -20 dev/issues/0099-datahub-app-launcher.md muestra YAML legible + /issue show 0099 (cuando exista) imprime tabla limpia.
• User-facing repeat: cada issue nuevo creado con /issue create (issue 0101) hereda el formato.
• User-facing onboarding: parrafo en dev/issues/README.md: "Cada issue empieza con frontmatter YAML. Para ver/filtrar: /issue list --domain trading --status pendiente."
• User-facing latencia: migracion completa en <60s sobre 71 archivos.