Since you asked for feedback: Good style guides contain rationale, weigh pros and cons and then make a recommendation. For example, you say "use an assert library", but why? You make an assertion (har har) about consistent error output, but I've seen style guides that use the exact same rationale to ban assert libraries.

This reads more like a list of things you wrote to remind yourself of, than something intended for consumption by other programmers.

It's fine to be opinionated, but a normative document must explain itself, so people (1) learn something and (2) know when a rule isn't really a rule and (3) can make an informed decision to change something in 5 years when you no longer work there.

I feel overall those are very reasonable rules. What I do differently:

1) Add context to errors - ok but sometimes the parent caller doesn't expect or wants that.

2) one-letter variables: I use them more, for example k,v for key,value loop through the map, n can be counter, or x is some value inside the loop.