Background
最近の customer-consumer-guard 失敗には、README や scaffold 出力の文言変更に対して guard が敏感すぎるために落ちていると見えるケースがあります。
特に、3 OS で同時に落ちるタイプの失敗は、環境依存の揺れというより、公開パッケージ経由の scaffold 契約テストが wording drift に強く引っ張られている可能性があります。
Problem
現在の guard には、customer-facing contract の検証として必要なものと、単なる wording drift まで過剰に failure にしてしまうものが混ざっている可能性があります。
その結果、実質的な product regression ではない変更でも CI が壊れやすくなり、guard の信頼性と保守性を下げています。
Proposal
customer-consumer-guard で見ている期待値を整理し、以下を分けたいです。
- exact match で守るべき customer-facing contract
- section / anchor / required guidance presence で十分な項目
- README テンプレートと guard の期待値を単一の定義元に寄せるべき項目
まずは、exact string 比較が本当に必要な箇所を明示し、それ以外は presence ベースへ寄せる方針を検討したいです。
Expected benefit
- wording drift による不要な CI failure を減らせる
- 本当に守りたい customer contract が明確になる
- README / scaffold 文言更新時の保守負荷を下げられる
- guard failure の意味が読みやすくなる
Definition of done
customer-consumer-guard の期待値が contract 種別ごとに整理される- exact match が必要な箇所と、presence で十分な箇所の方針が明文化される
- README テンプレートと guard 期待値の乖離を減らす仕組みが入る、または維持ルールが文書化される
Background
最近の
customer-consumer-guard失敗には、README や scaffold 出力の文言変更に対して guard が敏感すぎるために落ちていると見えるケースがあります。特に、3 OS で同時に落ちるタイプの失敗は、環境依存の揺れというより、公開パッケージ経由の scaffold 契約テストが wording drift に強く引っ張られている可能性があります。
Problem
現在の guard には、customer-facing contract の検証として必要なものと、単なる wording drift まで過剰に failure にしてしまうものが混ざっている可能性があります。
その結果、実質的な product regression ではない変更でも CI が壊れやすくなり、guard の信頼性と保守性を下げています。
Proposal
customer-consumer-guardで見ている期待値を整理し、以下を分けたいです。まずは、exact string 比較が本当に必要な箇所を明示し、それ以外は presence ベースへ寄せる方針を検討したいです。
Expected benefit
Definition of done
customer-consumer-guardの期待値が contract 種別ごとに整理される