Skip to content

deps: bump dikw-core from 0.5.1 to 0.5.3#18

Merged
helebest merged 2 commits into
mainfrom
dependabot/uv/dikw-core-0.5.2
Jun 18, 2026
Merged

deps: bump dikw-core from 0.5.1 to 0.5.3#18
helebest merged 2 commits into
mainfrom
dependabot/uv/dikw-core-0.5.2

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Jun 15, 2026

Copy link
Copy Markdown
Contributor

Bumps dikw-core from 0.5.1 to 0.5.3.

Release notes

Sourced from dikw-core's releases.

dikw-core v0.5.3

OpenTelemetry observability — complete (PR1–PR5, #200#207)

dikw-core now ships full traces + metrics + logs instrumentation behind an optional [otel] extra — off by default, zero-cost when unused — so its runtime data integrates with any OTLP backend (Jaeger/Tempo, Prometheus/Grafana, Datadog, …).

  • Traces — one trace spans client → HTTP server → background task → engine op → provider call. gen_ai.* spans carry model + token usage (incl. Anthropic prompt-cache tokens); each retrieval fusion leg (BM25/vector/asset/graph) gets its own span.
  • Metrics — GenAI token.usage + operation.duration histograms and dikw-domain counters/histograms (ingest / synth / embed / retrieve / task), exported over OTLP/HTTP.
  • LogsDIKW_LOG_FORMAT=json emits structured log records carrying trace_id / span_id / service for log↔trace correlation (text default unchanged, byte-for-byte).
  • Docs + validation stack — new docs/observability.md operator cookbook + a one-command docker compose stack (OTel Collector → Jaeger / Prometheus / Grafana).

Enable server-side via a telemetry: section in dikw.yml; the dikw client CLI joins the same trace via the standard OTEL_* env vars.

Synth prompt restructure (#199)

The cached synth system prompt is rewritten into a six-invariant standing-policy spine with a correspondingly slimmed user prompt (single source of truth per rule); synth now forbids sources / lint in emitted front-matter — both are engine-owned.


Full changelog: CHANGELOG.md → 0.5.3

Install: pip install 'dikw-core==0.5.3' — add the [otel] extra for observability, [postgres] for the pgvector backend.

dikw-core v0.5.2

synth-quality measurement + prompt tuning + post-synth self-check

This release is a synth-quality arc: it makes synth output measurable, then tunes the authoring prompt against those measurements, and adds a self-check the agent layer can gate on.

Highlights

Synth prompt-quality overhaul — Zettelkasten framing + worked English/Chinese examples (Phase 1), existing-page slug disambiguation + priority-create feedback to later fan-out groups (Phase 2), six targeted UP revisions (PR1), and an SP rewrite + cache-friendly prompt layout so the instruction prefix is byte-stable for OpenAI/codex prefix caching (PR2). The llm_max_tokens_synth default rises 2048 → 3072 (~768 tokens/page).

Synth-quality measurement foundation (Phase 0a/0b) — deterministic --eval synth diagnostics (source-chunk coverage, fallback/slug-merge ratios, category distribution) plus four opt-in, $0-by-default LLM judges with bootstrap 95% CIs: fact_entailment_ratio, category_correctness_ratio, wikilink_correctness_ratio, semantic_atomicity_ratio. Adds an A/B experiment harness (Welch t-test, no scipy) and a calibrated --judge-sample auto (n≥25 guarantees ≤±0.2 CI).

dikw client synth --verify — post-synth self-check over just this run's pages: persist / lint / semantic-duplicate legs emit one PASS/FAIL verdict, plus a report-only --judge grounding leg.

title_slug_quality lint — deterministic, zero-false-positive K-page title/slug hygiene (also a synth --verify gated leg).

dikw client eval --against / --write-baseline — machine-readable, direction-aware single-run regression gate.

Provider robustnessanthropic_compat + openai_compat complete() now stream, so the read timeout applies per SSE event (fixes reasoning-model timeouts on long syntheses, e.g. MiniMax-M3) and SDK failures are classified transient vs permanent. dikw client check no longer false-fails reasoning-model LLMs/embeddings; openai_compat embeddings are re-ordered by response index.

See the CHANGELOG for the complete, itemized list.

Install: pip install dikw-core==0.5.2 (or dikw-core[postgres]==0.5.2).

Changelog

Sourced from dikw-core's changelog.

0.5.3 — OpenTelemetry observability arc (traces + metrics + logs) + synth prompt restructure

Added

  • Observability docs + validation stack (PR5 of the OTel arc — arc complete). New https://github.com/OpenDIKW/dikw-core/blob/main/docs/observability.md operator cookbook: the full span/metric/log inventory, how to enable telemetry at server (dikw.yml telemetry: section) and client (OTEL_* env) ends, the DIKW_LOG_FORMAT=json log↔trace correlation, a dashboard PromQL cookbook (GenAI token spend, LLM latency, Anthropic cache hit-ratio, pipeline volume), and the zero-cost-when-off guarantee. New docs/observability/ validation stack — a docker-compose.yml wiring OTel Collector (:4318) → Jaeger (traces) + Prometheus (metrics) → Grafana (dashboards) with pre-provisioned datasources, so an operator can run one docker compose up -d, point dikw at http://localhost:4318, and see a full client → server → task → engine → provider trace end to end. telemetry.py is now in the module maps (CLAUDE.md + docs/architecture.md) with a fourth "seam on purpose"; docs/providers.md documents GenAI token metering. Docs-only — no code change, no behavior change. This closes the five-PR OpenTelemetry arc (traces + metrics + logs across server and client).
  • Log ↔ trace correlation + JSON logging (PR4 of the OTel arc). New DIKW_LOG_FORMAT env var: the default text keeps the human-readable terminal formatter byte-for-byte; json opts into one JSON object per log record (ts/level/logger/message, plus any extra={…} fields and an exception traceback) — the machine-readable form a log aggregator parses. When telemetry is active, records emitted inside a span also carry trace_id/span_id/service, so a log line pivots straight to its trace. configure_telemetry (server) and configure_client_telemetry_from_env (client) wire the OTel LoggingInstrumentor via a log hook with set_logging_format=False + enable_log_auto_instrumentation=False, so init_logging keeps full handler/format ownership and no OTLP log-export handler is bolted onto the root logger (log export stays deferred). Degrades gracefully without the [otel] extra or outside a span (no trace fields, no crash); the text default is unchanged. Like DIKW_LOG_LEVEL, it's an env var (CLI parses before any base loads), not a dikw.yml field.
  • OpenTelemetry dikw-domain metrics (PR3b of the OTel arc). The engine now emits domain counters + duration histograms mapped from the per-call report DTOs and existing instrumentation, so a Prometheus/Grafana dashboard sees ingest/synth/embed/retrieve/task volume without parsing logs. All flow through the same _meter_provider gate as the PR3a GenAI metrics (no-op when the [otel] extra is absent or telemetry is off) via five record_* helpers in telemetry.py that take plain scalars (so the seam stays decoupled from the DTOs):
    • dikw.ingest.files (tag dikw.result = added/updated/unchanged), dikw.ingest.chunks, dikw.ingest.errors (tag dikw.error.kind) — emitted once at ingest's return.
    • dikw.synth.pages (tag dikw.result = created/updated), dikw.synth.unresolved_wikilinks, dikw.synth.persist_errors — at synthesize's return.
    • dikw.embed.chunks / dikw.embed.skipped / dikw.embed.retries — from the shared chunk-embed consume seam (consume_embedding_stream), so they cover

... (truncated)

Commits
  • 01d3f2c chore(release): bump version to 0.5.3 + finalize changelog (#208)
  • 46cde5d docs(otel): observability cookbook + validation compose stack (PR5) (#207)
  • 0d21895 feat(otel): log↔trace correlation + JSON logging (PR4) (#206)
  • bfff775 feat(telemetry): dikw-domain metrics — counters + duration histograms (PR3b) ...
  • a429e28 feat(otel): GenAI token + duration metrics (PR3a) (#204)
  • 5d03e90 feat(otel): client→server traceparent propagation (PR2c) (#203)
  • 9083615 feat(telemetry): engine op-level spans — facade ops + retrieval legs (PR2b) (...
  • cdc0add feat(telemetry): tracing backbone — task linking + provider gen_ai spans + ht...
  • 758cb66 feat(telemetry): OpenTelemetry observability foundations (#200)
  • a17a6e3 feat(synth): restructure SP into invariant spine + slim UP + forbid sources/l...
  • Additional commits viewable in compare view

@dependabot @github

dependabot Bot commented on behalf of github Jun 15, 2026

Copy link
Copy Markdown
Contributor Author

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.

Copy link
Copy Markdown
Contributor

Automated Dependabot Review — BLOCKED ❌

Step 1: Code Review

Changes: Only uv.lock was modified (1 file, +6/-20). The lock resolves dikw-core from 0.5.1 → 0.5.2 and drops several ppc64le/s390x platform wheels for cffi and cryptography, consistent with uv pruning platforms not targeted by this workspace.

Issue found: The [package.metadata] blocks in uv.lock for dikw-converter-marker, dikw-converter-example, and dikw-converter-mineru were updated to show requires-dist = [{ name = "dikw-core", specifier = ">=0.5.2" }]. However, the underlying pyproject.toml files in each of those packages still declare dikw-core>=0.5.1. This creates an inconsistency between what the lock file records and what the workspace source actually specifies.

Security assessment of dikw-core 0.5.2: The release is a feature/quality release (synth quality measurement, prompt tuning, self-check). No security advisories noted. The new llm_max_tokens_synth default rise (2048 → 3072) is a config change inside dikw-core, not a plugin-layer concern. No breaking changes to the Converter Protocol are mentioned.

Step 3: CI Results — FAILED

The test (3.12) job failed and test (3.13) was cancelled. Root cause from logs:

uv lock --locked
The lockfile at `uv.lock` needs to be updated, but `--locked` was provided. To update the lockfile, run `uv lock`.
Error: Process completed with exit code 1.

The CI validates lock file consistency before running tests. Because the lock file's metadata for the converter packages says >=0.5.2 while the actual source pyproject.toml files say >=0.5.1, uv lock --locked detects a mismatch and aborts.

Decision: STOP — not merging

Per the fail-fast rule, this PR is not being merged. Dependabot needs to regenerate this PR so that both the individual package pyproject.toml files and the root uv.lock are updated consistently. You can trigger a rebuild with ·@·d·ependabot r·ecreate.


Generated by Claude Code

@dependabot dependabot Bot changed the title deps: bump dikw-core from 0.5.1 to 0.5.2 deps: bump dikw-core from 0.5.1 to 0.5.3 Jun 17, 2026
@dependabot dependabot Bot force-pushed the dependabot/uv/dikw-core-0.5.2 branch from e2fc46f to 829e414 Compare June 17, 2026 05:12

Copy link
Copy Markdown
Contributor

Automated Dependabot Review

Step 1: Code Review

Summary: This PR bumps dikw-core from 0.5.1 to 0.5.3 in uv.lock. The diff is limited to the lockfile only (changed_files: 1).

Consistency concern: The lockfile diff shows the [package.metadata] entries for every workspace converter package being updated from requires-dist = [{ name = "dikw-core", specifier = ">=0.5.1" }] to >=0.5.3. In uv's lockfile format, these metadata entries are derived verbatim from each package's pyproject.toml. Since the PR does not modify any pyproject.toml file, the resulting lockfile is inconsistent with the workspace manifests — the lockfile metadata claims a higher minimum version than the actual package declarations.

Step 2 & 3: Regression / CI — FAILED ❌

CI confirms the inconsistency. The test (3.13) job failed at step "Verify uv.lock is in sync with pyproject.toml" (step 5 of the CI workflow) in under 2 seconds. All downstream steps (sync, lint, mypy, tests, packaging) were skipped.

Step 5: Verify uv.lock is in sync with pyproject.toml → FAILURE

This gate runs uv lock --check, which re-derives the expected lockfile from the workspace pyproject.toml files. The mismatch between the >=0.5.1 specifiers in pyproject.toml and the >=0.5.3 entries Dependabot wrote into the lockfile metadata causes this check to fail.

Decision: NOT merging ⛔

This PR is blocked due to a lockfile/manifest inconsistency that breaks CI. Dependabot should regenerate or rebase this PR so that the lockfile metadata reflects the actual pyproject.toml specifiers. You can trigger a fresh attempt with:

·@·d·ependabot r·ecreate

Generated by Claude Code

Copy link
Copy Markdown
Contributor

Automated Dependabot Review — PR #18

Package: dikw-core 0.5.1 → 0.5.3

CI Failure: Step Blocked

CI fails at "Verify uv.lock is in sync with pyproject.toml" (step 5 of the test (3.13) job, run 27667310520).

Root Cause

Dependabot updated the [package.metadata] specifier entries inside uv.lock from >=0.5.1 to >=0.5.3 for all three converter packages:

 [package.metadata]
-requires-dist = [{ name = "dikw-core", specifier = ">=0.5.1" }]
+requires-dist = [{ name = "dikw-core", specifier = ">=0.5.3" }]

However, the actual pyproject.toml files for those packages still declare dikw-core>=0.5.1. The [package.metadata] section in uv.lock is generated by uv lock to mirror the pyproject.toml requirements verbatim — it is not a place Dependabot should be writing. When CI runs uv lock --check, it regenerates the metadata from the source manifests (which say >=0.5.1) and finds a discrepancy, causing the check to fail.

Decision: Not merging

This PR cannot be merged as-is. To fix it, either:

  1. Update the pyproject.toml files in each converter package to raise the lower bound to >=0.5.3, then regenerate the lock file with uv lock. This is the correct approach if you want to require the new dikw-core features (OpenTelemetry, synth prompt restructure).
  2. Revert the [package.metadata] lines in uv.lock back to >=0.5.1 while keeping the resolved version at 0.5.3. This keeps the lower bound flexible and the lock file valid. Close this PR and re-run uv lock locally to generate a correct lock file, then open a new PR with only the resolved version changed.

The PR as generated by Dependabot is malformed and must be recreated or manually corrected before it can land.


Generated by Claude Code

Bumps [dikw-core](https://github.com/OpenDIKW/dikw-core) from 0.5.1 to 0.5.3.
- [Release notes](https://github.com/OpenDIKW/dikw-core/releases)
- [Changelog](https://github.com/OpenDIKW/dikw-core/blob/main/CHANGELOG.md)
- [Commits](OpenDIKW/dikw-core@v0.5.1...v0.5.3)

---
updated-dependencies:
- dependency-name: dikw-core
  dependency-version: 0.5.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot force-pushed the dependabot/uv/dikw-core-0.5.2 branch from 829e414 to a33e05c Compare June 17, 2026 05:17
Dependabot bumped the resolved dikw-core version and the lockfile's
requires-dist floor to >=0.5.3, but left the workspace members'
pyproject.toml at >=0.5.1 (a known gap with uv workspace members),
so the lock no longer matched the manifests and `uv lock --locked`
failed CI. Bump the three members' floors to match the lock, in line
with the increase-strategy convention used for the 0.2.7 -> 0.5.1 bump.
@helebest helebest merged commit 64e2b44 into main Jun 18, 2026
4 checks passed
@helebest helebest deleted the dependabot/uv/dikw-core-0.5.2 branch June 18, 2026 10:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant