2026-05-25 に work/kouchou-ai/ の current main と GitHub PR 状態を確認し、LLM grouping 系 llm_grouping 実装の足場がどこまで main にあるかを観測したメモ。gh pr view 827 -R digitaldemocracy2030/kouchou-ai --json state では PR #827 は MERGED で、計画文書 PLAN_llm_grouping_capabilities.md は current tree に存在する。github-dev-docsより
観測事項
PLAN_llm_grouping_capabilities.mdは repo root に存在し、短期はanalysis_mode=llm_grouping+ viewer 互換、長期はanalysis_capabilitiesとrequirementsの導入、という二段計画を main 上の文書として保持している。source-codeよりpackages/analysis-core/src/analysis_core/orchestrator.pyではrun_default()がrun_workflow()を呼ぶ canonical path になっている。したがって、LLM grouping 系実装を入れるなら deprecated な direct-steprun()ではなく workflow path 側に差し込むのが current tree と整合する。source-codeより- ただし同ファイルの
run_workflow()は現状HIERARCHICAL_DEFAULT_WORKFLOWを固定で使っており、analysis_modeに応じた workflow 切替はまだない。source-codeより packages/analysis-core/src/analysis_core/workflows/hierarchical_default.pyもextraction -> embedding -> hierarchical_clustering -> ...の固定列で、llm_groupingステップは存在しない。source-codeよりapps/public-viewer/components/charts/plugins/types.tsには mode ごとのcanBeDisabled/isDisabledはあるが、plugin manifest のrequirementsはまだ無い。source-codeよりapps/public-viewer/type.tsのResult型にもanalysis_capabilitiesフィールドはまだ無い。viewer は今のところclusters構造を直接見て scatter detail / density の可否を場当たり的に判定している。source-codeより
含意
- 計画文書だけを見ると「mode 切替と capability gating はすぐ入りそう」に見えるが、current
mainの実装差分としては- analysis-core の workflow 分岐
llm_groupingステップ- aggregation/result schema への capability 追記
- viewer plugin manifest の
requirementsの 4 段がまだ残っている。source-codeより
- 一方で viewer 側には既に plugin registry と mode disable の仕組みがあり、完全新設ではなく 既存の disable 判定を capability ベースへ一般化する 方向で進められる。source-codeより
Open Questions
analysis_mode切替を config 正規化レイヤで持つのか、workflow definition 選択レイヤで持つのかllm_groupingを 1 ステップで「グループ発見 + assignment + cluster-level-* 互換生成」まで持つのか、複数 step に分けるのかanalysis_capabilitiesの source of truth を result JSON のみとし、viewer 側再計算は fallback に留めるのか
Updates
- 2026-05-25: 初回作成