curiosity-wiki Operations Flow

curiosity-wiki の運用パイプライン全体像。 Task Scheduler が起動するオーケストレーターから、intake / governance / graphify の各フローを経て operations cockpit に集約されるまでのデータフローを可視化。 Phase 5 感度最適化パイプライン (8エージェント + 9 Task Scheduler) と Phase 6 Canonicalレイヤーは LLMWIKI Pipeline タブを参照。 ファイル名より先に「何をするか」を読む。コードを読まなくても運用の流れが追える図。

External Data Sources Obsidian Vault VaultD KB文書・ナレッジ OpenClaw Workspace 設定・critical_facts・preferences GitHub API 公開/非公開リポジトリ情報 IntakeMetadata 1日4回 取り込みパイプライン起動 02:00/08:00/14:00/20:00 graduatedモード RepoGovernance 週次 GitHub全リポジトリ棚卸し セキュリティ監査・ティア判定を含む WeeklyMaintenance 週次 snapshot+discover+governance Wikiの状態保存後に各種メンテ実行 run_intake_metadata_pipeline.py 取り込み+正規化+監視を一括実行 discover→route→GLM→finalize→health更新 run_repo_governance_cycle.py 品質・安全・重要度を一括チェック registry→governance→portfolio→境界監査 run_weekly_maintenance.py snapshot → discover → governance → lint run_curiosity_cycle.py sync → finalize → monitor (手動/アドホック) Intake Pipeline raw/00-inbox/ 新着文書の入口 sync_vaultd_raw.py VaultD KB文書をコピー Obsidian Vaultから最新文書を取得 sync_workspace_raw.py OpenClaw設定を同期 critical_facts・user_preferencesを反映 discover_obsidian_candidates.py 取り込み候補をスコアリングで選定 更新頻度・重要度・鮮度で優先順位付け route_ingest.py ファイルをinbox/staging/ quarantineに振り分け GLM-5 Batch build_payload GLM用入力JSON組立 run_via_zai z.ai API経由でGLM正規化 validate + review + apply 応答検証 → フロントマター更新 finalize_ingest.py staging → 正式raw/に確定 (失敗→quarantine) 01-staging/ 正規化処理中 02-quarantine/ 検証失敗・隔離 vaultd/ | github/ 恒久的な配置先 raw/ vaultd/ | openclaw-workspace/ | github/ curiosity-wikiの本体データストア build_metadata_summary_index.py 全mdのフロントマターを集計して索引化 活動・関心・プロジェクト連携を可読化 Auto-Intake build_auto_intake_proposal.py 自動取り込み候補を1件選んで提案 スコア最高の未処理候補をピックアップ build_discover_preview.py 候補スキャン結果をJSONに変換 cockpitダッシュボード表示用データ Dry-Run Gates proposal_dry_run 選定シミュレーション finalize_dry_run 配置シミュレーション normalize_dry_run GLM正規化シミュレーション 3つ全通過で trial_apply 実行 run_auto_intake_trial_apply.py 1件の自動取り込みをE2Eで実行 discover→route→normalize→finalizeを一貫実行 build_auto_intake_graduation.py trial→graduated昇格判定 成功率と安定性で自動化レベルを評価 build_auto_intake_history トライアル実行履歴の集計 成功/失敗/スキップの統計レポート build_auto_intake_task_sync Task Schedulerのモードを graduation判定と同期 → discover_preview.json cockpitに候補状況表示 Governance update_github_repo_registry GitHub全リポジトリ情報を取得・更新 GitHub APIで公開/非公開リポを一括収集 build_portfolio_review ポートフォリオ審査候補を選定 長期放置・低活動リポの棚卸し対象を抽出 build_repo_governance_index 優先度ティア+アクション推奨を算出 archive / refresh / maintain build_public_boundary_audit 公開文書の秘密情報漏洩チェック Windowsパス・トークン・Bearer検出 → cockpit governance section registry/tier/auditを日本語可読化 Health & Ops build_intake_health 取り込み健全性計測 成功率・エラー率・滞留件数を算出 build_lint_health メタデータ品質検出 YAML形式・タグ一貫性・矛盾パターン検出 build_user_context ユーザー文脈の鮮度確認 critical_facts・preferencesの最終更新チェック Filed-Back Pipeline build_filed_back_proposal 再利用価値の高い生成物を選定 Claude生成物をWiki還元候補として評価 build_filed_back_action カタログ収録か却下かを判定 品質・重複・鮮度で採否を自動判定 build_filed_back_catalog → 採用済み一覧 build_operations_cockpit.py 全サブシステムの状態を 日本語ダッシュボードに集約 Graphify Pipeline rebuild_via_zai.py raw/全mdをチャンク分割して送信 キャッシュ付き中断再開に対応 z.ai API (GLM-5) 意味グラフ断片を抽出 graphify: build → cluster → analyze (God Nodes / Surprising Connections) 重複除去 → コミュニティクラスタリング → レポート生成 operations_cockpit.md 全状態を日本語1枚にまとめた運用ダッシュボード 15+個のJSON状態ファイルを可読化 metadata_summary_index.md 最近の活動・関心・プロジェクト連携の索引 日本語即読 .md + 構造化 .json graphify-out/ GLM-5ナレッジグラフとレポート graph.html / graph.json / GRAPH_REPORT.md curiosity-wiki-bootstrap.py セッション開始時にユーザー文脈を自動注入 SessionStartフックでcritical_factsを読込 llmwiki-user-context.md ユーザー特徴を聞かれたときの参照導線 ツール選定・プロジェクト優先順位の判断基準 raw/ Source Family vaultd/ | openclaw-workspace/ | github/
100%

External Data Sources

  • Obsidian Vault: VaultD KB文書・ナレッジの取り込み元
  • OpenClaw Workspace: critical_facts・preferences等の設定元
  • GitHub API: 公開/非公開リポジトリ情報の取得元

Task Schedulers

  • IntakeMetadata: 1日4回 取り込みパイプライン全体を自動起動
  • RepoGovernance: 週次でGitHub棚卸し+セキュリティ監査
  • WeeklyMaintenance: 週次でsnapshot+discover+governance

Intake Pipeline

  • discover: 取り込み候補をスコアリングで選定
  • route: inbox/staging/quarantineに振り分け
  • GLM-5: z.ai API経由でメタデータ正規化
  • finalize: 重複チェック+正式配置

Auto-Intake

  • proposal: 候補1件を選んで提案
  • dry-run: 3ゲート通過で初めて実行
  • trial_apply: E2Eで1件を自動取り込み
  • graduation: trial→graduatedへ昇格判定

Governance

  • registry: GitHub APIで全リポジトリを収集
  • governance_index: ティア+アクション推奨を算出
  • boundary_audit: 公開文書の秘密情報漏洩チェック

Health & Ops

  • intake_health: 成功率・エラー率・graduation判定
  • lint_health: YAML形式・タグ・矛盾パターン検出
  • filed-back: 生成物をWiki還元候補として選定
  • cockpit: 全状態を日本語1枚に集約

raw/ Data Store

  • curiosity-wikiの本体データストア（シリンダー表示）
  • vaultd/ | openclaw-workspace/ | github/ の3系統
  • Intake Pipelineが書き込み、Graphify/Governance/Healthが読み出す

Graphify Pipeline

  • rebuild_via_zai: raw/全mdをチャンク分割してGLM-5に送信
  • z.ai API: 意味グラフ断片を抽出（処理サービス）
  • graphify: build→cluster→analyze→レポート生成
  • 出力: GRAPH_REPORT.md / graph.html / graph.json
IntakeMetadata いつ取り込みが走るか 4回/日 (02:00/08:00/14:00/20:00) graduated モード: 完全自動で取り込みパイプラインを起動 RepoGovernance いつリポジトリをチェックするか 週次: GitHub上の全リポジトリを棚卸し セキュリティ監査・ティア判定・ポートフォリオ審査を一括実行 WeeklyMaintenance いつ定期メンテナンスが走るか 週次: snapshot + discover + governance + lint Wikiの状態を丸ごと保存してから各種メンテを実行 run_intake_metadata_pipeline.py 取り込み+正規化+監視を一括で走らせる discover → route → GLM-5正規化 → finalize 取り込み後に health / proposal / cockpit を全更新 intake pipeline タブで詳細 run_repo_governance_cycle.py リポジトリの品質・安全・重要度を一括チェック registry → governance → portfolio → 境界監査 公開リポジトリに秘密情報が漏れていないか検出 governance タブで詳細 run_weekly_maintenance.py 週次でsnapshot・discover・governanceを順に走らせる スナップショット取得 → 候補発見 → ガバナンスサイクル lint / user_context / filed_back / cockpit を全更新 health & ops タブで詳細 run_curiosity_cycle.py sync → finalize → monitor の短周期フルサイクル VaultD/workspace同期 → finalize → 全監視スクリプト更新 --with-zai でGLM-5ナレッジグラフ全体再構築も実行 手動/アドホック実行 (Task Scheduler登録はあるが主に手動) operations_cockpit.md 全サブシステムの状態を1枚にまとめる 15+個のJSON状態ファイルを日本語で可読化 全オーケストレーターの最後のステップで更新される metadata_summary_index.md 最近の活動・関心・プロジェクト連携の索引 raw/ 以下の全md文書のフロントマターを集計 日本語即読用 .md と構造化 .json の両形式で出力 graphify-out/ 全文書をGLM-5で意味解析してナレッジグラフに rebuild_via_zai.py: バッチでGLM-5に送信し再構築 graph.html / graph.json / GRAPH_REPORT.md を出力 curiosity-wiki-bootstrap.py Claude Codeセッション開始時にユーザー文脈を注入する SessionStart hook で critical_facts + user_preferences を読み込む フレッシュセッションでも「自分は誰か」を即把握できるようにする llmwiki-user-context.md ユーザーの特徴・適性・強みを聞かれたとき何を見るか Claude rule で curiosity-wiki への読み取りルーティングを定義 ツール選定・プロジェクト優先順位・ペルソナ参照の導線 raw/ ソースファミリー 全文書の入口: どこから来たかで分類される vaultd/ | openclaw-workspace/ | github/ 00-inbox(新着) → 01-staging(処理中) → 02-quarantine(要確認)
100%

3つの Task Scheduler

  • IntakeMetadata: 1日4回、取り込みパイプライン全体を自動起動
  • RepoGovernance: 週次でGitHubリポジトリの棚卸し+セキュリティ監査
  • WeeklyMaintenance: 週次でスナップショット+候補発見+全メンテナンス

4つのオーケストレーター

  • run_intake_metadata_pipeline: discover→route→GLM正規化→finalize→監視更新
  • run_repo_governance_cycle: GitHub registry→tier判定→境界監査→cockpit
  • run_weekly_maintenance: snapshot→discover→governance→lint→cockpit
  • run_curiosity_cycle: sync→finalize→monitor (+ZAI再構築)

3つの主要出力

  • operations_cockpit.md: 全状態を日本語1枚にまとめたダッシュボード
  • metadata_summary_index.md: 最近の活動・関心の可読索引
  • graphify-out/: GLM-5ベースのナレッジグラフとレポート

Claude Code 連携

  • bootstrap.py: セッション開始時にユーザー文脈を自動注入
  • llmwiki-user-context.md: ユーザーの特徴を聞かれたときの参照導線
  • natural-language-routing-policy.md: 自然言語の問いを適切なファイルへルーティング
raw/00-inbox/ 新しい文書が最初に落ちる場所 手動投入 or 外部取り込みの入口 sync_vaultd_raw.py VaultDのKB文書をraw/vaultdにコピー 秘密情報ファイルは自動除外される sync_workspace_raw.py OpenClaw workspaceの設定文書を同期 system/, memory/ 以下をraw/に差分コピー discover_obsidian_candidates.py 何を取り込む候補にするか決める HIGH_SIGNAL/DURABLE/LOW_SIGNALでスコアリング クールダウン・重複排除・auto_intake_eligible判定 route_ingest.py 取り込むファイルをどのレーンに振り分けるか決める ソースファミリー推論 → inbox / staging / quarantine に振り分け --apply なしならdry-runで実際の書き込みなし GLM-5 バッチ正規化 build_glm_metadata_batch_payload GLMに送る入力データを組み立てる YAML抽出 → パス・グループ・優先度のJSON生成 run_glm_metadata_batch_via_zai z.ai API経由でGLM-5に正規化させる 指数バックオフ付きリトライ・エラーハンドリング validate + review + apply GLMの応答を検証してYAMLに書き戻す フォーマット検証 → 品質チェック → フロントマター更新 バッチJSON出力 バッチごとの入出力を記録する manifest / payload / response をバッチ単位で保存 finalize_ingest.py stagingにあるファイルを正式なraw/に確定する タイトル正規化・コンテンツハッシュ重複チェック 失敗時は quarantine に退避して安全を確保 build_metadata_summary_index.py 最近の活動・関心・プロジェクト連携を索引化する 全mdのフロントマターを集計して可読索引を生成 → metadata-summary-index.md / .json raw/01-staging/ 正規化処理中のファイルが置かれる場所 GLM-5バッチ正規化の対象 raw/02-quarantine/ 検証に失敗して隔離されたファイル 手動確認が必要な状態 raw/vaultd/ | github/ | ... 正式に配置されたファイルの恒久的な置き場 ソースファミリーごとにディレクトリが分かれる
100%

ソースファミリー

  • vaultd: D:\antigravity_projects\VaultD\ (最高優先度)
  • openclaw-workspace: OpenClawのシステム設定ファイル
  • github: リポジトリのREADME/docs
  • 00-inbox: 手動投入 or 外部からの取り込み

GLM-5 バッチ正規化

  • 1. build_payload: YAML抽出してGLM用入力JSONを組み立てる
  • 2. run_via_zai: z.ai API経由でGLM-5にメタデータ正規化を依頼
  • 3. validate: レスポンスのフォーマット・品質をチェック
  • 4. review + apply: 正規化されたメタデータをYAMLに書き戻す

パイプラインの流れ

  • inbox → discover(候補選定) → route(レーン振り分け) → staging
  • staging → GLM-5正規化 → finalize(重複チェック+確定)
  • finalize → ソースファミリーごとの恒久的な配置先
  • quarantine: 検証失敗ファイルは隔離して手動確認待ち
run_intake_metadata_pipeline.py メインパイプラインの後に自動取り込みセクションが走る --auto-intake-trial フラグで条件を満たす場合のみ実行 build_auto_intake_proposal.py 次に自動取り込みすべき候補を1件選んで提案する trial_ready確認 → eligible候補を絞り込み → 先頭1件を選択 準備未完了なら decision=hold を返す build_discover_preview.py 候補スキャン結果をプレビューJSONに変換する target_group・role_hint・cooldown情報を付与 → discover_preview.json (cockpitに表示される) → discover_preview.json cockpitに候補状況として表示される Dry-Run セーフティネット proposal_dry_run どのファイルが選ばれるか 提案をシミュレーション finalize_dry_run どこに配置されるか 配置先をシミュレーション normalize_dry_run 正規化結果がどうなるか GLM正規化をシミュレーション 3つ全てが通過して初めて trial_apply が実行される run_auto_intake_trial_apply.py 1件の自動取り込みをエンドツーエンドで実行する route → GLM正規化 → finalize の一連を実行 結果をintake_runs/auto_intake_trial_TIMESTAMP/ に保存 build_auto_intake_graduation.py トライアルが本番昇格できる段階かどうか判定する run_count/applied_runs/exact_matchの3条件で評価 build_auto_intake_history トライアル実行履歴を時系列で集計 最大12件の一致率・成功率を追跡 build_auto_intake_task_sync Task Schedulerのモードを同期する graduation判定に合わせてタスク設定を変更
100%

Dry-Run セーフティネット

  • proposal: どのファイルが選ばれるかをシミュレーション
  • finalize: どこに配置されるかをシミュレーション
  • normalize: GLM正規化の結果がどうなるかをシミュレーション
  • 3つ全てが通過して初めて trial_apply が実行される

昇格フロー

  • trial: dry-runゲート付きの慎重モード (初期状態)
  • graduated: 完全自動取り込み (現在のモード)
  • 昇格条件: 3回以上実行・2回以上適用・配置先完全一致
  • task_sync: Task Schedulerのモードをgraduation判定と自動同期
run_repo_governance_cycle.py リポジトリの品質・安全・重要度を一括チェックする 週次でGitHub上の全リポジトリを棚卸しして状態を更新 update_github_repo_registry.py GitHubリポジトリ一覧とメタデータを取得して更新する gh CLI経由でリポジトリ情報を取得 CORE/PRODUCT/TRACKED/REFERENCEの4カテゴリに分類 build_repo_governance_index.py 各リポジトリの優先度ティアとアクション推奨を算出する README/CLAUDE.md/ローカルコンテキストを参照してスコアリング → repo-governance-index.md / .json (archive/refresh/maintain推奨付き) build_portfolio_review_candidates.py ポートフォリオ掲載に向けてレビューすべきリポジトリを選ぶ env-file/private-key/API鍵等のシークレットをREGEXで検出 重大度(high/medium/low)付きの審査リストを生成 build_public_boundary_audit.py 公開ドキュメントに秘密情報が漏れていないかチェックする Windowsパス・ローカルIP・トークン・Bearer認証を正規表現で検出 placeholder/redacted/example は誤検知として除外 build_operations_cockpit.py ガバナンス結果をコックピットのgovernanceセクションに統合 registry / tier / audit の結果を日本語で可読化してダッシュボードに出力
100%

Registry → Governance

  • GitHub APIで全リポジトリのメタデータを収集
  • auto_tier: README/CLAUDE.md/ローカルコンテキストからスコアリング
  • アクション推奨: archive / refresh / maintain を自動判定

セキュリティ監査

  • public_boundary_audit: 公開ドキュメントの秘密情報漏洩を検出
  • Windowsパス・ローカルIP・トークン・Bearer認証を正規表現で検出
  • portfolio_review: env-file/private-key等のシークレット検出付き審査リスト
build_intake_health.py 取り込みパイプラインの健全性を計測する 直近8件の成功率・エラー率を集計 graduation_readyフラグとTask Schedulerの推奨モードを出力 build_lint_health.py メタデータの品質とポリシー矛盾を検出する YAMLフロントマターの形式・タグ・リンク切れをチェック ポリシー軸ごとのallow/deny矛盾パターン検出 build_user_context_refresh.py ユーザープロファイルの鮮度をチェックする critical_facts / user_preferences の最終更新日時を確認 30日超の未更新やシグナル欠落を検出してwarningを出力 Filed-Back パイプライン build_filed_back_proposal.py 再利用価値の高い生成物をWiki還元候補に policy/guide/design等の耐久性名にスコアを付与 build_filed_back_action.py カタログ収録か却下かを決定する 既存rootにあれば already-live、なければ提案 build_filed_back_catalog.py → 採用済み一覧カタログ build_operations_cockpit.py 全サブシステムの状態を1枚の日本語ダッシュボードにまとめる 15+個のJSON状態ファイルを読み込み、英語コードを日本語に変換 全オーケストレーターの最後のステップで必ず更新される operations_cockpit.md 人間が読むための運用ダッシュボード キュー状況 / 健全性 / ガバナンス / 自動取り込み を1ファイルで確認
100%

取り込み健全性

  • Task Schedulerの状態・次回実行時刻を確認
  • 直近8件の成功率・エラー率から停滞を検出
  • graduation_readyフラグで昇格タイミングを制御

メタデータ品質

  • YAMLフロントマターの形式準拠チェック
  • 必須タグの存在確認・リンク切れ検出
  • ポリシー軸ごとの矛盾パターン検出

Filed-Back パイプライン

  • proposal: outputs/から再利用価値の高い生成物を選定
  • action: カタログ収録 or 却下を判定
  • catalog: 採用済みfiled-back成果物の一覧を生成

Operations Cockpit

  • 全サブシステムの状態を日本語で1枚にまとめる中央集約装置
  • 15+個のJSON状態ファイルを読み込んで可読化
  • 全オーケストレーターの最後のステップで必ず更新される
Task Scheduler（pythonw 非表示実行）— 独立スケジュール Ceiling Recognizer 毎日 08:30（フル） 08:55 / 13:55 / 18:55（軽量） Pipeline（1'→2'→A→Ingest） Morning 09:00 / Afternoon 14:00 / Evening 19:00 run_pipeline.py が Agent 1'→2'→A→Ingest→Git を直列起動 Quality Review 毎日 20:00 Agent 4（Codex GPT-5.4） Strategic Review 毎日 20:15 Agent S（5軸＋Shannon） Self Improve 日曜 20:30 Agent 5（週次・提案制） Meta Supervisor 毎日 21:00（安定後3日ごと） Agent C'（低リスク自動適用） 9タスク全て pythonw.exe（ウィンドウなし） logs: pipeline.log / ceiling.log 等に集約 Chrome起動必須（Grok4/Perplexity CiC使用時） Agent T — ceiling_recognizer.py（天井認知 + シフト推薦） Signal 1 (LLM非依存): known_ratio≥0.9 / 新規情報ゼロ×3回 / 重複率>80% Signal 2 (supplementary): Grok4天井シグナル（否定文脈チェック付き） Signal 3 (cross-review): Codex「未探索サブドメインは？」→ TTL: 通常14日 / アクティブ7日 → HIGH+はGitHub Issue自動投稿 ceiling_assessment.json シフト推薦 + 天井トピック + サブドメイン天井 ▼ メインパイプライン（run_pipeline.py が直列起動） Agent 1' — build_interest_ranking.py スコア = calibration(40%) + frontmatter(30%) + freshness(30%) 派生ベクトル分析: deepen / lateral / fresh / practical 天井トピックのスコアを 0.1x 減衰 → interest_ranking.json / query_candidates.json 段階的深化: auto-ingested→known_ratio上昇→deepen自動昇格 Agent 2' — query_selector.py wiki内部照合強化 + コスト/天井/文脈考慮 Tier A: 毎回 / Tier B: 1日1回 / Tier C: 3日1回 天井トピックは劣後 → 非天井クエリを優先 → selected_query.json Agent Sフィードバックで priority_score ±0.1 補正 Agent A — search_executor.py 検索チェーン: Grok4 CiC → Perplexity CiC → xAI API 天井シグナル検出（シグナル2用データ採取） Chrome起動必須（CiC使用時）/ xAIはAPIフォールバック → search_result.json Canonical層で既知率算出（boundary-aware マッチング） ingest_search_result.py Dual Output（curiosity-wiki + VaultD） frontmatter自動付与（auto-ingested） → raw/auto-collect/* に保存 → VaultD: Monetization/Intelligence/ 次回ランキングで known_ratio 上昇に寄与 ▼ 独立レビュー／改善ループ（Task Scheduler で別時刻起動） Agent 4 — quality_reviewer.py 取り込み結果の品質評価（Codex GPT-5.4） 情報密度・新規性・実用性をスコアリング → review_log.json 20:00 実行 Agent S — strategic_reviewer.py 5軸評価 + Shannon entropy でポートフォリオバランス テーマ適切性 / 新規性 / バランス / 派生可能性 / 天井接近速度 → strategic_review.json（1'/2'/T へフィードバック） 20:15 実行 Agent 5 — self_improver.py 品質+戦略レビュー参照 → 改善提案（Codex GPT-5.4） クエリテンプレ / ランキング / プロンプト自己改善 CALIBRATION_PRIORITY は自動変更しない 日曜 20:30 実行（週次・ユーザー承認制） Agent C' — meta_supervisor.py 権限分離: 低リスク自動適用 / 中高リスク承認制 優先度±0.1 / TTL±7日 → 自動 / トピック追加 → 承認 → meta_report.md / meta_adjustments_log.json 21:00 実行（安定後3日ごと） Agent S フィードバック (±0.1補正 + for_agent_t シグナル) Canonical Layer（Phase 6: 概念レジストリ + エイリアス解決） concept-registry.json（35概念・手動管理）+ alias-index.json（139エントリ・自動再構築） canonical.py: word-boundary matching（RAG in paragraph → False, CJK常に境界扱い） detect_known_boundary(): raw_keywords基準で known_ratio を算出（Agent 1'/Tが使用） 後方互換: registry未存在時は従来の部分文字列マッチにフォールバック エイリアス追加は concept-registry.json に1行足すだけ（alias-index.json は次回load時に自動再構築） raw/ auto-collect/ → auto-ingested 00-inbox/ / vaultd/ / github/ frontmatter 正規化済み VaultD (dual output) Monetization/Intelligence/ Obsidian Vault連携 cognee 検索対象（08:00更新） 現在アクティブな10クエリ（Tier制御） Tier A（毎回） Q2 cost-optimization / Q3 automation-reliability / Q5 freelance-strategy Tier B（1日1回） Q7 ai-monetization / Q9 client-delivery-automation / Q10 build-in-public Tier C（3日1回） Q1 knowledge-management / Q4 ai-character-ip Q6 multi-agent-orchestration / Q8 new-tools キャリブレーション元: raw/00-inbox/user-interest-calibration-2026-04-14.md ★ North Star Claudeが一流コンサルのように ユーザーの関心事を先回りして推奨案を答えられる状態 段階的深化ループ: 知識ギャップ検出 → クエリ → 取り込み → known_ratio上昇 → 次回は既知前提でより高度な質問（depth: standard → deepen）
100%

Agent T — 天井認知

  • multi-signal 方式: LLM非依存(1) + Grok4(2) + Codexクロスレビュー(3)
  • Codex利用不可時は Signal 1+2 にgraceful degradation
  • サブドメイン天井検出（推論手法・トレーニング手法など個別判定）
  • HIGH+ シフト提案は GitHub Issue（Tenormusica2024/dashboard）に自動投稿
  • TTL: 通常14日 / アクティブプロジェクト7日

メインパイプライン

  • run_pipeline.py が Agent 1'→2'→A→Ingest→Git を直列起動
  • 1日3回（09:00 / 14:00 / 19:00）独立スケジュール
  • Tier A/B/C で頻度制御（A毎回 / B日1 / C 3日1）
  • 派生ベクトル: deepen / lateral / fresh / practical の4方向
  • Dual output: curiosity-wiki + VaultD に同時保存

Post-Pipeline レビュー

  • Agent 4 (20:00): 品質評価 → review_log.json
  • Agent S (20:15): 5軸+Shannon → strategic_review.json → 1'/2'/Tへフィードバック
  • Agent 5 (日曜20:30): 週次自己改善（ユーザー承認制）
  • Agent C' (21:00): 低リスク自動適用 / 高リスク承認制
  • CALIBRATION_PRIORITY はユーザー主観値のため自動変更されない

Canonical Layer (Phase 6)

  • concept-registry.json: 35概念の canonical 名 + aliases
  • alias-index.json: 139エントリの逆引き辞書（自動再構築）
  • word-boundary matching で日英混在の偽陽性を排除
  • CJK文字は常に境界扱い（"RAG in paragraph" → False）
  • エイリアス追加は JSON に1行足すだけで反映

Task Scheduler 9タスク

  • 全て pythonw.exe（ウィンドウなし）で非表示実行
  • Ceiling: 08:30 フル + 08:55 / 13:55 / 18:55 軽量チェック
  • Pipeline: 09:00 / 14:00 / 19:00（3回）
  • Quality 20:00 / Strategic 20:15 / MetaSupervisor 21:00
  • Self Improve: 日曜 20:30（週次）
  • Chrome起動必須（Grok4/Perplexity CiC使用時）

★ North Star

  • Claudeが一流コンサルのようにユーザーの関心事を先回りして推奨案を答えられる状態
  • 段階的深化: auto-ingested → known_ratio上昇 → depth_suggestion "standard"→"deepen"
  • deepen時は「※前提: Xは既知。Yを重点的に知りたい」が自動付与
  • キャリブレーション: user-interest-calibration-2026-04-14.md

curiosity-wiki operations flow • ファイル名より先に見る意味 • generated 2026-04-17