Documentation should definitely unpack the architecture of the system as much as possible. Diagrams are useful for this.
A thorough description of the out-of-the-box behaviour is a basic requirement. If you are documenting a framework I would include examples on overriding or extending default behaviour. If I want to change behaviour X where do I put code Y? What patterns do I use?
Yes, you are right about the architecture part. Often that's the thing I try to look for in any project that I am trying to incorporate. Half the battle is won once the user knows what goes where.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.