AI-DLCをより安全にチーム開発向けにカスタマイズする

AI-DLCとは

AI-DLC（AI-Driven Development Lifecycle） は、AIを開発チームの中心メンバーとして位置づけ、ソフトウェア開発ライフサイクル全体に統合するフレームワークです。AWS の Principal Solutions Architect である Raja SP 氏によって提唱され、AWS DevOps ブログで紹介されています。

AI-DLCには2種類の公式ドキュメントがあります。

ドキュメント	内容	対象
White Paper（ホワイトペーパー）	フレームワークの完全な方法論。Intent・Unit・Bolt・Mob Elaboration など全概念を定義	チーム開発・メソッドロジーの全体像
GitHub MDファイル群（awslabs/aidlc-workflows）	White Paperをもとにした実装ルールファイル。Claude Code などのAIエージェントが直接読み込んで使う	AIエージェントによる自動ワークフロー実行

GitHub MDファイル群は便利ですが、1つのAIセッションが1つのUnitを担う前提で設計されており、複数チームが複数のAIセッションを並列稼働させる場合はそのままでは不十分です。

White Paperが推奨するConstruction Phase（Mob Construction）では、全チームが同じ部屋に集まりながら、各チームが自分の担当Unitのために独立したAIセッションを立ち上げて並列で動かします。DDD のサブドメイン境界に沿って Unit を分割すれば各セッションの独立性は確保できますが、それだけでは不十分です。各AIセッションは他のセッションの状況を知ることができないため、セッション間の調整ルールを別途整備する必要があります。

以下の4点は、GitHub MD ファイルで意図的に省略されており、複数チームが並列でAIセッションを動かす際に補完が必要になります。

補完が必要な点	内容
Unit オーナーシップ	どのチームがどの Unit を担当するかを記録・強制する仕組みが省略されている
Contract-First（設計フェーズ）	Unit 間の API・イベント仕様を Inception Phase でチーム間合意する Contract-First のプロセスが省略されている
テストの Shift Left（実行タイミング）	Unit Test の実行が全 Unit 完了後の Build and Test Phase にまとめられており、Bolt 単位の Definition of Done として機能しない
Contract Test（検証フェーズ）	設計フェーズで合意したインターフェースが実装で守られているかを継続的に検証する自動テストが省略されている

この記事では、White PaperとGitHub MDファイル群を精査したうえで、以下の3点を解説します。

1. AI-DLCの基本概念とScrumとの対応関係
2. MDファイルの限界とチーム開発で補うべきポイント
3. AI-DLCのExtension機構を使ってチームルールを自動適用する方法

---

目次

1. AI-DLCの基本概念とScrumとの対応
2. 公式ホワイトペーパーとGitHub MDファイルの対応関係
3. GitHub MDファイルはUnit単位の1セッション前提の実装
4. テストはBolt完了後すぐに実行する（Shift Left）
5. チームで使う際に補うべきガイドライン
6. Extension機構でチームルールを自動化する
7. 付録：Extensionファイル全文
8. 発展：Claude Multi-Agentで AI-DLCを自動化する

---

1. AI-DLCの基本概念とScrumとの対応

AI-DLCは公式ホワイトペーパーで定義された独自の用語体系を持っています。Scrum・DDDと対応させると理解しやすくなります。

AI-DLC概念	定義	Scrum/DDD対応
Intent	達成すべき最上位のゴール（ビジネス目標・機能・技術成果）	Epic / Feature
Unit of Work	Intentから派生した凝集性の高い作業単位。独立してデプロイ可能	Subdomain（DDD）/ Epic（Scrum）
Bolt	Unit内の最小イテレーション。1つ以上のUser Storiesを実装する	Sprint（Scrum）
Phase	Inception / Construction / Operations の3大区分	—
Stage	Phase内の個別作業ステップ（ALWAYS / CONDITIONAL）	タスク

知っておくべき注意点

AI-DLCを使っているとAIが生成する aidlc-state.md の中に 「Cycle 1」「Cycle 2」 といった表現が現れることがあります。これは複数回のワークフロー実行を区別するためにAIが自発的に使い始めた呼称であり、公式用語ではありません。

• 「Cycle」はAI-DLC公式用語ではありません。公式ホワイトペーパーにもGitHub MDにも定義されていません。混乱を避けるため、公式の Phase / Stage / Unit / Bolt の用語で整理し直すことを推奨します
• Bolt（Sprint相当）はGitHub MDファイルに明示的に実装されていません。MDファイルではPer-Unit Loopとして暗黙的に代替されています

---

2. 公式ホワイトペーパーとGitHub MDファイルの対応関係

AI-DLCの公式ホワイトペーパーに登場する概念が、GitHub MDファイル群（.aidlc-rule-details/）のどのファイルに対応するかを整理しました。

公式ホワイトペーパー概念	対応するMDファイル	実装内容
Intent	inception/requirements-analysis.md	Step 2 "Analyze User Request (Intent Analysis)" でゴール・スコープ・複雑度を分析・質問で明確化
Unit of Work	inception/units-generation.md common/terminology.md	Intentをuser storiesの論理グループに分解。疎結合・独立デプロイを原則とする
Bolt	inception/workflow-planning.md construction/code-generation.md	workflow-planningでBoltを計画、code-generationのPer-Unit Loopで実行
Mob Elaboration	inception/requirements-analysis.md inception/user-stories.md inception/application-design.md common/question-format-guide.md	チーム討議をAI-人間1対1に置き換え。AIが質問ファイル生成→ユーザーが[Answer]タグで回答
Mob Programming	construction/functional-design.md construction/nfr-requirements.md construction/nfr-design.md construction/infrastructure-design.md construction/code-generation.md	チーム実装をAI主導のPer-Unit Loopに置き換え。Unit単位で設計→コード生成を完結
Mob Testing	construction/build-and-test.md	全Unit完了後に一括実行。Unit/Integration/Performance/E2Eテスト手順を生成
Domain Design	construction/functional-design.md	インフラ非依存のビジネスロジック設計。エンティティ・ドメインモデル・ビジネスルールを定義
Logical Design	construction/nfr-requirements.md construction/nfr-design.md	NFR要件収集とアーキテクチャパターンへの落とし込み（CQRS・Circuit Breaker等）
Deployment Units	construction/infrastructure-design.md	論理コンポーネントを実インフラ（コンテナ・Lambda等）にマッピング
Risk Register	extensions/security/baseline/security-baseline.md	opt-inで有効化。各StageでOWASP等のセキュリティルールをブロッキング制約として強制
PRFAQ	対応なし	MDファイル群に相当するステージなし（公式ホワイトペーパーでもoptional扱い）
Phase	common/process-overview.md common/terminology.md	Inception / Construction / Operations の3区分を定義
Stage	common/terminology.md	ALWAYS-EXECUTE / CONDITIONALで実行判定
Brownfield対応	inception/workspace-detection.md inception/reverse-engineering.md	既存コード検出・アーキテクチャ文書化

---

3. GitHub MDファイルはUnit単位の1セッション前提の実装

White Paperでは、フェーズによってセッションの形が異なります。

フェーズ	AIセッション	形式
Inception（Mob Elaboration）	全員で1セッション共有	"single room with a shared screen led by a facilitator"
Construction（Mob Construction）	Unitごとに別セッションを並列稼働	"The Developer establishes the session with AI. AI prompts the developer to begin with the Unit assigned to them."

GitHub MDファイル群はConstruction Phaseのパターン（1Unit = 1AIセッション）を実装したものです。[Answer]: タグ・aidlc-state.md・ステージ承認など、すべての仕組みが1セッション = 1Unitを想定しており、複数セッション間の調整メカニズムは意図的に省略されています。

公式ホワイトペーパー（チーム向け）	GitHub MD（AIエージェント向け）
Mob Elaboration（集団討議）	AI質問ファイル + ユーザー回答
Mob Programming（集団実装）	AI主導のPer-Unit Loop
Mob Testing（集団テスト）	Build and Test Stage
Bolt（明示的Sprint単位）	Per-Unit Loopに暗黙統合
Intent（明示的ゴール定義）	requirements-analysisのIntent Analysisに統合

つまりチームで使う場合は、MDファイルが省略した部分を意識的に補う必要があります。次のセクションでその具体的な方法を解説します。

---

4. テストはBolt完了後すぐに実行する（Shift Left）

MDファイルの現状と問題点

construction/code-generation.md には次の記述があります：

"All code and tests generated (tests will be executed in Build & Test phase)"

MDファイルの実装では、テストコードの生成はUnit毎ですが、実行は全Unit完了後のBuild and Testフェーズにまとめられています。これは1Unit = 1AIセッションというMDファイルの設計上、全体フローの一貫性を優先してBolt単位のDefinition of Doneを省略したためです。

なぜBolt完了後すぐに実行すべきか

BoltはScrumのSprintに相当します。ScrumのDefinition of Doneでは「テストが通った状態」が完成条件です。したがってUnit Testは各Bolt完了直後に実行すべきです。

推奨フロー（Shift Left）:

Unit 1
  ├── Bolt 1（User Stories A, B実装）→ A, B のUnit Test実行 ✅
  ├── Bolt 2（User Stories C, D実装）→ A〜D のUnit Test実行 ✅
  └── Bolt n（完了）              → Unit 1 全Unit Test通過 = Unit完了
Unit 2
  ├── Bolt 1 → Unit Test実行 ✅
  └── ...
Build and Test
  └── Integration Test 実行（Unit間の結合テスト）
  └── E2E Test 実行（全体フロー）

Bolt毎 vs Unit毎：どちらが正しいか

	Bolt毎（推奨）	Unit毎
フィードバックの速さ	✅ 最速	△ Unit完了まで待つ
Shift Left度	✅ 高い	△ 中程度
実装の複雑さ	やや複雑	シンプル

Bolt毎が理論的に正しい。ただしUnitにBoltが1つしかない場合（小規模Unit）はBolt毎 = Unit毎となり実質同じです。

テスト種別ごとの実行タイミング

テスト種別	実行タイミング	理由
Unit Test	各Bolt完了後すぐ	Bolt内で完結。Definition of Doneの一部
Integration Test	依存Unitが揃い次第	Unit間の結合が必要
E2E Test	全Unit完了後	全体フローが必要
Performance Test	全Unit完了後	システム全体の負荷特性が必要

---

5. チームで使う際に補うべきガイドライン

GitHub MDファイルは1Unit = 1AIセッション前提の実装のため、複数チームが各自のUnitで並列AIセッションを稼働させる際は以下のガイドラインで補完します。

5.1 チームとUnitの対応

原則: 1チーム = 1Unit（または複数Unitのオーナーシップ）

UnitはDDDのSubdomain相当であり疎結合を保証しているため、チーム間の干渉を最小化できます。

Product Owner
  └── Intent 定義・承認

Team A  →  Unit 1（例: 認証サービス）
Team B  →  Unit 2（例: 注文サービス）
Team C  →  Unit 3（例: 通知サービス）

チーム分割の基準:

基準	説明
ビジネスドメイン境界	DDD Subdomain単位で分割（推奨）
独立デプロイ可能性	他チームのリリースを待たずにデプロイできるか
データオーナーシップ	各チームが自分のデータストアを所有する
依存方向	循環依存を禁止。依存は一方向のみ

5.2 Inception Phase（Mob Elaboration）のチーム運用

MDファイルではAI-人間1対1ですが、チームではMob Elaborationとして全員参加で実施します。

Mob Elaboration セッション構成:
  参加者: Product Owner + 全開発チーム + AI
  形式:   大画面1つ・AIがファシリテート
  目的:   Intent → User Stories → Units への分解を全員で合意

AIの役割:
  - 質問を生成し、曖昧さを排除
  - User Stories を Units に分類提案
  - 各Unitの依存関係・境界を可視化

人間の役割:
  - AIの提案を検証・修正
  - ビジネス制約・優先度を判断
  - Unit境界の最終決定

成果物（Inception Phase終了時）:

• requirements.md — Intent・機能/非機能要件
• user-stories/stories.md — User Stories + 受け入れ条件
• application-design/unit-of-work.md — Unit定義・責務
• application-design/unit-of-work-dependency.md — Unit間依存マトリクス
• application-design/unit-of-work-story-map.md — Unit別Story割り当て

5.3 Construction Phase（Mob Programming）のチーム運用

各チームが担当Unitを並列で進める。ただし以下の同期ポイントを設けます。

並列実行モデル:

Team A: Unit 1 ──[Bolt 1]──[Bolt 2]──[Unit Test ✅]──────────────────────┐
Team B: Unit 2 ──[Bolt 1]──[Bolt 2]──[Bolt 3]──[Unit Test ✅]────────────┤→ Integration Test → E2E
Team C: Unit 3 ──[Bolt 1]──[Unit Test ✅]────────────────────────────────┘

各チームの Mob Programming セッション構成（1セッション = 1Bolt）:

流れ:
  1. AIが Domain Design を提案 → チームが検証・修正
  2. AIが Logical Design（NFR対応）を提案 → チームが承認
  3. AIがコード + Unit Testを生成 → チームがレビュー
  4. Unit Test実行 → 全Pass = Bolt完了（Definition of Done）

チーム間インターフェース管理:

ルール	内容
Contract First	Unit間のAPIインターフェースをInceptionで先に定義
Consumer-Driven Contract	呼び出し側チームがテストシナリオを定義
Mock境界	他UnitはMockで代替し、Unit Testを独立実行可能にする
変更通知	インターフェース変更は依存チームに事前通知必須

5.4 テスト戦略（チーム向け）

注意: MDファイルにはContract Testの記述がありませんが、チーム開発では必須です。Unit間のインターフェース破壊を早期に検知するために導入してください。

テスト種別	実行者	タイミング	目的
Unit Test	各チーム	各Bolt完了後（Definition of Done）	Unit内の正確性保証
Contract Test	依存チーム間	依存Unitが揃い次第	インターフェース合意の検証
Integration Test	全チーム合同	全Unit完了後（Mob Testing）	Unit間の結合動作確認
E2E Test	QA / 全チーム	Integration Test通過後	ユーザーシナリオ全体の確認
Performance Test	全チーム合同	E2E通過後（必要な場合）	NFR達成確認

5.5 Bolt計画（Sprint計画相当）

Boltは0.5〜2日単位が理想です（公式ホワイトペーパーの「時間または日数で測定」より）。

Bolt計画の手順:
  1. Unit内のUser Storiesを確認（unit-of-work-story-map.md）
  2. AIがBolt単位への分割を提案
  3. チームが見積もりを調整（ストーリーポイント不要・完了可能量で判断）
  4. 各BoltのDefinition of Done（Unit Test Pass）を確認
  5. 開始

Boltのサイズ	目安	判断基準
小さすぎ	数時間以下	オーバーヘッドが大きい
適切	0.5〜2日	AIとのセッション1回で完結できる
大きすぎ	3日以上	さらにBoltを分割すべき

5.6 チーム向け AI-DLC 全体フロー

【Inception Phase】── 全チーム合同（Mob Elaboration）
  Product Owner が Intent を提示
  AI が Intent → User Stories → Units に分解提案
  全チームで検証・合意・Unit担当割り当て
  ↓
【Construction Phase】── チーム並列（Mob Programming per Unit）
  各チームが担当UnitをBolt単位で実装
  各Bolt完了 → Unit Test実行（Definition of Done）
  全Unit完了 → Contract Test実行
  ↓
【Mob Testing】── 全チーム合同
  Integration Test → E2E Test → Performance Test（必要時）
  ↓
【Operations Phase】── デプロイ・監視

---

6. Extension機構でチームルールを自動化する

セクション5のガイドラインを毎回手動で確認するのは現実的ではありません。AI-DLCのExtension機構を使えば、これらのルールをワークフローに組み込み、AIが自動的にチェックするようにできます。

6.1 Extensionとは

extensions/ ディレクトリにルールファイルを配置することで、AI-DLCの各ステージにカスタム制約を注入できる仕組みです。

ファイル	役割
<name>.opt-in.md	Requirements Analysis でユーザーに表示するオプトイン質問
<name>.md	実際のルール群（ユーザーが有効化した後に読み込まれる）

*.opt-in.md がない場合は常時強制適用されます。

6.2 チームガイドライン Extensionの配置

.aidlc-rule-details/extensions/team-guidelines/
├── team-guidelines.opt-in.md   # "チーム開発か？" の Yes/No 質問
└── team-guidelines.md          # TEAM-01〜TEAM-08 のルール群

6.3 実装済みルール一覧

Rule ID	タイトル	対応ガイドライン
TEAM-01	Unit Ownership Assignment	5.1 チームとUnitの対応
TEAM-02	Unit Boundary Alignment with DDD Subdomains	5.1 チーム分割の基準
TEAM-03	Contract-First Interface Definition	5.3 チーム間インターフェース管理
TEAM-04	Consumer-Driven Contract Tests	5.4 テスト戦略
TEAM-05	Mob Elaboration for Inception Phase	5.2 Inception Phaseのチーム運用
TEAM-06	Per-Bolt Unit Test Execution (Definition of Done)	4. Unit Test Shift Left + 5.5 Bolt計画
TEAM-07	Parallel Construction with Synchronization Gates	5.3 並列実行モデル
TEAM-08	Interface Change Notification	5.3 変更通知

6.4 他プロジェクトへの適用手順

1. team-guidelines.opt-in.md と team-guidelines.md を対象プロジェクトの .aidlc-rule-details/extensions/team-guidelines/ にコピー
2. CLAUDE.md の Extension Loading セクションにより、次回 AI-DLC 起動時に自動検出される
3. Requirements Analysis で "チーム開発か？" と聞かれたら A) Yes を選択
4. 以降、各ステージで TEAM ルールがブロッキング制約として強制される

6.5 ルール形式（公式フォーマット）

Extensionのルールは以下の形式で記述します。

## Rule <PREFIX-NN>: <Title>
**Rule**: MUST / MUST NOT / SHOULD ...（制約の本文）

**Verification**:
- チェック項目（準拠 / 非準拠 で判定）

• **Rule**: は MUST / MUST NOT / SHOULD で始まる強制表現
• **Verification**: はステージ完了時に AI が評価するチェックリスト
• 非準拠はブロッキング（"Continue to Next Stage" を提示しない）

---

7. 発展：Claude Multi-AgentでAI-DLCを自動化する

Section 5〜6 では「人間チームがUnit単位に分かれて並列AIセッションを動かす」モデルを解説しました。これをさらに発展させると、Claude自身がOrchestratorとなり、Sub-Agentを束ねてAI-DLCを自動実行する構成が可能です。

8.1 人間チームモデルとMulti-Agentモデルの対応

役割	人間チームモデル	Claude Multi-Agentモデル
調整役	Product Owner / Tech Lead	Orchestrator Claude
Unit担当	Human + Claude Session	Sub-Agent Claude（1Unit = 1Sub-Agent）
セッション間通信	口頭・Slackなど	Agent tool / SendMessage
状態管理	人間が aidlc-state.md を管理	Orchestratorが一元管理

構造は同型です。TEAM-01〜08 が「並列人間セッションの調整ルール」であったのと同様に、**MAGENT-01〜06 は「並列Claudeセッションの調整ルール」**です。

8.2 Multi-Agent Extension（MAGENT-01〜06）

extensions/multi-agent/ Extension を有効にすると、以下のルールが適用されます。前提として Team Guidelines Extension（TEAM-01〜08）が有効であることが必要です。

Rule ID	タイトル	概要
MAGENT-01	Orchestrator Role Definition	Orchestratorを1つ指定。Construction Phaseは直接実行せずSub-Agentへ委譲
MAGENT-02	Unit Assignment by Orchestrator	Sub-Agent起動前にUnit定義・Contract・Storiesを含むブリーフィングを渡す
MAGENT-03	Shared Resource Write Control	aidlc-state.md はOrchestrator専用。audit.md はUnit名プレフィックスで書き分ける
MAGENT-04	Sub-Agent Scope Isolation	isolation: "worktree" で各Sub-AgentをUnit単位に物理隔離する
MAGENT-05	Sub-Agent Completion Contract	完了時に構造化メッセージ（Unit Test結果・インターフェース変更）を返す
MAGENT-06	Inter-Agent Communication Protocol	Sub-Agent同士の直接通信禁止。全通信はOrchestratorを経由する

8.3 実行フロー

【Inception Phase】── Orchestrator Claude が単独実行
  Intent → Requirements → Units Generation → Contract確定
  ↓
【Construction Phase】── Sub-Agent を並列起動（TEAM-07 ゲート）
  Orchestrator: Agent({ isolation: "worktree", prompt: <briefing> })
    ├── Sub-Agent A → Unit 1（Unit Test完了まで実行）
    ├── Sub-Agent B → Unit 2（Unit 1完了後、または依存なければ並列）
    └── Sub-Agent C → Unit 3（Unit 1完了後）
  全Sub-Agent完了 → Orchestratorが completion contract を検証
  ↓
【Build and Test】── Orchestrator が統合テストを指示
  Integration Test → E2E Test

8.4 TEAM ルールとの相互作用

Multi-Agent 構成では TEAM ルールが「人間の手続き」から「技術的制約」に昇格します。

TEAM Rule	人間チームモデルでの意味	Multi-Agentモデルでの実装
TEAM-03 Contract-First	Inception でチーム合意	Orchestratorブリーフィングに Contract を埋め込む（起動前確定）
TEAM-07 Sync Gates	全Unit Test通過まで統合テスト待機	Orchestratorが completion contract を全件確認後にのみ統合テストを開始
TEAM-08 Interface Change	変更時に依存チームへ通知	Sub-Agentが interface_changes フィールドで報告 → Orchestratorが後続Sub-Agentのブリーフィングを更新

8.5 他プロジェクトへの適用手順

1. extensions/multi-agent/ ディレクトリをプロジェクトにコピー
2. Team Guidelines Extension も有効にする（必須前提）
3. Requirements Analysis で "Multi-Agent AI-DLC を使うか？" に A) Yes を選択
4. Orchestrator Claude が Inception Phase を単独実行し、Construction Phase で Sub-Agent を起動する

---

8. 付録：Extensionファイル全文

実際のExtensionファイルを以下に掲載します。コピーして使用してください。

team-guidelines.opt-in.md

# Team Guidelines — Opt-In

**Extension**: Team Guidelines

## Opt-In Prompt

The following question is automatically included in the Requirements Analysis clarifying questions when this extension is loaded:

## Question: Team Development Guidelines
Is this project developed by a team (multiple developers or multiple squads)?

A) Yes — enforce TEAM rules as blocking constraints (recommended for multi-developer or multi-squad projects)
B) No — skip TEAM rules (suitable for solo development, PoCs, or single-developer prototypes)
X) Other (please describe after [Answer]: tag below)

[Answer]: 

team-guidelines.md

# Team Development Guidelines

## Overview
These rules supplement the AI-DLC GitHub MD files (designed for 1 Unit = 1 AI session, as used in Mob Construction) with coordination constraints derived from the official White Paper methodology. They address the gap that arises when multiple teams run parallel AI sessions for their respective Units — enforcing Contract-First interfaces, ownership boundaries, and synchronization gates across those sessions.

**Enforcement**: At each applicable stage, the model MUST verify compliance before presenting the stage completion message.

### Blocking Finding Behavior
A **blocking TEAM finding** means:
1. The finding MUST be listed under a "Team Guidelines Findings" section with the TEAM rule ID
2. The stage MUST NOT present "Continue to Next Stage" until resolved
3. The finding MUST be logged in `aidlc-docs/audit.md`

---

## Rule TEAM-01: Unit Ownership Assignment

**Rule**: Each Unit of Work MUST have exactly one designated team owner. A team MAY own multiple Units, but each Unit MUST NOT have multiple owning teams.

**Verification**:
- `application-design/unit-of-work.md` includes a team ownership column or section for each Unit
- No Unit is listed without a named team owner
- No Unit is assigned to more than one owning team

---

## Rule TEAM-02: Unit Boundary Alignment with DDD Subdomains

**Rule**: Unit boundaries MUST align with DDD Subdomain boundaries. Each Unit MUST be independently deployable — it MUST NOT share a data store or runtime process with another Unit without an explicit justification documented in the design.

**Verification**:
- Each Unit owns its data store exclusively (no cross-Unit shared databases)
- Unit dependencies are unidirectional (no circular dependencies between Units)
- `application-design/unit-of-work-dependency.md` exists and shows a directed acyclic dependency graph

---

## Rule TEAM-03: Contract-First Interface Definition

**Rule**: All inter-Unit interfaces (APIs, events, messages) MUST be defined during the Inception Phase, before any team begins Construction. Interface contracts MUST be agreed upon by both the producer team and the consumer team.

**Verification**:
- `application-design/unit-of-work.md` includes interface definitions for each Unit boundary
- Both producer and consumer teams are identified for each interface
- Construction MUST NOT begin for any Unit until all its incoming/outgoing interfaces are contractually defined

---

## Rule TEAM-04: Consumer-Driven Contract Tests

**Rule**: For each inter-Unit interface, the consumer team MUST define Contract Tests. Contract Tests MUST be executed whenever the producer Unit's interface changes.

**Verification**:
- `build-and-test/` includes contract test instructions for each inter-Unit interface
- Contract tests are owned by the consumer team (not the producer)
- The producer team MUST run consumer-provided contract tests before declaring a Unit complete

---

## Rule TEAM-05: Mob Elaboration for Inception Phase

**Rule**: The Inception Phase (Requirements Analysis through Units Generation) MUST be conducted as a Mob Elaboration session with all teams present. No team MAY begin Construction on a Unit until all teams have participated in Inception and the Unit boundaries have been collectively agreed upon.

**Verification**:
- `aidlc-docs/audit.md` records participation of all teams in the Inception Phase
- `application-design/unit-of-work.md` shows sign-off or agreement confirmation
- Construction MUST NOT start if any team was absent from the Inception session without documented proxy approval

---

## Rule TEAM-06: Per-Bolt Unit Test Execution (Definition of Done)

**Rule**: Each Bolt MUST NOT be considered complete until all Unit Tests for the stories implemented in that Bolt pass. Unit Tests MUST be executed immediately after Bolt implementation — not deferred to the Build and Test phase.

**Verification**:
- Code Generation plan checkboxes include a Unit Test execution step after each Bolt
- Build and Test phase Integration Tests rely only on Units whose Unit Tests are fully passing
- No Bolt is marked `[x]` complete in `aidlc-state.md` without a corresponding test-pass confirmation in `audit.md`

---

## Rule TEAM-07: Parallel Construction with Synchronization Gates

**Rule**: Teams MAY develop their Units in parallel. However, Integration Testing MUST NOT begin until ALL Units have passed their Unit Tests. E2E Testing MUST NOT begin until Integration Tests pass.

**Verification**:
- `build-and-test/build-and-test-summary.md` documents the synchronization sequence: Unit Tests → Contract Tests → Integration Tests → E2E Tests
- No Integration Test references a Unit that has not yet completed Unit Testing
- `aidlc-state.md` tracks per-Unit completion status before Integration Test execution

---

## Rule TEAM-08: Interface Change Notification

**Rule**: When a producer team changes an inter-Unit interface (API contract, event schema, message format), all dependent consumer teams MUST be notified before the change is merged. The notification MUST be logged in `aidlc-docs/audit.md`.

**Verification**:
- `audit.md` includes an entry for each interface change with: change description, producer Unit, affected consumer Units, and notification confirmation
- Consumer teams have reviewed and updated their Contract Tests before the producer change is merged