chore(release): v1.2.3

[gloryfromca]

Release PR for 1.2.3. pyproject.toml was already at 1.2.3 (came in with #393); this moves the Unreleased entries under a dated heading and writes the release page's prose, per the release skill — the page is composed here, not at publish time.

What is in 1.2.3

Seven PRs since v1.2.2, 64 files, +6337/-691. Two roughly equal halves:

Agent-skill extraction and OME (#393). Extraction was stuck in a retry-then-dead-letter loop; target case data now travels on the event and existing skills are read from markdown, so the strongly-consistent path replaces the one that raced cascade. Alongside it: a path-traversal fix (CWE-22) — AgentSkillFrontmatter.name comes straight from LLM output and was concatenated into a directory path unsanitized, as were reference_name and script_filename; a renamed skill no longer strands an orphan directory; one unparseable SKILL.md no longer aborts enumeration for its whole cluster; POST /api/v2/ome/trigger reports not_dispatched instead of masking it; OME retries back off instead of burning their budget in milliseconds; agentic search reranks agent memory on the skill-shaped passage rather than the bare description.

Background maintenance (#392, #390). A soak on 1.2.2 found a table that had stopped reclaiming disk for 100 minutes while /health stayed green — nothing had failed, a call had simply never returned, and every signal was built from failure counters. Auditing for that shape found six more instances: reads with no deadline (which stop the whole md→LanceDB projection, not one table), background loops that die permanently on one exception with no log at all, an alert counter reset by the remediation it triggers, and both sides of the optimize↔rebuild wait. Also: keyword search no longer 500s during an index rebuild (FTS hard-fails without its index where vector search degrades), and the maintenance cadences moved into a [cascade] settings section.

The rest is CI (#387, #389, #391) and a doc marker (#399).

Validation

Tests — 2020 unit + 182 integration, ruff and import-linter clean.

Soak (run18, the release gate) — 2h at the throughput ceiling: 49,440 entries, 8,240 md writes, 10,324 searches, 12 QPS, two concurrent CLI writers, fuzz throughout. Ten fault counters, nine at zero; the tenth is one lost commit race out of 88 rebuilds, which succeeded on the next sweep.

BM25 failures during an index rebuild	0 across 10,324 searches × 88 rebuilds
Read / write-lock deadline misfires	0 / 0
Loop crashes, drain failures, lock waits	0
Disk	peak 6,995MB → 1,370MB after writes stop; all three tables collapse to versions=1
Memory	plateaus at 4.2GB — four runs now show 1× and 4× pressure converging to the same 4.1–4.4GB, so it is bounded and does not scale with load

Full write-up and the preceding runs are on Confluence (LanceDB soak folder, run1–18).

Upgrade notes

Both are in the CHANGELOG's ### Upgrade group, so they reach the release page:

• extract_foresight ships disabled — a deployment relying on it must set enabled = true in ome.toml.
• SkillClusterUpdated now persists a 1024-dim embedding, taking a skill_cluster_updated run_record row from ~0.8 KB to ~14 KB (~14 MB for the default 1000-record ring buffer, against ~0.8 MB). Worth knowing when sizing ome.db.

One thing to decide before tagging

Under sustained ceiling load with two concurrent CLI writers, the 900s prune-staleness alarm fires periodically. It reports something true — that table really did go 900s without reclaiming — and the system recovers on its own every time (heavy-beat win rate 83–87% across three runs, and the alarming table rotates rather than sticking). Real deployments neither sit at the throughput ceiling nor run a second writer continuously, so this reads as a threshold question rather than a defect.

Worth deciding whether to widen it from 3 missed beats to 5. Left as-is here because it is a judgement call, not a fix — but an operator who sees red while nothing is wrong learns to ignore the field, which is worse than not having it.

🤖 Generated with Claude Code