cache-engineeringlisted

# Freshness-Oriented Cache Engineering Treat a cache as a bounded copy with an explicit **freshness** contract: `authority -> key -> fill -> serve -> invalidate/expire -> degrade/recover -> prove` A cache earns its complexity only when comparable evidence shows lower user-visible latency or origin load without breaking correctness, isolation, or failure behavior. **Global completion criterion:** for every cached value being designed or materially changed, authority, complete key scope, freshness contract, fill owner, invalidation/expiry path, concurrent-fill behavior, degraded-mode policy, observable outcome, and executable falsifier are defined in one canonical contract row. Preserve supplied latency targets, freshness limits, isolation rules, and safety boundaries as fixed constraints. Missing evidence yields a gap or measurement plan while the target stays unchanged. ## Authority and scope - For review, diagnosis, or design, inspect code, configuration, telemetry, and supplied artifacts read-only; report evidence and gaps. - For build or fix requests, make in-scope local changes and run safe checks. - Treat production flushes, bulk invalidation, eviction-policy changes, cluster resize, traffic cutover, and any load test as separate actions requiring explicit authorization. Keep an authorized action's target and bounds exact, then verify it with fresh readback. Hand off database bottleneck attribution and SQL/index/capacity work to `postgres-performance`. Hand off d