write-bddlisted

# write-bdd（根拠づけられた入力からBDDを書く共通規律） 読み終えると、依頼と資料からBDDを書くときに、何を事実として書けるか、業務の言葉とは何か、シナリオ1件に何を必ず書くか、既存理解を反証してよい段階か、外部の段取り（`grill` / `write-doc`）へ何を渡し何を受け取るかを、このpackageの6つの公開入口と同梱skillが同じ基準で判断できる。この規律は成果物を作らず、適用する入口または同梱skillの工程の中で働く。入口ごとに違う判断（コアの線引き、Journeyの判定、永続化の3操作、論理構造への配置）はここに無く、それぞれの入口と同梱skillが持つ。 ## 入力 この規律を適用する入口または同梱skillの`SKILL.md`と、その入口が同じ文脈に保持する利用者の入力、明示された資料、`grill`の結果。適用先の工程が無ければ何もしない。 ## 判断基準 | 観察対象 | 述語 | 行動 | |---|---|---| | 事実として書く候補（用語、業務イベント、役割、決まり、記録する事実） | 利用者の発言、明示された資料、`grill`で確認した決定のどれかへ辿れる | 事実として書き、出所を辿れる状態にする。辿れなければ最も筋の良い候補を仮説として置き、仮説であることと根拠を該当箇所と未決に明示する。一般知識やもっともらしい例から補わない。[入力に根拠づける規律](references/input-grounding.md) | | 語 | 業務関係者が仕事の会話と判断で合意して使い、仕組みを全部やめても残る | 業務の語として使う。部品名、保存方式、内部状態名、技術語を平易に言い換えた独自語は使わず、合意語が無ければ入力にある語を仮置きして未決にする。[ユビキタス言語](references/ubiquitous-language.md) | | 役割 | 目的、権限、責任を持つ役割として言え、個人名や部署名ではない | 主アクター、支援アクター、利害関係者を分けて書く。各コマンドとクエリについて「誰が行えるか。本人以外が行ったとき誰の何が困るか」を問う。[アクターと利害関係者](references/actors-and-stakeholders.md) | | 業務イベント | すでに起き、業務上の判断や状態を変えた事実を過去形の業務語で言える | 業務イベントとして採る。要求、通知、画面操作、内部の技術動作は業務の事実へ言い換える。[業務イベント](references/domain-events.md) | | 概念の置き場（ドメイン、振る舞い、言葉、永続化、BDDの焦点） | どの問いで観察し、矛盾をどの観点へ返すかが決まる | その観点で形作り、他の観点へ送る事項を作業記録に残す。[概念の関係](references/concept-map.md) | | domain-ruleへ残す候補 | 業務の目的、事実、状態、出来事、権利・義務、判断、成立条件、拒む理由として、実現方式を変えても同じ意味で残る | 業務知識として残す。ユースケースの処理順、画面・操作導線、API・メッセージ契約、データモデル・永続化、コード・層・配置、運用・非機能の実現方式ならdomain-ruleへ混ぜず、その関心が守ろうとしている業務上の意味だけを残し、元の記述と送り先を作業記録へ分ける。[概念の関係](references/concept-map.md) | | BDD 1件 | Give