@maverickcer/env-cap: a one-page brief

The problem

As an application grows, nobody can say who owns a setting, whether it is still used, or when a secret expires. That knowledge sits in wikis, chat threads and people's memory.

What it does

Each part of the application declares the settings it owns. A build step turns those declarations into a report of owners, unused settings and approaching expiry dates, and the application checks its settings when it starts.

Why it matters

• Overdue secret rotations and orphaned settings are found by a report, not by an outage.
• It works alongside the validator and secret manager a team already has, so nothing is replaced.
• The part that runs in your application adds no dependencies to it.

What it costs

Adopting it in one application means adding the package and declaring the settings each part of the code owns. It is free, open source software under the MIT licence, and it replaces no existing tool.

What could go wrong

• env-cap is pre-1.0. Per VERSIONING.md, a minor release may still include a breaking change to the Stable tier before 1.0, so pin accordingly and read the changelog on every minor upgrade.
• Its reports are only as accurate as the declarations a team writes, and it cannot see settings read from outside the code it scans.
• Security fixes target the latest 0.x release only, and there is no backport branch before 1.0.
• The install includes a bundled compiler, about 24 MB unpacked, used only for the build-time reports.

What we are asking for

Agree that one application trials it for a few weeks, then judge from its ownership report whether to spread it.