docs(CONTINUE): record F2.3a-e completion + remaining sub-plan

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

continue.md

@@ -212,25 +212,45 @@ selectors y type unions coincidan.
 - F2.2 skeleton: `extension-types.ts` + `extension-registry.ts` con 14 tests verdes
 - F2.3a tipos de table movidos a `extensions/table/types.ts` con re-export en `engine/document.ts`
 
-**Siguiente sprint dedicado — F2.3b-j** (migración completa de table):
-
-Orden propuesto (incremental, commit por sub-paso, tests verdes en cada uno):
-1. **F2.3b** — factories de table (createTable, createTableRow, createTableCell) → `extensions/table/factories.ts`
-2. **F2.3c** — serialize-html.ts table-specific code → `extensions/table/serialize-html.ts` (~150 LoC)
-3. **F2.3d** — serialize-markdown.ts pipe-table code → `extensions/table/serialize-markdown.ts` (~50 LoC)
-4. **F2.3e** — render.ts table-specific code → `extensions/table/render.ts` (~100 LoC)
-5. **F2.3f** — path.ts deep-path helpers → `extensions/table/path.ts` (~80 LoC)
-6. **F2.3g** — normalize.ts table normalization → `extensions/table/normalize.ts` (~70 LoC)
-7. **F2.3h** — operations.ts insertTable / table-row / table-cell / etc. → `extensions/table/operations.ts` (~400-500 LoC, lo más entrelazado)
-8. **F2.3i** — wire `tableExtension: WordsExtension` al registry desde la construction del engine. El engine consulta el registry para rutas table; fallback al hardcoded path si no se encuentra.
-9. **F2.3j** — verify: engine.test.ts 129/129 + contracts + visual smoke
-
-Después F2.4 (code-block, similar plan), F2.5 (docs `EXTENSIONS.md`), F2.6 (verify final).
-
-**Riesgos del F2.3 completo**:
-- operations.ts es 2620 líneas con table refs muy entrelazadas con el normalize cascade
-- Importante: NO mover operations sin haber cabledado el registry primero (sino tests del motor rompen)
-- Sugerencia: hacer F2.3i (wire registry con stub table extension vacía) ANTES de F2.3h, así operations.ts se reescribe contra una API estable
+**F2.3 hecho** (sesión de hoy, 5 checkpoint commits + 143/143 tests verdes después de cada uno):
+
+- **F2.3a** ✅ — table types → `extensions/table/types.ts` (commit `088d31ec`)
+- **F2.3b** ✅ — table factories + predicates + value-set constants → `extensions/table/factories.ts` (commit `a0afa44d`)
+- **F2.3d** ✅ — table markdown serializer (serialize + parse + buildTableFromMarkdownRows) → `extensions/table/serialize-markdown.ts` (commit `d6f0af48`)
+- **F2.3c** ✅ — table HTML serializer (serializeTableHtml + parseTableHtml + cell helpers) → `extensions/table/serialize-html.ts` (commit `5797e69b`)
+- **F2.3e** ✅ — table render (renderTable + renderTablePlainText) → `extensions/table/render.ts` (commit `d8392735`)
+
+**F2.3 pendiente — los 4 sub-pasos restantes son el refactor difícil**:
+
+- **F2.3f** — path.ts navigation. Las refs de table están en BRANCHES dentro de funciones grandes (`resolvePath`, `updateNode`, `inferContainerKind`), NO en helpers aislados. Extracción requiere:
+  - Diseñar callback adapters para recursión (engine → extension → engine)
+  - O bien: el engine consulta registry sólo para "is this a node my extension owns?" y el resto del walk queda en engine
+  - Reflexión: ¿cabe redibujar el dispatcher al estilo visitor pattern? Sería más limpio.
+
+- **F2.3g** — normalize.ts. Mismo patrón: branches dentro de `normalizeBlock` / `normalizeNode`. Extracción requiere mismo enfoque que F2.3f.
+
+- **F2.3h** — operations.ts (2620 LoC, ~400-500 LoC table). Las funciones `insertTable*`, `deleteTable*`, `toggle-table-*` son funciones standalone — extraíbles. Pero comparten utilities (`tableCellOptions`, `tableOptions`, `replaceAt`) que viven en el engine. Extraer requiere:
+  - Mover utilities a `extensions/table/utils.ts` o re-exportar desde engine
+  - Mover los ~20 reducers a `extensions/table/operations.ts`
+  - El dispatcher central (`applyWordsCommand`) consulta registry.getCommand(opType) y fallback al switch existente
+
+- **F2.3i** — registry wire-up. Crear `tableExtension: WordsExtension` que cabledea TODOS los hooks (commands, render, serialize, etc.) al registry. El engine constructor registra `tableExtension` por defecto para backward compatibility. Después el dispatcher reescrito consulta registry.
+
+- **F2.3j** — verify final.
+
+**Recomendación de orden para próxima sesión** (lo que dije y se ha confirmado al hacer F2.3a-e):
+
+1. Antes de F2.3f/g/h, hacer **F2.3i con stub vacía**: construir `tableExtension: WordsExtension` que registra sólo nodeTypes ['table','table-row','table-cell'], commandNames y events. El engine al boot lo registra. Después en h-i se mueve la lógica gradualmente hacia los hooks.
+2. **F2.3h primero** (operations) usando el stub. Cada reducer extraído pasa de `case 'insertTable':` en switch a entrada en `extension.commands`. El switch del engine consulta registry.getCommand() antes del fallback.
+3. **F2.3f y F2.3g** al final, donde el engine ya consulta registry para todo el resto.
+
+**Estado del extension system** después de hoy:
+- `WordsExtension` interface ✅ (F2.2)
+- `WordsExtensionRegistry` con 14 tests verdes ✅ (F2.2)
+- `extensions/table/` con types + factories + 2 serializers + render ✅ (F2.3a-e)
+- Engine NO consulta registry aún (importa funciones directamente de extension). El cambio a "engine consulta registry para tipo X" llegará en F2.3i.
+
+Después F2.4 (code-block, plan similar), F2.5 (docs `EXTENSIONS.md`), F2.6 (verify final).
 
 ## Cómo retomar mañana