# Document The Connection String Cascade

Writes down which configuration keys a provider falls back through, in order, so a missing one is findable.

Follow these project instructions.
# Document The Connection String Cascade

Writes down which configuration keys a provider falls back through, in order, so a missing one is findable.

Version: `1.0.0`

A provider that falls back through several configuration keys is convenient right up to the moment it picks the wrong one. Write the order down next to the registration: every key it tries, in sequence, and which it settled on for each environment.

Check the order against the code rather than the documentation. In IBeam these cascades are copied per provider rather than shared, and the comment and the error message beside one of them each list fewer keys than the code actually tries - so a key that works is not always a key that is written down, and providers differ from each other.

When resolution fails, say what was tried. An error naming the keys in order turns a deployment problem into a single check; one saying a connection string is required sends someone reading source.

The ambiguous failure is worse than the missing one: a stale fallback key left in a shared configuration means the application starts and quietly talks to the wrong store. After changing configuration, confirm which key was used, not merely that the application started.

#### Constraints
- Do not leave a resolution failure reporting only that a connection string is missing.
- Never assume two providers share the same cascade - check each.
- Never rely on a fallback key that is not written down beside the registration.

#### Verification
- A deliberate misconfiguration produces an error naming the keys tried
- Each environment has a confirmed record of which key it resolves from
- The keys and their order are recorded next to the registration, checked against the code