[Adopter] Estoa — solicitud de incorporación y validación Track C de Baton

[montfort]

Solicitud de incorporación: Estoa / StrangeDaysTech

Solicitamos incorporar StrangeDaysTech/estoa al registro de adoptantes colaboradores de StrayMark y a la validación experimental Track C de Baton. El repositorio de Estoa es privado; su nombre se publica con autorización del mantenedor. No se adjuntan rutas, código, títulos ni documentos privados.

Stack y adopción

Plataforma modular ASP.NET/PostgreSQL en desarrollo, gobernada con StrayMark y SpecKit. Integración existente: framework 4.44.0, CLI 3.48.0, SpecKit 0.12.9. Baton instalado informa 0.2.1; se contrastará con upstream e83cc064faf5b2b1fc3cf2fc84eab24dc852fe74 (el último release publicado de Baton figura como 0.2.0). No instalaremos otra copia del framework.

Compromiso de colaboración

• Baton comienza exclusivamente en clasificación y recomendación (route --dry-run). No autoriza reducir modelos, cambiar razonamiento ni lanzar agentes.
• Compartiremos manualmente telemetría saneada de desarrollo conforme al kit Track C y al canal Adopter Feedback: versiones, cantidades por granularidad/verbo/procedencia/clase/tier, unidades sin declaración, discrepancias y limitaciones.
• Abriremos o actualizaremos issues con reproducciones sintéticas, esperado/observado y commit analizado; contribuiremos correcciones acotadas mediante PRs.
• Los findings enlazarán esta Discussion. Cadencia: al completar unidades pertinentes y una calibración retrospectiva tras 2–4 semanas, cuando existan 20–30 unidades declaradas; no declaramos cumplida esa validación hoy.

Privacidad y métricas

Solo compartiremos agregados de desarrollo y evaluación de Baton. Quedan excluidos datos operativos, expedientes, datos personales, secretos, credenciales, rutas y contenido interno. No habrá envío automático, endpoint ni servicio en segundo plano. Las etiquetas individuales permanecen locales por defecto. Los costos de routing se identificarán como ilustrativos, no como facturación, ahorro observado o medición de tokens; los campos no disponibles se declararán nulos.

N-context y primera contribución

Queremos aportar evidencia de otra base técnica al mecanismo declarado de #332. Incorporarse no acredita por sí solo validación independiente N=2 ni aceptación de un patrón. El reconocimiento inicial confirma la herencia pendiente en el inventario y una discrepancia entre el placement ratificado de batches y el kit. Prepararemos reproducciones y priorizaremos la herencia de tareas mediante vínculos explícitos, preservando undeclared ante ambigüedad.

Leídos ADOPTERS.md, Adoption Guide, Adopter Feedback y el kit Track C. Esta publicación es una solicitud/annuncio de incorporación, no una afirmación de aceptación upstream. Propondremos la fila correspondiente en ADOPTERS.md para revisión del mantenedor.

[montfort]

Verificación adicional del alcance actual

Sobre Baton 0.2.1 / upstream e83cc064, una fixture sintética confirma:

Señal declarada	Observado con política predeterminada
Charter implement/new, risk_level: high	implementer → economic; el riesgo del Charter no se cosecha
Follow-up implement/new, Severity high	implementer → frontier, escalated=true
Follow-up implement/upstream, Severity high	operator → local, escalated=false
Follow-up audit, Severity critical	auditor → economic, escalated=false

Esto concuerda con signals.rs (riesgo derivado solo de follow-up severity) y route.rs (escalamiento solo de Implementer). Se registra como limitación vigente de política/señal, no como regresión ni modificación autorizada de la política de riesgo. La integración Bridge→router sigue documentada como pendiente en #335; no se abrió otro issue equivalente.

El código y el ensayo CLI confirman ausencia de ejecución de modelos/agentes y rechazo de route sin --dry-run. Esta repetibilidad no demuestra suficiencia de los tiers recomendados. Estoa conservará su decisión humana de modelo y esfuerzo.

Registro: #429. Corrección acotada: #430. Hallazgos: #427 y #428. La incorporación sigue siendo solicitud y los PRs permanecen sin fusionar.

[montfort]

Cierre del primer ciclo de revisión (maintainer)

Gracias por los hallazgos de esta primera ronda: tenían reproducción sintética y límites bien declarados, y todos llevaron a una corrección. Queda todo en main a partir de 4081f0c.

Hallazgo	PR	Qué cambió
Registro	#429	Estoa figura en ADOPTERS.md como candidato N=2 del mecanismo de #332, en un dominio distinto al backend Go de Sentinel. Solo pasará a N=2 cuando la calibración lo confirme.
#427 herencia en tareas	#430	Se mergeó su corrección, con un ajuste de revisión: la tarea hereda cuando todos los Charters cuyo originating_spec resuelve al spec.md hermano declaran lo mismo. Con la regla de padre único, una spec que ganaba un segundo Charter (lo normal en cadenas de Charters) desclasificaba hacia atrás tareas ya hechas. Los padres se leen del YAML sin tipar. Un Charter ilegible desactiva la herencia y el CLI lo avisa en stderr.
#434 (encontrado en la revisión) + #431	#435	Baton ya no entra en checkouts anidados (.worktrees/, submódulos, clones), que duplicaban unidades con el mismo ID. Tampoco cuenta como follow-up el ejemplo comentado FU-NNN.
#432 + la parte CLI de #431	#436	straymark followups declare FU-NNN --work-verb … [--design-provenance …], y las mismas opciones en followups new. La declaración se escribe como unidad y con vocabulario validado. validate deja de avisar sobre el ejemplo de la plantilla.
#428 batches	#437	Un batch toma la declaración más cercana: su línea - **Work verb**: en el ledger (el override por heterogeneidad), si no el frontmatter del AILOG, y si tampoco, los Charters cuyo AILOG de ledger es ese (originating_ailogs[0], si no execution_ailogs[0], como en charter batch-complete), siempre que coincidan. El kit y la ratificación describen ahora el mismo contrato.

Las decisiones de diseño están en AIDEC-2026-09-13-001 (enmendado) y AIDEC-2026-09-17-001.

Qué conviene hacer del lado de Estoa

1. Volver a medir con main. Las capturas publicadas en [adopter] Baton task inventory does not inherit the ratified Charter declaration #427 incluyen dos artefactos ya corregidos: el placeholder FU-NNN y, si había un worktree dentro del checkout, unidades duplicadas. Además, ahora cuenta la herencia en batches.
   • Baton sigue diciendo 0.2.1 en Cargo.toml hasta el próximo release, así que identifiquen el binario por public_source_commit, como ya hacen.
   • fw-4.45.0 / cli-3.49.0 ya están mergeados pero aún sin tag. followups declare llegará a straymark update con ese release; mientras tanto, se puede compilar el CLI desde main.
2. Declarar los cuatro follow-ups pendientes con followups declare, sin editar el registro a mano ni usar Notes, que es justo lo que ustedes evitaron.
3. Mantener el criterio que ya aplican: lo heredado no cuenta como declaración independiente ni infla la muestra de calibración.

Sigue abierto a propósito

• core::architecture::collect_source_files tiene el mismo problema con los checkouts anidados. Arreglarlo requiere subir la versión de core y se hará aparte (anotado en Baton walkers descend into nested git checkouts (.worktrees/), duplicating units and contracts #434).
• Siguen sin implementar los vínculos de follow-ups con un padre, las declaraciones directas en spec y la integración Bridge→router (Baton: the #332 declared-signal principle applies to the Coherence Bridge — codescan's role=language heuristic is the same anti-pattern as title-scan #335).
• drift --apply sigue extrayendo sin declaración, a propósito: inferir el verbo desde el AILOG sería la heurística que Decisión: descontinuar title-scan; work_verb declarado como única señal de clasificación #332 descartó.

La calibración de Track C sigue como la plantearon: 2–4 semanas o 20–30 unidades declaradas, con etiquetas retrospectivas.

[montfort]

Actualización: versiones publicadas

Ya no hace falta compilar desde main, como decía el comentario anterior. Todo lo de este ciclo está publicado:

Componente	Versión	Qué trae para Estoa
Baton	baton-0.3.0	Herencia de verbo en tasks y batches, y un inventario sin checkouts anidados ni el ejemplo FU-NNN
CLI	cli-3.49.2 (straymark update-cli)	followups declare; títulos fieles en drift (#433); architecture, analyze y verify --claims ya no leen .worktrees/
Framework	fw-4.45.0 (straymark update-framework)	Skill y patrón de follow-ups con declare
Loom	loom-0.7.1	El inventario de arquitectura ignora los checkouts anidados

Para la nueva medición de Track C basta con identificar Baton como 0.3.0: ese número ya no coincide con el "0.2.1" compilado desde el código fuente que midieron antes. El kit de Track C pide ahora baton-0.3.0 o posterior.