feat(remote): wire the cache redis client and upstream tier (S13 Step 14, part 1/3)

David Fernandezrequested to merge
10io/s13-step-14-part1of3 into main

📦 What this MR does

Part 1 of 3 of S13 Step 14 (health monitoring): the composition-root floor — the cache-purpose Redis client and the upstream HTTP client the health monitor consumes, wired ahead of the library parts above.

  • wireCache is the first consumer of the S05-A cache-purpose Redis client, mirroring wireRedis's degrade-not-abort posture: registered non-critically with no readiness check, so an unreachable Redis at boot degrades health monitoring without failing startup, while a missing or invalid stanza still aborts boot at construction. The two wiring files carry parallel-by-design nolint:dupl markers; extracting a shared wirePurposeRedis helper was considered and declined — two purposes only, and the S05-A spec words wireCache "by analogy with wireRedis".
  • wireRemote is the S13 construct-and-hold tier: remoteConfigFrom maps the loaded virtual-repositories config onto the remote library's own struct (the iam.Config field-literal precedent, with TestRemoteConfigFrom_MapsEveryField pinning that no field is dropped), and upstreamhttp.NewClient constructs the security-hardened upstream client. Both are held on the wiring for the steps that consume them — the UpstreamDoer adapter (step 11) and the health-monitor wiring with the scheduled sweep (step 15). Nothing registers as an app.Component: the client is a pure RoundTripper stack with nothing to drain.
  • Boot coverage: a missing cache stanza is fatal (TestBuildApp_MissingCacheRedisIsFatal), an invalid upstream-client config fails boot at construction, TestWireRemote_ConstructsAndHolds loads the shared config fixture through config.Load so it tracks the real defaulting path, and the boot integration test asserts the exact closed readiness-check set so any future Redis-tier readiness registration fails a test under whatever key it picks.

Plan drift, called out per the drift carve-out: the plan folded this wiring into the step's library files; it lands as a dedicated wire_remote.go beside the existing per-tier wiring files, matching the composition root's one-file-per-tier layout.

⚙️ Why stacked

Step 14's full diff is ~1.8k reviewable LoC, so it ships as 3 stacked MRs, reviewed and merged bottom-up. This part is the bottom; part 2 (failure counter + test fakes) and part 3 (the health monitor) sit above.

🔗 References

  • Plan: docs/plans/2026-07-16-s13-virtual-remote-foundation.md — Step 14
  • Spec: docs/specs/S13-virtual-remote-foundation.md — health monitoring, security covers; S05-A for the cache-purpose client

🔬 e2e scenarios

No scenario added or affected: this is construct-and-hold wiring with no reachable request path until steps 11/12 wire the production adapter into resolution and step 15 schedules the sweep.

Related to #335 (closed)

📚 Stacked MRs (review/merge bottom-up)

Edited by David Fernandez

Merge request reports