releaselisted

# 配布 **マージした変更を、利用者が受け取れる状態にする。** マージは取り込みであって配布ではない。取り込んだだけの変更は、利用者の環境では起きていない。 ## 配布の形 **何をもって「受け取れる」かは対象で変わる。** 形を先に決める。手順の骨格は共通で、 形ごとに変わるのは**起点の決め方・公開の仕方・完了の確かめ方・取得の手順・取り消し手段**の 5 つである。 | 形 | 例 | 利用者へ届く仕組み | | --- | --- | --- | | パッケージ・プラグイン | npm / PyPI / Claude Code のプラグイン | 利用者が取得する | | サービス | Web アプリ / Web API / Web フロントエンド | 反映で届く。取得の動作は無い | | デスクトップアプリ | Windows / macOS のアプリ | 利用者が導入する。署名が要る | | モバイルアプリ | iOS / Android のアプリ | ストアの審査を経て公開される | | 手順・設定 | 運用手順 / 設定の変更 | 利用者へ配る | | スライド | 提案資料 / 月次の報告 / 説明資料 | 提出先へ置き、読み手が開く | | 文書 | 提案書 / 稟議書 / 報告書 | 同上 | | 表計算 | 指標の管理表 / 稟議の内訳 | 同上 | | ページ | 運用マニュアル / 稟議のページ | 同上 | **下の 4 つ（スライド / 文書 / 表計算 / ページ）は `documentation` モードの配布である。** 上の 5 つと違い、**配布が生成と提出の 2 段になる**。生成は対になる下書き先へ行い、その間に 生成物の内容照合と体裁レビューと制作物承認が入る。**投稿の手順は形ではなく置き先のシステムが 持つ**（`document-systems` の `system-<名前>.md`）。 形ごとの詳細は [references/distribution-forms.md](references/distribution-forms.md) の索引から辿る。 **着手したら、対象の形のファイルだけを読んでから手順へ入る。** 探しに行くのは、読んだ ファイルが別のファイルを名指しで指したときだけである（署名した配布物をストアへ出す場合など、 形が複合することがある）。当てはまる形が無ければ、最も近い形の考え方を借り、違うところを 完了報告へ書く。 **サービスは、反映を誰が起こすかでこの工程の形が変わる。** マージで反映が起きる仕組み （継続的配布）があると、マージが配布そのものになり、同意を取る時点がマージの前へ移る。 参照先の「反映の起動によって工程の形が変わる」を必ず読む。 ## 配布の段階 **配布は 1 度で終わらない。検証へ出す配布と、本番へ出す配布は別の配布である。** | 段階 | 何をするか | この工程の扱い | | --- | --- | --- | | 検証への配布 | 検証環境へ反映する。または開発版と分かる形で公開する | 提示して進めてよい | | 本番への配布 | 本番環境へ反映する。または正式版として公開する | **承認を得るまで進めない** | **`development-workflow` が自動で進めてよいのは検証への配布までである。** 本番への配布は 工程の続きとして自動で通さない。承認を求めて止まる。反映した瞬間に全利