test(robosoft): the same Core signal blocks, or does not, by tenant configuration

docs/audit/tracker-gap-reference-catalog.md

@@ -279,10 +279,18 @@ No se reutilizó `CoreEvaluationDeposit`: es la forma de la INGESTA y exige viol
 - **Criticality:** P1 · **Complexity:** M
 - **Proposed fix:** Añadir un robot `core-sdlc-parity` que ejecute una iniciativa multi-fase, consuma formatos vivos, produzca artefactos, sincronice/evalúe con Core y afirme decisiones tenant.
 - **Acceptance criteria:**
-  - [ ] El robot crea una iniciativa y recorre al menos discovery→design→construction con artefactos Core.
-  - [ ] Verifica recomendaciones y acciones requeridas visibles para el usuario.
-  - [ ] Prueba un tenant donde una señal es advisory y otro donde la misma señal bloquea.
-  - [ ] Emite evidencia JSON enlazable para cerrar los CP.
+  - [ ] El robot crea una iniciativa y recorre al menos discovery→design→construction con artefactos Core. **Parcial:** `core-sdlc-parity` monta la iniciativa y abre la compuerta de construction; NO recorre discovery→design→construction como jornada, que es lo que `governance-journey` ya cubre por separado.
+  - [ ] Verifica recomendaciones y acciones requeridas visibles para el usuario. **Sin empezar:** el Core no se despliega en este pipeline, así que no hay recomendaciones reales que enseñar; las del depósito se conservan (CP-05) pero no hay superficie que las muestre (CP-11).
+  - [x] Prueba un tenant donde una señal es advisory y otro donde la misma señal bloquea — **la aserción que sostiene el robot**, verificada contra un despliegue vivo: el MISMO depósito adjunto no aporta nada al veredicto sin matriz, aporta `core-signal:architecture` cuando el tenant lo marca `blocking`, y vuelve a no aportar nada al marcarlo `advisory`. Entre las tres evaluaciones no cambió nada del depósito: sólo la configuración.
+  - [x] Emite evidencia JSON enlazable — `robosoft/.evidence/robosoft-*.json`, como todos los robots.
+
+**Verificado de verdad, no en CI (2026-08-03).** Se levantó el stack local completo (`local-test.sh up`: kind + build + Helm) y el robot corrió contra él: **27 checks, 0 fallos**. Los nueve robots de la lista de CI corrieron contra ese mismo despliegue: **211 checks, 0 fallos**.
+
+**Una tenencia, dos configuraciones — dicho en vez de insinuado.** El criterio pide «un tenant … y otro»; el robot lo ejecuta como UN tenant reconfigurado entre evaluaciones, porque un depósito está ligado al tenant de la clave de máquina y un segundo tenant necesitaría otra clave más su propia iniciativa sembrada. El camino de código es idéntico —`CoreSignalRule` se guarda por tenant Y fase, así que «la matriz de otro tenant» es la misma búsqueda contra otra fila— pero lo que NO prueba es el aislamiento entre matrices de dos tenants; esa clase la cubre `tenant-isolation`.
+
+**Por qué NO entra en la lista de CI.** Necesita una clave `CoreMachine` ligada al mismo tenant que lee el robot, y `deploy-check.yml` no configura ninguna — la misma razón por la que `core-evidence-ingest`, `core-integration` y `runtime-approvals` están fuera de `ROBOSOFT_ONLY`. Sin la clave **salta en blando y se ve**: el resumen reporta `0 ok`, no un PASS silencioso. Un robot que dijera PASS sin haber ejercitado nada sería el verde vacuo que este repositorio lleva toda la campaña encontrando.
+
+**Un fallo del propio robot, corregido:** su primera versión afirmaba «la compuerta NO está bloqueada por el depósito» comprobando que el estado no fuera `RETURNED`. La compuerta estaba `RETURNED` por una aprobación pendiente ajena al depósito, así que la aserción medía otra cosa. Ahora compara los motivos de incumplimiento con y sin matriz: con la señal advisory la compuerta queda EXACTAMENTE como sin matriz.
 - **Dependencies:** CP-02, CP-03, CP-04, CP-05, CP-06.
 
 #### CP-11

docs/audit/tracker-gap-tracking.md

@@ -24,7 +24,7 @@ This board is the single source of truth for Tracker technical debt, gaps, oppor
 | [`CP-04`](./tracker-gap-reference-catalog.md#cp-04) | El contexto que el Tracker envía al Core es demasiado pobre para evaluar artefactos, evidencia, autoría y revisión de repositorio | El Core recibe un gate casi sin insumos tipados y sólo puede emitir un veredicto básico, no inteligencia útil sobre el paquete de fase | Ya viajan tipados `schemaVersion`, `requester` y `repositoryRevision` — este último sale del `passthrough` que el Core no interpreta; y los artefactos de la fase viajan tipados con lo exigido y lo presentado, armados por el servidor; la evidencia de gate sigue siendo otro agregado y no se manda | `Integration` | Cross | P1 | M | `PENDING` |
 | [`CP-05`](./tracker-gap-reference-catalog.md#cp-05) | El resultado canónico del Core se reduce al mínimo y se pierden recomendaciones, acciones requeridas, señales y trazabilidad | La persona o agente que completa una fase no recibe inteligencia accionable, sólo un pass/fail parcial | `ParseVerdict` conserva `overallVerdict`, `outcome` y `results.gate`; descarta `rulesExecuted`, `policiesApplied`, `gaps`, `risks`, `recommendations`, `requiredActions` y otros result kinds | `Backend/WEB` | Cross | P1 | M | `PENDING` |
 | [`CP-07`](./tracker-gap-reference-catalog.md#cp-07) | El ingest Core→Tracker ya existe, pero sus depósitos no quedan adjuntos al expediente SDLC de iniciativa, fase o artefacto | Una evaluación producida por CLI, runtime o MCP queda en el ledger técnico, pero no aparece como recomendación o evidencia del gate que el usuario está trabajando | El vínculo tipado ya existe y se adjunta por API con permiso propio, sin copiar ni reinterpretar el veredicto; y el depósito adjunto ya pasa por la matriz de señales del tenant dentro de la decisión de la compuerta; falta la pantalla de fase y la cobertura del robot | `Integration/Governance` | Cross | P1 | M | `PENDING` |
-| [`CP-10`](./tracker-gap-reference-catalog.md#cp-10) | No hay robot de paridad SDLC que conduzca una iniciativa y pruebe formatos, evaluación Core, recomendaciones y reglas tenant por fase | Podemos cerrar piezas individuales sin demostrar que juntas sostienen el flujo principal del producto | RoboSoft prueba gobierno, scorecard y Core integration por separado, pero no un journey que use los formatos vivos del Core en cada gate | `Infra/Quality` | Cross | P1 | M | `PENDING` |
+| [`CP-10`](./tracker-gap-reference-catalog.md#cp-10) | No hay robot de paridad SDLC que conduzca una iniciativa y pruebe formatos, evaluación Core, recomendaciones y reglas tenant por fase | Podemos cerrar piezas individuales sin demostrar que juntas sostienen el flujo principal del producto | El robot core-sdlc-parity prueba contra un despliegue vivo que la MISMA señal del Core bloquea o no según la matriz del tenant; falta la jornada multi-fase y las recomendaciones visibles, que dependen de desplegar el Core | `Infra/Quality` | Cross | P1 | M | `PENDING` |
 | [`CP-11`](./tracker-gap-reference-catalog.md#cp-11) | No hay un modelo de interacción advisory que ordene chat, nudges, acciones on-demand y adjuntos al expediente SDLC | La inteligencia consultiva existe en varias puertas, pero el usuario no sabe cuándo hablar con el asistente, cuándo aceptar una sugerencia o cuándo ejecutar una consulta Core | Hay `AssistantPanel` con prompts fijos y algunas pantallas publican contexto; Design y Intake tienen acciones advisory, pero no una matriz de triggers por fase/capacidad/tenant | `WEB/Integration` | Cross | P1 | M | `PENDING` |
 | [`CP-14`](./tracker-gap-reference-catalog.md#cp-14) | Los artefactos SDLC no tienen versionado documental con comparación, restauración y línea base aprobada | Se puede actualizar un artefacto, pero no queda claro qué cambió, qué versión fue evaluada o cuál quedó aprobada | El historial por artefacto ya existe con autor, fecha, checksum, comparación y restauración, y lo aprobado no se modifica en sitio; y la aprobación de la compuerta sella qué versiones aprobó, con el vínculo del depósito nombrando la versión evaluada | `Backend/Artifacts` | Cross | P1 | M | `PENDING` |
 | [`CP-16`](./tracker-gap-reference-catalog.md#cp-16) | Falta una bitácora SDLC por iniciativa que una artefactos, ediciones, aprobaciones, agentes, evaluaciones Core y decisiones | El seguimiento queda repartido entre pantallas y logs técnicos, sin una línea de tiempo entendible para auditoría o gestión | La bitácora existe como PROYECCIÓN de auditoría, entregas de compuerta y depósitos adjuntos, filtrable por fase y artefacto y clasificando advisory, cumplido, bloqueo y excepción; con las versiones de artefacto ya enlazadas; sólo faltan los exports, que aún no se registran en ningún sitio | `Governance/Audit` | Cross | P1 | M | `PENDING` |