Eager store resolution — every infrastructure store resolves at startup

Status: binding. Two owner rulings, the second widening the first:

1. Owner ruling 2026-08-16 §4 — docs/product/decisions/20260816-owner-inputs-post-topology-close.md: “I agree with (b), with (a) for stores on the critical path.”
2. Owner ruling 2026-08-19 (work-queue B12 — docs/product/decisions/20260818-owner-work-queue.md — resolving the SPRINT_20260722_009 DOC-6 design fork): “extend it everywhere as we already [do]. let’s make it consistent everywhere.” Decoded against item 4’s option letters: the eager-startup-resolution shape (a) extends from critical-path stores to ALL store families in every host; data-plane QA probes © remain the behavioural visibility layer; and the separate doctor-check mechanism (b) — funded as 009 DOC-6 and blocked on the ten-family design fork — is dropped as superseded. For a store that resolves eagerly, a doctor check adds visibility but no protection; consistency is worth more than the residual reporting nuance.

The critical-path criterion below is retained as history and as the severity guide (it still tells you how bad a broken store is — whole data plane vs one feature area) — but it no longer decides whether a store resolves eagerly. Since 2026-08-19 the answer is: it does.

The failure this exists to prevent

On 2026-08-15 packsregistry-web returned HTTP 500 on its entire data plane while reporting Up (healthy). SeedFsPacksRegistryBlobStore’s constructor called Directory.CreateDirectory on a path it cannot write (/app is mode 500 in the hardened base image). Three things combined:

1. the constructor had an eager side effect that could fail;
2. the DI registration was a lazy singleton factory, so nothing constructed it at startup;
3. /healthz resolved nothing, so the health probe could not see it.

It was found by accident, while probing an unrelated routing question. Nothing in monitoring would have surfaced it. Two more instances of the same shape were found the same day by sweeping for it.

The posture (since 2026-08-19)

• Every infrastructure store resolves eagerly at startup, in every host that registers it. A store that cannot construct is a loud startup failure, never a healthy container with a dead data plane.
• Data-plane QA probes remain the behavioural layer — eager resolution proves the store constructs, not that its backing medium accepts writes; the QA feature-check probes are what exercise the store end to end.
• The 2026-08-16 default — “(b) a doctor/health check resolves the store and reports without refusing to boot” — is superseded. It was funded as SPRINT_20260722_009 DOC-6 and blocked on a real design gap (storage has ten service-owned interfaces and no universal type to bind, unlike NpgsqlDataSource); the 2026-08-19 ruling resolves that fork by dropping the mechanism rather than building it.

The criterion — is a store on the critical path? (severity guide)

A store is critical-path when the service’s data plane is unusable without it: if the store cannot construct, substantially every non-health endpoint fails.

Apply it by asking what else stops working, not by how important the store feels:

Worked examples, all measured rather than judged:

The criterion is discriminating — it does not classify everything as critical, which is what makes it usable as a severity guide. Since 2026-08-19 it no longer gates eager resolution.

The inventory — every store family, every resolving host

Verified against src/ 2026-08-24 and pinned by EagerStoreResolutionConformanceTests in the architecture pack (src/__Tests/architecture/StellaOps.Architecture.Contracts.Tests/), whose estate sweep fails the build when a NEW store-shaped interface appears without either an eager resolve in every registering host or a recorded not-applicable ruling.

How to implement

Resolve after builder.Build() and before any request can be served:

var app = builder.Build();
_ = app.Services.GetService<IMyCriticalStore>();

Three rules, each learned from a real defect:

• Never wrap it in try/catch. Failing to start is the intended behaviour; a swallowed exception restores exactly the blindness this removes.
• GetService, not GetRequiredService, when “unregistered” is a legitimate configuration. Some hosts register a store only when its backing feature is configured. GetService still constructs the singleton when it is registered — which is the point — without turning a valid feature-off configuration into a boot failure. Packsregistry’s current seed-reader and upload-store seams are both always registered; the upload-disabled posture uses its typed unavailable adapter.
• Put it in Program.cs, not in a hosted service. A hosted service starts after the host is already considered up.

One more rule the widening added:

• Eager resolution does not license unrelated constructor side effects. A read-only/content store must not mkdir, connect, or write merely to prove it can construct. A construction-time filesystem or network side effect is the original 2026-08-15 defect class when the deployment legitimately supplies a read-only backing root. The last known read-only-store instance, IEvidenceObjectStore’s FileSystem constructor, was closed on 2026-08-19: directory creation remains in StoreAsync, where a write actually requires it (see the inventory). A deliberately writable control authority may instead fail startup on an explicit-root readiness probe when that behavior is part of its recorded contract, as IReEnvelopeCheckpointStore now does.

What happened to the doctor-check half ((b))

Superseded — owner ruling 2026-08-19 (work-queue B12). The mechanism was funded as SPRINT_20260722_009 DOC-6 and blocked on a real gap: the ruling’s “bind stores the way the doctor context binds the data source” analogy fails because storage has ten service-owned interfaces and no universal type — there is nothing to GetService<T>() for generically. Rather than build a shared marker interface or a config-driven probe SDK across ten families, the owner extended eager resolution everywhere and dropped the check mechanism. The limit that decision accepts, stated honestly: eager resolution proves construction, not writability — a root that mounts read-only still fails at first write, per request. That residual is covered by the AppRootWritabilityConformanceTests static gate (unmounted/:ro roots fail the build) and by data-plane QA probes, not by a runtime health check.

Historical references for the dropped mechanism (kept because the traps generalise to any health check): register the doctor context BEFORE AddServiceDoctorChecks — an implicitly-bound context reads as null and reports HEALTHY; and red-proof any check against the pre-fix code — a check that cannot fail is the defect it was meant to catch. EvidenceLockerWriteCheck (src/Doctor/__Plugins/StellaOps.Doctor.Plugin.Storage/Checks/EvidenceLockerWriteCheck.cs) remains the model of a config-driven write probe, currently unreachable (its plugin family is orphaned — see 009’s Decisions & Risks).