v0.11.5

Security

• OpenSearch Docker base image pinned by digest. The kuromoji-enabled OpenSearch image is now pinned to its manifest digest, completing digest pinning across every container image, and Dependabot watches the docker/ directory to bump it as the tag moves (#148).

Maintenance

• Updated the upload-artifact action used by the Scorecard workflow to its latest major version (#150).

---

セキュリティ

• OpenSearch の Docker ベースイメージを digest で固定。 kuromoji プラグイン入りの OpenSearch イメージをマニフェスト digest で固定し、全コンテナイメージの digest 固定が完了しました。Dependabot が docker/ ディレクトリを監視して digest を追従更新します（#148）。

保守

• Scorecard ワークフローが使う upload-artifact アクションを最新メジャーに更新しました（#150）。

v0.11.4

Security

• Docker base image pinned by digest. The Node base image is now pinned to its manifest digest for a reproducible, tamper-evident build, and Dependabot bumps the digest as the upstream tag moves (#145).
• OpenSSF Scorecard analysis and badge. A scheduled OpenSSF Scorecard workflow publishes supply-chain security results and surfaces them as a README badge (#146).

---

セキュリティ

• Docker ベースイメージを digest で固定。 Node ベースイメージをマニフェスト digest で固定し、再現性・改ざん検知性を確保しました。Dependabot が上流タグの移動に合わせて digest を追従更新します（#145）。
• OpenSSF Scorecard 分析とバッジ。 OpenSSF Scorecard の定期ワークフローがサプライチェーンのセキュリティ結果を公開し、README バッジとして表示します（#146）。

v0.11.3

Security

• All dependency vulnerabilities reported by pnpm audit are resolved. 29 advisories (10 high / 14 moderate / 5 low) were cleared by updating direct dependencies (including Astro to 7.x) and adding scoped pnpm.overrides for transitive packages, with no breaking major bumps to runtime libraries (#125).
• Supply-chain hardening for CI. All GitHub Actions are now pinned to full commit SHAs, workflow token permissions are scoped to least privilege, and Dependabot plus CodeQL static analysis run continuously (#124).

Bug Fixes

• Multi-site databases now get their PostgreSQL extensions. A newly deployed site previously failed to start because its per-site database role lacks the privilege to CREATE EXTENSION, so the worker's startup migration errored and tripped the ECS circuit breaker. The site-database provisioner now creates pg_trgm and vector as the master user, so first deploys succeed (#142).

Maintenance

• Removed a deprecated CDK pattern. The per-site database construct now uses an explicit logGroup instead of the deprecated logRetention, which also drops the extra Custom::LogRetention helper resources from the synthesized template (#143).
• Dependencies and pinned action versions updated, including aws-cdk-lib, Next.js, better-auth, and the CodeQL / checkout / setup-node / upload-pages-artifact / create-github-app-token actions (#141, #131, #127, #129, #130, #128, #139, #135).

Documentation

• Guidance on multi-environment AWS accounts. The docs now recommend separate AWS accounts for dev and prd, and document the ECR asset-tag push conflict that can occur when the same commit is deployed to two environments in one account near-simultaneously, along with how to avoid it (#137).

---

セキュリティ

• pnpm audit が検出した依存脆弱性をすべて解消しました。 29 件（high 10 / moderate 14 / low 5）を、直接依存の更新（Astro の 7.x 化を含む）と推移的依存への範囲限定の pnpm.overrides で解消し、ランタイムライブラリのメジャー更新による破壊は避けました（#125）。
• CI のサプライチェーン強化。 すべての GitHub Actions をコミット SHA に固定し、ワークフローのトークン権限を最小化、Dependabot と CodeQL 静的解析を常時実行するようにしました（#124）。

バグ修正

• マルチサイトのデータベースに PostgreSQL 拡張が作成されるようになりました。 従来、新規デプロイしたサイトは、サイト単位の DB ロールに CREATE EXTENSION 権限が無いため Worker 起動時のマイグレーションが失敗し、ECS circuit breaker が発動して起動できませんでした。サイト DB のプロビジョナーがマスターユーザーで pg_trgm / vector を作成するようにし、初回デプロイが成功します（#142）。

保守

• 非推奨の CDK パターンを解消しました。 サイト DB construct が非推奨の logRetention ではなく明示的な logGroup を使うようになり、合成テンプレートから余分な Custom::LogRetention ヘルパーリソースも削除されます（#143）。
• 依存とアクションの固定バージョンを更新しました（aws-cdk-lib・Next.js・better-auth、CodeQL / checkout / setup-node / upload-pages-artifact / create-github-app-token アクション等。#141, #131, #127, #129, #130, #128, #139, #135）。

ドキュメント

• マルチ環境の AWS アカウント運用に関する指針。 dev と prd で AWS アカウントを分けることを推奨し、同一アカウントで同一コミットをほぼ同時にデプロイした際に起こり得る ECR アセットタグの push 競合とその回避方法を明記しました（#137）。

v0.11.2

Bug Fixes

• AWS deploys no longer need Docker to bundle the site-database Lambda. The infrastructure package now declares esbuild directly, so the NodejsFunction bundling used by the multi-site database bootstrap always runs esbuild locally instead of falling back to a Docker build. This unblocks cdk synth / cdk deploy in environments without Docker (for example CodeBuild), which forks could previously hit because esbuild was only available at the workspace root (#122).

---

バグ修正

• AWS デプロイでサイト DB 用 Lambda のバンドルに Docker が不要になりました。 infra パッケージが esbuild を直接依存するようになり、マルチサイトのデータベースブートストラップが使う NodejsFunction のバンドルが常にローカルの esbuild で実行されます（Docker バンドルへのフォールバックを回避）。従来は esbuild がワークスペースのルートにしか無く、フォークの cdk synth / cdk deploy が Docker の無い環境（例: CodeBuild）で失敗し得ましたが、これが解消されます（#122）。

v0.11.1

Improvements

• A site's brand now treats 'default' exactly like leaving it unset. After the multi-brand refactor the default brand is a real brand named default, so writing brand: 'default' and omitting the field are now equivalent — both build the default web image with no KUKAN_BRAND build argument. Previously an explicit 'default' passed an unnecessary build argument that produced a different image asset hash for the same image. The environment-config reference documents the field's default value accordingly (#120).

---

改善

• サイトの brand で 'default' を指定した場合と未指定を完全に同じ扱いにしました。 マルチブランド化でデフォルトブランドは default という名前の実在ブランドになったため、brand: 'default' と省略は等価になり、どちらも KUKAN_BRAND ビルド引数なしでデフォルトの web イメージをビルドします。従来は明示的な 'default' が不要なビルド引数を渡し、同じイメージなのにアセットハッシュが変わっていました。環境設定リファレンスにも既定値を明記しています（#120）。

v0.11.0

Breaking Changes

• The default brand moved from apps/web/src/brand/ to apps/web/brands/default/. Multi-brand support (ADR-042) consolidates every brand under apps/web/brands/, and the default brand now lives alongside the others. Forks that customized the brand must run git mv apps/web/src/brand apps/web/brands/default once when upgrading, and move any static assets from apps/web/public/brand/ to apps/web/brands/default/public/. The @/brand imports and the runtime /brand/... URLs are unchanged, so no application code changes are needed. See the "Appearance Customization" guide for the full migration (#118).

Highlights

• One fork can now ship multiple brands, one per site (ADR-042). A KUKAN_BRAND build argument selects which brand under apps/web/brands/ becomes the web image's look — its configuration, theme, messages, component overrides, static pages, and assets. Only the selected brand enters a build, so brands never mix in a bundle. In a multi-site deployment each site's brand in the environment definition drives a per-site image, so several municipalities can share one fork while each keeps its own identity. The default brand needs no configuration and builds exactly as before (#118).
• Multi-site is now on equal footing with single-site and can be the default shape (ADR-041). New deployments can start multi-site from day one, because the three rough edges are gone: the us-east-1 ACM certificate and WAF WebACL are auto-created for site domains in standalone mode (matching single-site), AWS Backup works for multi-site with the shared database backed up once and each site's bucket backed up per site, and a burstable shared OpenSearch is a synth warning rather than a hard error. The example configuration now presents the multi-site shape first, keeping the single-site layout as a backward-compatible option, and a new environment-config reference documents every field (#117).

Features

• feat(infra): give multi-site parity with single-site so it can be the default (ADR-041) (#117)
• feat(web)!: multi-brand build via KUKAN_BRAND (ADR-042) (#118)

---

破壊的変更

• デフォルトブランドの置き場所が apps/web/src/brand/ から apps/web/brands/default/ へ移動しました。 マルチブランド対応（ADR-042）で全ブランドを apps/web/brands/ 配下に統合し、デフォルトブランドも他のブランドと同じ場所に置くようにしたためです。ブランドをカスタマイズしていたフォークは、アップグレード時に一度だけ git mv apps/web/src/brand apps/web/brands/default を実行し、apps/web/public/brand/ に置いていた静的アセットは apps/web/brands/default/public/ へ移してください。@/brand のインポートと実行時の /brand/... URL は不変なので、アプリケーションコードの変更は不要です。詳しい移行手順は「外観カスタマイズ」ガイドを参照してください（#118）。

ハイライト

• 1 つのフォークでサイトごとに異なるブランドを配布できるようになりました（ADR-042）。 ビルド引数 KUKAN_BRAND で、apps/web/brands/ 配下のどのブランド（設定・テーマ・文言・コンポーネント差し替え・静的ページ・アセット）を web イメージの見た目にするかを選択します。ビルドに入るのは選択した 1 ブランドのみで、ブランド同士がバンドルで混ざりません。マルチサイト構成では環境定義の各サイトの brand がサイトごとのイメージを決めるため、複数自治体が 1 つのフォークを共有しつつ、それぞれ独自の見た目を保てます。デフォルトブランドは設定不要で、従来どおりビルドされます（#118）。
• マルチサイトがシングルサイトと同等になり、標準の構成として選べるようになりました（ADR-041）。 3 つの引っかかりが解消され、新規構築は最初からマルチサイトで始められます。us-east-1 の ACM 証明書と WAF WebACL は standalone モードでサイトドメイン分が自動作成され（シングルサイトと同じ）、AWS Backup はマルチサイトでも利用可能になり（共有データベースは 1 回、各サイトのバケットはサイトごとにバックアップ）、burstable な共用 OpenSearch は synth 時のエラーではなく警告になりました。サンプル設定はマルチサイト形状を第一に提示してシングルサイト構成を後方互換の選択肢として残し、全フィールドを説明する環境設定リファレンスを新設しました（#117）。

機能

• feat(infra): マルチサイトをシングルサイトと同等にし標準構成として選べるように（ADR-041）（#117）
• feat(web)!: KUKAN_BRAND によるマルチブランドビルド（ADR-042）（#118）

v0.10.0

Highlights

• Multi-site deployment: run multiple data catalog sites on one shared infrastructure (ADR-041). One operator can now host several sites — for example, data catalogs for multiple municipalities — while sharing the hourly-billed backbone (database cluster, OpenSearch domain, VPC, ECS cluster) and keeping everything that holds data isolated per site: each site gets its own PostgreSQL database with a dedicated role that cannot reach other sites' data, plus its own search index, S3 bucket, SQS queue, web/worker services, and CloudFront distribution with its own domain. Multi-site is strictly opt-in via a sites list in the environment definition; environments without it keep today's single-stack layout unchanged (#106, #107, #108).
• The multi-site configuration validates itself before anything reaches CloudFormation. Site names, per-site certificate requirements, and the shared database's connection budget are checked at synth. The connection check uses the AWS-documented Aurora Serverless v2 limits (including the 2,000-connection cap that a 0/0.5 minimum ACU imposes and the 5,000 absolute ceiling), counts the extra connections of one site's rolling update, and its messages tell you which setting actually helps — including when none does and the sites should be split across clusters (#111, #113, #115).
• On-premises multi-site with Docker Compose. Opt-in templates under docker/multi-site/ build the same shared-boxes/per-site model with Compose: one shared stack (PostgreSQL / MinIO / ElasticMQ / OpenSearch / Ollama / Caddy) plus one web/worker pair per site, with a runbook covering setup, adding and purging sites, capacity planning, and the security boundary of the shared services (#109).
• A golden-set evaluation harness for AI metadata suggestions. pnpm eval:suggest runs a golden dataset file against a live instance and reports per-field scores, latency, and hallucination canaries — built for comparing models, providers, and prompt changes side by side. The admin dashboard now also shows a quality caveat when suggestions run on a local model (#104, #105).

Features

• feat(api): add golden-set evaluation harness for AI metadata suggestions (#104)
• feat(web): show a quality caveat when AI suggestions run on a local model (#105)
• feat(search): wire OPENSEARCH_INDEX_PREFIX through to the OpenSearch adapter (ADR-041) (#107)
• feat(infra): add multi-site SharedStack/SiteStack deployment (ADR-041) (#108)
• feat(docker): add opt-in multi-site compose templates (ADR-041) (#109)
• feat(infra): validate the shared-database connection budget at synth (ADR-041) (#111)

Bug Fixes

• fix(infra): reject site-scoped fields on multi-site environment entries (ADR-041) (#113)

Improvements

• refactor(infra): add synth snapshot guard and extract stack composition (ADR-041) (#106)
• refactor: simplify the ADR-041 series and fix review findings (#115)

Documentation

• docs(adr): add ADR-041 multi-site deployment and ADR-042 multi-brand build (#61)
• docs: mark ADR-041 as accepted and add multi-site deployment guide (#110)
• docs(site): add multi-site operation guide (#112)
• docs(site): add multi-site deployment spotlight to the landing page (#114)

---

ハイライト

• マルチサイトデプロイ: 1 つの共有インフラで複数のデータカタログサイトを運用できるようになりました(ADR-041)。 複数自治体のデータカタログのように、1 つの運用主体が複数サイトをホストする際、時間課金される基盤(データベースクラスタ、OpenSearch ドメイン、VPC、ECS クラスタ)を共有しつつ、データを持つものはすべてサイト別に分離します — 各サイトは他サイトのデータへ到達できない専用ロール付きの PostgreSQL データベースを持ち、検索インデックス・S3 バケット・SQS キュー・web/worker サービス・独自ドメイン付き CloudFront もサイトごとに独立します。マルチサイトは環境定義の sites リストによる完全な opt-in で、sites の無い環境は従来の単一スタック構成がそのまま維持されます(#106, #107, #108)。
• マルチサイト設定は CloudFormation に到達する前に自己検証されます。 サイト名、サイトごとの証明書要件、共有データベースの接続数バジェットを synth 時に検査します。接続数の検査は AWS 公式ドキュメントの Aurora Serverless v2 上限(最小 0/0.5 ACU 時の 2,000 接続キャップ、絶対上限 5,000 を含む)に基づき、ローリング更新中の 1 サイト分の追加接続も計上します。エラーメッセージは「どの設定を変えれば実際に解決するか」— どの設定でも解決せずクラスタ分割が必要な場合を含めて — を案内します(#111, #113, #115)。
• Docker Compose によるオンプレミスのマルチサイト構成。 docker/multi-site/ の opt-in テンプレートが同じ「箱共有・サイト別分離」モデルを Compose で構成します: 共有スタック(PostgreSQL / MinIO / ElasticMQ / OpenSearch / Ollama / Caddy)1 つ + サイトごとの web/worker ペア。セットアップ、サイトの追加・削除、キャパシティ計画、共有サービスのセキュリティ境界を手順書にまとめています(#109)。
• AI メタデータ提案のゴールデンセット評価ハーネス。 pnpm eval:suggest がゴールデンデータセットを稼働中のインスタンスに対して実行し、フィールド別スコア・レイテンシ・ハルシネーション検出をレポートします — モデル・プロバイダー・プロンプト変更の比較用です。あわせて、ローカルモデルで提案が動作している場合に管理画面へ品質注記を表示するようになりました(#104, #105)。

機能

• feat(api): AI メタデータ提案のゴールデンセット評価ハーネスを追加（#104）
• feat(web): ローカルモデルで AI 提案が動作する場合に品質注記を表示（#105）
• feat(search): OPENSEARCH_INDEX_PREFIX を OpenSearch アダプターへ配線（ADR-041）（#107）
• feat(infra): マルチサイト SharedStack/SiteStack デプロイを追加（ADR-041）（#108）
• feat(docker): opt-in のマルチサイト compose テンプレートを追加（ADR-041）（#109）
• feat(infra): 共有データベースの接続数バジェットを synth 時に検証（ADR-041）（#111）

バグ修正

• fix(infra): マルチサイト環境の env エントリでサイトスコープのフィールドを拒否（ADR-041）（#113）

改善

• refactor(infra): synth スナップショットガードの追加とスタック合成の関数抽出（ADR-041）（#106）
• refactor: ADR-041 シリーズの簡素化とレビュー指摘の修正（#115）

ドキュメント

• docs(adr): ADR-041 マルチサイトデプロイ・ADR-042 マルチブランドビルドを追加（#61）
• docs: ADR-041 を承認済みへ変更しマルチサイトデプロイガイドを追加（#110）
• docs(site): マルチサイト運用ガイドを追加（#112）
• docs(site): LP にマルチサイトデプロイのスポットライトを追加（#114）

v0.9.0

Highlights

• AI metadata suggestions are now generated per resource, in parallel. Instead of one large LLM call that had to describe every file at once, each resource gets its own small completion and a final call integrates the results (ADR-040). This structurally removes the failure modes of small local models on large prompts, lets every file be judged with its full extracted material, raises the suggestion slots from 10 to 20 resources per dataset, and keeps the whole request inside a bounded time budget — a resource that fails or does not fit degrades to lightweight context instead of breaking the suggestion (#101).
• Suggestions now cover categories and the URL identifier. The integration step picks dataset categories from the site's existing groups only (the most-used 100 as candidates, with their descriptions; a dataset without a category gets a best-match pick), and proposes a URL slug for drafts, normalized and uniqueness-checked server-side. Tag and category suggestions are additions-only — adopting can never remove an existing value — and adopted dataset fields are saved immediately without a separate save step. The per-user limit was raised from 20 to 60 suggestions per hour to support regenerating a few times and picking the best result (#101).

Features

• feat(api): per-resource parallel metadata suggestions with category and URL slug (ADR-040) (#101)

Improvements

• chore(infra): enable CodePipeline V2 pipeline type via CDK feature flag (#102)

Documentation

• docs(adr): switch metadata suggestions to per-resource parallel generation (ADR-040 addendum) (#100)

---

ハイライト

• AI メタデータ提案がリソース単位の並列生成になりました。 全ファイルを 1 回の大きな LLM 呼び出しで記述する方式をやめ、リソースごとに小さな completion を並列実行し、最後に 1 回の統合呼び出しでデータセット全体をまとめます（ADR-040）。大きなプロンプトで起きていた小型ローカルモデルの破綻が構造的に解消され、各ファイルが自身の抽出素材をフルに使って記述されるようになり、提案対象は 1 データセットあたり 10 → 20 リソースに拡大しました。リクエスト全体は時間予算内に収まり、失敗・間に合わないリソースは提案を壊さず軽量コンテキストに降格します（#101）。
• カテゴリーと URL 識別子も提案対象になりました。 統合ステップがサイトの既存グループ（使用数上位 100 件を説明付き候補として提示、カテゴリー未設定のデータセットには最適 1 件を要求）からカテゴリーを選び、下書きには正規化・一意性確認済みの URL スラッグを提案します。タグ・カテゴリーの提案は追加専用で、採用によって既存の値が削除されることはありません。採用したデータセット側フィールドは保存ボタンなしでその場で保存されます。「何度か生成させて良いものを選ぶ」使い方に合わせ、ユーザーあたりの利用上限を 20 → 60 回/時に緩和しました（#101）。

機能

• feat(api): リソース単位の並列メタデータ提案とカテゴリー・URL スラッグ対応（ADR-040）（#101）

改善

• chore(infra): CDK フィーチャーフラグで CodePipeline V2 パイプラインタイプを有効化（#102）

ドキュメント

• docs(adr): メタデータ提案をリソース単位並列生成へ切り替え（ADR-040 追記）（#100）

v0.8.6

Highlights

• AI metadata suggestions now wait until every resource finishes processing. Previously the "Suggest metadata with AI" button and its nudge activated as soon as a single resource completed, so a suggestion could be generated while other resources were still uploading or being extracted — and silently leave them out. The button and nudge now activate only after all pipelines settle (including error endings). The gate closes before any request that starts a new pipeline is sent, and list-refresh and publish race conditions that could freeze the gate or roll statuses backwards were hardened away (#96).
• Brand customization now has a token operation policy. The appearance customization guide rates every CSS token — Recommended / Caution / Not recommended — together with its main usage locations and states (e.g. --accent drives button hover and dropdown selection), so deciding whether an override is safe no longer requires reading the source. Forks also get an official --brand-* namespace for designer-specified colors that fit no official token role, and component-scoped alias tokens can be added on demand to recolor a single upstream component without side effects (ADR-023) (#97).

Features

• feat(web): gate AI metadata suggestions until all resource processing settles (#96)

Documentation

• docs: define brand token operation policy and add override ratings (ADR-023) (#97)
• docs: note small local models are underpowered for AI metadata suggestion (#95)

Improvements

• ci: retry public mirror pushes on transient failures (#94)

---

ハイライト

• AI メタデータ提案が、すべてのリソース処理の完了を待つようになりました。 従来は 1 件のリソースが完了した時点で「AI にメタデータを提案させる」ボタンとナッジが活性化し、他のリソースがまだアップロード・抽出中でも提案が生成でき、それらが提案から漏れてしまうことがありました。すべてのパイプラインが終了（エラー終了を含む）してから活性化するようになり、パイプラインを起動する操作はリクエスト送信前からゲートを閉じ、リスト再取得や公開操作との競合でゲートが固まる・ステータスが巻き戻る問題も解消しています（#96）。
• ブランドカスタマイズにトークン運用ポリシーが定義されました。 外観カスタマイズガイドの CSS トークン表に上書き区分（推奨 / 注意 / 非推奨）と主な使用箇所・状態（例: --accent はボタンのホバーやドロップダウンの選択状態に波及）を明記し、上書き可否の判断にソースコードの調査が不要になりました。公式トークンの役割に当てはまらない独自色のためにフォーク専用の --brand-* 名前空間を新設し、本体画面の特定コンポーネントだけを安全に変えるためのエイリアストークンを需要ベースで追加する運用も定めています（ADR-023）（#97）。

機能

• feat(web): AI メタデータ提案の活性化をすべてのリソース処理の完了後に変更（#96）

ドキュメント

• docs: ブランドトークン運用ポリシーと上書き区分を定義（ADR-023）（#97）
• docs: 小型ローカルモデルは AI メタデータ提案には性能不足である旨を記載（#95）

改善

• ci: 公開ミラーへの push を一時的な障害発生時にリトライ（#94）

v0.8.5

Highlights

• AI metadata suggestions now read PDF and Office documents and ZIP archives. The pipeline persists the head of the text it already extracts from documents (PDF / DOCX / XLSX / PPTX / ODT / ODP / ODS / RTF) as a small storage artifact, and the suggestion API uses it — together with ZIP file listings — as generation material, with no extra download or parsing at suggestion time. This also works while a dataset is still a draft, where suggestions matter most: drafts now produce the artifact during editing, while their content continues to stay out of the search index until publish (ADR-040) (#89).
• Suggestions describe each resource first, then summarize the dataset. The model now writes each resource's name and description independently from that resource's own material, and only then writes the dataset title, description, and tags as an integration of those descriptions — so a single file no longer dominates a dataset that mixes resources of different natures. Guardrails for small local models were added as well: the opening lines of a document (usually its own title) outweigh recurring body themes, and proper nouns that appear nowhere in the material are not invented (#91).

Features

• feat: add PDF/Office/ZIP content materials to AI metadata suggestions (ADR-040) (#89)
• feat(api): generate resource suggestions before dataset metadata (ADR-040) (#91)

Bug Fixes

• fix(web): pipeline status badges no longer stick on "queued" / "processing" when bulk-uploaded resources finish processing between polls — the badge now trusts the fresher status delivered by the list refresh (#90)

Documentation

• docs(adr): promote PDF/Office/ZIP content materials to ADR-040 implementation (#88)
• docs: spotlight AI metadata suggestions on the landing page (#92)

---

ハイライト

• AI メタデータ提案が PDF・Office 文書・ZIP アーカイブの内容を読めるようになりました。 パイプラインが文書（PDF / DOCX / XLSX / PPTX / ODT / ODP / ODS / RTF）から抽出済みのテキストの先頭を小さな成果物として Storage に保存し、提案 API はそれと ZIP のファイル一覧を生成素材として使います。提案時の追加ダウンロードやパースはありません。提案が最も活きる下書き編集中のデータセットでも成果物が生成されます（下書きの内容が公開まで検索に出ない挙動は従来どおりです）（ADR-040）（#89）。
• 提案は「各リソースを先に記述してからデータセットを統合する」順で生成されます。 各リソースの名前・説明をそのリソース自身の素材から独立に記述した後で、データセットのタイトル・説明・タグをその統合として書くため、性質の異なるリソースが混在するデータセットで 1 つのファイルの内容が全体を支配しなくなりました。小型ローカルモデル向けのガードレールも追加しています: 文書の冒頭行（多くは文書自身のタイトル）を本文の頻出テーマより重視し、素材のどこにも現れない固有名詞を発明しません（#91）。

機能

• feat: AI メタデータ提案に PDF/Office/ZIP のコンテンツ素材を追加（ADR-040）（#89）
• feat(api): リソースの提案をデータセットのメタデータより先に生成（ADR-040）（#91）

バグ修正

• fix(web): 一括アップロード時にパイプラインステータスが「待機中」「処理中」のまま固まることがある問題を修正しました。ポーリングの合間に処理が完了した場合でも、リスト再取得が持つ新しいステータスが表示されます（#90）

ドキュメント

• docs(adr): PDF/Office/ZIP コンテンツ素材対応を ADR-040 の実装に格上げ（#88）
• docs: ランディングページで AI メタデータ提案を紹介（#92）