theus-cli-linux-x64 1.2.1 → 1.3.0

package/vendor/theus-arsenal/skills/diseno-api/SKILL.md

@@ -1,522 +0,0 @@
----
-name: diseno-api
-description: Patrones de diseño de APIs REST que incluyen nomenclatura de recursos, códigos de estado, paginación, filtrado, respuestas de error, versionado y limitación de tasa para APIs en producción.
----
-
-# Patrones de diseño de APIs
-
-Convenciones y buenas prácticas para diseñar APIs REST consistentes y amigables para desarrolladores.
-
-## Cuándo activarla
-
-- Al diseñar nuevos endpoints de API
-- Al revisar contratos de API existentes
-- Al añadir paginación, filtrado u ordenamiento
-- Al implementar manejo de errores para APIs
-- Al planificar la estrategia de versionado de la API
-- Al construir APIs públicas o para socios
-
-## Diseño de recursos
-
-### Estructura de URLs
-
-```
-# Los recursos son sustantivos, en plural, minúsculas, kebab-case
-GET    /api/v1/users
-GET    /api/v1/users/:id
-POST   /api/v1/users
-PUT    /api/v1/users/:id
-PATCH  /api/v1/users/:id
-DELETE /api/v1/users/:id
-
-# Sub-recursos para relaciones
-GET    /api/v1/users/:id/orders
-POST   /api/v1/users/:id/orders
-
-# Acciones que no mapean a CRUD (usa verbos con moderación)
-POST   /api/v1/orders/:id/cancel
-POST   /api/v1/auth/login
-POST   /api/v1/auth/refresh
-```
-
-### Reglas de nomenclatura
-
-```
-# BIEN
-/api/v1/team-members          # kebab-case para recursos de varias palabras
-/api/v1/orders?status=active  # parámetros de query para filtrado
-/api/v1/users/123/orders      # recursos anidados para expresar pertenencia
-
-# MAL
-/api/v1/getUsers              # verbo en la URL
-/api/v1/user                  # singular (usa plural)
-/api/v1/team_members          # snake_case en URLs
-/api/v1/users/123/getOrders   # verbo en recurso anidado
-```
-
-## Métodos HTTP y códigos de estado
-
-### Semántica de los métodos
-
-| Método | Idempotente | Seguro | Uso |
-|--------|-------------|--------|-----|
-| GET | Sí | Sí | Recuperar recursos |
-| POST | No | No | Crear recursos, disparar acciones |
-| PUT | Sí | No | Reemplazo completo de un recurso |
-| PATCH | No* | No | Actualización parcial de un recurso |
-| DELETE | Sí | No | Eliminar un recurso |
-
-*PATCH puede hacerse idempotente con una implementación adecuada
-
-### Referencia de códigos de estado
-
-```
-# Éxito
-200 OK                    — GET, PUT, PATCH (con cuerpo de respuesta)
-201 Created               — POST (incluye la cabecera Location)
-204 No Content            — DELETE, PUT (sin cuerpo de respuesta)
-
-# Errores del cliente
-400 Bad Request           — Falla de validación, JSON malformado
-401 Unauthorized          — Autenticación ausente o inválida
-403 Forbidden             — Autenticado pero sin autorización
-404 Not Found             — El recurso no existe
-409 Conflict              — Entrada duplicada, conflicto de estado
-422 Unprocessable Entity  — Semánticamente inválido (JSON válido, datos incorrectos)
-429 Too Many Requests     — Límite de tasa excedido
-
-# Errores del servidor
-500 Internal Server Error — Falla inesperada (nunca expongas detalles)
-502 Bad Gateway           — El servicio upstream falló
-503 Service Unavailable   — Sobrecarga temporal, incluye Retry-After
-```
-
-### Errores comunes
-
-```
-# MAL: 200 para todo
-{ "status": 200, "success": false, "error": "Not found" }
-
-# BIEN: usa los códigos de estado HTTP con su semántica
-HTTP/1.1 404 Not Found
-{ "error": { "code": "not_found", "message": "User not found" } }
-
-# MAL: 500 para errores de validación
-# BIEN: 400 o 422 con detalles a nivel de campo
-
-# MAL: 200 para recursos creados
-# BIEN: 201 con la cabecera Location
-HTTP/1.1 201 Created
-Location: /api/v1/users/abc-123
-```
-
-## Formato de respuesta
-
-### Respuesta de éxito
-
-```json
-{
-  "data": {
-    "id": "abc-123",
-    "email": "alice@example.com",
-    "name": "Alice",
-    "created_at": "2025-01-15T10:30:00Z"
-  }
-}
-```
-
-### Respuesta de colección (con paginación)
-
-```json
-{
-  "data": [
-    { "id": "abc-123", "name": "Alice" },
-    { "id": "def-456", "name": "Bob" }
-  ],
-  "meta": {
-    "total": 142,
-    "page": 1,
-    "per_page": 20,
-    "total_pages": 8
-  },
-  "links": {
-    "self": "/api/v1/users?page=1&per_page=20",
-    "next": "/api/v1/users?page=2&per_page=20",
-    "last": "/api/v1/users?page=8&per_page=20"
-  }
-}
-```
-
-### Respuesta de error
-
-```json
-{
-  "error": {
-    "code": "validation_error",
-    "message": "Request validation failed",
-    "details": [
-      {
-        "field": "email",
-        "message": "Must be a valid email address",
-        "code": "invalid_format"
-      },
-      {
-        "field": "age",
-        "message": "Must be between 0 and 150",
-        "code": "out_of_range"
-      }
-    ]
-  }
-}
-```
-
-### Variantes de envoltorio de respuesta
-
-```typescript
-// Opción A: envoltorio con wrapper "data" (recomendado para APIs públicas)
-interface ApiResponse<T> {
-  data: T;
-  meta?: PaginationMeta;
-  links?: PaginationLinks;
-}
-
-interface ApiError {
-  error: {
-    code: string;
-    message: string;
-    details?: FieldError[];
-  };
-}
-
-// Opción B: respuesta plana (más simple, común en APIs internas)
-// Éxito: devuelve el recurso directamente
-// Error: devuelve el objeto de error
-// Se distinguen por el código de estado HTTP
-```
-
-## Paginación
-
-### Basada en offset (simple)
-
-```
-GET /api/v1/users?page=2&per_page=20
-
-# Implementación
-SELECT * FROM users
-ORDER BY created_at DESC
-LIMIT 20 OFFSET 20;
-```
-
-**Pros:** fácil de implementar, permite "saltar a la página N"
-**Contras:** lenta con offsets grandes (OFFSET 100000), inconsistente con inserciones concurrentes
-
-### Basada en cursor (escalable)
-
-```
-GET /api/v1/users?cursor=eyJpZCI6MTIzfQ&limit=20
-
-# Implementación
-SELECT * FROM users
-WHERE id > :cursor_id
-ORDER BY id ASC
-LIMIT 21;  -- trae uno extra para determinar has_next
-```
-
-```json
-{
-  "data": [...],
-  "meta": {
-    "has_next": true,
-    "next_cursor": "eyJpZCI6MTQzfQ"
-  }
-}
-```
-
-**Pros:** rendimiento constante sin importar la posición, estable ante inserciones concurrentes
-**Contras:** no permite saltar a una página arbitraria, el cursor es opaco
-
-### Cuándo usar cada una
-
-| Caso de uso | Tipo de paginación |
-|-------------|--------------------|
-| Paneles de administración, datasets pequeños (<10K) | Offset |
-| Scroll infinito, feeds, datasets grandes | Cursor |
-| APIs públicas | Cursor (por defecto) con offset (opcional) |
-| Resultados de búsqueda | Offset (los usuarios esperan números de página) |
-
-## Filtrado, ordenamiento y búsqueda
-
-### Filtrado
-
-```
-# Igualdad simple
-GET /api/v1/orders?status=active&customer_id=abc-123
-
-# Operadores de comparación (notación de corchetes)
-GET /api/v1/products?price[gte]=10&price[lte]=100
-GET /api/v1/orders?created_at[after]=2025-01-01
-
-# Múltiples valores (separados por comas)
-GET /api/v1/products?category=electronics,clothing
-
-# Campos anidados (notación de punto)
-GET /api/v1/orders?customer.country=US
-```
-
-### Ordenamiento
-
-```
-# Un solo campo (prefijo - para descendente)
-GET /api/v1/products?sort=-created_at
-
-# Múltiples campos (separados por comas)
-GET /api/v1/products?sort=-featured,price,-created_at
-```
-
-### Búsqueda de texto completo
-
-```
-# Parámetro de query de búsqueda
-GET /api/v1/products?q=wireless+headphones
-
-# Búsqueda por campo específico
-GET /api/v1/users?email=alice
-```
-
-### Conjuntos de campos parciales (sparse fieldsets)
-
-```
-# Devuelve solo los campos especificados (reduce el payload)
-GET /api/v1/users?fields=id,name,email
-GET /api/v1/orders?fields=id,total,status&include=customer.name
-```
-
-## Autenticación y autorización
-
-### Autenticación basada en tokens
-
-```
-# Token Bearer en la cabecera Authorization
-GET /api/v1/users
-Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
-
-# API key (para servidor a servidor)
-GET /api/v1/data
-X-API-Key: sk_live_abc123
-```
-
-### Patrones de autorización
-
-```typescript
-// A nivel de recurso: verificar pertenencia
-app.get("/api/v1/orders/:id", async (req, res) => {
-  const order = await Order.findById(req.params.id);
-  if (!order) return res.status(404).json({ error: { code: "not_found" } });
-  if (order.userId !== req.user.id) return res.status(403).json({ error: { code: "forbidden" } });
-  return res.json({ data: order });
-});
-
-// Basado en roles: verificar permisos
-app.delete("/api/v1/users/:id", requireRole("admin"), async (req, res) => {
-  await User.delete(req.params.id);
-  return res.status(204).send();
-});
-```
-
-## Limitación de tasa
-
-### Cabeceras
-
-```
-HTTP/1.1 200 OK
-X-RateLimit-Limit: 100
-X-RateLimit-Remaining: 95
-X-RateLimit-Reset: 1640000000
-
-# Cuando se excede
-HTTP/1.1 429 Too Many Requests
-Retry-After: 60
-{
-  "error": {
-    "code": "rate_limit_exceeded",
-    "message": "Rate limit exceeded. Try again in 60 seconds."
-  }
-}
-```
-
-### Niveles de límite de tasa
-
-| Nivel | Límite | Ventana | Caso de uso |
-|-------|--------|---------|-------------|
-| Anónimo | 30/min | Por IP | Endpoints públicos |
-| Autenticado | 100/min | Por usuario | Acceso estándar a la API |
-| Premium | 1000/min | Por API key | Planes de API de pago |
-| Interno | 10000/min | Por servicio | Servicio a servicio |
-
-## Versionado
-
-### Versionado en la ruta de la URL (recomendado)
-
-```
-/api/v1/users
-/api/v2/users
-```
-
-**Pros:** explícito, fácil de enrutar, cacheable
-**Contras:** la URL cambia entre versiones
-
-### Versionado por cabecera
-
-```
-GET /api/users
-Accept: application/vnd.myapp.v2+json
-```
-
-**Pros:** URLs limpias
-**Contras:** más difícil de probar, fácil de olvidar
-
-### Estrategia de versionado
-
-```
-1. Empieza con /api/v1/ — no versiones hasta que lo necesites
-2. Mantén como máximo 2 versiones activas (actual + anterior)
-3. Cronograma de deprecación:
-   - Anuncia la deprecación (6 meses de aviso para APIs públicas)
-   - Añade la cabecera Sunset: Sunset: Sat, 01 Jan 2026 00:00:00 GMT
-   - Devuelve 410 Gone después de la fecha de retiro
-4. Los cambios no rupturistas no requieren nueva versión:
-   - Añadir nuevos campos a las respuestas
-   - Añadir nuevos parámetros de query opcionales
-   - Añadir nuevos endpoints
-5. Los cambios rupturistas requieren una nueva versión:
-   - Eliminar o renombrar campos
-   - Cambiar tipos de campos
-   - Cambiar la estructura de URLs
-   - Cambiar el método de autenticación
-```
-
-## Patrones de implementación
-
-### TypeScript (ruta de API de Next.js)
-
-```typescript
-import { z } from "zod";
-import { NextRequest, NextResponse } from "next/server";
-
-const createUserSchema = z.object({
-  email: z.string().email(),
-  name: z.string().min(1).max(100),
-});
-
-export async function POST(req: NextRequest) {
-  const body = await req.json();
-  const parsed = createUserSchema.safeParse(body);
-
-  if (!parsed.success) {
-    return NextResponse.json({
-      error: {
-        code: "validation_error",
-        message: "Request validation failed",
-        details: parsed.error.issues.map(i => ({
-          field: i.path.join("."),
-          message: i.message,
-          code: i.code,
-        })),
-      },
-    }, { status: 422 });
-  }
-
-  const user = await createUser(parsed.data);
-
-  return NextResponse.json(
-    { data: user },
-    {
-      status: 201,
-      headers: { Location: `/api/v1/users/${user.id}` },
-    },
-  );
-}
-```
-
-### Python (Django REST Framework)
-
-```python
-from rest_framework import serializers, viewsets, status
-from rest_framework.response import Response
-
-class CreateUserSerializer(serializers.Serializer):
-    email = serializers.EmailField()
-    name = serializers.CharField(max_length=100)
-
-class UserSerializer(serializers.ModelSerializer):
-    class Meta:
-        model = User
-        fields = ["id", "email", "name", "created_at"]
-
-class UserViewSet(viewsets.ModelViewSet):
-    serializer_class = UserSerializer
-    permission_classes = [IsAuthenticated]
-
-    def get_serializer_class(self):
-        if self.action == "create":
-            return CreateUserSerializer
-        return UserSerializer
-
-    def create(self, request):
-        serializer = CreateUserSerializer(data=request.data)
-        serializer.is_valid(raise_exception=True)
-        user = UserService.create(**serializer.validated_data)
-        return Response(
-            {"data": UserSerializer(user).data},
-            status=status.HTTP_201_CREATED,
-            headers={"Location": f"/api/v1/users/{user.id}"},
-        )
-```
-
-### Go (net/http)
-
-```go
-func (h *UserHandler) CreateUser(w http.ResponseWriter, r *http.Request) {
-    var req CreateUserRequest
-    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
-        writeError(w, http.StatusBadRequest, "invalid_json", "Invalid request body")
-        return
-    }
-
-    if err := req.Validate(); err != nil {
-        writeError(w, http.StatusUnprocessableEntity, "validation_error", err.Error())
-        return
-    }
-
-    user, err := h.service.Create(r.Context(), req)
-    if err != nil {
-        switch {
-        case errors.Is(err, domain.ErrEmailTaken):
-            writeError(w, http.StatusConflict, "email_taken", "Email already registered")
-        default:
-            writeError(w, http.StatusInternalServerError, "internal_error", "Internal error")
-        }
-        return
-    }
-
-    w.Header().Set("Location", fmt.Sprintf("/api/v1/users/%s", user.ID))
-    writeJSON(w, http.StatusCreated, map[string]any{"data": user})
-}
-```
-
-## Lista de verificación de diseño de API
-
-Antes de publicar un endpoint nuevo:
-
-- [ ] La URL del recurso sigue las convenciones de nomenclatura (plural, kebab-case, sin verbos)
-- [ ] Se usa el método HTTP correcto (GET para lecturas, POST para creaciones, etc.)
-- [ ] Se devuelven los códigos de estado apropiados (no 200 para todo)
-- [ ] La entrada se valida con un esquema (Zod, Pydantic, Bean Validation)
-- [ ] Las respuestas de error siguen el formato estándar con códigos y mensajes
-- [ ] La paginación está implementada en los endpoints de listado (cursor u offset)
-- [ ] Se exige autenticación (o el endpoint está marcado explícitamente como público)
-- [ ] Se verifica la autorización (el usuario solo accede a sus propios recursos)
-- [ ] La limitación de tasa está configurada
-- [ ] La respuesta no filtra detalles internos (trazas de pila, errores SQL)
-- [ ] Nomenclatura consistente con los endpoints existentes (camelCase vs snake_case)
-- [ ] Documentado (especificación OpenAPI/Swagger actualizada)