feat(storage): upgrade format 8 and 9 graphs to format 14

.github/workflows/ci.yml

@@ -771,7 +771,42 @@ jobs:
       - name: Check storage compatibility gate configuration
         run: python3 scripts/check-storage-upgrade-ci.py --self-test
 
-      # The genuine stamp-13 predecessor for the one in-place route
+      # The genuine predecessors of the release route (`omnigraph upgrade`,
+      # storage format 8 or 9 to 14): v0.11.0 writes stamp 9 and converts a
+      # v0.10.0 graph to stamp 8. The release assets are trusted exactly as
+      # the `test` job's v0.9.0 and v0.10.0 installs trust them: `install.sh`
+      # verifies the archive against the `.sha256` published beside it, and
+      # no digest is pinned here.
+      - name: Install released v0.10.0 and v0.11.0 CLIs
+        run: |
+          set -euo pipefail
+          v6_dir="$RUNNER_TEMP/omnigraph-v010"
+          v011_dir="$RUNNER_TEMP/omnigraph-v011"
+          # The installer downloads the official archive and verifies its
+          # SHA256 before extraction. An exact VERSION never falls back to edge.
+          # A failed download leaves nothing behind, so each release gets three
+          # attempts before this required context goes red.
+          install_release() {
+            for attempt in 1 2 3; do
+              REPO_SLUG=ModernRelay/omnigraph VERSION="$1" INSTALL_DIR="$2" \
+                bash scripts/install.sh && return 0
+              echo "install of $1 failed on attempt $attempt/3; retrying"
+              sleep 10
+            done
+            return 1
+          }
+          install_release v0.10.0 "$v6_dir"
+          test -x "$v6_dir/omnigraph"
+          [[ "$("$v6_dir/omnigraph" --version)" == "omnigraph 0.10.0" ]] \
+            || { echo "::error::the storage upgrades of a 0.10.0 graph require the genuine v0.10.0 CLI"; exit 1; }
+          install_release v0.11.0 "$v011_dir"
+          test -x "$v011_dir/omnigraph"
+          [[ "$("$v011_dir/omnigraph" --version)" == "omnigraph 0.11.0" ]] \
+            || { echo "::error::the release storage upgrade requires the genuine v0.11.0 CLI"; exit 1; }
+          echo "OMNIGRAPH_V6_BIN=$v6_dir/omnigraph" >> "$GITHUB_ENV"
+          echo "OMNIGRAPH_V011_BIN=$v011_dir/omnigraph" >> "$GITHUB_ENV"
+
+      # The genuine stamp-13 predecessor for the main-build in-place route
       # (`omnigraph upgrade`, storage format 13 to 14). Keep this immutable:
       # HEAD^ is not a stable format reference, and the last main commit that
       # wrote stamp 13 is the source the journey converts.

changelog.d/history-release.breaking.md

@@ -2,8 +2,8 @@
   commits and releases older ones into immutable Lance files under
   `__history`, so a publish no longer rewrites the branch's whole history.
   Graph commit ids take the form `hb1.<block>.<slot>.<nonce>`. This is
-  storage format 14: a standalone format 13 graph is converted by the offline
-  `omnigraph upgrade`, and a graph at any older format is rebuilt by export,
+  storage format 14: a standalone format 8, 9 or 13 graph is converted by the
+  offline `omnigraph upgrade`, and a graph at any other format is rebuilt by export,
   `init` and `load --mode overwrite`, as described in the
   [upgrade guide][history-release-upgrade]. A session may lower the release
   budget with `set history_release_bytes = <bytes>;` (`1024..=262144`, default

changelog.d/schema-contract-inlining.breaking.md

@@ -1,8 +1,8 @@
 - Schema apply and system-column upgrades now publish the schema source,
   compiled schema and identity atomically with their table references in the
   catalog. Ordinary open serves storage format 14 only and refuses every other
-  format. Convert a standalone format 13 graph with the offline
-  `omnigraph upgrade`; rebuild an older graph by export, `init` and
+  format. Convert a standalone format 8, 9 or 13 graph with the offline
+  `omnigraph upgrade`; rebuild a graph at any other format by export, `init` and
   `load --mode overwrite`, as described in the
   [upgrade guide][schema-contract-inlining-upgrade]. Fresh graphs no
   longer create separate root schema files.

changelog.d/storage-upgrade-v13-v14.breaking.md

@@ -1,17 +1,33 @@
-- `omnigraph upgrade` now converts a standalone storage format 13 graph
-  (written by main development builds from 2026-10-01 to 2026-10-04) to
-  format 14 in place, keeping its branches, commit ids and commit history; it
-  no longer only reports. The upgrade is offline: stop every process using
-  the graph, retain a verified backup of the whole root, run
+- `omnigraph upgrade` now converts a standalone graph to storage format 14
+  in place, keeping its branches, commit ids and commit history; it no longer
+  only reports. It accepts two sources: formats 8 and 9, written by release
+  0.11.x, and format 13, written by main development builds from 2026-10-01
+  to 2026-10-04. The upgrade is offline: stop every process using the graph,
+  retain a verified backup of the whole root, run
   `omnigraph upgrade <graph> --check`, then `omnigraph upgrade <graph>`. An
   interrupted run leaves the graph refused by normal open until the same
   command is run again. Cluster-managed graphs and every other format are
   still rebuilt by export, `init` and `load --mode overwrite`. Pre-upgrade
   commits are kept under `__history/legacy/`: a 14 build older than this
   change reports pre-upgrade commits as not found by id and refuses
   full-history reads on an upgraded root, so upgrade every binary before the
-  graph. The JSON report gains a `work` object and now reports
-  `check_passed` and `completed`. See the
+  graph. For a 0.11.x graph the schema is read from the three schema objects
+  at the graph root, which the upgrade leaves in place and which go stale at
+  the next schema apply; the objects must match the tables, so a stale copy
+  restored from an older backup is refused before any write; every
+  pre-upgrade commit is recorded under the one schema live at the upgrade; a
+  `.staging` schema object or a recovery file left by 0.11.x is refused until
+  a 0.11.x read-write open (`omnigraph snapshot`) resolves it, while a
+  `__schema_apply_lock__` branch left alone by a killed 0.11.x schema apply is
+  handled by the upgrade and is not a live branch afterwards; and on a root
+  where 0.11.x `cleanup` or `schema apply --allow-data-loss` ran, the first
+  `cleanup` after the upgrade is `cleanup --keep 1 --confirm` alone. The JSON
+  report gains a `work` object, names its route per source
+  (`history-lance-files-v8-to-v14`, `history-lance-files-v9-to-v14`,
+  `history-lance-files-v13-to-v14`), names `history-lance-files-to-v14` as
+  `recovery.failed_handler` when it stops before any route is known (an
+  unreadable pending marker, or recovery files on a format no route
+  converts), and now reports `check_passed` and `completed`. See the
   [upgrade guide][storage-upgrade-v13-v14-guide].
 
 [storage-upgrade-v13-v14-guide]: ../docs/user/operations/upgrade.md#storage-upgrade