2 Commits (06f3c264006da1ebe0e2d187e6a1c13f01f3e577)

Author	SHA1	Message	Date
dev	8b89c7f6b7	feat(agent): el kit de conformance del contrato de delegación — portable de verdad ... El segundo vehículo que la spec exige (§0.5 · Annex C.1), y el que de verdad acredita: `agent-check` es un lint de NUESTRO repo; esto lo corre un tercero contra SU implementación. PORTABLE POR CONSTRUCCIÓN El kit no importa `createEngineAgent`. Habla con un `ConformanceSubject` estructural —start · run · authorize · reject · resolveEscalation · stop · disable— que el implementor adapta sobre su motor; `subject.ts` es el ejemplo trabajado de ese adaptador, no una dependencia. Vive fuera del barrel (precedente `adapters/*`, D-AG.1c): quien no corre conformance no lo paga. DIEZ CASOS, CADA FALLO CITANDO SU ID AG-2 · AG-4 (el control vuelve aunque el transporte reviente — la lectura más dura del requisito) · AG-5 · AG-6 (escalada no terminal + razón tipada) · AG-9 (interrumpir es volver, no un error) · AG-10 (kill global) · AG-21 (una capacidad inventada vuelve como resultado corregible, no mata el run) · AG-25 (lo irreversible no se ejecuta sin revisar ni con el techo más suelto) · AG-26 (clamp de iniciativa) · AG-50 (degradación sin transporte). Un caso que falla solo se falla A SÍ MISMO: una implementación a la que le falte un requisito recibe igualmente el informe completo del resto, que es la diferencia entre una suite de conformance y un smoke test. Y EL KIT SABE FALLAR Un kit que no puede fallar no prueba nada, así que hay un test que rompe AG-4 a propósito y comprueba que el informe lo nombra. No es lo mismo que `engine-agent.test.ts`: aquella suite prueba el MOTOR con acceso a sus interioridades; ésta prueba el CONTRATO por la misma puerta que tiene un tercero, y es la que nos pillaría enviando un eje que nuestra propia especificación rechaza. AG-35 y AG-41 quedan FUERA a propósito mientras §D de la spec siga abierta — un kit que afirmara un requisito sin decidir estaría inventando la decisión. Hay un test que fija esa ausencia. TRAMPA CAZADA, QUE ES LO QUE HACEN LAS SUITES Tres casos fallaban por lo mismo, y no era el motor: pasar `createEngineTimers()` como `timers` TIPA pero revienta — `EngineTimers` expone `schedule`, no `once`, así que el primer timeout llama a `undefined` y el run cierra como `transport-error`. La factory de `active-app` adapta el puerto justamente por eso. Anotado en el handoff. Verificado: agent 33/33 (10/10 conformance) · arts:check 24/24 · agent:check limpio · docs:check sin errores nuevos · check de vuelta en los 73 preexistentes (los 17 que aparecieron eran míos: `asserts condition` exige llamarse por un nombre anotado, y yo lo desestructuro del contexto). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2 months ago
dev	31580f3b39	docs(spec): el contrato de delegación como especificación normativa (DRAFT) ... Fase 1 del plan de corrección, y materialización de D-AG.12a firmada ayer: `docs/spec/delegation-contract.md`, versionada por fecha (2026-07-28). QUÉ ES 50 requisitos `AG-1…50` en RFC-2119, con escalera de estabilidad por sección (stable | provisional | reserved), identificadores estables que NUNCA se renumeran ni se reciclan (un requisito retirado conserva su número), y la exigencia de que ambos vehículos de conformance CITEN el identificador que incumplen — «una suite que no nombra lo que falla no acredita a nadie». La doctrina pasa a ser el PORQUÉ y lo declara explícitamente: si doctrina y spec discrepan sobre un requisito, manda la spec y la doctrina se corrige. Annex A lleva las dos reclamaciones de frontera con estado `claimed` (ninguna materializada) y su gate de promoción: ≥2 FORMAS DE DOMINIO con manifiesto conforme — y dice por qué dos participantes de texto no valen: un formato probado solo sobre texto secuencial asume texto secuencial en silencio. Annex B mapea el modelo de amenazas a requisitos concretos en vez de dejarlo como prosa. §0.6 declara la posición honesta (actos secuenciales, cliente- first, generalidad en prueba). LO QUE LA ESCRITURA SACÓ A LA LUZ — y no estaba en ninguna lista - **AG-35 (presencia)**: el invariante correcto NO es «Aura montada» sino «alguna superficie está expresando el ciclo». El playground de agnt ya expresa el ciclo SIN Aura, y exigir el componente lo rechazaría siendo correcto. Además resuelve el problema técnico: el motor es un arte sin DOM y no puede saber qué hay montado, pero sí puede contar adjuntos. - **AG-41 (elicitación)**: especificado y NO cumplido, con el porqué estructural — la escalada lleva razón tipada pero no la pregunta, y la resolución es binaria y no lleva respuesta. No era falta de superficie. - **AG-44**: «ningún estado se distingue solo por el color» sube de decisión de componente a requisito del contrato (ya lo fija `shapes.test.ts`). §D — DECISIONES ABIERTAS, VISIBLES Un DRAFT puede llevarlas; al promocionar, §D debe quedar VACÍA. Son dos y ninguna la firmo yo: `SHOULD` vs `MUST` en AG-35 (con recomendación razonada: SHOULD + política que lo eleve a MUST, porque rehusar por defecto rompería los 30 tests del motor y le quitaría al app el derecho a elegir su superficie) y la forma del canal de elicitación en AG-41. Registrada en el índice del corpus. `docs/README.md` lo edita otra sesión en paralelo: stageada SOLO mi fila (backup → HEAD → mi cambio → add → restaurar su versión + mi cambio), verificado que lo suyo queda sin stagear. Verificado: docs:check 542 docs, sin errores nuevos (el único es el ajeno preexistente de callout). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2 months ago