shared-env-contract

To enforce a shared environment loading contract across microservices, use a single loader function, a single shared env file, and one allowed local override. This prevents misconfigurations and hard-coded secrets by ensuring all services read env vars via core/config.py.

Your dotenv configuration causes silent failures when override-enabled dotenv calls bypass the central loader. By requiring a single loader function and disallowing override-enabled dotenv calls, the shared contract detects missing values and cross-service impacts during env var renames.

To audit environment variable changes across chatbot and MCP services, evaluate the cross-service impact of adding or renaming env vars. This governance process verifies MCP server conformity, prevents hard-coded ports, and checks whether changes affect multiple services.

Yes, you can use per-service env file overrides with a shared environment loader. The contract enforces use of app/config/.env_{env} or .env as the shared base, while allowing exactly one optional per-service local override, plus documentation in .env.example.

The best way to debug missing environment values in a microservices stack is to audit the shared environment loading contract. This validates that env vars are read via core/config.py, checks for disallowed override-enabled dotenv calls, and ensures MCP server conformity.

You should not use multiple dotenv calls for environment loading when managing a microservices stack. The shared contract requires a single loader function from services/shared_env.py and prohibits override-enabled dotenv calls to prevent silent failures and misconfigurations.