2026 年 5 月 28 日

• プロジェクト作成
• 農業ゲームコンセプト整理
• ゲームアセット収集およびダウンロード完了（132 個 PNG）
  • GitHub リポジトリクローン: GuardianofNature, FarmLands, Sproutville, OldTownFarm, claude-farmer
  • 出典: Sprout Lands (Cup Nooble, CC0), SpriteCook (CC0), Kenney (CC0), CraftPix (Free License)
  • アセット分類: characters (26 個), tiles (19 個), objects (36 個), ui (31 個)
  • すべて商用利用可能
• CI/CD パイプライン設定: GitHub Actions + reviewdog + ESLint + actionlint
  • ESLint v9 フラットコンフィグ移行（.eslintrc.json → eslint.config.js）
  • reviewdog fail_level バグ修正（errors → error）
  • CodeRabbit AI PR レビュー — すべてのチェック合格（5/5 ✅）
  • CodeFactor 連携完了 — コードスコア（A~F）自動評価
• AI ツール連携: CodeRabbit + Qwen Code（RunPod self-hosted）
• LLM: Qwen 3.6 35B（RunPod）で開発実施
• 開発振り返り: docs/retrospectives/2026-05-28.md

アセット構造

assets/
├── characters/    - キャラクター、動物スプライト
├── tiles/         - タイルセット（地面、水、建物、環境）
├── objects/       - 家具、作物、木、道具
├── ui/            - ボタン、ダイアログボックス、アイコン、マウスカーソル
├── music/         - BGM（未整理）
└── sfx/           - 効果音（未整理）

Godot 公式文書 RAG データ準備

Godot 3/4 判別器と今後の Qwen ベース Godot コーディングモデル学習のために、公式文書ベースの RAG データを別途構築した。目的は LLM がラベルを任意に決定する構造ではなく、公式文書からの根拠チャンクとシステムルールに基づいてラベル候補を作成し、LLM は説明／修正コード／学習データ生成補助のみを担うことである。

関連文書は次の場所に集める。

• docs/README.md: 文書ディレクトリインデックス
• docs/research-notes/: 設計メモとデータ生成構造
• docs/roadmaps/: 全体開発ロードマップ
• docs/retrospectives/: 日付別回顧
• work/godot_rag/: 現在空。RAG チャンク／後処理成果物は削除済み
• outputs/godot_docs_full/: Godot 公式文書クロール結果

関連回顧:

• docs/retrospectives/2026-06-17-godot-rag-judge.md
• docs/retrospectives/2026-06-18-godot-rag-reset.md

Source Data

RAG に使用する公式文書原本は次のパスである。

outputs/godot_docs_full/pages

outputs/godot_docs_stableは中間復元フォルダーであり、RAG基準データとして使用しません。

最終収集検証:

Official search index target pages: 1568
Collected markdown pages: 1570
Missing pages: 0
Failed fetches: 0

2個が多い理由は @GDScript、@GlobalScope の URL エンコードエイリアスが一緒に収集されたためです。

チャンクングステータス

6月17日に作成したRAGチャンクング/後処理/カタログ成果物は、6月18日に基準線から削除しました。

削除した範囲：

v1 docs_chunks.jsonl  
v2 docs_chunks_v2.jsonl  
v3/v3.1 catalog/index/mapping 成果物  
チューニング/後処理/検証 草案スクリプト  
初期 chat/index 草案

削除理由：

元の公式ドキュメント構造を十分に分析しないままチャンク化を進めました。  
LLMにチャンク化と後処理を任せたことで、中間判断が不透明になりました。  
一部の API をコア MVP と見なしたりハードコーディングしたりする方向に流れ、全体のドキュメントベース RAG の目的が揺らぎました。  
結果として、チャンクの品質、メタデータ、カタログの信頼性を個別に検証することが困難な状態になりました。

次の作業は新しいチャンクをすぐに作成することではなく、outputs/godot_docs_full/pages の元文書の実際の構造をまず分析することです。