Modelo de esfuerzo — la unidad de trabajo

El esfuerzo es la unidad de trabajo para construir TED OS, y GitHub es la fuente de verdad única. El esquema del esfuerzo es además un esquema de dataset de trazas de entrenamiento — cada campo de abajo es también una columna de entrenamiento (ADR-006; ver Decisiones).

La unidad

1 esfuerzo = 1 issue padre · 1 rama · 1 worktree · 1 PR. Sin PRs minúsculos forzados — los PR-esfuerzo grandes están bien mientras se construye. Un esfuerzo se descompone en N sub-issues nativos de GitHub (paralelos o secuenciales, decididos al delimitar el alcance).

issue padre #N  ──►  rama + worktree effort/<N> (desde develop)
   ├─ sub #a ─► worktree sub/<N>a (desde effort/<N>)  ─┐
   ├─ sub #b ─► worktree sub/<N>b                      ├─ merge a effort/<N>
   └─ sub #c ─► worktree sub/<N>c                      ┘
effort/<N>  ──►  UN PR ──►  develop

Los esfuerzos secuenciales pueden commitear sub-issues directamente en la rama de esfuerzo (un commit por sub-issue — ese diff de commit es el parche de entrenamiento del sub-issue). Los sub-issues paralelos usan sus propios worktrees disjuntos por archivo y se fusionan.

El issue padre ES el plan

No hay archivos de plan MDX (el requisito está retirado). El cuerpo del issue padre es el plan, usando cuatro secciones que mapean 1:1 a columnas de dataset:

Sección	Mapea a
Goal	enunciado del problema
Scope	el plan (el DAG de sub-issues; cada uno marcado paralelo / secuencial)
For agents	contexto de recuperación — rutas de archivo / puntos de entrada exactos
Verification	la etiqueta / recompensa (comandos, checks, aceptación)

La narrativa de estrategia / roadmap vive en el knowledge/ del repo; la vista "dónde estamos" se genera de los datos de issues de GitHub — ver el Plan Engine (/plan · /roadmap · /work).

Ciclo de vida

Paso	Qué
new	un issue padre (la plantilla) + sub-issues nativos
start	una rama + worktree effort/<N>; tablero → In Progress
orchestrate	sub-issues en sus propios worktrees (disjuntos por archivo) → merge a la rama de esfuerzo
pr	un PR effort/<N> → develop (cuerpo rico + una sección ## For agents)
close	merge → cierra el padre + subs → tablero Done → snapshot de sub-diffs antes del squash → poda

El estado del tablero + plan es correcto por construcción — la operación de cierre los posee, no un paso separado de "marcar como hecho".

Nombrado de ramas

<kind>/<issue-number>-<slug> — kind ∈ feat fix task chore security scaffold ci adr spike plan. Un esfuerzo usa effort/<N>-<slug>; sus sub-issues usan sub/<N><letter>-<slug> (que nunca abren su propio PR — aterrizan en la rama de esfuerzo).

Por qué sirve además como datos de entrenamiento

El flujo de trabajo (objetivo → plan → parche → verificar → resultado) es exactamente un dataset de trayectorias de agente constructor. Los diffs por sub-issue se capturan antes del squash (el squash destruiría los pares por paso); las etiquetas de resultado vienen del resultado (mergeado = positivo · abandonado/revertido = negativo) más una marca gold manual para ejemplares. Los secretos se depuran y los datos de tenant/cliente nunca entran al corpus — ver Decisiones (ADR-006/007).