feat(query): document hybrid business wiki answers

Teach wiki-query to split entity overview questions into an ordinary wiki context track and a read-only business facts track, then fuse the results. Update the MCP query prompt to explicitly allow read-only hybrid subagents while preserving public-only and mutating-command restrictions. Add a skill instruction regression test and update docs.

Validation: python3 -m unittest tests/test_wiki_skills.py -v; python3 -m unittest tests/test_mcp_query.py -v; python3 -m unittest tests/test_business_facts.py -v; python3 -m unittest discover -v; python3 -m compileall obsidian_wiki tests scripts; git diff --check
This commit is contained in:
Codex
2026-07-07 16:05:16 +00:00
parent 11b4261d29
commit e5f26a5540
6 changed files with 45 additions and 3 deletions
+19
View File
@@ -76,6 +76,25 @@ If it is a business facts query:
4. If the template or guarded SQL returns an answer, answer from that JSON result as structured business facts. Do not cite wiki pages unless you also used wiki pages for business context. Mention stale sync warnings when `is_stale` is true.
5. If the CLI/database is unavailable or the question is not a business facts query, continue with the normal wiki retrieval protocol below.
### Step 1b: Hybrid Business + Wiki Route (subagent split)
Do not use hybrid mode when filtered mode is active. In filtered mode, skip business facts entirely and continue with ordinary filtered wiki-query retrieval.
Use hybrid mode when the user asks for an entity overview, situation, background, profile, current status, or "大体情况" where both wiki context and business facts would materially improve the answer. Common examples: customer overview with recent orders, customer relationship status, product situation with order signals, salesperson activity with related customers/projects, or "告诉我一下某某客户的大体情况".
For a hybrid query, spawn two subagents when the platform supports subagents:
1. **ordinary wiki-query subagent** — run the normal wiki-query retrieval path only. Do not use business facts. Return concise narrative context with wiki citations: customer/project background, relationships, email-derived signals, risks, open questions, and pages consulted.
2. **business facts query subagent** — run only the business facts route. Load `obsidian-wiki business schema --json`, prefer templates such as `customer_summary`, `customer_order_list`, `breakdown_by_product` with `--customer`, `order_trend`/`sales_trend` with customer filters, or guarded `business sql` when no template fits. Return structured metrics, rows, `last_sync`, and `is_stale`.
The main agent must wait for both tracks, then fuse the two results into one answer:
- Lead with the business snapshot when available: recent order count, sales amount, main products, latest orders, trend, and data freshness.
- Then add wiki context: who the customer is, related projects/products, important relationship history, risks, and citations.
- Keep business numbers separate from narrative claims; cite wiki pages only for wiki-derived statements.
- If one track fails or has no data, still answer from the other track and state that gap.
- If subagents are not available, run the same two tracks sequentially and mention only material limitations, not internal tooling details.
### Step 2: Index Pass (cheap)
Build a candidate set *without opening any page bodies*: