Voted Other, Depends, Yes
I don't believe in the Monolithic Design Bible approach for a number of reasons:
- Hard for developers to navigate and find what they need. Devs don't want to read your DD, they want to get on with making the game, and will often just not bother - TL;DR.
- Takes a long time to write and maintain, often resulting in it becoming out of date.
- Puts the designer in a position of being some kind of creative despot, stifling the creativity of the rest of the team and demotivating them.
I generally consider the GDD to be a distinct entity from the TDD and the MDD (Technical Design Document and Media Design Document - code and art design respectively).
For me, the GDD is all about the gameplay. It needs to describe the core feature set and game mechanics in sufficient detail that the developers can boil them down into a set of concrete technical and artistic requirements. It may contain graphics, but these should be more to explain the mechanics rather than being considered concept art - that is left to the MDD.
Ultimately, devs are intelligent and creative people and are perfectly capable of pointing out any errors or omissions in the GDD, and can work with the designer to fix them. So long as it doesn't effect the fundamental requirements, It's generally better to work out details this way (updating the GDD accordingly) than to try and think of everything up front. However you do need to get the fundamentals right and nailed down early. It's no good if half way through the game's development you discover that you need to be using a completely different engine!