Specifications aren't magic; they're just words on paper. I can put anything into a specification, but it doesn't magically make code actually follow the spec. I can also take the specification and write tests, but again, the tests don't magically make the code follow the specification.
Before commenting further on the topic you need to read the Bitcoin sourcecode yourself. If you can't read it, you have no business commenting on software development anyway. If you can, you'll find that while it isn't perfect and could use some refactorings, all in all understanding the intent of the different parts is fairly easy and thus the code itself acts as a perfectly good specification.
You are right, I should read the code indeed. A protocol defined in the code rather than in a specification - pros: no maintenance effort, no ambiguity (in theory); cons: difficult to read and understand, difficult to make other implementations (including new versions of the same program). The blockchain fork happened because devs forgot that Berkeley DB was part of the protocol. Without reading the code I find this bit messy.