A new team trying to adopt an internal module cannot tell from its files which inputs are required, what each one means, or how a typical call looks, and keeps asking the maintainers. What change best makes the module's contract self-documenting?
Select an answer to reveal the explanation.
Short Explanation
Your module's files are its manual, so write the manual. Descriptions on every variable and output, a README, and a working example let a newcomer read the contract instead of messaging you.
Full Explanation
HashiCorp's standard module structure expects a README describing what the module does and how to use it, variables.tf and outputs.tf with a description on every variable and output, and an examples directory with working calls. Registries parse this structure to generate documentation that lists required inputs (those without defaults), optional inputs with their defaults and types, and outputs, so following it makes the contract visible both in the code and on the registry page. Descriptions should be written from the consumer's point of view, explaining what a value is for and what it expects. Reordering variable blocks within main.tf changes nothing about whether their meaning is documented and departs from the conventional file layout tools look for. Giving every variable a null default removes required inputs by hiding them: callers can now omit values the module actually needs and discover the problem only at plan or apply time. A changelog records history across versions; it is useful, but it does not describe the current interface in a single authoritative place. Exam caveat: examples double as integration test fixtures and as the quickest onboarding path, so keep them runnable. Operational check: view the module in the private registry and confirm the Inputs tab separates required from optional inputs with descriptions.