# Drive New Behaviour Through Options

Puts behaviour some hosts will not want behind a setting instead of a hard-coded default.

Follow these project instructions.
# Drive New Behaviour Through Options

Puts behaviour some hosts will not want behind a setting instead of a hard-coded default.

Version: `1.0.0`

Put the choice in options. A typed options object read at registration, with a default that suits most hosts, lets one application take new behaviour and another keep the old one without either forking the code.

Choose the default deliberately: it is what every host that never reads the setting will run. Default to the safe behaviour, not the new one, whenever the new one could surprise an existing application.

Prefer resolution that reads attribute first, then options, then a built-in fallback, so a specific declaration beats a general setting and something always answers. Do not add a feature-flag library for this - options plus a sensible fallback is the pattern already in use, and an extra dependency is a second place for behaviour to be decided.

Validate at startup. An option that only fails on the code path it controls turns a missing setting into an incident at whatever hour that path first runs.

#### Constraints
- Do not default a new behaviour to on when it could surprise an existing application.
- Never hard-code behaviour that a host might reasonably want switched off.
- Never leave an invalid option to fail later on the path it controls.

#### Verification
- An invalid or missing value fails at startup with a message naming the setting
- The behaviour can be switched without changing code
- The default was chosen deliberately and is written down