Repository Explorer – Observabilityを実装する

これはデータベースに保存された、Repository ExplorerのIndexerが生成したインデックスです。
コード内のシンボル、リポジトリ名、ファイル名が索引化されています。

ここを調査の手がかりとして使います。

調査には、

• インデックスの検索
• リポジトリ内ファイルの読み込み
• 仮説の生成

を繰り返して、十分な根拠が集まった時点で調査を終了して回答を作成する仕組みです。

これが調査回路。

• 何を検索するか
• 根拠として十分か

などはLLMにやらせます。

Observabilityは、調査回路の中に仕込んでいて、調査のトレースした内容を見ることができます。

トレース内容の例です。

Target: pivot-service
Query: Gateway
locate Gateway implementation in pivot-service
Found 477 search result(s) in pivot-service for query: Gateway

Findings
pivot-service:.env.example:20: GATEWAY_BEARER_TOKEN=pivotgw
pivot-service:doc/CP_PIVOT_FACTROW_MAINTENANCE_01.md:38: – GatewayAdminTab
pivot-service:doc/CP_PIVOT_FACTROW_MAINTENANCE_02.md:60: – GatewayAdminTab
pivot-service:doc/CP_PIVOT_MULTI_VALUE_MEASURE_01.md:663: – Admin Fact / Mapping / Gateway tabs
pivot-service:doc/MOD_BEDORE_PRE.md:654: Pivot Gateway / Pivot Ingest
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:1: # Pivot Gateway 実装設計書 v0.1
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:5: Pivot Gateway は、外部システムから送られる Ingest データを受け取り、受信台帳と配送状態を保持しながら、Pivot Service に安全かつ安定して配送する常駐コンポーネントである。Gateway 自身は LLM 抽出や canonicalization を行わず、入力の受理、軽い整形、キューイング、再送、失敗管理、状態可視化に責務を限定する。
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:16: ### 2.1 Pivot Gateway の責務
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:18: Pivot Gateway は以下を担当する。
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:22: * Gateway Input Envelope の内部共通形式化
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:23: * gateway_requests への受信台帳保存
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:24: * gateway_delivery_items への配送単位生成
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:30: ### 2.2 Pivot Gateway の責務外
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:45: Pivot Service 側は ingest の受理、normalize、抽出、canonicalization、FactRow 保存、Pivot / Detail 提供を責務とし、収集処理や外部データ取得は責務外である。Gateway はその手前で配送層として機能する。
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:63: Gateway は CPU ではなく I/O 中心なので、Python でも十分成立する。
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:73: pivot-gateway
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:80: Gateway は HTTP サーバー、PostgreSQL 状態保存、sender worker を持つ常駐プロセスとして動く。
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:91: Pivot Gateway
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:106: admin_gateway.py
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:120: gateway_request_repo.py
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:136: ## 5.1 Gateway Input Envelope
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:138: 受信形式は Pivot Service の ingest request そのものではなく、Gateway Input Envelope とする。最低必須項目は次の5つ。
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:153: class GatewayInputEnvelope(BaseModel):
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:163: Gateway は「軽い transform」だけを行うので、payload の深い意味検証はしない。
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:176: v0.2 の重要点として、受信単位と配送単位を分ける。Gateway Request は受信台帳、Delivery Item は Pivot Service に送る配送単位である。1 Request から 1〜N Delivery を生成できる構造にする。
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:181: gateway_request
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:191: Gateway は SQLite ではなく Pivot Service と同じ PostgreSQL を使う。理由は durability、運用単純化、SQL 調査、UI 統合のため。
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:193: ## 7.1 テーブル: gateway_requests
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:199: * gateway_request_id PK
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:212: * gateway_request_id は ULID か UUID
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:220: ## 7.2 テーブル: gateway_delivery_items
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:227: * gateway_request_id FK
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:255: * (gateway_request_id, delivery_index) unique
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:259: * FK: gateway_request_id -> gateway_requests.gateway_request_id
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:287: Body: GatewayInputEnvelope
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:298: “gateway_request_id”: “gw_01J…”,
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:315: 2. gateway_requests insert
pivot-service:doc/PIVOT_GATEWAY_DESIGN_v0.1.md:320: ここで Pivot Service への送信はしない。そこを同期にすると Gateway の存在意義が崩れる。
…
…
…

すごく長いのでここまで

一般的なテーマを扱う会話なら、それなりに賢そうに回答するLLMは、一般的ではない組織や個人に固有の情報に対しては、情報が不十分だと盛大にでっち上げます。

LLMの中身までは見えませんが、小さい処理のチェーンを実行させて、個々の処理の結果を並べていけば、LLMの振る舞いを見ることができます。