[codex] Prepare 0.4 release version parity

[Fieldnote-Echo]

Summary

This prepares the stacked release work for a lockstep 0.4.0 cut across the repo’s published and release-visible surfaces.

• bumps the core crate, Python crate/package, manifest crate, FFI crate, threat model, changelog, and fuzz lock to 0.4.0
• adds a release version-sync invariant covering Cargo manifests, Python pyproject.toml, Python __version__, manifest dependency version, FFI version, changelog entry, threat-model release status, and fuzz/Cargo.lock
• updates the release graph so ordvec-manifest is packaged, attested, staged, and published after the matching core ordvec version is on crates.io
• keeps core/Python release assets and manifest release assets in separate draft-staging jobs, with the final un-draft gated on all registry publishes
• adds Go version/ABI accessors and narrows Python API parity wording to avoid overclaiming Rust-only manifest/probe APIs

Why

A fresh lockstep ordvec-manifest release cannot be packaged normally before the matching ordvec version exists on crates.io. This branch makes that dependency order explicit: publish and byte-verify the core crate first, then package/attest/stage/publish the manifest crate with normal cargo package --locked semantics.

Validation

• bash tests/release_publish_invariants.sh
• bash tests/release_signed_release_invariants.sh
• /tmp/ordvec-actionlint/actionlint .github/workflows/release.yml .github/workflows/ci.yml .github/workflows/fuzz.yml
• cargo metadata --manifest-path fuzz/Cargo.toml --locked --format-version 1 >/tmp/ordvec-fuzz-metadata.json
• cargo metadata --no-deps --format-version 1 --locked >/tmp/ordvec-metadata.json
• cargo test -p ordvec-manifest --no-default-features
• cargo test -p ordvec-manifest --all-features
• cargo build -p ordvec-ffi --release
• GOCACHE=/tmp/ordvec-go-build go test -count=1 ./... in ordvec-go
• PYTHONPATH=ordvec-python/python python3 -c 'import ordvec; print(ordvec.__version__)'
• cargo publish -p ordvec --dry-run --locked --allow-dirty
• Verified cargo package -p ordvec-manifest --locked currently fails before core 0.4.0 is on crates.io, then verified the CI wrapper defers only that exact resolver failure to the release workflow after publish-crate
• adversarial subagent review of the release/version graph, including a focused re-review after remediation

[Fieldnote-Echo]

/agentic_review

[gemini-code-assist]

Code Review

This pull request updates the project version to 0.4.0 across all crates and bindings, documents the lockstep release pipeline for ordvec-manifest, and introduces new release invariant checks in Python and Shell scripts. The review feedback highlights a Python 3.10 compatibility issue with tomllib in the new invariant script, a potential null-pointer panic in the Go bindings, and suggests regex robustness improvements for parsing version strings.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Fieldnote-Echo]

/agentic_review

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0)

1. Brittle CI defer heuristic ✓ Resolved 🐞 Bug ☼ Reliability

Description

CI treats a failed cargo package -p ordvec-manifest --locked as success based solely on grepping
for a specific Cargo error substring, which can silently skip real packaging failures that still
include that text. It can also start failing CI unexpectedly if Cargo adjusts the error wording.

Code

.github/workflows/ci.yml[R265-276]

+      - name: cargo package -p ordvec-manifest when lockstep core exists
+        run: |
+          set -euo pipefail
+          log="${RUNNER_TEMP}/ordvec-manifest-package.log"
+          if cargo package -p ordvec-manifest --locked 2>&1 | tee "$log"; then
+            exit 0
+          fi
+          if grep -q 'failed to select a version for the requirement `ordvec = "' "$log"; then
+            echo "::notice::ordvec-manifest package check is deferred: the lockstep ordvec version is not published yet. release.yml packages ordvec-manifest after publish-crate succeeds."
+            exit 0
+          fi
+          exit 1

Evidence

The CI step explicitly exits 0 on a specific stderr substring match after cargo package fails,
which is a fragile classification mechanism and can hide non-deferral failures.

.github/workflows/ci.yml[260-276]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The CI step defers the `ordvec-manifest` packaging check by matching a hard-coded Cargo stderr substring. This is brittle and can (a) misclassify other failures as deferrable, or (b) break when Cargo’s wording changes.

### Issue Context
The intent is to skip the manifest packaging check only when the lockstep `ordvec` version is not yet published on crates.io.

### Fix Focus Areas
- .github/workflows/ci.yml[260-276]

### Suggested fix
Replace the stderr-grep heuristic with an explicit “is this version published?” probe:
1. Read the core version (e.g., `cargo metadata --no-deps --format-version 1` and extract the `ordvec` package version).
2. `curl -fsI` a stable crates.io endpoint for that exact version (e.g., the same download/static URLs used in release.yml).
3. If the version is not found (HTTP 404), emit the existing notice and skip.
4. If the version exists, require `cargo package -p ordvec-manifest --locked` to succeed (no skip path).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. No retry manifest package ✓ Resolved 🐞 Bug ☼ Reliability

Description

build-manifest-crate runs a single cargo package -p ordvec-manifest --locked, so any transient
crates.io registry/index inconsistency will fail the release workflow after the core crate is
already published. This is inconsistent with the workflow’s explicit retry/backoff for crates.io
propagation in its post-publish byte-identity readback steps.

Code

.github/workflows/release.yml[R275-279]

+        # The lockstep manifest crate depends on the just-tagged `ordvec`
+        # version, so package it only after `publish-crate` has published and
+        # verified the core crate. This is the first point where Cargo can
+        # resolve the dependency through the registry for a fresh release.
+        run: cargo package -p ordvec-manifest --locked

Evidence

The manifest packaging step runs once with no retry/backoff, while other parts of the same workflow
explicitly handle crates.io propagation delays with retries, indicating this workflow expects
eventual consistency and should harden this packaging edge similarly.

.github/workflows/release.yml[258-279]
.github/workflows/release.yml[817-841]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`build-manifest-crate` packages `ordvec-manifest` once immediately after `publish-crate`. If Cargo cannot resolve the freshly-published `ordvec` version via the registry index yet, the release run fails after the core publish has already happened.

### Issue Context
The workflow already implements propagation retries for crates.io readback downloads, but not for the first registry-backed dependency resolve needed to package `ordvec-manifest`.

### Fix Focus Areas
- .github/workflows/release.yml[258-279]
- .github/workflows/release.yml[817-841]

### Suggested fix
Wrap `cargo package -p ordvec-manifest --locked` in a small retry loop (e.g., up to 12 attempts with `sleep 5`) that retries only on the specific resolver error indicating the `ordvec` version is not yet selectable, and fails fast on all other errors. Emit a clear `::notice::` on retries and a final `::error::` if the retry budget is exhausted.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

Review Summary by Qodo

Prepare 0.4 release version parity with lockstep manifest publishing

✨ Enhancement 🧪 Tests

Walkthroughs

Description

• Bumps all crates and Python bindings to version 0.4.0 for lockstep release
• Adds release version-sync invariant covering Cargo manifests, Python package metadata, and
  documentation
• Restructures release workflow to defer manifest crate packaging until core crate publishes to
  crates.io
• Separates core and manifest asset staging into distinct draft-release jobs with independent
  provenance
• Adds Go version/ABI accessors and narrows Python API parity documentation

Diagram

flowchart LR
  A["Version Bump<br/>0.3.0 → 0.4.0"] --> B["Release Invariants<br/>Check"]
  B --> C["Build Core Crate"]
  C --> D["Attest & Provenance<br/>Core"]
  D --> E["Stage Core Assets<br/>release-assets-draft"]
  E --> F["Publish Core<br/>publish-crate"]
  F --> G["Build Manifest<br/>build-manifest-crate"]
  G --> H["Attest & Provenance<br/>Manifest"]
  H --> I["Stage Manifest Assets<br/>release-manifest-assets-draft"]
  I --> J["Publish Manifest<br/>publish-manifest-crate"]
  J --> K["Un-draft Release<br/>publish-github-release"]

Loading

File Changes

1. Cargo.toml Version bump +1/-1

Bump core crate version to 0.4.0

Cargo.toml

---

2. ordvec-python/Cargo.toml Version bump +1/-1

Bump Python Rust bindings version to 0.4.0

ordvec-python/Cargo.toml

---

3. ordvec-python/pyproject.toml Version bump +1/-1

Bump Python project version to 0.4.0

ordvec-python/pyproject.toml

---

View more (15)

4. ordvec-python/python/ordvec/__init__.py Version bump, documentation +6/-4

Update version to 0.4.0 and narrow API parity claims

ordvec-python/python/ordvec/init.py

---

5. ordvec-manifest/Cargo.toml Version bump +2/-2

Bump manifest crate and ordvec dependency to 0.4.0

ordvec-manifest/Cargo.toml

---

6. ordvec-ffi/Cargo.toml Version bump +1/-2

Bump FFI crate version to 0.4.0

ordvec-ffi/Cargo.toml

---

7. ordvec-go/ordvec.go ✨ Enhancement +12/-0

Add ABIVersion and Version accessor functions

ordvec-go/ordvec.go

---

8. ordvec-go/ordvec_test.go 🧪 Tests +18/-0

Add tests for version accessor functions

ordvec-go/ordvec_test.go

---

9. tests/release_publish_invariants.py Tests, enhancement +209/-0

Add comprehensive release version-sync invariant checking

tests/release_publish_invariants.py

---

10. tests/release_signed_release_invariants.sh Tests, enhancement +73/-22

Update release graph to separate manifest asset staging

tests/release_signed_release_invariants.sh

---

11. .github/workflows/release.yml ⚙️ Configuration changes +160/-49

Restructure release workflow for deferred manifest packaging

.github/workflows/release.yml

---

12. .github/workflows/ci.yml ⚙️ Configuration changes +20/-9

Update manifest package check to defer until core publishes

.github/workflows/ci.yml

---

13. .github/workflows/fuzz.yml ⚙️ Configuration changes +4/-0

Add fuzz lockfile currency check to CI

.github/workflows/fuzz.yml

---

14. CHANGELOG.md 📝 Documentation +16/-0

Add 0.4.0 release notes with manifest publishing details

CHANGELOG.md

---

15. THREAT_MODEL.md 📝 Documentation +1/-1

Update threat model status to v0.4.0

THREAT_MODEL.md

---

16. RELEASING.md 📝 Documentation +32/-27

Document lockstep manifest crate release process

RELEASING.md

---

17. CONTRIBUTING.md 📝 Documentation +11/-7

Clarify release automation and manifest crate timing

CONTRIBUTING.md

---

18. ordvec-manifest/README.md 📝 Documentation +4/-5

Update installation instructions for published releases

ordvec-manifest/README.md

---

[qodo-code-review]

Code review by qodo was updated up to the latest commit ef3dc00