docs: document Articles IV, V & VI as project-customizable in spec-driven.md

spec-driven.md

@@ -318,6 +318,18 @@ No implementation code shall be written before:
 
 This completely inverts traditional AI code generation. Instead of generating code and hoping it works, the LLM must first generate comprehensive tests that define behavior, get them approved, and only then generate implementation.
 
+#### Project-Specific Standards: Common Constitution Areas
+
+Project-specific standards are defined by each team in their constitution via `/speckit.constitution`. A project may define fewer or more principles than any default template, but in many constitutions these standards often cover areas such as integration, operations, and lifecycle expectations:
+
+- **Article IV** may address integration concerns—such as integration testing requirements, contract testing across service boundaries, or cross-component communication standards.
+
+- **Article V** may address operational concerns—such as observability, structured logging, or monitoring requirements.
+
+- **Article VI** may address lifecycle concerns—such as versioning schemes, breaking-change policies, or deprecation strategies.
+
+These article numbers are illustrative rather than reserved slots. Teams are free to define, name, scope, add, remove, or reorder principles in whatever way best fits their project, with `/speckit.constitution` serving as the mechanism for codifying those project-specific architectural standards.
+
 #### Articles VII & VIII: Simplicity and Anti-Abstraction
 
 These paired articles combat over-engineering: