[aaltshuler]

Summary

• state the public node/edge/type/entity/property vocabulary break in the coordinated-upgrade warning
• label the detailed compatibility entry as a breaking graph-vocabulary change
• remove the redundant internal development-line history from the public release note

The published GitHub v0.10.0 release body has already received the same correction. The immutable v0.10.0 tag is unchanged.

Validation

• python3 scripts/check-docs.py
• git diff --check

Greptile Summary

The PR clarifies that v0.10 introduces a breaking public graph-vocabulary change and strengthens the coordinated-upgrade warning.

• Foregrounds the node, edge, type, entity, and property terminology migration.
• Labels the detailed compatibility entry as breaking.
• Removes redundant history about unreleased experimental manifest formats.

Confidence Score: 5/5

The documentation-only PR appears safe to merge.

The revised compatibility warning is consistent with the public vocabulary contract, and the retained release text continues to identify storage format v6 and the supported v0.9 upgrade path.

Important Files Changed

Filename	Overview
docs/releases/v0.10.0.md	Clarifies the documented v0.10 vocabulary break and removes internal development-line history without introducing an actionable documentation defect.

_{Reviews (1): Last reviewed commit: "docs(release): foreground v0.10 vocabula..." | Re-trigger Greptile}

[ragnorc]

Checked against current main's v0.10.0.md — applies cleanly, foregrounds removals the Compatibility entry already stated (and the vocabulary guard actually enforces), and removing the development-line note orphans nothing: the v7–v19 refusal remains covered in versioning.md and RFCs 0024/0026, and the one inbound release-note link targets an anchor that survives. LGTM.

[ragnorc]

Rebase this pull request onto current main and resolve the one conflict. Keep the new upgrade wording. Keep the deletion of the development-line note.

Why

An operator who upgrades from v0.9 must see the client-vocabulary break in the first warning. The page on main still places that break only in the compatibility list. The GitHub release body for v0.10.0 already uses the stronger wording. This change makes the page on main say the same thing, and it removes a stamp sentence that is now false.

What

The change edits docs/releases/v0.10.0.md only.

• The coordinated-upgrade paragraph names nodes, edges, types, entities, and properties, and says the ambiguous public table and row names are removed.
• The compatibility bullet carries the label Breaking graph vocabulary.
• The development-line note is removed.

How to land it

main is 9e2425d26a03b1b5628030a359ee51f096d3ca1c. This head is 11c33b6f98f523fae98a78e6bd2c630e4c21201b. The pull request is open. GitHub reports it conflicting (mergeable: CONFLICTING, mergeStateStatus: DIRTY).

A merge of this head with current main conflicts in one place: the compatibility list in docs/releases/v0.10.0.md. The upgrade paragraph merges cleanly. The note deletion merges cleanly. Commit 73ea201b (2026-09-06, "fix: preserve CLI targeting and embedding APIs with managed data access") inserted a bullet about ServerConfig, ServingSnapshot, and ResolvedActor directly above the vocabulary bullet.

Keep both bullets. Put the embedding-API bullet first. Put the labeled vocabulary bullet second. Keep the managed-folder highlight that is already on main.

The page on main has two sections that the GitHub release body does not have: the managed-folder highlight and the embedding-API bullet. Keep both. The tag v0.10.0 (a625748c) still has the old page, including the development-line note and without the breaking label. This pull request leaves that tag in place. That matches the pull-request description.

Blocking

1. Resolve the conflict before merge. The pull-request side of the conflict is only the labeled vocabulary line. The main side is the embedding-API bullet plus the unlabeled vocabulary line. A resolution that takes only this head deletes the embedding-API bullet.

Which text is wrong

The new sentences match the v0.10 public contract. Current code still enforces that contract.

• openapi.json on main contains graph_manifest_version. It contains no table_key, row_id, rows_loaded, or manifest_version.
• export --help exposes --type. export --table fails as an unexpected argument (crates/omnigraph-cli/tests/integration/cli_schema_config.rs).
• Load output counts entities and node types, and it does not print rows_loaded (crates/omnigraph-cli/tests/integration/system_local.rs).
• skills/omnigraph/references/migrations.md lists the same removed names. It tells readers to use node, edge, type, entity, property, graph-manifest, and published-dataset terms, plus export --type.

The sentence that is wrong sits on main, in the note this pull request deletes:

Those abandoned formats remain refused.

That sentence treats stamps v7–v19 as abandoned. docs/dev/versioning.md now gives shipped meanings to stamps 7 through 16. The current binary serves stamps 14 to 16. The v0.11 upgrade path converts stamps 8 and 9. Unreleased MemWAL graphs stay refused. A reused stamp number does not make one of those graphs readable. The current rule is the paragraph in docs/dev/versioning.md that starts "the unreleased v7–v19 stamps", and the section "Why there is no MemWAL path" in docs/dev/ingestion.md. Delete the note. Leave the rule in those two guides.

The only copy of the sentence "an earlier unreleased experiment also used 0.10.0" is that note. That sentence is internal history. The operator rule is the stamp refusal above.

Lance MemWAL is an experimental log-structured write path for a Lance table (upstream page "MemTable & WAL", still marked experimental). OmniGraph has no MemWAL consumer (docs/dev/lance.md, full-text and MemWAL rows). The deleted note records OmniGraph stamp history. It does not describe a Lance procedure.

RFC 0024's opening banner still says the current binary serves manifest v6. That banner is stale. Use docs/dev/versioning.md for the stamp rule. RFC 0026 still records that the experiment was removed. The 2026-09-01 comment on this pull request treated RFC 0024 as current coverage. versioning.md and ingestion.md are the coverage that is current.

The v0.10 intro already says this release keeps graph storage format v6. That sentence stays true. The link from docs/user/operations/upgrade.md to docs/releases/v0.10.0.md#compatibility still resolves. No page links to #development-line-note.

Optional

Reflow the compatibility bullet. At this head, line 115 of docs/releases/v0.10.0.md ends with properties, and line 116 starts the rest of the sentence. Join those lines so the names read as one phrase. The published GitHub release body has the same break. A reflow changes line wrapping only.

Later releases

This page is still the hand-written v0.10 note. v0.11 documents a separate identity-field change (@id, __id, __src, __dst). v0.12 and v0.13 are generated format-1 snapshots. changelog.d/release.json names the next version v0.14.0. There is no v0.14 release page. Open pull request #880 proposes format-2 pages for releases after v0.12 and leaves the v0.12 page unchanged. It does not replace this edit.

Hand-editing docs/releases/v0.10.0.md remains the right mechanism. The rule that a published fragment stays frozen, and that a correction gets a new note, applies to changelog.d inputs for generated pages (docs/dev/documentation.md). v0.10 has no provenance block. main already edited this page after the tag, in 73ea201b.

Tradeoff and liability

The upgrade banner and the compatibility list describe one break. The banner makes the break visible at the top of the page. The list keeps the removed names. Removing the development-line note leaves stamp policy in docs/dev/versioning.md. The page gains no API, no stored state, and no engine rule.

Further wording fixes of this kind stay cheap while they remain edits to this one historical page. Copying each new stamp rule back onto the v0.10 page would add a second policy that drifts. This change avoids that copy.

The page on main stays different from the immutable tag. It also keeps the managed-data paragraphs that the GitHub release body lacks. That split is already true. This change closes the vocabulary gap between the release body and main.

Correctness of the upgrade warning comes first. The edit stays small: three text changes in the existing page, and the existing docs check.

Regression proof

This change does not fix a behavioral bug. The regression-proof rule does not apply. A .gqt case cannot express release-note wording. No Rust test owner needs a new assertion.

Validation

Isolated checkout of 11c33b6f98f523fae98a78e6bd2c630e4c21201b:

• git merge --no-commit --no-ff 9e2425d26a03b1b5628030a359ee51f096d3ca1c conflicted only in docs/releases/v0.10.0.md.
• git diff --check 11c33b6f^..11c33b6f exited 0.
• python3 scripts/check-docs.py at that commit printed Documentation OK (117 Markdown files checked).
• The same command at 9e2425d2 printed Documentation OK (343 Markdown files checked).
• The same command on 9e2425d2 with the conflict resolved as described above printed Documentation OK (343 Markdown files checked). The diff against main is 8 insertions and 12 deletions.

A docs check in the uncommitted merge, while HEAD was still 11c33b6f, failed with 926ba3528c51583049c862f02a9604a610a9f560 is not a known ancestor of 11c33b6f; fetch complete history. That run compared main's release configuration with the old commit. The check of the resolved page on current main passed.

CLI behavior above is from source and tests on 9e2425d2. This review did not run the CLI binary. It makes no performance claim. The Greptile note in the pull-request body reviews this same head and does not account for the later conflict.

Reviews already on this head

There is no GitHub review. There are no inline review comments. The issue comment of 2026-09-01 says the patch applies cleanly. That was true against main that day. It is false against 9e2425d2.