The YAML Indentation Fear Remains Provisionally Approved

Summary

At 11:07, the subject opened a YAML configuration file to make a single change. The change required adding one key-value pair.

By 11:49, the subject had reviewed all forty-three lines of the file.

Timeline

11:07 , File opened. Change identified. Subject prepares to add the key.

11:08 , Subject notices that the indentation of the surrounding block uses two spaces. Subject counts to verify.

11:09 , Subject verifies that all other two-space blocks are consistently two spaces. They are. Subject notes one block that looks like it might be two-point-five spaces. It is not. It was the font.

11:11 , Key-value pair added. Correct indentation applied.

11:12 , Subject rereads the key-value pair. It looks correct. Subject is not fully certain.

11:13 , Subject looks for a YAML validator. Finds three. Opens two.

11:16 , File pasted into validator. Validator returns: valid. Subject notes the validator might not understand the specific format this deployment system requires.

11:19 , Subject reads the surrounding configuration more carefully. The semantic meaning of the configuration begins to raise questions separate from the indentation.

11:31 , The questions are investigated. The answers require reading documentation that references another document.

11:44 , Documentation read. Original change was correct. No semantic issues.

11:47 , Subject returns to the file. The file looks the same as it did at 11:11. The change is applied.

11:49 , Pull request opened.

Governing Rule

Any YAML indentation fear that restores service once may be reused until someone proves why it worked.

The YAML indentation fear restored service in a previous incident when the spacing actually was wrong. This experience is now applied to all YAML files regardless of context.

Status

The change was correct. The indentation was fine. The configuration worked. The subject will open the next YAML file with the same vigilance.