team-charters

# Team Charters Defines the mission, ownership, core principles, quality bar, and (for most roles) communication rules for each role in a multi-agent coding team. Each charter is a reference file under `references/`. ## Available Roles | Role | Mission | Charter | |---|---|---| | **architect** | Own the technical blueprint: how the system is built, how it should be rebuilt, whether the implementation follows the design, and build verification (smoke test) | `references/architect.md` | | **backend** | Own the server-side implementation: build the logic that powers the product | `references/backend.md` | | **dba** | Own the data layer: make sure data is modeled correctly, stored safely, and migrates reliably | `references/dba.md` | | **devops** | Own CI/CD pipelines, deployment automation, and operational infrastructure | `references/devops.md` | | **frontend** | Own the client-side implementation: build what the user sees and interacts with | `references/frontend.md` | | **pm** | Own the product definition: what features exist, what needs to be built, and whether the delivered result matches | `references/pm.md` | | **security** | Audit and verify security posture — find vulnerabilities and escalate, do NOT fix them | `references/security.md` | | **teamlead** | Own the execution blueprint and quality gates: constitution, implementation plans, testing strategies, task breakdowns, and gate verdicts | `references/teamlead.md` | | **tester** | Own runtime-validation execution: verify that the system works correctly by executing the approved testing strategy through integration and end-to-end testing | `references/tester.md` | | **ux** | Own user experience design: how users interact with the system, what they see, and how information is organized | `references/ux.md` | ## Usage To look up a specific role's charter, read `references/<role>.md`. Each charter contains: 1. **Mission** — one-line purpose statement 2. **You Own** — ownership scope for the role 3. **Core Principle** — boundary constraints and what the role must NOT do 4. **Quality Bar** — minimum standards the role must meet 5. **Communication** (most roles) — when and whom to notify or escalate to ## Key Design Principles - **WHAT vs HOW**: PM defines WHAT (features, acceptance criteria). Architect defines HOW (design, patterns, contracts). - **Validation planning vs validation execution**: teamlead owns testing strategy and conformance review; tester owns runtime-validation execution only. - **Read-only roles**: PM, architect, security, ux produce documentation only — no source code. Teamlead focuses on planning and quality gates. - **Tester never modifies production code** — escalates bugs to the responsible role. - **Ownership boundaries are strict** — if work crosses into another role's territory, delegate via notify/escalate.