stack-pull-requests

スタック型プルリクエスト

スタック型プルリクエストは、垂直方向のストーリー分割の代わりではなく、任意のブランチ、レビュー、統合のトポロジーとして使用します。

各垂直実装スライスは、デフォルトでトランクを対象とする1つのPRにします。順序付けられたブランチによってレビューの質が大きく向上する場合、または下位のレビューがマージされる前に、進化し続ける同じベースライン上で作業を継続できる場合に限り、スタックを使用します。ただし、テスト可能性、デプロイ可能性、理解しやすさを損なわないことが条件です。

GitHub のネイティブなスタック型PRサポートと公式の gh-stack 拡張機能は、限定プレビュー機能であり、リポジトリで有効になっていない場合があります。GitHub の正確な動作、コマンドの由来、またはこれらのルールの根拠が重要な場合は、references/source-notes.md を読み込んでください。プレビュー固有のコマンドに依存する前に、最新の公式ドキュメント、リポジトリへのアクセス、gh stack --help を確認してください。

3つの単位を分けて考える

単位	問い	担当	ルール
バックログストーリー	どのような範囲の能力が価値や学びをもたらしますか？	story-splitting	垂直に保ち、デリバリー計画の前に受け入れ範囲を確定します
実装スライス	そのストーリーを前進させ、正常な状態を保つ最小の垂直方向の増分は何ですか？	planning	宣言済みの前提条件が満たされたら、安全にマージしてリリースします。デフォルトでは1つのPRを使用します
PRの境界	計画された実装作業を、レビューしやすいようにどのようにまとめますか？	このスキル	通常はスライス全体を1つのPRで扱いますが、代わりに1つのスライス内の依存レイヤーを扱うこともあります

シーケンスは作業順序を表し、スタックはブランチの依存関係を表します。スタック内の下位PRは個別にマージできる場合がありますが、上位PRはすべて直下のブランチを対象とします。したがって、複数の垂直スライスが自動的に独立したPRになるわけでも、スタックになるわけでもありません。

各スライスがトランクを対象にでき、安全な順序でブロックも作業の重複もなくマージできる場合、または次のブランチが前のブランチのマージ後にのみ開始される場合は、独立したPRを使用します。厳密な系譜（上位のスライスが下位のスライスを必要とする場合）またはフローの系譜（スライスはそれぞれ独立して完了できるものの、下位のレビューとマージを待たずに、同じ進化するベースライン上で上位の作業を開始し、下位から順に固定された順序で反映しても問題ない場合）のいずれかに当てはまる場合は、スライスをまたぐスタックを使用します。1つの固定されたスライスが効果的なレビューには大きすぎる場合は、スライス内のスタックを使用します。

手戻りはスタックの実質的な利点です。下位ブランチの修正は担当するPR内にとどまり、スタックツールによって上位へ伝播されます。ただし、保険として無料で使えるわけではありません。変更された上位ブランチはすべてリベース、プッシュ、再確認が必要であり、競合が発生したり、古くなった承認が無効になったりする可能性があります。依存する上位の作業がすでに進行している間に、下位の境界で反復が発生しそうな場合は、それを利点として捉えてください。以前の決定がいつか変更されるかもしれないというだけで、ブランチの依存関係を作り出してはいけません。

スライス内のPRレイヤーは、子ストーリーでも実装スライスでもなく、受け入れ範囲を追加してはいけません。スライスをまたぐスタックのメンバーは、計画された完全なスライスとその受け入れ基準を担当できますが、承認済みのスライスの範囲外に新たな範囲を作ってはいけません。

次の順序で進めます。

1. リクエストに複数の顧客成果、経路、役割、または品質レベルがまだ含まれている場合は、story-splitting を読み込みます。
2. 垂直方向の子ストーリーを1つ選びます。
3. planning を読み込み、その垂直実装スライス、依存関係、クラス、エビデンス、最終的な義務を定義します。
4. 1つのスライスにレビュー用のレイヤーが必要な場合、または厳密な系譜もしくはフローの系譜を持つ連続したスライスをまとめて進行させる場合に、このスキルを使用します。
5. レビュー、リードタイム、修正の振り分けによる利点が、固定された順序と連鎖的なコストを正当化しない場合は、スライスを独立したトランクベースのPRとして維持します。
6. 受け入れ基準、リリース上の制約、または中間段階の安全性が不明確な場合は、find-gaps を使用します。

database → API → UI → tests をバックログストーリーにしてはいけません。これらの境界が選択した実装スライスのレビューに役立つ場合は、依存するPRレイヤーとして説明し、リリース状態を明確に保ちます。

独立した PR にするか、スタックにするか

次のすべてに該当する場合に限り、スタックを選択してください。

• 対象範囲が、計画済みの単一のスライス、または意図的に順序付けられた連続する垂直スライスもしくは縮小の移行に限られています。
• 具体的な利点が少なくとも一つあります。変更をまとめることで差分を絞り込めるか、下位のレビューとマージが完了する前に、後続の順序付けられた作業を進める必要があります。
• ブランチには意図的な一方向の系譜があります。つまり、ハードな依存関係があるか、同じ進化中のベースライン上で下位のマージ前に上位の作業を実際に開始する意図的なフローの系譜があり、下位から順に固定して取り込む方法を許容できます。
• 各 PR は、実用上可能な限りスライス全体を担当するか、下位レイヤーと自身の差分から理解できる、スライス内の一貫したレイヤーを担当します。
• 各 PR の境界で、累積したブランチを正常な状態に保てます。ビルド可能で、検証済みであり、安全にデプロイできるか、明示的に休止状態にできます。
• 上位の作業をすべて中止した場合でも、下位の各スライスは有用かつ安全にマージできます。
• 想定されるカスケード／リベースのコストが、絞り込んだレビュー、リードタイム、修正の担当範囲を明確にする利点を下回ります。
• リポジトリとチームが、依存するブランチ、カスケードするリベース、ネイティブなプレフィックス／グループマージ、または手動の下位から順のマージに対応できます。
• 想定するスタックの仕組みで、必要な CI とリポジトリのルールをすべての PR に適用できます。

次のいずれかに該当する場合は、独立したトランクベースの PR を優先してください。

• 変更全体が、すでに短時間で一貫性のあるレビューを行える規模です。
• 分割した各 PR をトランクを対象にして、他の PR を取り込まずに、独立してマージ、順序変更、または破棄できます。
• 有用な作業やフィードバックを妨げることなく、前提となる PR のマージまで次の依存スライスを待たせられます。
• 分割すると、テストや根拠が、それらの保護対象である動作や契約から切り離されます。
• 各レイヤーを判断するために、レビュー担当者がスタック全体を理解する必要があります。
• 中間段階でマージすると、安全でないスキーマ、契約、ブリッジ、または未完成の機能が公開されます。
• 変更が十分に横断的で、各レイヤーが同じコードを繰り返し変更することになります。
• 提案された境界が、ファイル、アーキテクチャ階層、作業フェーズ、またはチームの担当範囲だけです。
• 提案されている唯一の利点が、以前の判断が変わった場合に便利かもしれないという推測です。
• リベースと CI のやり直しのコストが、差分を小さくすることで得られる節約を上回ります。

2 つの反実仮想を検討する

1. トランクの反実仮想： 提案する各 PR は、現行のトランクから開始し、他の PR を取り込まずにマージ、順序変更、または破棄できますか？ できない場合は、ほかの条件も満たすことを前提に、ハードな系譜のスタックを使ってください。
2. フローの反実仮想： できる場合、下位の PR がマージされる前に、上位の作業を同じ進行中のパス上で実際に開始しますか？ 下位から順に固定して取り込む方法を許容できますか？ 待ち時間の短縮や、下位の担当者に修正を割り当てられる利点は、スタックの組み直しと再レビューの負担を上回りますか？ すべて「はい」なら、フローの系譜を持つスタックが有効です。それ以外の場合は、独立した PR を使ってください。

反射的にスタックを組まないでください。判断を一文で記録します。

Delivery: single PR — the end-to-end change is already one focused review.

または：

Delivery: 3-PR stack — the dormant migration, tested repository adapter, and
fixed sign-in slice form one-way dependencies with meaningful verification.

または：

Delivery: 3-PR flow-lineage stack — each vertical slice is known-good in order,
upper work starts now on the same evolving path, and lower-first landing is acceptable.

コードを書く前にスタックを設計する

1. ストーリーとスタックの対象範囲を固定する

選択したストーリーの担当者と成果を記述し、次の内容を記録します。

• スタックが単一のスライス内に収まるか、連続する複数のスライスにまたがるか
• 含めるすべてのスライス、そのトリガー、観測可能な成果または維持すべき契約、本番環境への経路、受け入れの根拠、分類、リリース上の制約
• スタックが対象とする、承認済み範囲の固定された全体

ストーリーに複数の顧客向け機能が記述されている場合は、story-splitting に戻ってください。複数のスライスを同じスタックで扱う場合でも、planning では、垂直方向の各成果または縮小の移行をそれぞれ独立したスライスとして維持してください。スライスをまたぐスタックでは、各 PR が依存関係の順に、承認済みの受け入れケースを追加できます。スライス内のスタックでは、PR のレイヤーを決める前に、選択したスライスの範囲を確定してください。

縮小作業では、スタックへの参加によって台帳やゲートが不要になるわけではありません。置き換えられる仕組みや追加されたブリッジが残っている限り、移行によって純減を主張することはできません。仕組みのゲートを満たし、固定された最終状態を主張できるのは、最終縮小スライスだけです。

2. 系譜グラフを描く

ハードな依存関係と、意図的なフローの系譜を特定します。これらを慣例的なビルド順序と区別してください。「通常はバックエンドを先に構築する」は根拠になりません。「レビューが進行中のこの進化し続けるベースライン上で、次に承認されたスライスに今すぐ着手できる」は根拠になり得ます。

境界は次の順で優先します。

1. 垂直スライス全体 — 各 PR が承認済みの既知の良好なスライスを 1 つ担当します。上位の作業にはハードな依存関係または意図的なフローの系譜があり、下位のレビューと並行して進みます。
2. テスト可能なパスの増分 — 別のスライスに属する受け入れケースを追加せずに、各 PR が同じ固定スライスを前進させます。
3. 動作を維持する準備 — 後続の変更をレビュー可能にする、焦点を絞ったリファクタリングまたは安全性の特性評価です。
4. 後方互換性のある有効化 — 移行、コントラクト、またはインフラストラクチャの変更で、検証済みかつ休止状態にあり、次の PR で直接使用されます。
5. リスクの分離 — セキュリティ、データ、またはパフォーマンスに関わる変更で、専門家による集中的なレビューに値します。
6. レビュアーの専門知識 — サブシステムの境界です。ただし、スタックの残りの部分についての長い説明がなくても PR が成り立つ場合に限ります。

次のことは避けてください。

• すべてのテストを最上位の PR に含める
• 推測に基づく基盤や抽象化
• 「同じフォルダー内のファイル」であることしか根拠のない境界
• 上位の境界がないと、コンパイル、安全な移行、CI の通過、または担当者のいない橋渡しの解消ができない下位境界
• 担当する下位境界を修正せず、上位の境界で重複した修正を行う
• カスケードとレビューの負荷が支配的になる長いスタック

境界の数や行数に普遍的な上限はありません。各 PR が 1 つの概念を扱い、短時間で読める最小限のスタックにしてください。隣接する 2 つの境界で同じ説明や根拠が必要なら、まとめてください。

3. 境界の種類に応じて検証を割り当てる

GitHub のチュートリアルではテストを最終レイヤーとして説明していますが、この順序をこのワークフローにそのまま適用しないでください。

本番環境の動作を変更する境界の場合：

• コードを変更する前に、tdd、testing、該当する場合は refactoring のガイダンスを読み込みます。
• その境界が担当する動作について、高速な RED-GREEN-REFACTOR の反復に従います。
• コントラクト、移行、単体、統合、または UI のテストは、その動作を担当する最初の境界に含めます。
• それ以外の点で境界が PR の準備完了状態になったら、mutation-testing を読み込み、意味がある場合は親に対して累積スコープのゲートを 1 回実行するか、相応の代替根拠を示して N/A を記録します。

本番環境の動作を維持する境界の場合：

• 該当するテストと refactoring のガイダンスを読み込みます。保護が不十分な場合は、finding-seams と characterisation-tests も読み込みます。
• 変更対象のコンシューマーパスについて、動作維持を示すテスト合格の根拠を確立します。
• 動作を変更せずにリファクタリングし、該当する集中的／影響範囲のテストを合格状態に保ちます。
• PR の準備が整った時点で、同じ境界ごとに 1 回のミューテーションテストまたは代替根拠のゲートを実行します。構造上存在しないミュータントをでっち上げないでください。

削減への移行または最終削減の境界では、選択したスライスの reduce-system-complexity 台帳、維持されるコントラクト、橋渡しの担当と削除の義務、および動作／メカニズムのゲートの状態も維持します。

ドキュメント、リリースメタデータ、設定、または本番環境に影響しない機械的な変更では、境界に誤りがあれば失敗する最小限の実行可能な検証を使い、適切な場合はミューテーションテストを N/A として記録します。

PR の各境界で、リポジトリが必須とするビルド、Lint、型、セキュリティ、および watch モードではない完全なテストチェックを実行し、累積ブランチを検証します。上位の PR には下位の境界がすべて含まれるためです。

最上位の境界では、含まれるすべてのスライスについて、累積的な受け入れ例または最終ゲートを検証する必要があります。スタック全体を対象とするテストを追加しても構いませんが、ある動作の最初のテストは、その動作を導入する PR に含める必要があり、後続のスタックメンバーに回してはいけません。

4. スタック化する前に CI のトポロジーを確認する

PR を作成する前に、PR が GitHub ネイティブのスタックとしてリンクされるのか、リンクされない依存ブランチのチェーンを形成するだけなのかを記録してください。求められる成果がスタックの場合、GitHub とリポジトリのポリシーが対応していれば、ネイティブの仕組みをデフォルトで使用してください。リンクされないチェーンは、ユーザーまたはリポジトリが明示的に選択した場合、またはネイティブのサポートが利用できない場合に限り使用してください。そのうえで、ワークフロー、ルールセット、必須ステータスコンテキスト、マージキューを確認します。

• GitHub ネイティブでリンクされたスタックの場合、GitHub はスタックの trunk に対して、Actions、ブランチ保護、必須チェック、レビュー、CODEOWNERS、コードスキャンを評価します。その trunk を対象にフィルタリングされた pull_request ワークフローは、すべてのスタック PR で実行されます。上位の PR が機能ブランチを直接対象にしているというだけで、ワークフローの変更を必須にしないでください。
• リンクされていない依存 PR、または同等のスタックメタデータを持たないツールでは、通常の直近のベースブランチに対するセマンティクスが適用されます。機能ブランチをベースとする PR が必須ワークフローを実行することを確認してから、それらに依存してください。
• 必須ステータスが、必要なすべての PR 境界で生成されることを確認してください。
• リポジトリがマージキューを使用している場合、必須ワークフローが merge_group に対応していることを確認してください。
• 各境界で実行する対象を絞ったチェックと、最上位で実行する累積チェックまたはエンドツーエンドチェックを決めてください。スタック化を容易にするために、必須のマージチェックを弱めないでください。
• リベースによって再実行されるワークフローと、既存の影響範囲テストやキャッシュの動作を考慮してください。

依存ブランチと機能ブランチをベースとする PR は、どちらの仕組みにも必要ですが、それだけでは GitHub のリモートスタックオブジェクトの存在を証明できません。リンクされていないチェーンを GitHub ネイティブのスタックとして説明しないでください。

選択したスタックの仕組みでは、リスクの高い CI 変更なしに各境界で信頼できる必須チェックを実施できない場合は、PR を 1 つにすることを優先してください。

5. 中間状態を安全にする

下位の PR は、次のいずれかでなければなりません。

• 単独でデプロイでき、実用性がある
• 動作を維持している
• 後方互換性があり、休止状態にある
• フラグで非表示になっている
• 独立して検証可能な削減の遷移であり、管理者が明確で範囲が限定されたブリッジを備え、削減が完了したという主張を先走って行わない
• 承認済みの連続したグループの一部としてのみマージすることを意図しており、その理由が明記されている

呼び出し元を破壊する、利用できないスキーマを必要とする、セキュリティを弱める、または不完全な動作を公開する中間状態は、決してマージしないでください。後方互換性を保ちながら拡張してから縮小する変更は、通常、別々のスタックにする必要があります。すべての利用側が移行するまで、クリーンアップを待つ必要があるためです。

デリバリープランを作成する

同一スライス内のスタックの場合は、選択した実装スライスの下にこのセクションを追加してください。スライスをまたぐスタックの場合は、対象に含める最初のスライスの直前に共通のマップを 1 つ配置し、対象に含める各スライスからそのマップを参照してください。

#### Delivery Shape

**Mode**: Single PR | Stacked PRs
**Stack scope**: Intra-slice | Cross-slice
**Reason**: [Why this shape improves review without weakening delivery]
**Story scope**: [Fixed parent story; PR boundaries must not expand it]
**Included slices**: [One fixed slice, or the exact contiguous slice sequence]
**Done when**: [Acceptance criteria or terminal gates for all included slices]

| # | Ownership unit | PR boundary | Base | Owns | Depends on | Verification | Release state |
|---|---|---|---|---|---|---|---|
| 1 | [whole slice or intra-slice layer] | [focused title] | [repository default branch] | [one coherent change] | — | [tests/evidence/checks] | [deployable/dormant/etc.] |
| 2 | [whole slice or intra-slice layer] | [focused title] | [boundary 1 branch] | [one coherent change] | [specific contract or deliberate flow lineage] | [tests/evidence/checks] | [...] |

### Whole-stack gate

- [ ] Every included slice's acceptance examples, conserved contract, and applicable terminal gates pass cumulatively at the top
- [ ] Every PR boundary's focused and cumulative checks pass
- [ ] No behavior waits beyond its owning PR for its first test
- [ ] Every PR-ready boundary has current mutation or alternate evidence for its focused review scope
- [ ] Intermediate merge and release states are explicit and safe
- [ ] Reduction ledger, bridge, and mechanism-gate obligations remain accurate when applicable
- [ ] Native stack-trunk or unlinked immediate-base CI semantics are identified; required statuses and `merge_group` run where applicable
- [ ] When native stacking was selected, GitHub's remote stack object exists and its trunk and bottom-to-top entries match this plan; PR base refs alone are not proof
- [ ] Review sequence is bottom-up for lineage-sensitive boundaries; independent specialist reviews may run in parallel
- [ ] Merge includes every required lower PR: native all-or-nothing prefix/group, or manual bottom-up order

各 PR 境界について、次の項目も記録してください。

• レビューで焦点を当てる質問
• 含める範囲と除外する範囲
• 不必要に実装方法を指定せず、関連しそうなファイルまたはサブシステム
• 必要な専門分野のレビュアーがいれば、そのレビュアー
• その PR が担う動作、維持する契約、または機械的な変更についての受け入れ基準と検証方法

リポジトリのブランチ命名規則に従ってください。ユーザーが許可していない限り、ブランチの作成、コミット、プッシュ、PR の提出、共有ブランチのリベース、マージは行わないでください。

下から上へ構築する

各PRの境界について、次の手順を実行します。

1. コミット済みで、正常動作が確認されている最上位のブランチから始めます。
2. コードを書く前に、その境界の受け入れ条件または維持すべき契約をユーザーに確認します。
3. 該当する実装ルートを完了し、対象を絞ったチェックと影響を受けるチェックをすべて成功させます。
4. その境界が他の点ではPRを出せる状態になったら、変更または代替エビデンスのゲートとリポジトリのチェックを完了します。
5. trunk ではなく、親ブランチと差分を比較してセルフレビューします。
6. 上位の境界に属する作業を取り除きます。
7. 対象を絞った差分と検証エビデンスを提示します。
8. ユーザーとリポジトリのワークフローから許可された場合に限り、コミットします。
9. 現在の境界がコミット済みで正常動作が確認されてから、次のブランチを作成します。スタックを拡張するのにレビュー承認は必要ありません。

リポジトリでプレビューアクセスが可能で、拡張機能がすでにインストールされているか、インストールが許可されており、リポジトリのポリシーにも合致する場合に限り、公式の gh stack コマンドを優先します。記憶に頼らず、現在のヘルプを確認してください。ローカルで追跡されているネイティブスタックは gh stack submit で送信します。ブランチやPRを別のツールで作成した場合は、現在ドキュメントに記載されているリンクコマンドを使用します。それ以外の場合は、既存の Git／GitHub ツールを使って、明示的にリンクされていない依存チェーンを管理します。

ネイティブスタックが作成済み、またはPRを出せる状態だと報告する前に、リモートオブジェクトを検証します。PullRequest.stack が null ではなく、その trunk と順序付きエントリーがデリバリープランと一致している必要があります。PRのベース参照が正しく連なっているだけでは不十分です。リモートで検証できない場合は、PRをネイティブスタックではなく、未検証の依存チェーンとして報告します。

未完了の上位境界はドラフトとして開きます。各PRには、対象を絞ったタイトルと簡潔な説明を付け、次の内容を含めます。

• 選択したストーリー、含まれる実装スライス、およびこのPRの目的
• 親／ベースとなるPRと次の境界（判明している場合）
• この差分でレビューすべき内容
• 実施した検証
• リリース状態
• 意図的に先送りした項目

レビューと修正

レビューを依頼する前に、すべてのPR境界をセルフレビューします。機能、意図、コード品質、依存関係、AI固有の誤り、テストの完全性を確認します。

後続の境界が先行する判断に強く依存する場合は、下位から上位へレビューを依頼します。対象を絞った各差分が理解しやすければ、異なる専門家が各境界を並行してレビューし、承認してもかまいません。マージ可能な状態にする順序とマージ順序は、引き続き下から上へ進めます。

フィードバックによって下位の境界に変更が生じた場合：

1. その変更を所有するブランチに移動します。
2. そこで修正し、テストします。
3. その上位にあるすべてのブランチをリベースするか、スタックし直します。
4. リポジトリのポリシーに照らして、既存の変更／代替エビデンスが引き続き有効かを再評価し、必要に応じて影響を受ける対象限定チェックと累積チェックを再実行します。
5. 上位の差分を再レビューし、意図しない重複や意味のずれがないか確認します。
6. 安全なリース保護と許可を確保したうえでのみ、プッシュします。

下位の不具合に対する回避策を上位に追加してはいけません。

発見事項は、それを所有する境界に含めます。

• 下位のスライスが約束した動作や契約を修正するものであれば、下位のブランチを修正してスタックし直します。
• 上位のスライスだけが所有する受け入れ範囲を追加するものであれば、上位に残します。
• 所有する下位のPRがすでにマージ済みであれば、trunkを基点とする対象を絞った修正を行います。マージ後、続行する前に残りの上位スタックを同期またはリベースし、再確認します。
• 計画した境界が無効になる場合は、作業範囲を下位へ紛れ込ませるのではなく、スタックと計画を組み直します。

エビデンスによって必要になった場合は、スタックを組み直します。個別にレビューできない隣接PRは統合し、2つ目の概念を取り込んだ境界は分割します。依存関係が許す場合に限り、順序を変更します。構造を変更する前提条件として、作業ツリーがクリーンであり、復旧可能なリベース経路があることを確認します。

マージと完了

マージ前に、次のことを行います。

• 境界と、その下にあるすべての境界について、チェックの合格と必要な承認を必須にします。
• スタックの履歴が線形であることを必須にします。
• 最上位のブランチが、宣言されたスタックのスコープ全体と、累積した受け入れ基準または最終ゲートを満たしていることを確認します。
• 一部がマージされた状態でも安全性が保たれることを確認します。
• ネイティブのスタック PR 機能はプレビューであるため、最新の GitHub ガイダンスに従ってドキュメントの競合を解決します。

GitHub ネイティブのリンクされたスタックでは、承認済みの先頭部分またはスタック全体を gh stack merge でマージします。選択した PR とその下にあるすべての PR は、マージキューが処理を複数のグループに分けない限り、すべて成功するか、すべて失敗する操作としてマージされます。リンクされていない依存関係チェーンやその他のツールを使う場合は、下から順にマージし、下位のマージ後にスタックを再構成します。下位の依存関係がすべてマージされるまで、上位の PR をマージしてはいけません。

下位の境界がマージされたら、残りのスタックを同期またはリベースし、影響を受けるチェックを再実行して、各 PR に意図した範囲の差分だけが表示されることを確認します。スライスをまたぐスタックでは、担当する PR がマージされた時点でそのスライスを完了として扱います。スライス内のスタックでは、最上位がマージされた時点でのみ、そのスライスを完了として扱います。最上位がマージされた時点で、スタック全体が完了します。その後、planning に記載されたリポジトリ計画の所有者のクローズ／アーカイブ／削除ライフサイクルに従います。通常の権限で削除するのは、フォールバックの一時的な計画ファイルだけにしてください。

例

1 つの垂直スライス内でレイヤーを使う

選択したストーリーと固定された実装スライス：

A registered customer can sign in with valid credentials and reach their account.

エンドツーエンドの差分をすでにレビューできる場合は、ストレージ、認証の動作、エントリポイント、レスポンス、テストを含む 1 つの PR を使います。

範囲が大きすぎる場合は、次のような責任あるスタックを作成できます。

1. マイグレーションとロールバックの検証を含む、後方互換性があり、休止状態の認証情報ストレージのマイグレーションを追加します。
2. 契約テストを含め、既存の境界の背後に認証情報リポジトリアダプターを追加します。
3. 動作テストとともに、実際のエントリポイント、ドメインの動作、ストレージ、レスポンス、オブザーバビリティを通じて、有効な認証情報の経路を追加します。

ストーリーとスライスは垂直のままにし、スコープを広げません。レイヤー 1 と 2 はイネーブリングタスクであり、ユーザーストーリーや実装スライスではありません。具体的なリポジトリの制約により安全性が高まり、かつ各レイヤーがこのスキルのゲートを満たす場合に限り、「すべてのエンドポイント」または「すべてのミドルウェア」を別々の PR にします。テストをすべて最終 PR まで先送りしてはいけません。

複数の垂直スライスをスタックにする

計画では、代わりに次の承認済みスライスを定義することもできます。

1. 登録済みの顧客が、有効な認証情報でサインインできます。
2. 無効な認証情報を入力した顧客には、安全な拒否が表示されます。
3. 無効な試行が繰り返されると、アカウントが一時的にロックされます。

これらは 3 つの実装スライスとして維持します。それぞれが、ブロックや作業の重複を生じさせずにトランクを対象にでき、任意の順序でマージできる場合は、独立した PR を使います。スライス 2 と 3 が下位の動作を必要とする場合、または同じ進化中のベースラインで下位のレビュー完了前に作業を開始し、下位から順に固定してマージすることによるカスケードコストを許容できる場合は、スライスをまたぐ 3 つの PR のスタックを使います。下位のスライスが担当するフィードバックは下位のスライスで修正し、上位へ反映します。新たな上位スライスのスコープは上位のスタックに維持します。