When working with this reference it helps to remember the order in which new fields appear. Changes in the command line often ship before the static documentation is updated and before any book is printed. So if a field is not in the reference, that does not always mean it does not exist: it is worth looking at the current configuration through the built-in command and the release notes. The reverse rule applies too: an unknown field is usually just ignored, and the file still looks functional - so the presence of a line in the configuration does not prove that it does anything.

A field may also disappear or change meaning, and that is more dangerous. That is exactly why a team's shared configuration should hold only what you understand and have verified. A copied foreign file with twenty fields works right up to an update, after which nobody remembers why half of them were needed. The check is simple and cheap: remove the field, observe a change in behavior, put it back. If there is no difference, the field is not needed.

From the limitation of the project layer follows a practical conclusion that is often learned late. The autonomy level and the sandbox settings live in the personal file, which means the repository cannot set them on a colleague's behalf. A requirement that everyone works with every action reviewed is not implementable through that file - it rests on an agreement alone, and an agreement is not a control. If the requirement is mandatory, it needs a different mechanism: allow and deny lists in the project layer, or an administrative policy that cannot be loosened from below.

The attribution fields are worth knowing too, because they have a sensible default and non-obvious consequences when switched off. By default a mark of authorship is added to commits and pull requests made by the agent. Turning it off for the sake of a clean history is a poor trade: six months later, while investigating a strange change, that very mark answers the question of whether a human or an agent wrote it, and whether to look for a prompt rather than an author. One service trace in a commit message is cheaper than an hour of archaeology.

The practical approach is simple: start from the minimum and add a field only when you can name the problem it solves. Such a file is easy to review, easy to explain to a newcomer and easy to fix - because every line in it answers a specific operational question.

The engineering conclusion is simple: configuration is not a place for completeness. Completeness lives in the documentation, while decisions live in your file. The fewer decisions, the less surface for divergence between machines and for surprises during an update.

The typical failures are predictable. Putting personal preferences into the project file where only permissions are supported. Expecting the personal file to set autonomy for the whole team. Copying someone else's configuration whole. Switching off authorship marks and losing the trace during an investigation. And adding fields in advance without a problem they solve.