Phase 9: Team Workflows & AI-Native Process · 45 min · Claude Code · GitHub Spec Kit · Python

Spec Governance Across Teams

Two engineers changing the same acceptance criterion differently, in parallel, without knowing about each other, is a real conflict — and silently picking one is worse than surfacing it.

Real-world application: Treating spec conflicts with the same rigor as code merge conflicts — detecting and surfacing them instead of silently resolving them — shows you understand spec governance as real team infrastructure, not a solo-developer habit that happens to also apply to teams.

What you will learn

Explain who owns a spec at team scale and how spec review functions as the primary code review
Apply the spec-as-source model to a multi-engineer team, not just a solo project
Detect a real conflict when two engineers edit the same acceptance criterion differently in parallel
Explain why uneven drift-gate enforcement across a team undermines the gate's entire value

Introduction

Spec Governance Across Teams

Objective

Given a base version of a spec's acceptance criteria and two parallel branches' versions, detect any criterion both branches changed differently from the base and from each other, flagging it for human resolution.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, The Concept, Build, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account — the opening phases of 29 of 35 courses are free, no credit card.