@tacuchi/agent-workflow-cli 11.0.1 → 12.0.0

package/skills/agent-workflow/specialties/design-develop/SKILL.md

@@ -1,115 +0,0 @@
----
-name: design-develop
-description: Convergencia en problem statement + divergencia en soluciones (variantes/mocks). Iteración con el usuario hasta tener una propuesta validada. Produce PROBLEM.md, IDEAS.md y opcionalmente mocks/wireframes en `docs/referencias/` (carpeta transversal manual del usuario, DEC-004 v2). Invocado en execution después de design-discover (o directo si el OBJECTIVE no requiere discovery).
-version: 2.2.0
----
-
-# design-develop — qtc v2.1+
-
-Specialty skill **design**: convergencia en problema + divergencia/iteración de soluciones. Núcleo creativo del flujo design.
-
-## Cuándo se invoca
-
-- Composición desde `agent-workflow:session` en `execution` cuando hay OBJECTIVE + (DISCOVERY.md o sesión saltó discovery por trivialidad).
-- NL del usuario: "vamos a diseñar opciones", "propone variantes", "cómo lo resolvemos", "boceto rápido".
-- Recomendado por `design-discover` como siguiente paso.
-
-## Acción
-
-Producir 2-3 artefactos en paralelo:
-
-### 1. PROBLEM.md — convergencia
-
-Statement de problema en 1-3 oraciones. Foco en QUÉ se resuelve, no en CÓMO. (legacy: `PROBLEMA.md`)
-
-```markdown
-# Problem — sessionNNN-design-<slug>
-
-## Statement
-[1-3 oraciones: usuario X necesita Y porque Z].
-
-## Key constraints
-- [restricciones técnicas, de UX, de tiempo, de tokens del design system]
-
-## Success metrics
-- [cómo sabemos que la solución funciona]
-```
-
-### 2. IDEAS.md — divergencia
-
-Lista de variantes con tradeoffs. **No** elegir todavía:
-
-```markdown
-# Ideas — sessionNNN-design-<slug>
-
-## Variant A: <name>
-- Descripción 1-2 oraciones.
-- Pros: ...
-- Cons: ...
-- Mockup: docs/referencias/A-mockup.png  (si el usuario lo aporta) o link Figma/Stitch
-
-## Variant B: <name>
-- ...
-
-## Variant C: ...
-- (3 variantes es típico; más sólo si justifica)
-
-## Initial recommendation
-- [variante preferida y por qué; queda abierto a feedback del usuario]
-```
-
-### 3. `docs/referencias/` — mocks aportados por el usuario (DEC-004 v2)
-
-- Wireframes/mocks bajos en fidelidad para iteración rápida.
-- Storage:
-  - Local: `<workspace-root>/docs/referencias/A-*.png|svg|md` (el **usuario** los coloca; el AI los lee). Carpeta transversal — cualquier sesión accede a las mismas referencias sin re-subirlas.
-  - Externo (Figma/Stitch): URL en IDEAS.md, nada en `docs/referencias/`.
-- **El AI no escribe en `docs/referencias/` salvo solicitud explícita** del usuario ("guardá este wireframe en referencias"). Si necesita generar un esqueleto ASCII, lo embebe directamente en IDEAS.md.
-- Para `type=system`, las referencias pueden ser ejemplos de uso de tokens/componentes (no mockups de pantallas).
-
-## Loop de iteración
-
-```
-[propuestas] → [feedback usuario] → [refinar] → [propuestas v2] → [...]
-                                       ↓
-                                  [convergencia]
-                                       ↓
-                              [→ design-deliver]
-```
-
-Cada iteración:
-- Editar PROBLEM.md/IDEAS.md (no recrear).
-- Si el usuario aporta nuevos mockups en `docs/referencias/`, leerlos y reflejarlos en IDEAS.md. El AI no toca `docs/referencias/` salvo pedido explícito.
-- Confirmar con el usuario antes de la próxima iteración.
-
-## Reglas
-
-- **3 variantes es óptimo**: si el espacio de soluciones es claro, 1-2 alcanza. Si el problema es muy abierto, hasta 4. Más es ruido.
-- **No saltar a deliver sin convergencia explícita**: el usuario debe confirmar "OK, vamos con la variante X" antes de pasar a `design-deliver`.
-- **Mocks de baja fidelidad primero**: alta fidelidad en `design-deliver`. Acá importa el flujo, no el pixel.
-- **Spec-only**: NO escribir código de UI. Mocks como imágenes/wireframes/Figma URLs.
-- **Frontend-design es referencia, no obligación**: para `type=system`, las decisiones de tokens/componentes ALIMENTAN `frontend-design` (no al revés).
-
-## Composición con otras skills
-
-| Skill | Cuándo |
-|---|---|
-| `design-deliver` | siguiente paso una vez hay convergencia |
-| `frontend-design` | consultar patterns existentes para validar consistencia |
-| `design-discover` | si surge nueva pregunta que requiere investigación, retroceder |
-
-## Sandbox read-only
-
-Reglas universales en el canon (`sandbox-readonly-rules.md`). En plan mode esta skill describe en el plan file:
-
-- **Paths destino**: `.workflow/sessions/<folder>/PROBLEM.md`, `IDEAS.md`, opcional lectura de `<workspace-root>/docs/referencias/` (carpeta transversal manual del usuario, DEC-004 v2) con mocks/wireframes que el usuario aporte.
-- **Problem statement** propuesto: 1-2 oraciones que capturan QUÉ resolver y POR QUÉ.
-- **Variantes a explorar**: 2-4 enfoques distintos (estructura, layout, interacción) con pros/cons textuales — sin diseñar mocks aún.
-- **Iteración prevista**: cuántas rondas con el usuario, qué validar en cada una.
-
-NO ejecuta: `Write` sobre PROBLEM.md/IDEAS.md, generación de mocks en `docs/referencias/` (manual del usuario), ediciones a `docs/especificaciones/`.
-
-## Recursos
-
-- skill `frontend-design` — patterns reutilizables (form/list/modal/navigation/feedback).
-- shared-contract §14 — fase execution del lifecycle universal.

package/skills/agent-workflow/specialties/design-discover/SKILL.md

@@ -1,103 +0,0 @@
----
-name: design-discover
-description: Fase de investigación divergente del diseño dentro del lifecycle universal. Investiga usuarios, flows existentes, código relacionado, design system actual y referencias externas. Produce DISCOVERY.md como artefacto lazy. Invocado desde execution cuando ya hay OBJECTIVE con Type capturado por design-brief y el usuario está listo para divergir antes de converger en problema/soluciones.
-version: 1.2.0
----
-
-# design-discover — qtc v1.1+
-
-Specialty skill **design**: investigación divergente. Primer paso de `execution` para sesiones design.
-
-## Cuándo se invoca
-
-- Composición desde `agent-workflow:session` en `execution` cuando hay OBJECTIVE con `## Type` (legacy: `## Tipo`) y todavía no existe `DISCOVERY.md`.
-- NL del usuario: "investigá el contexto", "qué hay del usuario X", "miremos cómo está hecho hoy".
-- Recomendado por `design-brief` como siguiente paso natural.
-
-## Acción
-
-Producir o iterar `.workflow/sessions/<folder>/DISCOVERY.md` con investigación divergente sobre 4 ejes:
-
-### 1. Usuarios
-
-- Quién va a usar esto, en qué contexto, con qué frecuencia.
-- Si hay personas/role-models existentes, referenciarlas.
-- Si hay usuarios reales accesibles, considerar entrevistas (lo decide el usuario).
-
-### 2. Flows / proceso actual
-
-- Cómo se hace HOY (si existe). Pasos, frustraciones, walking skeleton.
-- Capturas de pantalla / refs al código existente si aplica.
-- Para `type=project` → mirar pantallas existentes del módulo.
-- Para `type=system` → mirar componentes/tokens existentes en `docs/especificaciones/` (kind=`especificacion`, modelo nuevo) o el design system instalado.
-
-### 3. Design system existente
-
-- Qué tokens / componentes ya tenemos que aplican.
-- Patterns establecidos (`skill frontend-design references/*-patterns.md`).
-- Decisiones previas en `docs/especificaciones/NNN-*/DELIVERY.md` (kind=`especificacion`; legacy: `ENTREGA.md`).
-
-### 4. Referencias externas
-
-- Productos parecidos (con screenshots/links si el usuario los provee).
-- Buenas prácticas del dominio.
-- Restricciones de accesibilidad / responsive / multi-idioma.
-
-## Estructura típica de DISCOVERY.md
-
-```markdown
-# Discovery — sessionNNN-design-<slug>
-
-## Users
-
-- ...
-
-## Current flow
-
-- ...
-
-## Applicable design system
-
-- Tokens: ...
-- Components: ...
-- Patterns: ...
-
-## External references
-
-- ...
-
-## Key findings
-
-- [1-3 hallazgos accionables que el siguiente paso (define+develop) usa]
-```
-
-## Reglas
-
-- **Divergir ahora, converger después**: no proponer soluciones todavía — eso es `design-develop`.
-- **Citar fuentes**: cada afirmación con un link/path a evidencia (código, screenshots, docs).
-- **DISCOVERY.md es lazy**: si el OBJECTIVE es trivial (ej. cambio menor a un componente existente), saltar a `design-develop` directo.
-- **No escribir código**: spec-only siempre.
-
-## Composición con otras skills
-
-| Skill | Cuándo |
-|---|---|
-| `design-develop` | siguiente paso una vez DISCOVERY tiene hallazgos accionables |
-| `frontend-design` | consultar patterns existentes para el inventario "design system aplicable" |
-| `analyze-investigate` | si la investigación requiere análisis técnico profundo (latencia, datos), invocar acá |
-
-## Sandbox read-only
-
-Reglas universales en el canon (`sandbox-readonly-rules.md`). En plan mode esta skill describe en el plan file:
-
-- **Path destino**: `.workflow/sessions/<folder>/DISCOVERY.md`.
-- **Fuentes a consultar**: pantallas existentes (paths o screenshots), flows del repo, design system actual (`docs/especificaciones/` con kind=`especificacion` y `## Type: system` interno), referencias externas (links). Material aportado por el usuario en `<workspace-root>/docs/referencias/` también se considera (carpeta transversal — DEC-004 v2).
-- **Preguntas de investigación**: lista priorizada (qué hacen los usuarios hoy, qué duele, qué falta).
-- **Esqueleto del DISCOVERY.md**: secciones (Contexto, Stakeholders, Estado actual, Pain points, Referencias, Preguntas abiertas).
-
-NO ejecuta: `Read` sobre código fuente (sí permitido — read-only), `Write` sobre DISCOVERY.md.
-
-## Recursos
-
-- skill `frontend-design` — patterns reutilizables.
-- shared-contract §14 — fase execution del lifecycle universal.

package/skills/agent-workflow/standards/README.md

@@ -1,12 +0,0 @@
-# standards/
-
-Estándares técnicos universales (no doctrina del lifecycle, no específicos de empresa).
-
-Contenido esperado (T2 PR2):
-
-- `coding-standards.md` — estándares por stack (Java/Spring, Angular/TS, Node) + seguridad (sin secrets, SQL parametrizado, logging por nivel).
-- `sql-mutation-guard.md` — patrón del hook que aborta SQL no parametrizado / DDL fuera de scripts/.
-- `i18n-conventions.md` — convención EN-canon + ES-legacy aliases bilingües.
-- `commit-style.md` — formato de commit messages compatible con el ecosistema.
-
-Inyectables vía `profile.migrate_legacy_rules[]` cuando una empresa tiene estilos heredados.

package/skills/agent-workflow/standards/coding-standards/SKILL.md

@@ -1,102 +0,0 @@
----
-name: coding-standards
-description: Estándares de código por stack (Java/Spring, Angular, Node) — fail-fast, logging por nivel, seguridad (no secrets, SQL parametrizado), naming descriptivo, manejo de errores, validación de input, reglas FE-BE (Sparse DTO unificado, PATCH semantics, sin fallbacks ocultos). Activar al implementar, revisar o refactorizar, o ante NL como buenas prácticas/código limpio/cómo valido este input. Referencia transversal sin dependencia de sesiones.
-version: 0.4.0
----
-
-> **Profile parametrization**: lee `mcp_databases[] + examples_path` de `profile.json` (resuelto vía cascade 5 capas). Ver [`references/profile-parametrization.md`](../../references/profile-parametrization.md) para el contrato completo y comportamiento por defecto cuando el profile está vacío.
-
-# Coding Standards
-
-Estándares de código aplicables durante la implementación. Consultar la referencia del stack correspondiente para detalles.
-
-## Principios generales
-
-- **SOLID** — Single Responsibility, Open/Closed, Liskov, Interface Segregation, Dependency Inversion
-- **Fail fast** — Validar y retornar errores al inicio del método (early returns, evitar nesting)
-- **Nombres descriptivos** — El código habla por sí mismo; comentarios solo para el "por qué"
-- **Métodos pequeños** — Una sola responsabilidad por método/función
-- **Composición sobre herencia**
-- **Reutilización antes que duplicación (DRY)** — antes de crear un componente, función o clase nueva, revisar si ya existe en `shared/` (frontend) o el paquete `common/`/`util/` (backend). Si un patrón aparece 2-3 veces, proponer extracción. Aplica transversalmente; para detalles de componentes frontend y `shared/`, ver skill `frontend-design` + `references/frontend-structure.md`.
-
-## Estándares por stack
-
-### Java / Spring Boot
-Constructor Injection (sin Field Injection), `@Transactional(readOnly=true)` para lecturas, Java records para DTOs Request/Response, Jakarta Validation para inputs. Ver `references/java-spring.md`.
-
-### Angular / TypeScript
-Constructor injection, NgModules, `async` pipe en templates, evitar `any`. Arquitectura `@data`/`@presentation`. Ver `references/angular-typescript.md` y `references/frontend-structure.md`.
-
-## Integración FE-BE (flow=dev v2.6+)
-
-Aplica a sesiones `flow=dev` con `## Type: feature|refactor` y a refactors guiados por `agent-workflow:refactor`. Reglas canónicas en `references/fe-be-integration.md`:
-
-- **R1 — Sparse DTO unificado**: mismo DTO `<Feature>SaveRequest` para create + edit, todos los campos nullable. `null` = "no tocar".
-- **R2 — PATCH para edit**: `@PatchMapping` en BE, `http.patch()` en FE. POST queda solo para create. PUT no se usa salvo replace total justificado.
-- **R3 — FE envía solo cambios**: payload diff entre `formValue` y entidad original.
-- **R4 — Sin fallbacks que oculten errores**: prohibido `catchError(() => of([]))` en FE; prohibido try/catch con fallback al método legacy en BE durante migraciones. Usar feature flags explícitas si se necesita rollout gradual.
-- **R5 — Validación BE con Bean Validation + groups**: `@NotNull(groups = OnCreate.class)` para distinguir reglas POST vs PATCH cuando comparten DTO.
-- **R6 — DB stub-first**: funciones/SP nuevas arrancan en Phase 0 devolviendo mock (`RETURN '[]'::jsonb`); implementación real recién en Phase 1/2.
-
-## Seguridad
-
-- **Nunca** exponer secrets, API keys o credenciales en código
-- **Nunca** logear datos sensibles (contraseñas, tokens, datos personales)
-- **Siempre** parametrizar queries SQL (nunca concatenar strings)
-- **BD vía MCP** — `<mcp-cert>` (pruebas) y `<mcp-prod>` (producción) son READONLY. Modificaciones a BD solo mediante scripts SQL versionados en `docs/scripts/` del workspace de la fuente; el usuario es quien aplica el script (no el AI), nunca ejecución directa via MCP, Bash, psql ni cualquier otro canal. Excepción única: el usuario explícitamente pide "ejecutalo vos contra cert" — aún así, confirmación por bloque y no asumir autorización ampliada
-
-## Manejo de errores HTTP
-
-- **Nunca silenciar errores HTTP con `catchError(() => of([]))` ni equivalentes.** Los errores del backend se propagan al usuario vía toast/mensaje; solo así detectamos regresiones durante guardado, sincronizaciones y creaciones. Si hace falta lógica de reintento, usar operadores RxJS explícitos (`retry`, `retryWhen`), no silenciar.
-
-## Logging
-
-- `ERROR` — Fallos que requieren atención inmediata
-- `WARN` — Situaciones inesperadas pero manejadas
-- `INFO` — Eventos de negocio relevantes (inicio/fin de procesos)
-- `DEBUG` — Detalle técnico para diagnóstico
-
-## Git y ramas
-
-Política de commits: ver `agent-workflow:commits-policy` (canónico).
-
-### Estrategia de ramas
-- **`certificacion`** — Rama principal/producción. Base para crear feature branches.
-- **`desarrollo`** — Rama QA. Solo para probar features desplegados. Se sincroniza desde `certificacion`. No se usa como base.
-- **Feature branches** — Siempre desde `certificacion`, PR hacia `certificacion`.
-
-### Prefijo opcional Conventional Commits
-
-Si la sesión/equipo lo prefiere, se puede combinar con el formato canónico:
-
-- `feat(session<NNN>):` nueva funcionalidad
-- `fix(session<NNN>):` corrección de bug
-- `docs(session<NNN>):` documentación
-- `chore(session<NNN>):` mantenimiento, dependencias
-- `refactor(session<NNN>):` reestructuración sin cambio funcional
-
-Ramas: `feature/`, `fix/`, `hotfix/` + descripción-kebab-case.
-
-## Sandbox read-only
-
-Canon universal en `../session/references/sandbox-readonly-rules.md`. Esta skill es read-only por diseño — carga estándares de código por stack y reglas FE-BE, no edita ni ejecuta nada.
-
-En plan mode: describir en el plan file qué reglas se aplicarían al edit/refactor propuesto (fail-fast, FE-BE R1-R6, MCP READONLY, SQL parametrizado) y listar los refs relevantes (Java/Spring, Angular/TypeScript, fe-be-integration). NO ejecuta `Write`, `Edit`, `MultiEdit`, `Bash` con efectos colaterales, ni queries MCP mutantes.
-
-Compatible con plan mode sin restricciones adicionales.
-
-## Recursos adicionales
-
-### Archivos de referencia
-- **`references/fe-be-integration.md`** — Reglas FE-BE (Sparse DTO unificado, PATCH, sin fallbacks ocultos, Bean Validation con groups, DB stub-first). Aplica a `## Type: feature|refactor`.
-- **`references/java-spring.md`** — Convenciones Java/Spring Boot (inyección, records, transacciones, validación) + PATCH+Sparse DTO con records.
-- **`references/angular-typescript.md`** — Convenciones Angular/TypeScript (constructor injection, NgModules, ApiService) + PATCH client + interfaces sparse.
-- **`references/frontend-structure.md`** — Arquitectura `@data`/`@presentation`, ApiService, interfaces espejeo backend, environments, build
-- **`references/database-conventions.md`** — Nomenclatura BD: esquemas `esq_`, tablas `tb_`, columnas, sequences, funciones `fn_`/`sp_`, patrón maestra-detalle, auditoría, estilo de scripts SQL (transacciones, CTE, comentarios, idempotencia)
-- **`references/project-structure.md`** — Estructura de paquetes backend, capas Entity→Repository→Service→Controller, wrappers `ReqBase`/`RespBase`, convención DTOs `P`/`R`/`Req`
-- **`../frontend-design/`** — Principios de diseño UX para formularios de mantenimiento (agnóstico a framework) + reutilización de componentes y framework-first CSS. Consultar en paralelo con `angular-typescript.md` cuando el trabajo es frontend de mantenimiento.
-
-### Skills de base de datos
-Cuando el stack involucra BD y se escriben scripts SQL:
-- **`sql-script-organizer`** — Organiza scripts en 4 categorías, aplica estilo y genera bundle listo para producción
-- **`sql-rollback-generator`** — Genera rollback acoplado por script y bundle global de reversión

package/skills/agent-workflow/standards/coding-standards/references/angular-typescript.md

@@ -1,266 +0,0 @@
-# Angular / TypeScript — Convenciones detalladas
-
-## Inyección de servicios
-
-Los proyectos actuales usan constructor injection con `private`:
-
-```typescript
-@Injectable({ providedIn: 'root' })
-export class SolicitudService {
-  constructor(private apiService: ApiService) {}
-}
-
-@Component({ ... })
-export class MiComponente {
-  constructor(
-    private solicitudService: SolicitudService,
-    private router: Router
-  ) {}
-}
-```
-
-> **Nota**: `inject()` es válido en Angular 14+ y preferible en proyectos nuevos, pero seguir la convención del proyecto actual.
-
-## NgModules
-
-Los proyectos usan NgModules con routing modules separados:
-
-```typescript
-@NgModule({
-  declarations: [AppComponent],
-  imports: [
-    BrowserModule,
-    AppRoutingModule,
-    ComponentsModule,
-    SharedModule,
-    ToastrModule.forRoot(),
-    BrowserAnimationsModule
-  ],
-  bootstrap: [AppComponent]
-})
-export class AppModule {}
-```
-
-> **Nota**: Standalone components son válidos en Angular 15+ pero los proyectos actuales no los usan. No migrar a standalone a menos que el usuario lo pida.
-
-## Async pipe en templates
-
-Preferir async pipe sobre subscribe manual para datos del template:
-
-```html
-<div *ngIf="solicitudes$ | async as solicitudes">
-  <app-tabla [data]="solicitudes"></app-tabla>
-</div>
-```
-
-```typescript
-solicitudes$ = this.solicitudService.listar();
-```
-
-## Tipos estrictos
-
-Evitar `any`. Usar interfaces en `@data/interfaces/`:
-
-```typescript
-// Interfaces que espejean el backend
-export interface IResponsePayload<T> {
-  trace: Trace;
-  status: Status;
-  payload: T;
-}
-
-export interface ResponseDTO {
-  identificador: number;
-  cuerpo: string;
-  mensaje: string;
-}
-
-// Incorrecto
-const data: any = response.body;  // NO
-```
-
-## Estructura de proyecto
-
-Ver `references/frontend-structure.md` para la arquitectura completa `@data`/`@presentation`.
-
-## PATCH + Sparse DTO unificado (qtc-dev v2.6+)
-
-Para mantenimientos CRUD seguir las reglas de `references/fe-be-integration.md`:
-
-- **Interface única** `<Feature>SaveRequest` para create + edit con campos opcionales (`?` o `| null`).
-- **POST** envía todos los required cargados; **PATCH** envía solo los campos modificados (resto omitido).
-- ApiService expone `patch<T>(url, body)` paralelo a `post<T>(url, body)`.
-
-```typescript
-export interface CategoriaSaveRequest {
-  nombre?: string | null;
-  descripcion?: string | null;
-  activo?: boolean | null;
-  ordenVisual?: number | null;
-}
-
-@Injectable({ providedIn: 'root' })
-export class CategoriasService {
-  constructor(private apiService: ApiService) {}
-
-  create(req: CategoriaSaveRequest): Observable<IResponsePayload<CategoriaResponse>> {
-    return this.apiService.post(`${env.API_ADMIN}v1/categorias`, req);
-  }
-
-  edit(id: number, cambios: CategoriaSaveRequest): Observable<IResponsePayload<CategoriaResponse>> {
-    return this.apiService.patch(`${env.API_ADMIN}v1/categorias/${id}`, cambios);
-  }
-}
-```
-
-En el componente de edición, construir el payload diff con solo los campos que cambiaron:
-
-```typescript
-guardar(): void {
-  const original = this.categoriaOriginal;
-  const form = this.form.value;
-  const cambios: CategoriaSaveRequest = {};
-  if (form.nombre !== original.nombre) cambios.nombre = form.nombre;
-  if (form.descripcion !== original.descripcion) cambios.descripcion = form.descripcion;
-  if (form.activo !== original.activo) cambios.activo = form.activo;
-  if (form.ordenVisual !== original.ordenVisual) cambios.ordenVisual = form.ordenVisual;
-
-  if (Object.keys(cambios).length === 0) return; // nada cambió
-
-  this.servicio.edit(original.id, cambios).subscribe({
-    next: (res) => this.toast.success('Guardado'),
-    error: (err) => this.errorHandler.handle(err) // R4 — no silenciar
-  });
-}
-```
-
-**Anti-pattern**: enviar `form.value` completo en PATCH equivale a PUT y rompe la semántica sparse. Detalles + casos edge: `references/fe-be-integration.md`.
-
-## Services y API
-
-Todas las llamadas HTTP pasan por `ApiService` (wrapper central en `@data/services/`):
-
-```typescript
-@Injectable({ providedIn: 'root' })
-export class SolicitudService {
-  constructor(private apiService: ApiService) {}
-
-  generaSolicitud(solicitud: Solicitud): Observable<IResponsePayload<ResponseDTO>> {
-    const request = armarPayload<any>(solicitud);
-    const url = `${env.API_PRESTAMO}v1/solicitud`;
-    return this.apiService.post(url, request);
-  }
-
-  getOfertas(idSolicitud: number): Observable<IResponsePayload<IPayloadListG<Oferta>>> {
-    const params = requestFilter({ idSolicitud });
-    const url = `${env.API_PRESTAMO}v1/solicitud/listar-ofertas?${params}`;
-    return this.apiService.get(url);
-  }
-}
-```
-
-No usar `HttpClient` directamente en services de presentación.
-
-## Environments
-
-URLs de API se configuran en environment files:
-
-```typescript
-export const environment = {
-  production: false,
-  API_PRESTAMO: '',
-  API_SOLICITUD: '',
-  API_IDENTIDAD: '',
-  API_MOTOR: '',
-};
-```
-
-Archivos: `environment.ts`, `environment.dev.ts`, `environment.prod.ts`
-
-## Build y verificación
-
-- Build producción: `npm run build:prod` (equivale a `ng build -c=production`)
-- Build desarrollo: `npm run build:dev` (equivale a `ng build -c=development`)
-- Serve local: `npm run start:dev`
-- Tests: `ng test --watch=false`
-- Estilos: SCSS
-- UI: Angular Material + Bootstrap
-
-## Formularios reactivos
-
-Patrones al trabajar con `FormGroup` / `FormControl` en mantenimientos CRUD. Para los principios de UX (cuándo usar switch vs checkbox, layout de cards, hints en combos), ver skill `frontend-design`.
-
-### Combo dependiente con carga diferida
-
-Cuando el valor del combo B depende del valor del combo A, suscribirse a `valueChanges` de A en `ngOnInit`:
-
-```typescript
-this.formMantenimiento.get('idPadre')?.valueChanges.subscribe((valor) => {
-  this.formMantenimiento.get('idHijo')?.setValue('');
-  if (valor) {
-    this.listarHijos(String(valor));
-  } else {
-    this.lstHijos = [];
-  }
-});
-```
-
-Al editar, la **precarga inicial** debe setear padre e hijo **sin** disparar el listener (para no perder el valor de hijo que viene del backend):
-
-```typescript
-this.formMantenimiento.patchValue({
-  idPadre: data.idPadre != null ? String(data.idPadre) : '',
-  idHijo:  data.idHijo  != null ? String(data.idHijo)  : ''
-}, { emitEvent: false });
-
-if (data.idPadre) {
-  this.listarHijos(String(data.idPadre));
-}
-```
-
-### Normalización de tipos en controles compartidos
-
-Componentes custom tipo `search-select` o equivalentes suelen comparar opciones con `===`. Si las opciones tienen `value: "1"` (string) pero el DTO trae `1` (number), la opción **no matchea** y el combo queda vacío.
-
-Regla: normalizar consistentemente en el `patchValue`. La forma que expone el componente UI manda:
-
-```typescript
-this.formMantenimiento.patchValue({
-  idRol: data.idRol != null ? String(data.idRol) : ''
-}, { emitEvent: false });
-```
-
-Aplicar la misma regla a todos los campos tipo id. Documentar la decisión si no es obvia.
-
-### Sincronizaciones secuenciales con `concat`
-
-Cuando N operaciones HTTP deben correr **en orden estricto** (evitar race conditions contra restricciones de unicidad del backend), usar `concat` de RxJS, no paralelo:
-
-```typescript
-import { concat, of } from 'rxjs';
-import { toArray } from 'rxjs/operators';
-
-const ops = [
-  ...paraDesactivar.map(r => this.servicio.desactivar(r.id)),
-  ...(nuevoRequerido ? [this.servicio.asignar(nuevo)] : [])
-];
-return ops.length ? concat(...ops).pipe(toArray()) : of([]);
-```
-
-Orden: primero desactivar los sobrantes, luego asignar el nuevo. Nunca paralelo en estos casos.
-
-### Switch Bootstrap alineado
-
-Patrón de clases para que el switch (3em×1.5em) quede alineado verticalmente con su label:
-
-```html
-<div class="form-switch d-flex align-items-center gap-2 ps-0 mb-0">
-  <input type="checkbox" class="form-check-input m-0" role="switch" id="mi-switch"
-         [checked]="activo" (change)="toggle($event)">
-  <label class="form-check-label mb-0" for="mi-switch">Texto del switch</label>
-</div>
-```
-
-Claves: `d-flex align-items-center gap-2` (alinea), `ps-0` (anula padding-left 1.5em default de `.form-check`), `input.m-0` y `label.mb-0` (anulan márgenes que desalinean con el switch grande).
-
-Para la decisión UX **cuándo usar switch vs checkbox**, ver skill `frontend-design` (`references/form-patterns.md` §5).