chore: release witan-core 0.18.0 and revert omnigraph to 0.9.0

[blarghmatey]

What are the relevant tickets?

tk-the-write-gate-is-sized-against-a-3-45s-solo-wri-73fc2b, under wp-witan-multi-user-service-deployment-dcf6ee. Findings recorded in les-omnigraph-0-10-0-edge-looks-worse-than-0-9-0-on--ef8f5d.

Ends the experiment opened by #231 and releases the gate work from #232.

Description (What does it do?)

Two things in one commit, because the revert has to be in the released version.

1. Revert omnigraph 0.10.0 edge → v0.9.0

#231 pinned the upstream edge build specifically to measure its effect on the write ceiling. That measurement is now in, across several runs, and the sign is wrong.

Same probe, same cluster, same actor, same evening:

build	load	result
0.9.0	8 writers	PASS — 8 acked, 0 indeterminate, readers clean
0.10.0	8 writers	FAIL ×6 consecutive — 2 to 8 of 8 indeterminate, every reader degraded in every run
0.10.0	4 writers	PASS ×2 — clean

The clean point moved from 8 to 4 — the ceiling roughly halved. Higher loads are the same story, worse: 12w → 10 of 12 indeterminate, 16w → 10 of 16, 24w → 19 of 24 with the pod log showing all 24 handlers "outcome": "ok". Every one of those committed while its caller was told it failed.

0.10.0 also produces a shape 0.9.0 never did — a few genuine server-side errors, ~7ms, on task_get and memory_store at the same instant. Small in number, not the main effect, but new.

Mutual exclusion is unaffected. Probe A passed at every load on both builds: exactly one claimed: true, every loser a structured refusal, zero errors. What changed is the write path's capacity, not its correctness.

And nothing in 0.10.0 was aimed at our problem anyway. The two upstream changes that address the indeterminate write — cancellation shielding and the async job API — are not in it. The first was closed on 2026-08-13 as superseded by RFC-035 (#498), which along with RFC-034 (#496) and RFC-036 (#499) is an open design document. So this build was carrying a measured regression in exchange for nothing, on an unreleased binary off upstream main.

⚠️ Weakness to carry forward

The 0.9.0 side is one run at 8 writers against six on 0.10.0. Six consecutive failures where 0.9.0 was clean is strong evidence, but the clean baseline is not itself replicated. Re-running 8w a few times on 0.9.0 would close that, and is the thing to do before concluding anything upstream.

2. Release witan-core 0.18.0

The predictive write gate (#232). The gate previously bounded concurrency and the wait for a slot, and neither predicts how long the work takes once admitted — so it let through exactly the writes that strand. It now measures what an admitted write costs per graph and refuses when that no longer fits the call's remaining budget.

This does not raise the ceiling. It converts the writes that cannot succeed into a clean pre-send refusal instead of an indeterminate outcome.

How has this been tested?

• just check-omnigraph-pins → omnigraph pins agree: 0.9.0 (tag v0.9.0, sha 507a36f385be…)
• just check-omnigraph-format → omnigraph 0.9.0 reads storage format 6, as declared.
• just check-versions → consistent across 5 packages
• Image fetch stage built against the reverted pins → produces omnigraph 0.9.0, confirming the v0.9.0 digests are correct before they reach the pipeline
• witan-core 478 passed, witan-council 785 passed, witan-code 516 passed
• prek clean

The revert is as cheap as the upgrade was, for the same reason: storage format 6 is unchanged in both directions, so it is a binary swap against the same store with no migration and no rebuild.

Deploy note

Merging rebuilds the omnigraph-server image and CI's Pulumi deploy triggers on the fresh build, restarting the data tier automatically — the same path #231 took. Concourse polls rather than being triggered by the merge, so expect roughly half an hour before the image appears.

Worth doing once it lands: re-run 8w on 0.9.0 a few times to replicate the clean baseline, then re-measure the new gate, whose expected shape is WriteQueueFull refusals replacing the indeterminate writes.

Does this change require a change to documentation?

No.

[Copilot]

Pull request overview

Releases witan-core 0.18.0 and restores the stable OmniGraph 0.9.0 binary after the edge-build performance experiment.

Changes:

• Updates witan-core release metadata and changelog.
• Reverts OmniGraph version, release tag, and checksums consistently across installer and images.
• Preserves storage format compatibility without migration.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
uv.lock	Records witan-core 0.18.0.
packages/witan-core/witan_core/omnigraph_install.py	Restores OmniGraph 0.9.0 installer pins.
packages/witan-core/pyproject.toml	Bumps package and release-tool versions.
packages/witan-core/CHANGELOG.md	Documents predictive write admission.
docker/witan.Dockerfile	Restores OmniGraph 0.9.0 in the MCP image.
docker/omnigraph-server.Dockerfile	Restores OmniGraph 0.9.0 in the data-tier image.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.