Break the project into phases with a sign off by the person that developed the requirements at each phase. (aka CYA)
Don't do the requirements yourself and be involved as little as possible. This may sound strange, but from my exprience in an environment such as the one you describe in your "rant" post, you need to make sure they don't make you the scapegoat at any point. If they want you to write the requirements yourself then get someone to sign off on them that is senior to you.
Manage Expectations. Know what person (team) X wants that doesn't go in the requirements. For example, if you know that "Fred" is a stickler for all the fonts to match, don't let an odd size font slip into any of the demo/testing processes. Little things can and do throw people completely off track and can lead to lose of confidence. So know what the person you are reporting is looking for that they didn't put in the requirements.
NEVER ask what they will be looking for, most likely they won't be able to put into words and some people have new pet peeves daily. (this is the hidden stuff like the fonts, not the information in the requirements, the requirements should be detailed enough that you don't have to ask what they will be looking for app wise)
Always look beyond today.
Use flexible datastructures
Don't write COOL code, write readable (maintainable) code (aka have pity on the poor bastard that has to maintain it)
Do exception testing as part of your everyday work.
Document anything you do (unless requested to make something elaborate, just keep a couple of text files or daily text files of what you did) and make sure the requirements include the server setup and any restrictions as far as OS, location, does it need SSL (you already knew that one :), etc.
Don't take anything personal. So when responding to comments, keep your focus on the code and the task. Even if they DO attack you personally don't reward them with a counter attack.
Keep your eye on the prize. (good code that works)