{
  "context": "Tests whether the agent proactively applies graceful degradation when building an order enrichment endpoint that calls four internal microservices. The task describes the business requirement and notes which services are required vs supplementary, but says nothing about timeouts, fallbacks, retries, or circuit breakers. The agent should add resilience patterns on its own.",
  "type": "weighted_checklist",
  "checklist": [
    {
      "name": "timeouts-on-all-service-calls",
      "description": "Every HTTP request to orders, shipping, payments, and inventory services includes an explicit timeout (AbortSignal.timeout, axios timeout, or equivalent). No bare fetch() calls without a timeout.",
      "max_score": 15
    },
    {
      "name": "per-dependency-timeouts",
      "description": "Different services have different timeout values based on their characteristics (e.g., inventory check might be faster than payment lookup). Timeouts are configurable per dependency, not one hardcoded value.",
      "max_score": 8
    },
    {
      "name": "supplementary-services-independent",
      "description": "Shipping, payment, and inventory services are fetched independently so that one failing does not block the others. Uses Promise.allSettled() or individual try/catch blocks, NOT Promise.all().",
      "max_score": 15
    },
    {
      "name": "partial-response-when-supplementary-fails",
      "description": "When shipping, payment, or inventory services fail, the endpoint returns 200 with the available data and null/default values for failed services, rather than returning a 500.",
      "max_score": 15
    },
    {
      "name": "required-vs-optional-distinction",
      "description": "The order service is treated as required -- its failure results in an error response (404 or 500). The other three services are treated as optional/supplementary with fallbacks.",
      "max_score": 10
    },
    {
      "name": "warnings-for-failed-services",
      "description": "The response includes a warnings or errors field listing which supplementary services were unavailable, so the client knows which sections may be missing.",
      "max_score": 8
    },
    {
      "name": "structured-failure-logging",
      "description": "Caught dependency failures are logged with structured context: the service name, error details, order ID, and what fallback was applied. Not just console.log(err).",
      "max_score": 10
    },
    {
      "name": "retry-logic-present",
      "description": "At least the order service (required dependency) includes retry logic with exponential backoff for transient errors, since its failure means the entire request fails.",
      "max_score": 10
    },
    {
      "name": "circuit-breaker-considered",
      "description": "A circuit breaker pattern is implemented or discussed for at least one dependency, to avoid repeatedly calling a service that is known to be down.",
      "max_score": 9
    }
  ]
}