Ownership de filas bloqueantes del ledger v11

Propósito y alcance

Este documento asigna un único owner de seguimiento a las nueve filas que CORE-3 identificó como huérfanas en el plan de convergencia. No cambia el contrato, no aprueba transiciones y no convierte una ruta Kernel en equivalente a la ruta legacy. Es un mapa de cola de trabajo: una fila sin owner no puede ser cerrada por una prueba que pertenezca a otra fila.

La asignación es deliberadamente estrecha. Un ticket puede coordinar varias filas, pero una fila de esta tabla tiene sólo un owner primario. UNOWNED no significa que el comportamiento sea irrelevante; significa que no hay evidencia local suficiente para asignarlo a un ticket existente sin inventar alcance.

Snapshot verificable

• Fecha de lectura: 2026-09-20.
• Bloqueantes actuales: 34. Se derivan con scripts.feature_preservation_gate._blocking_rows(_contract()) sobre docs/concepts/feature-preservation-{contract,inventory}.json.
• Filas CORE-3: 9 de esos 34; son las que no tenían un owner de ticket específico y verificable en el plan consolidado, no las filas ya cubiertas por los lanes Gitea de prompting, retrieval, reflection, telemetry, pause o cache.
• Dependencia de integridad: esta tabla depende de CORE-14. Antes de cualquier cierre, el gate debe comprobar que el outcome y los nodos de transición de la misma fila son los que se ejecutaron; no se permite tomar evidencia de otra fila del mismo outcome.

El gate de release completo no se usó como prueba de estado: rechaza un árbol sucio por diseño. El conteo anterior usa únicamente su función pura de clasificación, por lo que no afirma una atestación de artefacto.

Matriz de ownership

Fila bloqueante	Estado / hueco actual	Owner primario	Evidencia de alcance	Cierre exacto
activation_log_mode	removed-without-equivalent; falta comparación de prompt compilado	Gitea #223 — activation-log transition	El inventario apunta a agent/cutover/retired_settings.py, declara que no existe consumidor y marca MISSING: compiled-prompt comparison. La memoria de proyecto registra #223 como lane de activation log.	Dossier que decide retener, reemplazar o retirar; un nodo ejecutado propio de la fila que demuestre el observable elegido; transición aprobada en el contrato.
domain.core_preferences	admitted-but-inactive	Gitea #218 — governance transitions	platform/core_preferences.py y test_core_preferences_migration.py demuestran adaptación, mientras el gate marca la fila inactiva. #218 es el lane de transiciones de governance.	Un capability/plan consume la preferencia en una vuelta pública, o una decisión aprueba no activarla; outcome y evidencia propia quedan enlazados.
enabled_layers	sin outcome ejecutado propio	UNOWNED	El inventario señala agent/cutover/memory_orchestrator_rows.py; no hay branch/ticket local cuyo nombre o alcance asigne esta selección de capas. CORE-20 cubre admisión de defaults, no este contrato de composición.	Crear/nombrar un ticket de composición de capas; añadir outcome propio y un eval de vuelta Kernel que pruebe capas consumidas, o aprobar su retiro.
entity_linker_extractor	replacement-unverified; sin outcome ejecutado	Gitea #186 — entity linking	La fila vive en capabilities/memory/policy.py; existen las ramas feat/issue-186-entity-linking y fix/issue-186-confidence-floor-evidence.	Eval público que capture el extractor/modelo elegido en la vuelta compuesta y comparación/decisión de reemplazo; enlazar ese nodo a la fila.
phase_12_action_type_from_tool_calls	replacement-unverified; sin outcome ejecutado	Gitea #186 — entity linking / consolidation policy	Comparte capabilities/memory/policy.py y el paso de consolidación con el lane #186; su prueba declarada es tests/core/learning/test_phase_12_tool_calls_fallback.py.	Outcome que ejecute esa prueba y pruebe el tipo de acción observable en una vuelta pública, o transición aprobada si cambia la semántica.
phase_12_llm_model	replacement-unverified; falta assertion pública de modelo	Gitea #186 — entity linking / consolidation policy	La fila y el target LearningPolicy.phase_12_llm_model pertenecen a capabilities/memory/policy.py, igual que el lane #186.	Añadir assertion pública determinista del modelo seleccionado, outcome propio y decisión si difiere del legacy.
quick_nap_interval	replacement-unverified; el test no está en outcome	UNOWNED	El inventario lo sitúa en capabilities/memory/schedule.py y declara tests/platform/test_nap_after_the_turn.py; no existe una rama/ticket local que nombre scheduling/cadence como alcance primario.	Ticket de scheduling/consolidation con matriz legacy/native para N positivo, cero y negativo; outcome ejecutado y transición/equivalencia propia.
skill_auto_approve	admitted-but-inactive; falta journey nativo	UNOWNED	agent/cutover/tools_surfaces.py y MISSING: native approval journey no se corresponden con un ticket/branch local de #186, #187, #188, #189, #191, #218, #220 o #221.	Ticket de capability humana/tools; journey nativo con aprobación y rechazo, prueba de consumo por Kernel y decisión de compatibilidad.
working_memory_recent_turns	sin outcome ejecutado propio	UNOWNED	El inventario señala agent/cutover/memory_retrieval_rows.py y tests/agent/cutover/test_memory_retrieval_lane.py; no hay ticket/branch local que asigne el contrato de ventana. CORE-21 puede aportar comparación diferencial, pero no es owner de producto.	Ticket de ventana de memoria; eval que mida límite, aislamiento de scope y contenido entregado al prompt en Kernel; outcome y transición de esta fila.

Fuentes y límites de la asignación

1. El estado y las pruebas declaradas de cada fila proceden de docs/concepts/feature-preservation-inventory.json; los motivos bloqueantes proceden de scripts/feature_preservation_gate.py:_blocking_rows.
2. La relación #186 se sustenta además en las refs locales feat/issue-186-entity-linking y fix/issue-186-confidence-floor-evidence. La de #218 se sustenta en fix/issue-218-governance-transitions.
3. La relación #223 procede del registro MCM de reconciliación de blockers; no había una ref local conservada para ese ticket.
4. El estado remoto abierto/cerrado de Gitea/Plane no fue verificable en esta ejecución: el host configurado no resolvió DNS. Por ello, antes de mover una fila de UNOWNED o cerrar una asignada, se debe confirmar que el ticket citado sigue abierto y acepta ese alcance. Si no, la fila vuelve a UNOWNED; no se reasigna por similitud de nombre.

Regla de cierre de CORE-3

CORE-3 sólo puede cerrarse cuando las nueve filas tienen exactamente un owner primario abierto y confirmado, incluido el reemplazo de los cuatro UNOWNED, y CORE-14 está activo. No basta con enlazar un ticket genérico: cada owner debe incluir explícitamente el id de fila, su observable, el nodo de evidencia propio y, si el estado no es equivalent-proven, la decisión de transición requerida por el gate. Después se reejecuta el evaluador de blockers; una fila sólo deja la lista cuando satisface la regla del contrato, no cuando cambia este documento.