test: [TESIS-161] make the tenant isolation sweep cover every route with an id

[LauAubert]

Ticket de Jira

https://proyectofinalfrlp.atlassian.net/browse/TESIS-161

ID provisorio: se reemplaza por la clave real al cargar la card en Jira. Card: cards/032.md.

---

Descripción

El criterio de aceptación de E4b §2.6 pide que «ningún tenant pueda acceder a datos de otro tenant bajo ningún escenario de prueba». tenant_isolation_spec.rb lo prueba barriendo rutas con un id de otra empresa y esperando 404, pero la lista de rutas está escrita a mano: una ruta nueva sólo quedaba cubierta si alguien se acordaba de sumarla. Revisándola contra el router, faltaban tres:

• POST /api/v1/shipments/:id/dispatch
• POST /api/v1/products/:product_id/mappings
• DELETE /api/v1/products/:product_id/mappings/:id

Las tres responden 404 con un id ajeno: no hay fuga, pero no estaban probadas.

• Suma las tres al barrido (con un other_mapping de la otra empresa para la baja).
• Agrega «sweeps every route of the API that takes an id»: toma del router toda ruta de /api/v1 cuyo path lleva un id (:id, :order_id, :product_id, :service_id) y falla, nombrándola, si no está en el barrido. integrations#update queda listada aparte: su id es una plantilla global (Service), y la integración que toca es siempre la de la empresa de la sesión.

Dientes: sacando la línea de dispatch del barrido, el ejemplo nuevo falla con expected ["shipments#confirm"].empty? to be truthy.

Orden de merge: proyecto-api#102 (card 009) agrega POST /orders/:id/cancel; ya sumé esa ruta al barrido en su propia rama, así que mergear una antes que la otra no rompe nada (a lo sumo, un conflicto de líneas vecinas en la lista).

---

Evidencia visual

N/A

---

Cómo probar

1. bundle exec rspec spec/requests/api/v1/tenant_isolation_spec.rb → en verde.
2. Sacar cualquier ruta del barrido → falla el ejemplo nuevo nombrando controlador#acción.

Verificación: bundle exec rspec (1568 ejemplos, 0 fallas), rubocop limpio.

---

Impacto y consideraciones

¿Introduce breaking changes?
No. Sólo tests.

¿Requiere nuevas variables de entorno?
No

¿Afecta la arquitectura o genera un nuevo patrón?
No. Mismo criterio que la card 031 para ADR-015: la regla se verifica contra el router y no contra una lista.

🤖 Generated with Claude Code

[TomasMartin2004]

Revisado. Lo veo bien para implementar.

Lo mergearía por lo que encontró: POST /api/v1/shipments/:id/dispatch, POST /api/v1/products/:product_id/mappings y DELETE .../mappings/:id estaban fuera del barrido de aislamiento. Son tres rutas que mueven stock o tocan el vínculo con un canal, y el criterio de aceptación de E4b §2.6 pide que ningún tenant alcance datos de otro bajo ningún escenario de prueba. Que faltaran no quiere decir que fueran vulnerables —el default_scope de CompanyScoped las cubre igual—, pero sí que nadie lo estaba probando, que es lo que el criterio pide demostrar.

Lo que verifiqué

• El ejemplo sweeps every route of the API that takes an id cierra el agujero de raíz: usa recognize_path sobre las rutas del barrido y las compara contra las que el router expone con un id. Una ruta nueva con id que nadie agregue hace fallar el spec y la nombra. Eso es lo que convierte esto en una garantía y no en otra lista que se va a quedar vieja.
• tenantless_id_routes = %w[integrations#update] está bien justificado: el :service_id apunta a una plantilla global y la integración que se actualiza es siempre la de la sesión. Es la única excepción y está escrita como excepción, no escondida dentro del filtro.
• other_mapping se crea dentro de as_intruder, igual que el resto de los fixtures ajenos, así que nace con el company_id de la otra empresa y no con el que dejó colgado un request anterior.

Antes de mergear

Igual que #113: scan_ruby en rojo es la corrida vieja del 02/10 y el PR sólo toca spec/. Rebasá sobre master y vuelve a correr.

Lo tomaría como parte del trabajo de QA del tablero, no como una card de desarrollo.

[TomasMartin2004]

Revisión del diff completo. El código es idéntico al que leí cuando los PRs estaban en draft —ningún commit nuevo—, así que lo que sigue es el veredicto formal.

✅ Aprobado

Es el PR con mejor relación valor/costo de la tanda, junto con #113: 41 líneas, todas de spec, y cubre una de las tareas transversales de QA que siguen abiertas.

Lo que encontró es el punto: POST /shipments/:id/dispatch, POST /products/:product_id/mappings y DELETE .../mappings/:id estaban fuera del barrido de aislamiento. Son tres rutas que mueven stock o tocan el vínculo con un canal, y el criterio de aceptación de E4b §2.6 pide que ningún tenant alcance datos de otro bajo ningún escenario de prueba. Que faltaran no quiere decir que fueran vulnerables —el default_scope de CompanyScoped las cubre— pero sí que nadie lo estaba demostrando, que es lo que el criterio pide.

Lo que verifiqué

• El ejemplo sweeps every route of the API that takes an id cierra el agujero de raíz: usa recognize_path y compara contra lo que el router expone. Una ruta nueva con id que nadie sume hace fallar el spec y la nombra. Eso es lo que lo convierte en una garantía y no en otra lista que se va a quedar vieja.
• tenantless_id_routes = %w[integrations#update] es la única excepción y está escrita como excepción, no escondida en el filtro. El :service_id apunta a una plantilla global y la integración que se actualiza es siempre la de la sesión.
• other_mapping nace dentro de as_intruder, así que tiene el company_id de la otra empresa y no el que dejó colgado un request anterior.

Sin objeciones. Lo tomaría como trabajo de QA del tablero, no como una card de desarrollo.