Unfortunately, there is not one comprehensive document for this. In reality, I've seen few good examples of these in my career, though when they do exist, they tend to be incredibly valuable... and in very mature environments (from a product / operations architecture standpoint).
Conventions like CamelCasing are valuable for consistency (no doubt), and we use and enforce many such conventions. But they don't help with more rigorous or situational requirements like "when is it ok or not ok to use http context". That's a question which must be answered in a general way first, but then very specifically within your architecture implementation. And then the guidelines need to become enforceable... precisely because it is hard to know and apply all the recommendations and constraints of a robust system.
An example of a place where some of these objective considerations is documented is the Module Localization Guide (thank you Vicenç) and other docs which you can find here: http://www.dotnetnuke.com/About/Documentation/ProjectDocuments/tabid/478/Default.aspx
The place we really want to be, and are working toward, is a continuous integration and build environment that implements rules & warnings on all of these kinds of considerations. To use the previous example of http context... would generate a warning or error on build if used inappropriately (according to architecture constraints) so that the problems would not have to be found later at runtime.
At present, we are building the core and a couple of projects using a robust CI process that we should be able to share for others to use also. This effort is ongoing and is a pilot implementation... when we roll it out broadly to other projects, we will definitely do so.
Cheers