← Go: Production EngineeringCONTENT HISTORY

Update to Go: Production Engineering

Snapshot Sep 30, 2026 · 23:15 UTC · version 0.4.0

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Use for Go process/deployment lifecycle, health, telemetry, drain, Kubernetes, and releases. Do not use for domain logic.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 247
    },
    {
      "relative_path": "evals.json",
      "size_in_bytes": 4897
    },
    {
      "relative_path": "references/incident-contract.md",
      "size_in_bytes": 1193
    },
    {
      "relative_path": "references/rollout-and-rollback.md",
      "size_in_bytes": 4486
    },
    {
      "relative_path": "skill.json",
      "size_in_bytes": 2965
    }
  ],
  "name": "go-production-operations",
  "skill_md_contents": "---\nname: go-production-operations\ndescription: \"Use for Go process/deployment lifecycle, health, telemetry, drain, Kubernetes, and releases. Do not use for domain logic.\"\nlicense: Apache-2.0\ncompatibility: \"Go 1.24 or newer; deployment-platform behavior must be verified against the active environment.\"\n---\n\n# Go production operations\n\nStartup, readiness, telemetry, overload signals, and shutdown are externally observable service behavior.\n\n## Startup\n\nParse and validate configuration before serving. Distinguish required secrets, immutable startup settings, and safely reloadable values. Every reload validates a complete candidate snapshot before atomic publication and retains the last known-good state on failure. Initialize dependencies in ownership order and return startup errors from a testable `run` path rather than hiding work in `init`.\n\n## Telemetry\n\nUse structured events with stable names and bounded fields. Metrics labels must have bounded cardinality. Propagate trace context across supported protocols, record errors without secrets, and correlate request identity without treating it as authorization. Define signals for success, rejection, overload, dependency failure, retry, ambiguity, and degraded behavior.\n\nMake telemetry export a bounded failure domain. Choose queue and batch limits, drop or sampling policy, request-path blocking behavior, exporter deadlines, and shutdown flush budget explicitly. Exporter outage must not create unbounded memory or stall the service indefinitely. Expose dropped records, queue saturation, sampling, and export failure through an independent bounded signal; absence of backend data is otherwise indistinguishable from a quiet system.\n\n## Health and overload\n\nReadiness means the instance can safely accept its intended traffic. Liveness means restart is likely to restore progress. Do not make liveness fail for every downstream outage. Keep probes cheap and reserve enough capacity for diagnosis and drain.\n\n## Shutdown\n\nOn termination: stop or mark admission, drain accepted work, stop background producers, wait within the platform budget, flush bounded telemetry, and close dependencies after their users. Surface forced termination and abandoned work.\n\nUse `go-service-boundaries` as well when shutdown correctness depends on HTTP bodies, streams, protocol draining, or client/server resource ownership.\n\n## Delivery\n\nBuild reproducibly, pin CI inputs, generate checksums and provenance, scan archives, run as a non-root minimal image where practical, set realistic resources, and design rolling updates for mixed versions and rollback.\n\nRead [references/incident-contract.md](references/incident-contract.md) for lifecycle, cardinality, backpressure, and telemetry-loss traps.\n\nFor staged deployment, controller progress, canary evidence, data migration, and rollback safety, read [references/rollout-and-rollback.md](references/rollout-and-rollback.md). Platform availability is necessary rollout evidence, not proof that the new artifact preserves business or data invariants.\n\n## Output contract\n\nState the lifecycle order, deployment assumptions, and signals that prove each state. Avoid copied Kubernetes or logging templates without causal fit.\n"
}

SHA-256 of public snapshot: 4e3158c546403d2b823206d49a05093060daa0a3bb7ff46a0a25f4e7db4a253f