authoring-constitution

# Authoring Constitution

## Overview

Write project constitutions that teams actually follow. Every principle must be enforceable, testable, and justified. Vague aspirations are rejected in favor of actionable constraints with measurable criteria.

## When to Use

- User asks to "create a constitution" or "define governance"
- Starting a new greenfield project that needs governance
- User wants to "write principles" or "define constraints"
- Establishing quality gates and enforcement mechanisms
- Defining amendment processes and version policies

## When NOT to Use

- **Brownfield projects with existing code**: Use `humaninloop:brownfield-constitution` instead, which provides Essential Floor + Emergent Ceiling approach
- **Reviewing an existing constitution**: Use `humaninloop:validation-constitution` for quality checks
- **Syncing CLAUDE.md after constitution changes**: Use `humaninloop:syncing-claude-md` for synchronization

## Common Mistakes

| Mistake | Problem | Fix |
|---------|---------|-----|
| Vague principles | "Code should be clean" has no enforcement | Add specific, measurable criteria: "Functions MUST be ≤40 lines" |
| Missing enforcement | Principles without verification become suggestions | Every principle needs CI automation, code review checklist, or audit process |
| Untestable criteria | "Good architecture" can't be verified | Define binary pass/fail: "No domain imports from infrastructure layer" |
| No rationale | Future maintainers don't know why rules exist | Explain the failure mode prevented and success enabled |
| Skipping SYNC IMPACT | Constitution changes without audit trail | Always update the SYNC IMPACT REPORT header with version changes |
| CLAUDE.md drift | AI assistants operate with outdated guidance | Include CLAUDE.md Sync Mandate section; update both files together |

## The Three-Part Principle Rule

Every principle MUST have three components. A principle without all three is incomplete and should not be accepted.

### 1. Enfor