Merge develop into main: GT-590 runtime approval subject - #85
Merged
Conversation
…se aprobo (GT-590) Hasta aqui una `RuntimeApproval` llevaba solo `skillId` + `intent`, asi que TODA decision tomada a traves de una misma capacidad se veia igual: igual para el humano que la concede e igual en el ledger que la registra. Eso basta para «puede ejecutarse esta capacidad?» y no para «es ESTA la correspondencia correcta?» — que es la pregunta que el Core empezo a enrutar por esta compuerta. El sujeto se espeja del contrato del Core (`approval.port.ts`, `ApprovalSubject`) con sus mismos nombres — `kind`/`ref`/`summary`/`confidence`/`payload` — y no se reinterpreta. Renombrarlos haria que el dia que el contrato cambiara, el campo llegara y se descartara en silencio. Decisiones que el codigo no explica solo: · TODO el sujeto es opcional: los runtimes ya desplegados no lo envian y no pueden romperse por esta ficha. Pero un sujeto PRESENTE y a medias se rechaza con 400 en vez de recortarse — un `kind` sin `summary` dejaria al humano decidiendo a ciegas mientras cree que ve el objeto, que es peor que no ver nada. · El payload se valida como OBJETO JSON en el dominio, no en la base: un jsonb invalido reventaria en `SaveChanges` como un 500 opaco cuando lo cierto es que el cuerpo venia mal. · `confidence` fuera de [0,1] no es «poco fiable», es que quien la emitio no habla de una probabilidad. Existe para DECIRLE al humano que ratifica una CONJETURA (GT-584), y la pantalla la muestra por eso. · El indice de sujeto NO es unico, a diferencia del de `correlationId`: un mismo objeto puede volver a someterse tras un rechazo o una expiracion, y unificarlo convertiria un reintento legitimo en un error de base. · Rehidratar no revalida. Revalidar haria que un endurecimiento posterior de las reglas volviera ilegibles filas historicas que fueron validas cuando se escribieron. · La cola humana estrena DTO propio en vez de ampliar `RuntimeApprovalResponse`: aquel es el espejo del contrato de MAQUINA y solo lleva el veredicto. Quien concede necesita otra cosa — que capacidad, sobre que objeto, desde cuando espera y cuando vence. `AgentGovernanceMd3` declaraba la cola HITL como capacidad ausente del BFF. Ya no lo es: la pantalla la lista y decide sobre ella. Lo que sigue faltando —y ahora lo dice con precision— es el registro de skills. Verificado: `dotnet ef migrations has-pending-model-changes` confirma que el modelo y el snapshot cuadran; 34 tests nuevos (79 de RuntimeApproval en verde); nx typecheck, lint y build del front en verde. La suite completa pasa de 1066 a 1101 tests superados, con los mismos 10 fallos que develop ya tiene sin Postgres local. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…-subject GT-590: el expediente dice QUÉ se aprobó, no sólo que algo se aprobó
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promueve
developamain.Qué lanza
#84 — GT-590: el expediente dice QUÉ se aprobó, no sólo que algo se aprobó. Una
RuntimeApprovalllevaba sóloskillId+intent, así que toda decisión tomada a través de una misma capacidad se veía igual — para el humano que concede y en el ledger que la registra. El sujeto (kind/ref/summary/confidence/payload) espejaApprovalSubjectdel Core y hace la decisión atribuible a un objeto concreto.Es opcional de extremo a extremo —los runtimes ya desplegados no lo envían y siguen funcionando— pero un sujeto presente y a medias se rechaza con 400 en vez de recortarse: un
kindsinsummarydejaría al humano decidiendo a ciegas mientras cree que ve el objeto. La cola HITL deAgentGovernanceMd3, que la pantalla declaraba como capacidad ausente del BFF, ya es real.Verificado en CI con Postgres:
Backend (build + test),Deploy (kind + Helm + smoke),Frontend (lint + typecheck + build)yGap registry coherenceen verde, con 34 tests nuevos incluidos los de persistencia (ida y vuelta del payloadjsonb, relectura de una fila sin sujeto, coexistencia de dos aprobaciones sobre el mismo objeto).Checks rojos conocidos, preexistentes en este tronco
Ninguno lo causa ni lo empeora esta promoción:
conform— falla endevelopy enmaindesde97916eb, que volvió obligatorio el checkout del Core y aborta conexit 1cuando falta el secretoCORE_REPO_TOKEN. Ese secreto no está configurado en el repositorio, así que toda ejecución desde 2026-08-01T08:29 está en rojo.Validate documentation— falla desde al menos 2026-07-25: las filas del registro endocs/audit/tracker-gaps-opportunities-tracking.mdno respetan el orden BLOCKED → OPEN → DEFERRED → RESOLVED. El fichero es byte-idéntico entremainydevelop.🤖 Generated with Claude Code