chore(webapp): 純粋な JS/TS パッケージを dependencies から devDependencies へ移動する

[konokenj]

executor 07（全コードベースのコードレビュー）が発見し、独立したセキュリティレビュー（サブエージェント, opus-4.7）で裏付けた。

問題

AGENTS.md にはこう書かれている:「Dependencies: esbuild and Next.js bundle everything, so only packages with native binaries needed at Lambda runtime belong in dependencies. Everything else goes in devDependencies.」（esbuild と Next.js がすべてをバンドルするため、Lambda 実行時にネイティブバイナリを必要とするパッケージのみが dependencies に属する。それ以外はすべて devDependencies へ。）

apps/webapp/package.json:18-39 は、純粋な JavaScript/TypeScript パッケージを dependencies 配下に宣言している:

• @aws-amplify/adapter-nextjs, @aws-sdk/client-lambda, @aws-sdk/client-ssm
• @repo/db, @repo/event-utils, @repo/shared-types（ワークスペースパッケージ）
• aws-amplify
• class-variance-authority, clsx
• drizzle-orm
• lucide-react
• next, next-safe-action, next-themes
• react, react-dom, react-hook-form
• sonner
• tailwind-merge, tw-animate-css
• zod

比較として、apps/async-job/package.json と apps/db-migrator/package.json はすべてを devDependencies に正しく配置し、ビルド時の esbuild によるバンドルに依存している。

webapp の Docker イメージは Next.js の output: 'standalone' を使うため、実行時に Lambda が実行するのは apps/webapp/.next/standalone/* のみである。standalone がトレースして出力に含めたものが実際に動作する対象であり、dependencies リストは実行時のクロージャではない。実行時に不要なパッケージを dependencies に残すと、推移的なインストールクロージャが肥大化し、Dependabot の監査対象が不明瞭になり、キットのコピー利用者に誤ったパターンを示してしまう。

根拠

• 正規表現: apps/webapp/package.json の dependencies。
• AGENTS.md の Conventions セクション。
• Docker ビルド: apps/webapp/Dockerfile:1-29（ビルダはワークスペース全体をインストールし、ランナーには .next/standalone + .next/static + run.sh のみをコピーする）。

対応の方向性

Next.js の standalone トレーシングが実行時の外部依存として必要としない各パッケージを devDependencies へ移動する。イメージを再ビルドしてスモークテストで検証する。ネイティブ限定の例外（もし現れれば、例: sharp）はコメント付きで dependencies に残してよい。

apps/webapp はこの点で apps/async-job と同じ見た目になるはずである。

サンプルとしての教育的リスク

コピー利用者は肥大化した本番依存セットを引き継ぎ、サプライチェーンアラートの対象を広げ、ベースイメージサイズに関するコスト/複雑さの議論を悪化させる。

関連

• executor 07 の発見まとめ: .kiro/specs/v3-release-prep/review-full-report.md (M3)

[konokenj]

Closing: this issue was filed by an automated code review during v3 release preparation. Per repository policy, review findings are handled within the release review process, not as individual issues. The finding is preserved in the release review reports and will be addressed there if accepted.

[konokenj]

Reopening after maintainer triage of the v3 release code review: accepted into the v3-fix milestone as a discussion item — the direction needs to be decided before implementation. See the discussion points below.

[konokenj]

Maintainer triage — decide between two directions before implementing:

1. Fix the code: move pure JS/TS packages to devDependencies per the AGENTS.md rule. Requires a smoke test that the Next.js standalone output tracing still bundles everything needed at Lambda runtime (expected to work, unverified).
2. Relax the rule: change AGENTS.md to match the current practice if there is a reason to keep runtime deps explicit.

Leaving the documented rule and the code in contradiction is the only unacceptable outcome.