deps: bump dikw-core from 0.5.3 to 0.6.0

[dependabot]

Bumps dikw-core from 0.5.3 to 0.6.0.

Release notes

Sourced from dikw-core's releases.

dikw-core v0.6.0

0.6.0 — config-driven provider API-key env vars (BREAKING); DeepSeek V4 Pro + Gitee bge-m3; horizontal model comparison

Changed

• BREAKING — provider API-key env var is now config-driven, and DIKW_EMBEDDING_API_KEY is removed. ProviderConfig gains two required fields, llm_api_key_env and embedding_api_key_env, naming the environment variable that holds each leg's key. The engine no longer hardcodes any key var name: anthropic_compat/openai_compat read exactly the var named in dikw.yml, with no fallback. The dikw-invented DIKW_EMBEDDING_API_KEY magic name is gone — embedding keys now use vendor-canonical names (OPENAI_API_KEY, GITEE_API_KEY, …) chosen via embedding_api_key_env. The LLM/embedding "two separate keys" separation is now achieved by naming distinct vars (point both legs at one var to share a key, or at different vars to split vendors) rather than by a special name + no-fallback rule. Migration: add the two fields to every dikw.yml provider: block (a fresh dikw init scaffold writes them), and in .env rename DIKW_EMBEDDING_API_KEY → the vendor var your config names; a same-vendor Anthropic+MiniMax .env that reused ANTHROPIC_API_KEY for a MiniMax key should move the MiniMax key to MINIMAX_API_KEY and set llm_api_key_env: MINIMAX_API_KEY. Wipe the local evals/.cache/snapshots/ after upgrading (its snapshot dikw.ymls predate the fields). /v1/health's api_key_present and the dikw client check probe now key off the configured var; the tools/e2e_verify.py real-leg gate derives its required keys from the active profile's provider.{llm,embedding}_api_key_env.

Added

• DeepSeek V4 Pro (LLM) + Gitee AI bge-m3 (embeddings) support — config-only. DeepSeek runs via the existing anthropic_compat protocol against its Anthropic-compatible endpoint (llm_base_url: https://api.deepseek.com/anthropic, llm_model: deepseek-v4-pro, key in DEEPSEEK_API_KEY); DeepSeek ignores the cache_control field the provider sends (no error — only the Anthropic prompt-cache discount is absent, same cost note as openai_compat). bge-m3 runs via openai_compat embeddings against Gitee (embedding_base_url: https://ai.gitee.com/v1, embedding_model: bge-m3, embedding_dim: 1024, embedding_batch_size: 16, key in GITEE_API_KEY). No engine code; a committed reference config ships at tests/fixtures/live-deepseek-gitee-bgem3.dikw.yml. See docs/providers.md.
• Horizontal model-comparison harness (evals/tools/compare_models.py). A dev tool (not shipped in the wheel) that runs the same eval dataset against N model arms and emits an arm-by-metric comparison matrix + per-arm JSON. compare compares embedding models via retrieval eval (deterministic, 1 run/arm: hit@k / mrr / nDCG@10 / recall@100); compare-synth compares LLM models via synth eval (N runs/arm + a Welch t-test of each arm vs the baseline arm: grounding / atomicity / duplicate / wikilink / language, plus judge dims with --judge). Each arm carries a full provider: block, so two same-protocol vendors (DeepSeek + MiniMax) resolve distinct keys via their *_api_key_env. Reuses the tested statistics from ab_experiment.py and the direction rule from client/baseline.py. See evals/README.md and docs/providers.md.
• Real-environment end-to-end verification harness (tools/e2e_verify.py). A dev tool (not shipped in the wheel) that drives every dikw client verb against a live server in one of two throwaway environments, then destroys it: --mode local (temp-dir base + long-lived dikw serve on SQLite) and --mode docker (server +

... (truncated)

Changelog

Sourced from dikw-core's changelog.

0.6.0 — config-driven provider API-key env vars (BREAKING); DeepSeek V4 Pro + Gitee bge-m3; horizontal model comparison

Changed

• BREAKING — provider API-key env var is now config-driven, and DIKW_EMBEDDING_API_KEY is removed. ProviderConfig gains two required fields, llm_api_key_env and embedding_api_key_env, naming the environment variable that holds each leg's key. The engine no longer hardcodes any key var name: anthropic_compat/openai_compat read exactly the var named in dikw.yml, with no fallback. The dikw-invented DIKW_EMBEDDING_API_KEY magic name is gone — embedding keys now use vendor-canonical names (OPENAI_API_KEY, GITEE_API_KEY, …) chosen via embedding_api_key_env. The LLM/embedding "two separate keys" separation is now achieved by naming distinct vars (point both legs at one var to share a key, or at different vars to split vendors) rather than by a special name + no-fallback rule. Migration: add the two fields to every dikw.yml provider: block (a fresh dikw init scaffold writes them), and in .env rename DIKW_EMBEDDING_API_KEY → the vendor var your config names; a same-vendor Anthropic+MiniMax .env that reused ANTHROPIC_API_KEY for a MiniMax key should move the MiniMax key to MINIMAX_API_KEY and set llm_api_key_env: MINIMAX_API_KEY. Wipe the local evals/.cache/snapshots/ after upgrading (its snapshot dikw.ymls predate the fields). /v1/health's api_key_present and the dikw client check probe now key off the configured var; the tools/e2e_verify.py real-leg gate derives its required keys from the active profile's provider.{llm,embedding}_api_key_env.

Added

• DeepSeek V4 Pro (LLM) + Gitee AI bge-m3 (embeddings) support — config-only. DeepSeek runs via the existing anthropic_compat protocol against its Anthropic-compatible endpoint (llm_base_url: https://api.deepseek.com/anthropic, llm_model: deepseek-v4-pro, key in DEEPSEEK_API_KEY); DeepSeek ignores the cache_control field the provider sends (no error — only the Anthropic prompt-cache discount is absent, same cost note as openai_compat). bge-m3 runs via openai_compat embeddings against Gitee (embedding_base_url: https://ai.gitee.com/v1, embedding_model: bge-m3, embedding_dim: 1024, embedding_batch_size: 16, key in GITEE_API_KEY). No engine code; a committed reference config ships at tests/fixtures/live-deepseek-gitee-bgem3.dikw.yml. See docs/providers.md.
• Horizontal model-comparison harness (evals/tools/compare_models.py). A dev tool (not shipped in the wheel) that runs the same eval dataset against N model arms and emits an arm-by-metric comparison matrix + per-arm JSON. compare compares embedding models via retrieval eval (deterministic, 1 run/arm: hit@k / mrr / nDCG@10 / recall@100); compare-synth compares LLM models via synth eval (N runs/arm + a Welch t-test of each arm vs the baseline arm: grounding / atomicity / duplicate / wikilink / language, plus judge dims with --judge). Each arm carries a full provider: block, so two same-protocol vendors (DeepSeek + MiniMax) resolve distinct keys via their *_api_key_env. Reuses the tested statistics from ab_experiment.py and the direction rule from client/baseline.py. See evals/README.md and docs/providers.md.
• Real-environment end-to-end verification harness (tools/e2e_verify.py). A dev tool (not shipped in the wheel) that drives every dikw client verb against a live server in one of two throwaway environments, then destroys it: --mode local (temp-dir base + long-lived dikw serve on SQLite) and --mode docker (server + pgvector Postgres via a generated compose project, image built **from the local

... (truncated)

Commits

• 8eb13b3 chore(release): 0.6.0 + scope CodeQL to shipped code (#223)
• 423f901 feat(providers)!: config-driven API-key env var; drop DIKW_EMBEDDING_API_KEY;...
• 28a4905 fix(observability): bump OTel collector pin to 0.117.0 for arm64 static build...
• 8ed168e feat(tools): real-environment e2e verification harness — local + docker, full...
• 8cd5c37 docs: replace stale "K/W have no scan-based reindex" claims in source + tests...
• d813a95 docs: correct 28 factual drifts across living docs to match current code (#218)
• 3ddf277 chore(deps): raise python-multipart floor to >=0.0.31 — clear stale Dependabo...
• eccb860 feat(lint): dangling_provenance drift kind — flag K/W pages citing a deleted ...
• 73b4af7 feat(lint): stale_index + untracked_file drift lint kinds — re-project hand-e...
• 8557835 feat(lint): missing_file drift lint kind — purge orphaned D/K/W rows (ADR-000...
• Additional commits viewable in compare view

[dependabot]

Labels

The following labels could not be found: deps. Please create it before Dependabot can add it to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

[helebest]

Code Review — automated

PR author: dependabot[bot] ✅
Diff scope: uv.lock only (1 file, 12 changed lines)

Summary

This PR bumps dikw-core from 0.5.3 → 0.6.0. The release is a minor-version bump with one breaking change (config-driven provider API-key env vars; DIKW_EMBEDDING_API_KEY removed). The breaking change lives entirely in the server-side ProviderConfig layer. Per the project's layering invariants, converter plugins must not import from dikw_core.providers.* or any server/engine module — so the breaking change is out-of-scope for this repo and poses no risk to plugin consumers.

No new transitive dependencies were introduced; the sdist/wheel hashes are from the official PyPI upload.

Issue found — lock file inconsistent with pyproject.toml ⚠️

Dependabot updated the [package.metadata] sections in uv.lock to requires-dist = [{ name = "dikw-core", specifier = ">=0.6.0" }], but the three pyproject.toml files still declare dikw-core>=0.5.3. uv stores a snapshot of each workspace member's dependencies in uv.lock; when the snapshot diverges from pyproject.toml, uv lock --locked (which CI runs) rejects the file:

The lockfile at `uv.lock` needs to be updated, but `--locked` was provided.

This is the direct cause of the test (3.12) CI failure.

Fix: bump the lower-bound constraint in all three pyproject.toml files from >=0.5.3 → >=0.6.0 to match the lock file metadata. This is also semantically correct — given the breaking change in 0.6.0, plugins should not be installable against dikw-core 0.5.x.

Applying the fix now and pushing to this branch.

---

Generated by Claude Code

[helebest]

Verification & merge decision

Step 2 — Regression verification: All checks passed on the fix commit (6cc8ecc):

Check	Result
test (3.12)	✅ success
test (3.13)	✅ success
analyze (CodeQL)	✅ success
CodeQL	✅ success

The uv lock --locked gate that previously rejected the inconsistent lock file now passes, confirming the pyproject.toml fix is correct.

Step 3 — CI monitoring: All checks green, no failures.

Step 4 — Merging via squash merge now.

---

Generated by Claude Code