> For the complete documentation index, see [llms.txt](https://summerain-1.gitbook.io/summerain/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://summerain-1.gitbook.io/summerain/ja/rirsunto/v2.0.0.md).

# V2.0.0

> \[!IMPORTANT] **v2.0.0 は初期段階のメジャーリリースです。** アップロードプロトコル、ブラウザー画像パイプライン、スキーマ、互換動作、運用上の既定値は、今後も頻繁に変更される可能性があります。パッチリリースが頻繁に行われることを想定し、アップグレード前に必ず変更履歴を確認し、本番環境では正確なバージョンまたは OCI インデックスダイジェストを固定してください。V2 を初めて起動する前に、MySQL と画像ボリューム全体をバックアップしてください。

本リリースは V1 のアップロードホットパスを、他のサービスと共有する 3 コア、4 GB のホストで大画像が集中してアップロードされる状況を想定した、リソース考慮型 V2 パイプラインに置き換えます。既存 V1 画像を引き続き読み取れるようにしながら、新しい Web アップロードを、マニフェスト宣言型クライアント前処理、固定永続バリアント、永続バックグラウンド公開、上限付きクリーンアップへ移行します。

本変更履歴で V1 と比較する基準はタグ `v0.1.0` です。

## ハイライト

* 新しい V2 Web アップロードでは、負荷の高いデコード、リサイズ、形式変換、圧縮をサーバーからブラウザーへ移します。
* 初回読み取り時にサムネイルを生成せず、固定レシピの WebP バリアントを永続化し、新しい画像に対する V1 の二重読み取り・二重書き込みホットパスを解消します。
* 再開可能で冪等なアップロードセッションと、MySQL を使用した永続公開ジョブ、クリーンアップ状態、ストレージ系統情報、トランザクション outbox 配信を追加します。
* V1 画像配信を維持し、V2 を無効にしたデプロイ向けに、サーバーが明示する V1 アップロードフォールバックを提供します。
* 制約のある共有ホスト向けに、上限付きデプロイプロファイル、ディスク負荷による受付制御、有限のデータベース/Redis プール、増分クリーンアップを追加します。
* 復旧可能でリリースタグが不変のワークフローにより、再現可能なマルチプラットフォームイメージを Docker Hub と GHCR へ公開します。

## V1 からの全変更履歴

### ブラウザー側の画像処理

* 静止画 JPEG、PNG、BMP、WebP、AVIF 入力向け V2 前処理を追加しました。
* デコード前に、拡張子、MIME、寸法、空ファイル、アニメーションを含むシグネチャベースの形式検査を追加しました。
* アニメーション PNG、WebP、AVIF を明示的に拒否します。GIF は V2 アップロード形式ではありません。
* 元ファイルを 15 MiB、元画像を 50 MP に制限します。
* クロップとリサイズの前に EXIF を考慮した向き補正を追加しました。
* HEIF/AVIF デコード、シングルスレッド実行、操作キャッシュの無効化、追跡キャッシュの上限を備えた専用 `wasm-vips` worker 高速経路を追加しました。
* Pica、`ImageBitmap`、`OffscreenCanvas`、Canvas 2D に基づくネイティブフォールバックを追加しました。
* 生成した各パートが完全な WebP コンテナーであることをアップロード前に確認する実行時検証を追加しました。
* 8 分のクライアント処理タイムアウト、キャンセル、および worker、bitmap、canvas、blob URL、object URL の明示的クリーンアップを追加しました。

V2 は次の固定レシピアセットを生成します。

| アセット             | 形状                    |     品質 | ライフサイクルと用途                          |
| ---------------- | --------------------- | -----: | ----------------------------------- |
| `master`         | 向き補正後の元の寸法            |     80 | 永続化するフル解像度 WebP。owner/admin がアクセス可能 |
| `gallery`        | 400x400 cover クロップ    |     60 | 「マイ画像」とダッシュボードの永続プレビュー              |
| `admin`          | 120x160 cover クロップ    |     60 | 画像管理用の永続プレビュー。2 倍密度の 60x80 で表示      |
| `publish_source` | アスペクト比を維持し、長辺が最大 2048 |     80 | `publish` の作成に使用する一時アップロードパート       |
| `publish`        | `publish_source` から派生 | サーバー出力 | 任意の透かしを持つ永続公開/非公開アセット               |

* アップロードマニフェストに SHA-256、バイト数、寸法、品質、プロセッサーバージョン、レシピバージョンのメタデータを追加しました。
* V2 は元のエンコード済みソースバイトを保持しません。`master` がフル解像度、品質 80 の WebP 代替になります。
* 永続化する V2 バリアントはすべて WebP です。AVIF は入力形式としてのみ対応します。

### 再開可能なアップロードプロトコルとブラウザー復旧

* レシピ取得、初期化、パートアップロード、完了、単一/一括状態照会、キャンセルに対応するセッションベースの `/api/v1/uploads` API を追加しました。
* 必須の `Idempotency-Key` 処理を追加しました。同じ key とマニフェストでは既存セッションを返し、異なるマニフェストは拒否します。
* 初期化、転送、処理、完了、失敗、キャンセル、クリーンアップ保留を表す永続セッション状態を追加しました。
* 存在しない ID が他ユーザーのものかを漏らさず、最大 100 ID を全件成功または全件失敗で照会する一括状態 API を追加しました。
* クライアント/サーバーマニフェストを厳密に照合する、4 パートの再開可能マニフェストを追加しました。
* バイト単位の XHR 進捗、2 分のパートタイムアウト、ジッター付き指数バックオフ、最大 5 回のパート試行を追加しました。
* 明示的に冪等と指定されたリクエストだけで CSRF 更新と再送を行います。
* ブラウザーでのキャンセルまたはパートの最終失敗後に、サーバーセッションのキャンセルをベストエフォートで実行します。
* 完了レスポンスが不明確な場合、再試行前に永続サーバー状態を確認して復旧します。
* ポーリング継続、現在の試行の再利用、終了/期限切れ後の新規試行作成を選べる再試行分類を追加しました。
* 公開処理の適応型ポーリングを追加しました。最初の 30 秒は 2 秒間隔、2 分までは 5 秒間隔、その後は 10 秒間隔で、期限は 10 分です。
* ブラウザー処理は同時に 1 画像、アップロードパイプラインは 2、ユーザーごとの有効アップロードセッションは 4 に制限します。
* パート転送は同時実行数 2 で開始し、能力があり、高速で、従量制でない接続では 3 へ増やせます。
* 1 回の試行中はアップロードの公開範囲を固定し、バッチ処理中は変更できません。
* クライアントは前処理前に `/api/v1/uploads/recipe` を読み、サーバーが `v2_enabled=false` を明示した場合だけ V1 multipart 経路を使用します。
* V2 有効時にファイル単位の未処理ソースフォールバックはありません。WASM と上限付きネイティブ経路のどちらも利用できないブラウザーには明確なエラーを返します。

### バックエンドのアップロード検証と不変ストレージ

* 各パートをステージングへ直接ストリーミングしながら、1 回の処理で SHA-256 を計算し、バイト長、RIFF/WebP 構造、寸法、アニメーションを検証します。
* 切り詰められたコンテナー、偽装 RIFF サイズ、末尾の余分なバイト、予期しない形状、ハッシュ不一致、不正な MIME/レシピフィールド、アニメーション WebP パートを拒否します。
* V2 パート全体を Go メモリへ読み込まず、形式検証だけを目的としたステージングの 2 回目の読み取りも行いません。
* `master`、`gallery`、`admin` を不変のコンテンツアドレスストレージへ昇格し、既存ターゲットを再利用する前に同一性を検証します。
* 高負荷なターゲット事前検証をプロセスレベル容量ゲートの外で行いつつ、トランザクションと昇格制御は直列化します。
* 完了処理を冪等にし、画像、固定バリアント、クォータ計上、公開ジョブ、処理イベントを 1 回の永続遷移としてコミットします。
* 公開成功後に `publish_source` とアップロードステージングディレクトリを削除します。アップロード中間物はユーザーに見えるアセットとして保持しません。

### 永続公開処理と透かし

* 優先度、再試行上限、リース、更新、fencing token、期限切れ worker 復旧を持つ MySQL ベースの非同期公開ジョブを追加しました。
* リースを失った worker が古い結果をコミットまたは再作成することを防ぎます。
* 再試行を使い切った終了ジョブに補償クリーンアップを追加し、画像が半公開状態に残り続けることを防ぎます。
* 完了処理で公開ジョブを作成するときに透かし設定をスナップショット化し、後の設定変更がキュー内画像へ影響しないようにします。
* サーバー側の透かしは最終 `publish` アセットだけに適用します。クライアント生成の `master`、`gallery`、`admin` には適用しません。
* 透かしのアトミック置換、プロセス内ロック、ファイルシステム `flock`、復旧ジャーナルを使用します。
* 同じ透かしスナップショットのジョブは同時実行できます。過去のスナップショットは、有効 SVG を安全に切り替えて復元する間、直列化されます。
* V2 公開処理と imgproxy はそれぞれ既定で 2 worker とし、さらに制約や競合が強いホスト向けに 1 worker へのフォールバックを文書化しました。

### 固定配信ルートと V1 互換性

* 固定 V2 ルートを追加しました。
  * `/i/<asset_link>.webp`
  * `/i/<asset_link>/master.webp`
  * `/i/<asset_link>/gallery.webp`
  * `/i/<asset_link>/admin.webp`
  * `/i/<asset_link>/publish.webp`
* クエリパラメーターから追加の V2 サイズや形式は生成されません。
* `master` と `admin` には owner または管理者の認可が必要です。非公開 `gallery` と `publish` は通常の非公開画像認可を維持します。
* 既存 V1 画像は元の短縮リンクで引き続き読み取れます。
* V1 の動的形式、幅、高さ、品質パラメーターを維持し、寸法上限は 4096 です。
* 既存のサイズ指定なし WebP とバックグラウンド AVIF 出力は永続化されたまま利用できます。任意の V1 変換は上限付き一時ファイルを使用し、最後の待機レスポンス終了後に削除します。
* 同じ V1 変換への同時リクエストは 1 つの imgproxy ジョブを共有します。
* V1 動的生成は実行中 2 変換、待機中 4 変換 key に制限され、超過した処理には再試行可能なビジーレスポンスを返します。
* バックグラウンド V1 AVIF 生成は同時に 1 操作へ制限し、レスポンス上限を適用し、一時ファイルとアトミック rename で永続化します。
* V2 有効時、従来の `POST /api/v1/images/` は `4262` を返します。`V2_UPLOAD_ENABLED=false` にすると V1 multipart アップロードエンドポイントが再び有効になります。

### 画像 UI と管理

* ローカル処理、転送、サーバー側公開処理に個別のキュー状態を追加しました。
* 未処理ソースのプレビューを、処理済み `gallery` blob のプレビューへ置き換えました。
* ファイル単位の再試行、一括再試行、ページ離脱時のキャンセル、確定的な object URL クリーンアップを追加しました。
* アップロード完了操作を、V2 WebP 公開リンクを含む固定 Markdown のコピーへ変更しました。
* アップロードページから、任意 URL/Markdown/BBCode/HTML と元画像/WebP/AVIF 出力の組み合わせを削除しました。
* 「マイ画像」とダッシュボードの V2 プレビューは `gallery` を使用します。
* 画像管理では 60x80 CSS ピクセルの `admin` を使用し、拡大表示には `master` を使用します。
* V2 詳細では固定 Publish、Master、Gallery、Admin リンクを公開し、V1 詳細では動的変換コントロールを維持します。
* パイプラインを考慮した URL 解決と、安全な token クエリ/fragment 処理を追加しました。
* 新規発行トークンの有効期限を即時表示し、失効後にローカルクリーンアップを行います。
* active、suspended、pending-deletion、内部 deleting ユーザーに対する明確な管理者動作を追加しました。
* R2 設定変更では過去のファイルを移動せず、別の移行ツールが必要であることを明確にしました。

### ストレージ整合性、R2 系統情報、クリーンアップ

* CDN purge とローカル/R2 物理削除向けのトランザクション outbox を追加しました。
* 正式な業務行を削除する同じ MySQL トランザクションで削除意図を記録します。
* 物理削除前に共有ストレージロック下で `image_variants` と `image_files` の参照を再確認します。
* R2 の 404 レスポンスを冪等な削除成功として扱います。
* 新しい V1 R2 アップロードが最初のリモート `PUT` を行う前に、永続クリーンアップ意図を作成します。
* 新しい V1 オブジェクトに正確なストレージバックエンド、endpoint、bucket を記録します。
* 現在有効な R2 target ではなく、保存済みの系統情報に基づいて読み取り、ダウンロード、削除を行います。
* レコードが別 target を参照している、過去レコードが未分類、またはリモート削除イベントが保留中の場合、endpoint や bucket の変更を禁止します。
* R2 endpoint と公開 URL を検証し、埋め込み資格情報、query string、fragment、HTTP(S) 以外の URL を拒否します。
* 同期 `/api/v1/admin/r2/migrate` 経路を削除しました。過去の移行は checkpoint、監査、ロールバックに対応する別ツールで行います。
* 起動時に過去の V1 ストレージ target を推測または書き換えません。
* ロールバック後に再試行可能なステージング復元と、参照のない永続 V2 ファイルの増分復旧を追加しました。
* ディレクトリ cursor を維持し、項目数、時間、バッチ予算を適用して、大規模なステージング/孤立ツリーを無制限にメモリへ読み込まないようにします。
* 失敗したストレージ削除イベントは、一般的な保持クリーンアップで削除せず、成功するまで保持します。
* 一括ダウンロード ZIP をストリーミングし、圧縮済み画像には store モードを使用して、アーカイブ全体をメモリ上で組み立てません。

### CDN、プライバシー、公開範囲

* 上限付きバッチ、リース、レート、タイムアウトを持つ永続 Cloudflare purge 配信と、汎用認証 webhook フォールバックを追加しました。
* 配信先が未設定の場合、成功と誤報せず purge イベントを保留状態に残します。
* 公開オリジンのキャッシュを 10 分に制限し、能動的な purge 配信が利用できない場合も公開範囲の変更を収束させます。
* V2 の公開から非公開への変更では、有効なオリジンエイリアスを `<unique_link>` から `<unique_link>S` へ切り替え、古い公開 URL の purge 処理をキューへ追加します。
* 非公開から公開への変更では非公開エイリアスを削除し、有効なアクセストークンを失効させ、影響する URL を purge します。
* 非公開レスポンスはブラウザー、プロキシ、surrogate の全キャッシュヘッダーで `no-store` を維持します。
* 画像行でアクセストークン置換を直列化し、同時リクエスト中も画像ごとに 1 つだけを有効にします。

### MySQL スキーマ、復旧、アカウント削除

* データベーススコープの advisory lock と予約接続の下で、順序付き追加型 MySQL マイグレーションを追加しました。
* `schema_migrations` に不変 SHA-256 チェックサムを記録し、不明、欠落、並べ替え、変更、未適用のマイグレーション履歴がある場合は起動を失敗させます。
* `images` に V2 パイプラインメタデータを追加し、`image_variants`、`upload_sessions`、`upload_parts`、`processing_jobs`、`outbox_events`、グローバル容量状態、ストレージ参照インデックス、保持インデックス、R2 系統フィールドを追加しました。
* 既存画像行は V1 かつ completed のままです。起動時に V2 バリアントを生成したり過去ファイルを移動したりしません。
* `pending_deletion` を内部の fail-closed `deleting` 段階から分離しました。
* 上限付きで再開可能な段階に分けてアカウント削除を実行し、有効なアップロードと公開処理が安全な終了状態になるまで待機します。
* 削除前に共有ファイル参照を再計算しながら、バリアント、重複排除ファイル、ローカル/R2 オブジェクト、セッション、トークン、通知、監査データ、アップロードレコードを永続的にクリーンアップします。

### 共有ホスト向けリソース管理

既定のコンテナー予算：

| サービス     |  CPU |      メモリ | PID 上限 |
| -------- | ---: | -------: | -----: |
| バックエンド   | 0.75 |  640 MiB |    128 |
| MySQL    | 0.75 | 1024 MiB |    256 |
| Redis    | 0.15 |  192 MiB |    128 |
| imgproxy | 0.70 |  512 MiB |    128 |

* バックエンドコンテナー内で `GOMEMLIMIT=512MiB` を設定します。
* MySQL は最大 8 接続、アイドル 4 接続、寿命 30 分に制限し、Redis は 8 接続プールに制限します。
* Redis に AOF、128 MB データセット上限、`noeviction` を設定し、制御状態を暗黙に削除せず容量不足を明示的な失敗にします。
* ディスク負荷のソフト/ハード受付しきい値を 80% と 90% に設定します。
* アップロード予約に宣言済み全パートと、上限付き 32 MiB 公開容量を含めます。
* クォータ検査に有効セッション予約を含め、並行セッションが同じ残容量を個別に消費できないようにします。
* MySQL を通じてバックエンドインスタンス間のグローバル容量を直列化し、プロセス内受付ゲートで小さなデータベースプールを保護します。
* 既定ではパートアップロードを全体で 8、ユーザーごとに 4、ユーザーごとの有効バックエンドセッションを 8 に制限します。
* 通常の JSON 本文を 1 MiB に制限しながら、画像アップロード固有のストリーミング上限は維持します。
* header、read、write、idle、大容量アップロードの明示的タイムアウトを定義します。
* 上限付きキュー、ヘルスチェック開始猶予、グレースフルシャットダウン、PID 上限、ログローテーション、`no-new-privileges` の既定値を追加しました。

### セキュリティとブラウザー互換性

* 大画像 WASM 処理経路向け COOP/COEP クロスオリジン分離を既定で有効にします。
* 分離有効時は起動時と実行時管理の両方で GeeTest v4 を拒否します。`none`、reCAPTCHA、Turnstile は引き続き対応します。
* 型付きで保護された reCAPTCHA/Turnstile 統合と、ライブラリ利用不可を明示するエラーを追加しました。
* 認証済み、完全一致オリジン、Fetch Metadata 対応の CSRF 更新を追加し、順不同のブラウザーレスポンス向けに有効トークンの重複期間を制限付きで許可します。
* Web とデバイス認証で、不明または破壊的なアカウント状態を fail-closed にします。
* 絶対保存パス、path traversal、ルート外へ出る symlink、通常ファイル以外を拒否します。
* ステージングを永続ストレージの子にすることを要求し、制限付きローカル権限を適用します。
* 観測された Chrome 93+ Android 互換性下限に合わせ、ブラウザー本番出力を ES2020 に固定します。
* UA allowlist ではなく実行時に能力を検出します。
* 50 MP WASM 経路には、クロスオリジン分離、`SharedArrayBuffer`、Worker 対応、報告デバイスメモリ約 4 GB 以上が必要です。
* ネイティブフォールバックは、低メモリ端末で 8 MP、一般または未報告メモリ端末で 13 MP、8 GB 以上を報告する端末で 16 MP に意図的に制限し、最大寸法は 8192 ピクセルです。

### デプロイ、開発、依存関係、CI

* Compose からアプリケーションイメージのビルドを削除しました。GitHub Actions だけがアプリケーションイメージをビルドします。
* 本番環境で正確な `DOCKER_IMAGE` タグまたはダイジェストを必須とし、`pull` と `up -d --no-build` によるデプロイを文書化しました。
* 同一ファイルシステム上でアトミックに昇格させるため、ステージングを永続画像ボリュームの `/data/images/.staging` へ移動しました。
* UID/GID 10001 向け V2 ディレクトリを制限付き権限で作成する `storage-init` サービスを追加しました。
* 本番環境では MySQL、Redis、imgproxy を非公開にし、バックエンドだけを loopback で公開します。
* 依存サービスだけの Compose、Go/Vite の直接開発、ローカル HTTPS、同一オリジン API/画像プロキシを、ローカルアプリケーションイメージなしで提供する `scripts/dev-wsl.sh` を追加しました。
* `requirements.lock` を追加し、Dockerfile、Compose、Go、npm、実行時設定、リリースポリシーと相互検証します。
* Go 1.26.5、Node.js 24.18.0 LTS、Alpine 3.24.1、MySQL 8.4.10 LTS、Redis 8.8.0、imgproxy 4.0.11、libvips 8.18.3、Pica 10.0.2、wasm-vips 0.0.18 を固定しました。
* サードパーティ GitHub Actions を完全な commit SHA に固定しました。
* GitHub Actions で provenance、SBOM、共有ビルドキャッシュ付き `linux/amd64`、`linux/arm64` イメージをビルドし、Docker Hub と GHCR へ push します。
* 通常の commit は `edge` と `sha-<12-character-commit>` を公開します。
* 安定版 v2.0.0 は `v2.0.0`、`2.0.0`、`2.0`、`2`、`latest`、commit タグを公開します。
* 正確な SemVer タグを不変に保護し、`latest`、major、minor、`edge`、commit エイリアスは移動可能にします。
* レジストリ間のダイジェスト対応リリース復旧を追加しました。部分公開は既存 descriptor digest から修復し、正確なダイジェストの競合時はリリースを停止します。
* Docker Hub policy API の失敗に上限付き再試行を追加し、通常の edge 公開は管理 API から独立させます。
* 公開成功後にルート README を Docker Hub へ同期します。

## 破壊的変更

* V2 有効時、新しい V2 アップロードにはブラウザー前処理が必要です。
* V2 は元のエンコード済みソースバイトを保持しません。`master` は品質 80 の WebP です。
* V2 Web クライアントはアニメーション画像と GIF アップロードに対応しません。
* V2 は固定 WebP バリアントだけを公開します。任意サイズ、品質、形式の変換は V1 専用です。
* V2 はクエリパラメーターから新しいアセットを作らず、`/i/<asset_link>.webp` と固定バリアントパスを使用します。
* AVIF は V2 では入力専用です。
* 既定のクロスオリジン分離では、サードパーティスクリプト、フォント、画像に互換 CORS または CORP ヘッダーが必要です。
* GeeTest v4 には分離の無効化が必要で、大画像 WASM 経路が失われるため 50 MP 環境では推奨しません。
* 過去の R2 移行はプロセス内の管理者操作ではなくなりました。
* MySQL、Redis、imgproxy、コンテナーパス、非 root ID、必須環境設定が変更されています。新しい例を確認せずに本番設定を再利用しないでください。
* データベースマイグレーションは追加型で、自動 down migration はありません。

## V1（`v0.1.0`）からのアップグレード

1. 同じ時点の MySQL と完全な `image_storage` ボリュームをバックアップします。
2. secret を置き換えず、`backend/.env.example` の新しい値を既存の非公開設定へマージします。
3. `DOCKER_IMAGE=jaykserks/summerain:2.0.0` を設定するか、公開済み OCI マルチプラットフォームインデックスダイジェストを使用します。本番アップグレードで `latest` を使用しないでください。
4. `V2_STAGING_PATH` が `STORAGE_PATH` の子であることを確認します。既定は `/data/images/.staging` です。
5. ディスク使用率が 80% のソフトしきい値未満で、UID/GID 10001 がファイルを読み取れることを確認します。
6. 既存サービスボリュームを再利用する前に MySQL 8.4、Redis 8.8、imgproxy 4 の互換性を確認し、サービス単位のバックアップを保持します。
7. 次のコマンドでデプロイします。

   ```bash
   docker compose --env-file backend/.env -f backend/docker-compose.deploy.yml pull
   docker compose --env-file backend/.env -f backend/docker-compose.deploy.yml up -d --no-build
   ```
8. 起動時のマイグレーションチェックサムと設定エラーを監視し、`/health`、`/ready`、V1 画像アクセス、V2 アップロード、固定バリアント、公開範囲変更、CDN 動作を確認します。

既存 V1 レコードと動的ルートは引き続き対応します。メインサービスは過去画像を一括変換しません。別の移行ツールが公開され、checkpoint、監査、ロールバック処理を完了するまで、現在の過去ストレージ target を利用可能な状態にしてください。

## ロールバック

* `DOCKER_IMAGE` を以前の不変タグまたは OCI インデックスダイジェストへ変更し、`--no-build` で再デプロイします。
* アプリケーションだけのロールバックを優先します。新しいサービスバージョンがデータボリュームを開いた後に MySQL や Redis をその場でダウングレードしないでください。依存関係のダウングレードが必要な場合は互換バックアップを復元します。
* アプリケーションのロールバック中も追加型 V2 マイグレーションと ledger を維持します。
* 完全な状態ロールバックには同じバックアップ時点の MySQL と画像ストレージが必要です。
* V1 は V2 が作成したすべてのバリアント、ジョブ、系統レコードを理解しません。V1 ロールバックを完了とみなす前に、アップグレード後にアップロードした画像を検証してください。

## 既知の制限

* アニメーション画像アップロードは後のリリースへ延期されています。
* 過去画像の変換とストレージ移行はメインサービスにも本リリースにも含まれません。
* 現在の V2 は固定 WebP アセットをローカルストレージへ永続化します。本リリースの R2 系統情報改善は主に V1 互換経路を保護します。
* バックエンドはコンテナーの完全性、ハッシュ、形状、MIME、レシピ宣言を検証しますが、クライアント出力を再エンコードせず、見た目のクロップや実際のエンコーダー品質も独立検証しません。
* 大画像対応はブラウザーと端末の能力に依存します。入力形式に対応するブラウザーでも、上限付きネイティブフォールバックでは処理できない場合があります。
* 適切な CORS または CORP ヘッダーがないサードパーティリソースは、クロスオリジン分離によって遮断される場合があります。
* CDN purge 配信には Cloudflare または webhook 設定が必要です。未設定の場合、イベントは保留され、10 分のキャッシュ上限が最悪時の収束境界になります。
* 3 コア/4 GB プロファイルは保守的な基準であり、普遍的なスループット保証ではありません。ディスク速度、透かしの複雑さ、データベース遅延、CDN 動作、同居ワークロードが 10 分目標へ影響します。
* 公開処理は非同期です。クライアントは 4 番目のパートがアップロードされた時点で `publish` が存在すると仮定せず、永続アップロード状態をポーリングする必要があります。
* 初期メジャーリリースのため、パッチリリースが頻繁になる可能性があります。正確なタグを固定し、各変更履歴を読み、本番環境では移動エイリアスを避けてください。

## 検証

* バックエンドの build、vet、module verification、全テスト、全 race test が成功しています。
* フロントエンドの lint、本番ビルド、94 件の自動テストが成功しています。
* Docker/Compose 設定検査、依存ロック検証、リリース復旧テスト、Docker Hub policy payload テスト、ワークフロー YAML 解析、shell 構文検査が成功しています。
* WSL 開発スタックでは、MySQL、Redis、imgproxy の正常性、バックエンド `/health` と `/ready`、フロントエンド HTTPS、同一オリジン API プロキシ、COOP/COEP ヘッダーを検証済みです。

## 比較

ソース全体の比較：`v0.1.0...v2.0.0`


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://summerain-1.gitbook.io/summerain/ja/rirsunto/v2.0.0.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.