build: 複数スクリプトのビルドを範囲限定・上限付きで並列化する

[YukiWorks432]

Issue

Refs #48

このPRは配布用の develop を基点とし、既定ブランチ main へのリリース統合前の候補です。そのため、今回のマージだけではIssue #48を自動終了しません。リリース統合時に受け入れ条件を再確認して終了します。

変更範囲

• pnpm build、--all、--app、既存のアプリ別ビルド別名を専用ビルドスクリプトへ切り替え
• Rollupの公開JavaScript APIと上限付きスケジューラーで単発ビルドを並列化
• スクリプトの静的な相対依存、共通初期化、環境型定義へTypeScriptの処理範囲を限定
• TypeScriptの構文解析とモジュール解決で、文字列・コメント内の偽陽性を除外
• 全件成功時だけビルドハッシュ履歴を確定し、一時ファイルから置換することで保存失敗時も既存履歴を保持
• 並列度・依存範囲・監視時の互換性・追加アプリ別名・失敗処理・成果物一致のテストと利用方法の文書を追加
• @babel/plugin-transform-classes を直接の開発依存へ追加

対象外

• pnpm watch の並列化・再設計
• 生成済み成果物の巻き戻し
• 動的な並列度変更、子プロセス分離

検証

• pnpm install --frozen-lockfile --strict-peer-dependencies: 成功
• pnpm lint: 成功
• pnpm test: 成功（18件）
• pnpm build --all: 成功
• pnpm exec prettier --check .: 成功
• git diff --check: 成功

Validation

• 上記の検証コマンド: pass
• gh signoff on 06c23906646c0de43eddd022a17bdde49fd7eac3: success
• gh signoff status --branch develop: ✓ signoff
• GitHub Actions CI for 06c23906646c0de43eddd022a17bdde49fd7eac3: success
• 独立レビュー: READY（06c23906646c0de43eddd022a17bdde49fd7eac3）

版・リリースへの影響

版番号、タグ、リリース設定は変更していません。単発ビルドの実行経路と開発依存関係を変更します。

残存リスク

実行時間とメモリ使用量は環境差があります。CIでは固定の速度条件を置かず、並列上限、成果物一致、失敗時の履歴整合性を検証します。

再開点

追加レビューの2件（依存関係の構文解析、ハッシュ履歴の安全な保存）を修正し、最新先端で独立レビューREADYを取得済みです。マージ後はIssue #48を開いたまま、developからmainへのリリース統合時に受け入れ条件と終了状態を確認します。

[YukiWorks432]

独立PRゲート

対象: #52 / head 34fd4f3080bc3fd29648a0eab3c32baf2e8ef4c9
base: develop@6cf756ef165946042a94b58309b5659213693248

判定: FIX_REQUIRED

阻害事項:

• 中 — 公式のアプリ追加経路が新しいビルド経路を迂回します。scripts/addApp.mjs:307,313 は新規アプリの build:<appId> を rollup -c --app=... と生成するため、複数スクリプトの上限付き並列化、失敗時のハッシュ調停、専用実行経路を使いません。既存の package.json の別名だけでなく、追加後の別名も scripts/build.mjs --app=... へ揃えてください。

• 中 — Issue build: 複数スクリプトのビルドを範囲限定・上限付きで並列化する #48 の「範囲限定前後で、動的なビルドメタデータを正規化した実行コードが一致する」受け入れ条件を検証できません。scripts/buildOutput.test.mjs:50-67 は新実装同士の逐次・並列比較だけで、従来の範囲または正規化比較を行っていません。比較用の決定論的な回帰検証を追加してください。

• 中 — pnpm watch の既存挙動を保つ根拠が不足します。package.json:15 は従来の Rollup 監視経路のままですが、rollup.config.mjs:529-557 の範囲限定設定は監視時にも無条件で適用され、TypeScript の監視対象・診断範囲を変更し得ます。監視時は従来設定を維持する分岐、または意図した変更であることを示す回帰検証が必要です。

CI は Node.js 22/24 で成功し、署名も成功していますが、上記の仕様・直接利用経路の問題を解消した後に同じ独立ゲートを 34fd4f3080bc3fd29648a0eab3c32baf2e8ef4c9 以後の新しい head SHA で再実施してください。

[YukiWorks432]

独立PRゲート

対象: #52
base: develop@6cf756ef165946042a94b58309b5659213693248
head: feature/issue-48-parallel-build@4191ddc2dc19c9511e50a82c2f71274d20914fee
スタック: なし

判定: READY

阻害事項: なし

仕様適合:

• pnpm build、--all、--app、既存のアプリ別名、および addApp.mjs が生成する新規別名が scripts/build.mjs を利用します。
• 既定値は min(4, os.availableParallelism(), 対象件数)、取得不能時は os.cpus().length にフォールバックし、--concurrency の正整数検証と1指定を実装しています。
• Rollup公開API、上限付き停止スケジューラー、開始済みbundleの close 保証、対象名順の最終集計、全件成功時のみのハッシュ確定を確認しました。
• 静的相対依存・共通初期化・環境型定義の範囲限定、逐次／並列のバイト一致、範囲限定前後の動的メタデータ正規化比較、失敗時の未開始停止をテストしています。
• pnpm watch は従来のRollup監視経路を維持し、直接依存、利用文書、品質ゲートも受入条件に適合しています。

技術品質:

• scripts/build.mjs、buildScheduler.mjs、rollup.config.mjs の実行経路と関連テストを確認しました。
• 前回指摘の「生成別名」「比較試験の範囲」「watch設定」は、最新差分で妥当に解消されています。
• 指定head SHAのCI（Node.js 22/24: lint、test、build、整形、差分検査）と signoff は成功、未解決レビュー・スレッドはありません。

この READY は上記の固定head SHAにのみ適用します。PRはDraftのまま維持し、Ready化・マージ・Issue操作は行っていません。

[YukiWorks432]

追加レビュー

対象: feature/issue-48-parallel-build@4191ddc2dc19c9511e50a82c2f71274d20914fee

判定: FIX_REQUIRED

Rollup の公開 JavaScript APIで対象ごとに独立したビルドを作り、上限付きスケジューラーで並列化し、各 bundle を finally で close() する基本設計は妥当です。maxParallelFileOps は単一ビルド内のファイル操作上限であり、複数ビルドの並列度を制御する用途ではないため、現在の外側のスケジューラーという方向性で問題ありません。

阻害事項は次の2件です。

1. 中 — TypeScript の処理範囲が文字列解析の誤検出で広がり得ます（rollup.config.mjs:267）

   collectImportDependencyFiles は正規表現でソース文字列を走査していますが、今回その結果を @rollup/plugin-typescript の include に渡したことで、解析の弱点がコンパイル対象の分離に直結しました。たとえば文字列リテラル内の import "../sibling" を依存として誤検出すると、別スクリプトのファイルが TypeScript のプログラムへ混入します。また、文字列内のコメント記号によって実際の import を取りこぼす経路もあります。Issue #48 の「対象スクリプトと静的相対依存だけを処理する」という分離契約を満たすには、TypeScript の構文解析（ts.preProcessFile / AST）と ts.resolveModuleName で依存を収集し、import 風文字列・コメント記号を含む文字列の回帰テストを追加してください。

2. 中 — ハッシュ履歴の保存失敗時に既存内容を壊し得ます（rollup.config.mjs:332）

   fs.writeFileSync(BUILD_HASH_FILE, ...) は既定の w フラグで既存ファイルを先に切り詰めます。ディスク容量不足や途中の書き込み失敗ではコマンド自体は失敗しても、既存の履歴が空または部分書き込みになり得るため、「失敗時は既存のハッシュ履歴を変更しない」という受け入れ条件を満たしません。同一ディレクトリの一時ファイルへ完全に書き込んだ後で rename/replace し、失敗時は一時ファイルだけを掃除する方式にしてください。書き込み失敗を注入し、既存ファイルがバイト単位で不変であることを確認するテストも必要です。

参考: Rollup JavaScript API、Rollup maxParallelFileOps、TypeScript Compiler API、Node.js fs.writeFileSync

この判定は上記 head SHA にのみ適用します。