fix: resolve query-tool endpoint from destinations (explicit-first fallback)

[colombod]

What this PR does

Fixes a real bug in the context-intelligence query path, introduces a coherent read-source config model, and corrects how session metadata records the working directory. All changes are scoped to the bundle's read/query side plus one hook metadata fix; the upload/fan-out write path is untouched .

sources is unreleased (introduced here), and the read-tool modules have a single in-repo composition site (agents/graph-analyst.md), so there is no migration for any existing user or external consumer.

---

The bug being fixed (and why it mattered)

Symptom. With the server up and event upload working, graph_query failed with:

configuration_error: "context-intelligence server URL not configured"

Root cause. Two orthogonal config-lookup paths that nothing bridged:

• Upload path (hook-context-intelligence) reads config.destinations["<name>"].url / .api_key.
• Query path (tool-graph-query, tool-blob-read) read only the top-level scalars context_intelligence_server_url / context_intelligence_api_key — it never inspected the destinations block.

After destinations: became the primary documented config, a user who configures only destinations: got working uploads but a dead query tool. This is exactly the failure observed in the field with a single-destination, no-scalar, no-env config.

The fix. Give the query tools an explicit-first, per-field fallback that finally reads the same config the uploader uses. See feature #1 below.

---

Features / changes

1. fix: query-path endpoint resolution (explicit-first fallback) — 747c5a7

A shared helper context_intelligence/tool_resolver.py::resolve_query_endpoint resolves (server_url, api_key) independently per field, explicit-read-config first:

Tier	Source
1	first entry of the tool's own sources (or a default synthesized from explicit top-level scalars)
2	first hook destinations entry — the bridge that makes a destinations-only setup "just work" for reads
3	canonical env AMPLIFIER_CONTEXT_INTELLIGENCE_SERVER_URL / _API_KEY (single last-resort; no *_PRIVATE_* names)
—	else → configuration_error

Rationale for the ordering: an operator's explicit read config must win (least surprise), but absent it, the tools should transparently follow the same server the hook uploads to — so the common case needs zero extra config. Env is a true last resort and never outranks the hook destination.

Also adds PYTHONPATH=${{ github.workspace }} to the module test step so unit tests resolve the in-repo context_intelligence (incl. the new tool_resolver.py) instead of the published @main copy.

2. refactor: merge the two read tools into one module — f944020

The two read tools shipped as separate modules, each building its own resolver and requiring read config to be set twice (two namespaces that could silently drift). Merged into one module tool-context-intelligence-query that mounts both tools.

• mount() builds one ToolConfigResolver and injects the same instance into both tools; the tool constructor is now (coordinator, resolver=None) and the unused config param is dropped.
• One config namespace overrides.tool-context-intelligence-query.config.sources serves both tools — they can no longer diverge.
• Tool names unchanged (graph_query, blob_read); resolution semantics unchanged; the lazy hook lookup stays at execute() (tools mount before hooks — a guaranteed kernel invariant). Idiomatic per the module contract (one module → multiple tools, à la tool-filesystem; mount() returns None since non-callable returns are kernel-ignored; plain injection, not a capability, for the intra-module resolver).

Rationale: the tools always travel as a pair (the agent pulls both), so the natural brick boundary is "CI read tools," not "one tool per module." This removes the duplicate-config foot-gun and halves the packaging/lockfile/test/CI overhead.

3. Read-source config model — sources (single source)

The read config key is sources (a mapping mirroring the hook's destinations shape). Only a single read source is supported in this version — the read path does not fan out. With nothing configured, the read tools use the first configured destination in the hook config as their read source (tier 2). sources exists only for the read-replica / split-endpoint case.

4. fix(hook): source metadata working_dir from the session capability, not events — 6cd4f02

metadata.json recorded working_dir by scraping event payloads (data.get("working_dir", "")), which was wrong on three counts:

• working_dir is a session attribute, not an event attribute;
• only session:start/fork events carry it, so if the first event seen for a session was any other type, metadata was written with working_dir: "" (and never corrected for forwarded/partial sessions);
• a present-but-empty "" in the event payload was stored as-is (the .get(key, "") default only applies when the key is absent).

The fix. Added HookConfigResolver.working_dir — a live (uncached) read of the session.working_dir capability (the same source the resolver already uses for project_slug; "" when unavailable). The LoggingHandler now sources both metadata writes from self._resolver.working_dir. Reading live also tracks mid-session working-directory changes. Rationale: session metadata should come from the session, deterministically, not depend on a particular event type arriving.

---

Testing

• Unit: full per-tool resolution matrix for both tools, plus new module-level tests — mount() registers exactly two distinct tools; shared-resolver identity and consistency; a late-mount timing test proving the hook lookup stays lazy at execute(); malformed/empty sources inputs. Hook metadata: working_dir filled from the resolver when the first event isn't session:start, present-but-empty event value no longer wins, empty resolver doesn't clobber a prior value, and the working_dir property handles missing/empty/non-str capability and is uncached. Query module 85 passing; hook module 380 passing; root 19 passing.
• End-to-end (Digital Twin): with the real destinations-only config, one mount() mounts both tools, each resolves its endpoint from the first hook destination (tier 2), and both issue real READ requests (POST /cypher, GET /blobs) to a mock CI server carrying the destination's Bearer key; negative control (no hook resolver) reproduces the configuration_error.
• Bundle validator (full mode): packaging build passes, all bundles load "good", bundle.dot regenerated.

---

Commits

Commit	Type	Summary
747c5a7	fix	query-path endpoint resolution (explicit-first; reads hook destinations) + CI PYTHONPATH shadow
f944020	refactor	merge graph-query + blob-read into tool-context-intelligence-query (one shared resolver, one sources namespace)
6cd4f02	fix(hook)	source metadata working_dir from session.working_dir capability, not events
0c20c12	docs	clarify the read path supports a single source only
f049931	style	apply root ruff formatting to the new hook tests (Lint)