docs: the deployment path now selects the production feature set

The warning that nothing passed production to create_app, so webhook
loaded in production regardless of the declared lists, described a gap
that has been fixed: the module-level app respects FLASK_ENV, whose
values map directly onto the config names. The pages now describe the
working behaviour, with a line noting the old one for anyone comparing
against an earlier checkout.

Author: drorganvidez

architecture/feature_selection.md

@@ -204,12 +204,10 @@ Under an app created with `config_name="production"`, `env` is `prod`, the loade
 
 Nobody edits a file to make that happen at deploy time. The environment split is a property of the contract itself: the lists describe every environment at once and travel with the source, so the same checkout behaves correctly wherever it is deployed.
 
-{: .warning-title }
-> The shipped production entrypoint does not select the `prod` set
+{: .note-title }
+> How the deployment path selects the set
 >
-> The mechanism above is real, but nothing in the repository currently activates it. No call site anywhere passes `"production"` to `create_app`, and `docker/entrypoints/production_entrypoint.sh` serves the app with `gunicorn app:app`, which imports the module-level `app = create_app()` at the bottom of `app/__init__.py`. That uses the default `config_name="development"`, so `env` resolves to `dev` and `webhook` is registered in production too.
->
-> Setting `FLASK_ENV=production`, as `.env.docker.production.example` does, does not change this. `app/__init__.py` derives `env` from the `config_name` argument and never reads `FLASK_ENV`, and `ConfigManager.load_config` only falls back to `FLASK_ENV` when `config_name` is falsy, which a defaulted `"development"` never is. Treat `features_prod` as a contract that is declared and resolved correctly but not yet reached by the deployment path, and verify what a running instance actually registered rather than assuming.
+> The module-level `app = create_app(...)` that gunicorn imports passes `FLASK_ENV` as the config name, and the values in the env examples (`development`, `production`, `testing`) are exactly the names `ConfigManager` accepts. With `FLASK_ENV=production`, as `.env.docker.production.example` sets, `env` resolves to `prod` and the loader reads `features` plus `features_prod`, so `webhook` is not registered. Earlier revisions always built the development config here regardless of environment, which is worth knowing when comparing against an old checkout.
 
 ## Verifying what actually loaded
 

features/features.md

@@ -51,14 +51,12 @@ features_prod = []
 
 At startup, `app/feature_loader.py` reads these lists and loads the union of `features` and
 `features_<env>`, where `env` is `prod` when the app is created with `config_name="production"` and
-`dev` otherwise. On paper that keeps `webhook` out of production.
-
-In practice it does not, because nothing in the repository passes `"production"` to `create_app`.
-`docker/entrypoints/production_entrypoint.sh` serves the app with `gunicorn app:app`, which imports
-the module-level `app = create_app()` at the bottom of `app/__init__.py`. That uses the default
-`config_name="development"`, so `env` resolves to `dev` and `webhook` is registered in production
-too. See [Feature selection]({{site.baseurl}}/architecture/feature_selection) for the full contract
-and the resolved per-environment table.
+`dev` otherwise, which keeps `webhook` out of production.
+
+The module-level `app = create_app(...)` that gunicorn imports passes `FLASK_ENV` as the config
+name, so with `FLASK_ENV=production` the loader resolves the `prod` set and `webhook` is not
+registered. See [Feature selection]({{site.baseurl}}/architecture/feature_selection) for the full
+contract and the resolved per-environment table.
 
 A package sitting in `app/features/` that is not named in either list is simply skipped. If neither
 list is declared at all, every package found on disk is loaded.