2026-05-19 に digitaldemocracy2030/kouchou-ai の PR #735 と Issue #685、および work/kouchou-ai/ の current origin/main を照合した観測メモ。Issue #685 は「公開 IP での HTTP アクセス時に crypto.randomUUID error と CSP violation が出る」「LocalLLM モデル取得が自動ではない」と報告しており、PR 本文もその解決を狙っている。github-dev-docsより
Observations
PR #735は 2025-12-05 作成の draft PR で、2026-05-19 時点でもstate: OPEN,isDraft: true,mergeable: CONFLICTING,reviewDecision: REVIEW_REQUIREDgh pr checksでは当時のbuild2 本とe2e-testsが fail、test2 本とCodeRabbitは pass- 差分は 8 files /
+331 -12で、変更対象はclient/とclient-admin/配下に限られる - しかし current
origin/mainの frontend はapps/public-viewer/とapps/admin/に再編済みで、client//client-admin/は現行 tree に存在しない。したがって PR の競合は単なる軽微な rebase 漏れではなく、frontend 再編前提の stale patch と読める。source-codeより
Current Main Gaps
- current
apps/admin/app/create/hooks/useAISettings.tsにはprovider === "local"時の自動フェッチはまだ入っておらず、手動fetchLocalLLMModels()呼び出し前提 - current
apps/public-viewer/next.config.tsとapps/admin/next.config.tsには PR #735 相当の CSP header 設定は入っていない - current
apps/admin/app/create/components/EnvironmentCheckDialog.tsxとapps/admin/app/create/hooks/useBasicInfo.tsでは今もcrypto.randomUUID()を直接呼んでいる
Interpretation
- つまり
Issue #685の問題意識自体は stale ではない - ただし
PR #735は current main にそのまま merge して問題解決できる状態ではなく、現行apps/*構成に合わせた再実装が必要 と考えるのが自然
Open Questions
crypto.randomUUID問題は、現行ブラウザ support policy 上どこまで polyfill で拾うべきか、それとも HTTP/non-secure access 自体を制限すべきか- CSP は公開 IP 直アクセスを恒久サポートする設計にするのか、dev / self-host 向けの限定対応に留めるのか
Updates
- 2026-05-19: 初版作成
- 2026-05-19: 後続 issue として
#833(Issue #685 follow-up: reimplement remote HTTP/CSP/UUID fixes on current apps/* tree) を作成し、PR #735はその issue へ誘導して close した