スタック仕様書の更新
更新するのは事実（バージョン、日付、測定値、ソース）です。決定事項は作者に提案し、待機します。引数が指定されている場合は、そのツールをチェックします。それ以外の場合はすべてチェックします。
1. 棚卸し
stack-spec.md から以下をリストアップします:
- §2 の各行とそのバージョン行
- §3 および §4 のすべてのバージョン、リリース日、安定性の主張（「stable」「release candidate」「alpha」「experimental」、ツール名の横にあるバージョン番号）
- 再訪条件 の各行（テストする条件として）
- ヘッダーのバージョン日付
2. 各項目を一次情報源と照合
レジストリ、リリースノート、公式ドキュメント。決して記憶に頼らないでください。
- npm:
npm view <pkg> dist-tags time --json。現在 = 少なくとも14日前にリリースされた最新バージョン。それより新しいリリースは「近日リリース」としてリストアップします。 - nixpkgs ツール（Node.js、Biome、nixfmt、Wrangler、Playwright ブラウザ）:
nix eval --raw nixpkgs#<pkg>.versionをnixos-unstableで実行し、さらにプロジェクトのリリースページを確認します。 - プラットフォーム機能（Cloudflare、ブラウザサポート）: 公式ドキュメントページとその日付。
ツールごとに記録: 仕様書のバージョン行、現在のバージョン、およびその間にメジャーリリース（または仕様書が待機しているリリース）があるかどうか。
3. 各変更を分類
新しいメジャーバージョンの変更ログまたは移行ガイドをすべて読み、仕様書が依存するドキュメントも読みます。その後、次のように分類します:
- 事実（バージョン行、日付、パッケージ数）: 更新します。
- 理由（記載された欠点が修正された、新しい欠点が導入された）: 理由のテキストを更新し、レポートにリストアップします。
- 決定（選択そのもの、代替案がより優れている、再訪条件 のトリガーが発火した）: 編集しません。レポート: 何が変わったか、ソース、コストを含む選択肢、推奨事項。待機します。
4. 編集
- 仕様書のスタイルを維持: 簡潔、ルール優先、理由後置、ISO日付。変更した決定テキストには「Amended <日付>: …」とマークします。
- 新しい事実 → 番号付きリストの末尾に新しいソースを追加し、「checked <日付>」と付記します。ソースの番号を絶対に振り直さず、参照がなくなった場合のみ削除します。
- セクションの番号を絶対に振り直しません。新しいトピックは、そのセクションの次のサブセクションになります。作者にその番号が既に使用されているかどうかを尋ね、選択した番号を報告します。
- ヘッダーのバージョン日付を更新します。
- 仕様書を使用しているサイト、ユーザー、リポジトリの名前は一切記載しません。
5. 検証とコミット
- すべての新しいまたは変更されたURLが解決可能であること:
curl -sIL <url>で確認します。 - 仕様書を使用しているサイト、ユーザー、リポジトリの名前が記載されていないこと。
- Jujutsu、署名付き、テーマごとに1コミット（例: 「Record Astro 8」「Propose TypeScript 7」）。コミットメッセージには、何が変わったか、なぜ変わったか、確認したソースを記載します。依頼がない限りプッシュしません。
6. レポート
ツールごとに: 仕様書のバージョン → 現在のバージョン。次に: 更新された事実、変更された理由、推奨事項を含む提案された決定、まだ14日経過していない近日リリース。