standalone用composeの追加・プロジェクト名の統一・PUBLIC_BASE_URL対応

- docker-compose.standalone.yml を追加。`.env`もクローンも置けない環境
  (NASのコンテナマネージャー等、管理画面にYAMLを貼り付けるタイプ)向けの単体定義。
  本番用との違いは「${...}を使わず値を直書き」「bindマウントを絶対パスで書く」の2点だけで、
  サービス構成・起動順は同じ。編集する値はすべて冒頭の「ここだけ編集」にまとめた
- composeのプロジェクト名を3ファイルとも travel-log に統一（旧: travel-log-prod /
  travel-log-dev）。元々ポート3000とdb/dataを共有していて同時起動はできなかったため、
  名前を分ける意味が薄かった。旧名で動かしているホストは初回だけ旧スタックを
  down してから起動する必要がある（README参照）
- 外向きURLの決定に PUBLIC_BASE_URL を追加（lib/auth/request-url.ts）。
  優先順位は PUBLIC_BASE_URL → X-Forwarded-Proto/Host → リクエスト自身のURL。
  forwardedヘッダを送らないリバースプロキシの背後では、GoogleログインのリダイレクトURIが
  http:// で組まれて認証に失敗するため、公開URLを明示できるようにした

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: claude

.env.example

@@ -15,6 +15,12 @@ SESSION_SECRET=
 GOOGLE_CLIENT_ID=
 GOOGLE_CLIENT_SECRET=
 
+# 公開URL(任意)。リバースプロキシ(HTTPS終端)の背後で動かす場合、プロキシが
+# X-Forwarded-Proto/X-Forwarded-Host を送らない構成だと、Googleログインの
+# リダイレクトURIが http:// で組まれて認証に失敗する。そのときだけ設定する。
+# 未設定ならリクエストから自動導出する(lib/auth/request-url.ts)。
+# PUBLIC_BASE_URL=https://travel.example.com
+
 # 訪問記録の写真の保存先(lib/photoStorage.ts)。
 #   fs       … ローカルのファイルシステム(既定)。Docker運用はこちら。
 #              docker-compose は ./photos を /app/photos にbindマウントする。

CLAUDE.md

@@ -15,7 +15,9 @@ npm run build                                            # 本番ビルド(型
 
 どちらにも`predev`/`prebuild`で`npm run copy-maplibre-worker`(`scripts/copy-maplibre-worker.mjs`)が付いており、MapLibreのワーカースクリプトを`node_modules`から`public/maplibre-gl/`へコピーする(生成物のためgit管理外。理由は下記「MapLibreのワーカースクリプト」)。`next dev`/`next build`を直接叩くとこのコピーが走らないため、地図が真っ白になったらまず`npm run copy-maplibre-worker`を実行すること。
 
-`docker-compose.yml`(本番用)と`docker-compose.dev.yml`(開発用)はプロジェクト名を分けてある(`travel-log-prod`/`travel-log-dev`)ため、同一ホスト上で両方動かしてもコンテナ・イメージ・ボリュームは衝突しない。
+3つのcomposeファイル(`docker-compose.yml`=本番用 / `docker-compose.dev.yml`=開発用 / `docker-compose.standalone.yml`)はどれもプロジェクト名を`travel-log`に揃えてある。同じホスト上で本番用と開発用を**同時に**は動かせない(元々ポート3000も`db/data`も共有しているため、名前を分けても同時起動はできなかった)。切り替えるときは先に`docker compose -f <今動いている方> down`すること。
+
+`docker-compose.standalone.yml`は、`.env`もリポジトリのクローンも置けない環境(NASのコンテナマネージャー等、管理画面にYAMLを貼り付けて起動するタイプ)向けの単体定義。`docker-compose.yml`との違いは「`${...}`を使わず値を直書きする」「bindマウントを絶対パスで書く」の2点だけで、サービス構成・起動順は同じ。**`docker-compose.yml`側のサービス・環境変数を変えたら、standalone側にも同じ変更を反映すること**(値の直書きぶん古くなりやすい)。
 
 このプロジェクトにテストスイート/テストコマンドは存在しない。リンターも未導入(Next.js 16で`next lint`が廃止された際、代替のESLint導入は見送った — eslint-config-nextの依存チェーンに未修正のbrace-expansion脆弱性(GHSA-mh99-v99m-4gvg)が含まれ、導入するとDependabotの高深刻度アラートが解消不能な形で付くため。エコシステム側の修正後に導入を検討する)。型チェックは`next build`が行う。
 
@@ -80,6 +82,8 @@ Next.jsのRoute Handlersのみで、別立てのAPIサーバーは存在しな
 
 NextAuthではなく自前実装。`lib/auth/session.ts`がHMAC-SHA256で署名したCookie(Web Crypto APIのみ使用、外部依存なし)を発行し、`proxy.ts`(Next.js 16で`middleware.ts`から改名されたもの。Node実行)とRoute Handlersの両方で同じロジックにより検証できるようにしている。Cookieには`{ sub: userId, exp }`のみを持たせ、roleは意図的にCookieに含めていない — `lib/auth/current-user.ts`経由で毎リクエストDBから引き直すことで、管理者によるロール変更やDB作り直しが古いCookieのまま反映されない事態を防いでいる。`proxy.ts`は`/login`と`/api/**`、および`/manifest.webmanifest`(ブラウザのmanifest取得は既定でCookieを送らないため、ガードするとPWAとしてインストールできなくなる)以外の全ルートをガードする。
 
+外向きのURL(GoogleログインのリダイレクトURIとCookieの`Secure`属性)は`lib/auth/request-url.ts`が組み立てる。優先順位は`PUBLIC_BASE_URL`(環境変数) → `X-Forwarded-Proto`/`X-Forwarded-Host` → リクエスト自身のURL。リバースプロキシがforwardedヘッダを送らない構成(NAS内蔵のリバースプロキシ等)では、`PUBLIC_BASE_URL`を設定しないとリダイレクトURIが`http://`で組まれてGoogleログインが失敗する。**外向きのURLを組む処理を増やすときは`request.url`を直接使わず、必ずこのモジュール経由にすること**。
+
 ### PWA(インストール可能化)
 
 manifest(`app/manifest.ts`、Next.jsのMetadata Files規約で`/manifest.webmanifest`として配信)+アイコン(`public/icons/`のmanifest用3枚と、`app/icon.png`・`app/apple-icon.png`のファビコン/apple-touch-icon)による最小構成のPWA対応で、Service Worker・オフライン対応は意図的に持たない(「デプロイしたのに古い画面が出る」系の問題を避けるため、必要になるまで導入しない方針)。インストール後も中身は同じWebアプリで、認証Cookieもそのまま使われる。iOSはmanifestの`display`/`icons`を見ないため、`app/layout.tsx`の`metadata.appleWebApp`と`app/apple-icon.png`で別途同等の設定をしている。ページ自体のズームは`app/layout.tsx`の`viewport`(`maximumScale: 1`+`userScalable: false`)で無効化してある — 検索窓等への入力フォーカス時の自動ズームで下のタブバーが隠れ、地図表示中はピンチが地図操作に取られてページのズームを戻せなくなるため(地図の拡大縮小はMapLibreのジェスチャなので影響しない)。`/manifest.webmanifest`は`proxy.ts`のガード対象から除外が必要(上記「認証」参照)。アイコンPNGは`scripts/generate-icons.mjs`(sharp使用、依存には含めない)で生成したものをコミットしてあり、デザイン変更時のみ再生成する。iOSのスタンドアロン起動では`target="_blank"`の外部リンクがアプリ内ブラウザ(オーバーレイ)で開かれてしまうため、外部サイトへのリンク(`SpotInfoModal`の「Wikipediaで続きを読む」)はiOS+スタンドアロンのときだけ`x-safari-https://`スキーム(未文書化だがiOSが解釈する)で本物のSafariに切り替えている(`isIosStandalone`)。

README.md

@@ -89,6 +89,26 @@ http://localhost:3000 を開くと `/login` にリダイレクトされる。初
 既存のメールアカウントと同じメールアドレスでGoogleログインした場合は自動的に紐付く。
 自由なサインアップはできず、管理者が作成したアカウントのみログインできる。
 
+**リバースプロキシ(HTTPS終端)の背後で動かす場合**、アプリが受け取るリクエストは
+プロキシからのプレーンHTTPになる。リダイレクトURIのスキームは`X-Forwarded-Proto` /
+`X-Forwarded-Host`から判断しているため、これらを送らないプロキシ(NAS内蔵の
+リバースプロキシ機能など、設定項目が無いものもある)ではリダイレクトURIが
+`http://`で組まれ、Googleコンソールに登録した`https://`のURIと一致せず認証に失敗する。
+その場合は`PUBLIC_BASE_URL`に公開URLを設定する(設定するとヘッダより優先される)。
+
+```
+PUBLIC_BASE_URL=https://travel.example.com
+```
+
+- `.env`(Docker Compose)/ `.env.local`(Dockerを使わない場合)/
+  `docker-compose.standalone.yml`冒頭の`x-public-base-url` のいずれかに書く
+- パス部分は使わず、スキーム・ホスト・ポートだけを見る
+- `https://`を設定するとセッションCookieに`Secure`属性が付く。同じインスタンスに
+  LAN内から`http://<ホスト>:3000`で直接アクセスしてもログインできなくなる点に注意
+  (公開URL経由でアクセスすること)
+- 直接`http://<ホスト>:3000`で使う場合や、`X-Forwarded-*`を送るプロキシ(nginx等で
+  設定済み)の場合は設定不要
+
 </details>
 
 ### 本番運用
@@ -106,6 +126,15 @@ echo "SESSION_SECRET=$(openssl rand -base64 32)" >> .env
 docker compose pull && docker compose up -d
 ```
 
+- Composeのプロジェクト名は本番・開発・standaloneとも`travel-log`。以前は
+  `travel-log-prod`/`travel-log-dev`に分けていたため、**それ以前から動かしている
+  ホストでは初回だけ旧スタックを止めてから起動すること**(止めずに`up`すると、
+  同じ`db/data`とポート3000を奪い合う新旧2つのスタックが並ぶ)
+
+  ```bash
+  docker compose -p travel-log-prod down          # 開発機では -p travel-log-dev -f docker-compose.dev.yml
+  docker compose pull && docker compose up -d
+  ```
 - 公開されるイメージは2つ。`ghcr.io/rtcode337/travel-log`(アプリ本体)と
   `ghcr.io/rtcode337/travel-log-db-init`(DBの準備とマイグレーション適用)
 - **DBスキーマの更新は自動**。`docker compose up`すると`db-migrate`サービスが未適用の
@@ -128,6 +157,17 @@ docker compose pull && docker compose up -d
   イメージがいつのどのコミットのものか、pull後の反映確認に使える(ローカル開発時など
   埋め込みが無い場合は「開発ビルド」と表示される)
 
+#### リポジトリを置けない環境(NASのコンテナマネージャー等)
+
+`.env`もクローンも置けず、管理画面にYAMLを貼り付けて起動するタイプの環境向けに
+[docker-compose.standalone.yml](docker-compose.standalone.yml)を用意している。
+`${...}`を使わず値を直書きし、bindマウントを絶対パスで書いたもの(サービス構成・
+起動順は`docker-compose.yml`と同じ)。冒頭の「ここだけ編集」——3つの置き場
+(`db` / `db/data` / `photos`)の絶対パスと`SESSION_SECRET`——を書き換えて貼り付ければ起動する。
+
+`SESSION_SECRET`は空のままだとログイン時に`SESSION_SECRET is not set`で失敗するので、
+必ず32バイト程度のランダム文字列を入れること。
+
 ## 画面
 
 すべて`/[種別キー]/...`の形式(例: `/tourist/map`)で、種別ごとに切り替えて使う。

docker-compose.dev.yml

@@ -1,4 +1,4 @@
-name: travel-log-dev
+name: travel-log
 
 services:
   db:
@@ -49,6 +49,9 @@ services:
       SESSION_SECRET: ${SESSION_SECRET:-local-dev-secret-change-me}
       GOOGLE_CLIENT_ID: ${GOOGLE_CLIENT_ID:-}
       GOOGLE_CLIENT_SECRET: ${GOOGLE_CLIENT_SECRET:-}
+      # 公開URL(任意)。本番と同じ挙動を手元で試したいときだけ設定する
+      # (lib/auth/request-url.ts)
+      PUBLIC_BASE_URL: ${PUBLIC_BASE_URL:-}
       NODE_ENV: development
     ports:
       - "3000:3000"

docker-compose.standalone.yml

@@ -0,0 +1,127 @@
+# `.env` を置けず、リポジトリのクローンもできない実行環境向けの単体定義。
+# (NASのコンテナマネージャー等、管理画面にYAMLを貼り付けて起動するタイプの環境を想定)
+#
+# docker-compose.yml との違いは2点だけ:
+#   1. `${...}` を使わず、値をYAMLに直接書く(`.env`もシェルの環境変数も無い前提のため)
+#   2. bindマウントを相対パス(./db・./photos)ではなく絶対パスで書く
+#      (管理画面から登録する環境では相対パスの基準が分かりにくいため)
+# サービス構成・起動順(db-init → db → db-migrate → app)は本番用と同じ。
+#
+# 使い方:
+#   1. 「ここだけ編集」の置き場を、そのホストの絶対パスに書き換える
+#   2. SESSION_SECRET に32バイト程度のランダム文字列を設定する(必須)
+#   3. その内容を管理画面に貼り付けて起動する
+#   4. http://<ホスト>:3000/ を開く(初回アクセス時のセットアップで管理者アカウントを作る)
+#
+# 更新は管理画面の「イメージを最新にして再作成」相当の操作(`docker compose pull` +
+# `up -d`)だけでよい。未適用のマイグレーションは db-migrate が自動で当てる。
+# 特定時点に戻したいときは、下の2つの image のタグを `latest` から
+# `sha-xxxxxxx`(Actionsが付けるコミットSHAタグ)に変える —— ただしマイグレーションは
+# 前進のみで巻き戻せないため、スキーマ変更を伴うリリースを戻すにはDBのリストアが要る。
+#
+# 通常の(リポジトリを配置できる)環境では docker-compose.yml を使う
+# ——こちらは値の直書きぶん古くなりやすい。
+
+name: travel-log
+
+# ---- ここだけ編集: データの置き場(すべてホストの絶対パス) ----
+# db     … db-init が中に data/ を作る親ディレクトリ
+# db-data… Postgresの実データ。**必ず db の直下の data にすること**
+#          (db-init が /db/data を作って postgres(uid/gid 70)に chown するため)
+# photos … 訪問記録の写真。DBには相対パスだけが入るので、DBと一緒にバックアップする
+# いずれも無ければDockerが自動作成するが、先に作っておくのが確実。
+x-db-dir: &db-dir "/path/to/travel-log/db"
+x-db-data-dir: &db-data-dir "/path/to/travel-log/db/data"
+x-photos-dir: &photos-dir "/path/to/travel-log/photos"
+
+# ---- ここだけ編集: アプリの設定(.env の代わり) ----
+# セッションCookieの署名鍵(必須)。32バイト程度のランダム文字列を入れる
+# (生成例: openssl rand -base64 32)。空のままだとログイン時に
+# "SESSION_SECRET is not set" で失敗する。変更すると既存のログインセッションは
+# すべて無効になる(再ログインすれば直る)。
+x-session-secret: &session-secret ""
+# Googleでログイン(任意)。空のままならメールログインのみ。
+# 取得方法・リダイレクトURIの設定はREADMEの「Googleログインの設定」参照
+x-google-client-id: &google-client-id ""
+x-google-client-secret: &google-client-secret ""
+# 公開URL(任意。例: "https://travel.example.com")。
+# リバースプロキシ越し(HTTPS終端あり)で使う場合、プロキシが X-Forwarded-Proto /
+# X-Forwarded-Host を送らない構成だと、Googleログインのリダイレクトが http:// で
+# 組まれて認証に失敗する。そのときはここに公開URLを書いて明示する。
+# 直接 http://<ホスト>:3000 で使うなら空のままでよい。
+x-public-base-url: &public-base-url ""
+
+services:
+  # dbの起動前に、bindマウント先(db/data)の作成と所有者調整を行うワンショット
+  # (詳細は db/entrypoint.sh の prepare 関数のコメント参照)。
+  db-init:
+    image: ghcr.io/rtcode337/travel-log-db-init:latest
+    user: root
+    volumes:
+      - type: bind
+        source: *db-dir
+        target: /db
+    command: ["prepare"]
+    restart: "no"
+
+  db:
+    image: postgres:16-alpine
+    depends_on:
+      db-init:
+        condition: service_completed_successfully
+    environment:
+      # ホストにポート公開しないコンテナ間だけの接続。変えるなら db-migrate の
+      # PG* と app の DATABASE_URL も同じ値に揃えること
+      POSTGRES_USER: travel_log
+      POSTGRES_PASSWORD: travel_log
+      POSTGRES_DB: travel_log
+    volumes:
+      # db/init はマウントしない。スキーマ本体(01_schema.sql)は db-migrate が流す
+      - type: bind
+        source: *db-data-dir
+        target: /var/lib/postgresql/data
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U travel_log"]
+      interval: 5s
+      timeout: 5s
+      retries: 10
+    restart: unless-stopped
+
+  # スキーマ本体(/init/01_schema.sql)と未適用のマイグレーション(/migrations/*.sql)を
+  # 順に適用するワンショット。適用済みリビジョンは schema_migrations テーブルに記録され、
+  # 2回目以降は何もせず終了する。app はこれが正常終了するまで起動しない
+  # (古いスキーマのままアプリが動くのを防ぐ)。
+  db-migrate:
+    image: ghcr.io/rtcode337/travel-log-db-init:latest
+    depends_on:
+      db:
+        condition: service_healthy
+    environment:
+      PGHOST: db
+      PGUSER: travel_log
+      PGPASSWORD: travel_log
+      PGDATABASE: travel_log
+    restart: "no"
+
+  app:
+    image: ghcr.io/rtcode337/travel-log:latest
+    depends_on:
+      db-migrate:
+        condition: service_completed_successfully
+    environment:
+      DATABASE_URL: postgres://travel_log:travel_log@db:5432/travel_log
+      # 値は冒頭の「ここだけ編集」にまとめてある
+      SESSION_SECRET: *session-secret
+      GOOGLE_CLIENT_ID: *google-client-id
+      GOOGLE_CLIENT_SECRET: *google-client-secret
+      PUBLIC_BASE_URL: *public-base-url
+      NODE_ENV: production
+    volumes:
+      # 訪問記録の写真ファイル置き場(lib/photoStorage.ts)。DBには相対パスのみ保存される
+      - type: bind
+        source: *photos-dir
+        target: /app/photos
+    ports:
+      # host:container。LAN内からのみ見える状態にしておくこと
+      - "3000:3000"
+    restart: unless-stopped

docker-compose.yml

@@ -1,4 +1,4 @@
-name: travel-log-prod
+name: travel-log
 
 services:
   # dbの起動前に、bindマウント先(./db/data)の作成と所有者調整を行う
@@ -62,6 +62,10 @@ services:
       SESSION_SECRET: ${SESSION_SECRET:?SESSION_SECRET is required (openssl rand -base64 32)}
       GOOGLE_CLIENT_ID: ${GOOGLE_CLIENT_ID:-}
       GOOGLE_CLIENT_SECRET: ${GOOGLE_CLIENT_SECRET:-}
+      # 公開URL(任意)。リバースプロキシがX-Forwarded-Proto/Hostを送らない構成では
+      # これを設定しないとGoogleログインのリダイレクトURIがhttp://で組まれる
+      # (lib/auth/request-url.ts)。例: https://travel.example.com
+      PUBLIC_BASE_URL: ${PUBLIC_BASE_URL:-}
       NODE_ENV: production
     volumes:
       # 訪問記録の写真ファイル置き場(lib/photos.ts)。DBには相対パスのみ保存される