Every backend service MUST use structured logging — pino/structlog/slog, JSON format, request IDs, proper log levels. console.log is never acceptable.
88
85%
Does it follow best practices?
Impact
97%
3.03xAverage score across 4 eval scenarios
Passed
No known issues
{
"context": "Tests whether the agent proactively sets up structured logging when building a Go HTTP service. The task describes business requirements for an inventory webhook receiver -- it mentions Kubernetes and Fluent Bit (hinting at production deployment) but never explicitly asks for structured logging, slog, request IDs, or JSON log format. A production Go service running in K8s should use slog with JSON output from the start.",
"type": "weighted_checklist",
"checklist": [
{
"name": "slog or structured logger used (not fmt.Println)",
"description": "Uses log/slog or another structured logging library (zerolog, zap) for all logging. No bare fmt.Println, fmt.Printf, or log.Println calls in the application code.",
"max_score": 15
},
{
"name": "JSON log output configured",
"description": "Logger is configured with a JSON handler (slog.NewJSONHandler or equivalent) since the task mentions Fluent Bit and Elasticsearch which need JSON-formatted logs.",
"max_score": 10
},
{
"name": "Request ID middleware",
"description": "Middleware assigns a unique request ID to each request -- reads from X-Request-ID header if present, otherwise generates a UUID or random value.",
"max_score": 12
},
{
"name": "Request ID in response header",
"description": "The assigned request ID is written back to the response via the X-Request-ID header.",
"max_score": 5
},
{
"name": "Logger in request context",
"description": "A request-scoped logger carrying the request_id field is stored in the request context and retrieved by handler functions -- not manually passing request_id in every log call.",
"max_score": 10
},
{
"name": "Per-request completion log",
"description": "Middleware logs one structured line per completed request containing HTTP method, path, status code, and duration in milliseconds.",
"max_score": 10
},
{
"name": "Health check excluded from request logging",
"description": "The /health endpoint does not produce a request completion log entry (health checks are too noisy for production logging).",
"max_score": 7
},
{
"name": "Business events logged at info",
"description": "Inventory events (stock received, shipped, adjusted) are logged at info level with structured fields like sku, quantity, warehouse_id, event_type.",
"max_score": 8
},
{
"name": "Validation failures and 404 not logged as error",
"description": "Validation failures (400), not-found (404), and conflict (409) are logged at warn level -- NOT at error level. Error level is reserved for unexpected failures.",
"max_score": 8
},
{
"name": "Startup logged with structured logger",
"description": "Server startup is logged using the structured logger (not fmt.Println).",
"max_score": 5
},
{
"name": "Structured fields not formatted strings",
"description": "Log calls use slog's key-value API (e.g. slog.Info(\"msg\", \"sku\", sku, \"qty\", qty)) rather than fmt.Sprintf-style formatted messages.",
"max_score": 5
},
{
"name": "Errors with context",
"description": "Error log entries include relevant contextual fields (what failed, relevant IDs) as structured key-value pairs -- not just a bare error message string.",
"max_score": 5
}
]
}