chore(release): v1.3.0rc1

[gloryfromca]

Pre-release for smoke-testing the optional Milvus derived-index backend (#332) and the everalgo transitive pin against a real PyPI resolution.

Why an RC

The release pipeline's own smoke installs the built wheel with --no-deps (Makefile package target), so it cannot catch a dependency-resolution break. That is exactly how 1.2.3 shipped with POST /add answering 500 on a default install: everalgo-boundary floated to 0.3.0, which added a third required field to the public DetectionResult NamedTuple while everalgo-agent-memory 0.4.0 still built it with two. An RC is the first chance to verify the pin through a real pip install.

Changes

File	Change
pyproject.toml	version = "1.3.0rc1"
docs/openapi.json	regenerated — info.version tracks everos.__version__ (installed package metadata), and make lint fails on a stale dump
uv.lock	project version

No CHANGELOG section: release.yml requires one only for stable tags (if match is None and not prerelease), and a pre-release page falls back to a generic body. The 1.3.0 prose comes with the stable bump.

Verification

• make lint — all checks pass, 4 import-linter contracts kept, openapi dump matches
• pytest tests/unit — 2143 passed
• tests/unit/test_entrypoints/test_api/test_app_metadata.py — pins app.openapi()["info"]["version"] == __version__

Smoke-testing the RC

pip skips pre-releases by default, so the version must be named explicitly. Pin the exact version — do not use --pre:

pip install everos==1.3.0rc1
python -c "import everos; print(everos.__version__)"                     # 1.3.0rc1
python -c "import everalgo.boundary as b; print(b.DetectionResult._fields)"
# ('cells', 'tail')                 -> pin is in effect
# ('cells', 'tail', 'should_wait')  -> pin did not take; stop here

Caution

An earlier revision of this description said pip install --pre everos. That is wrong and was corrected after it broke a smoke run. --pre (and uv's --prerelease=allow) is a global switch: it permits pre-releases for every transitive dependency too, not just everos. It resolved httpx — not declared in pyproject.toml, pulled in transitively — to 1.0.dev6, whose top-level API has no Timeout, and POST /add answered 500 with AttributeError: module 'httpx' has no attribute 'Timeout'. Same failure class as the boundary break this RC exists to verify, one package over. An exact == pin needs no --pre and leaves every other dependency on its stable resolution (httpx 0.28.1, matching uv.lock).

RC verification (2026-09-07, against the published package)

Installed from PyPI by exact pin, both installation paths, everos init → server → /add → /flush → cascade → /get → /search:

	default (LanceDB)	[milvus] extra
resolved everalgo-boundary	0.2.1	0.2.1
DetectionResult._fields	('cells','tail')	same
three unrelated conversations ingested	all extracted	all extracted
cascade pending / retryable / permanent	0 / 0 / 0	0 / 0 / 0
/get episode	3, subjects accurate	3
/search discrimination (4 methods x 3 topics)	11/12	12/12
owner isolation (unknown user)	0 rows	0 rows

The one LanceDB miss is keyword x one topic, caused by extraction-language drift (that episode came back in Spanish from English input, so English BM25 terms cannot reach it) — a known LLM instruction-following issue, unrelated to the index backend, and absent from the Milvus run on the same input.