heal-hf: validate the rewritten manifest via 'ollama show' + roll back on failure

Before this, `make heal-hf` trusted its own rewrite: after the
`jq` digest-substitution succeeded and the atomic `mv` into place
landed, the script proceeded to remove the old qwen36 blob and
declare success. A rewrite that produced jq-parseable but
ollama-rejected JSON — e.g. layer order off, missing mediaType,
digest no longer matching the on-disk blob bytes — would only
surface at the user's next `ollama run`, by which point the old
blob was gone and the tag was stuck in a half-broken state.

Two changes to make the script crash-safe:

1. **Backup before rewrite, restore on validation failure.** Step 5
now `cp`s the original manifest to `${MANIFEST}.heal-backup`
before invoking jq, runs the rewrite + atomic `mv` as before,
then runs `ollama show ${TAG} >/dev/null` as a self-test.
`ollama show` parses the manifest, walks layer digests, and
reads enough of the model blob to extract metadata (arch,
params, etc.) — it's exactly the surface that needs to hold
for `ollama run` to subsequently load. On failure the script
`mv`s the backup back over the manifest, prints a diagnostic,
and exits non-zero. On success the backup is removed.

2. **Reordered old-blob cleanup to come AFTER validation.** What
was step 6 (remove old qwen36 blob if no other manifest refs
it) is now step 7, gated behind step 6 (validate). This means
a rollback always lands on a consistent state: original
manifest still pointing at the original blob, both still
present. The new qwen35 blob is left in the store as an
orphan; ollama auto-prunes unreferenced blobs on next service
restart, so disk usage tidies up on its own.

Doesn't change runtime materially — `ollama show` finishes in
milliseconds because it only reads GGUF metadata (KV header), not
tensor data.

Verified end-to-end this session against the actual broken pull:
manifest rewrite + `ollama show` validation pass, smoke + tool-call
round-trip continue to succeed on the healed `hf.co/...` tag. The
rollback path is defensive and exercised by reading the code, not
by an integration test (the heal logic itself works; the rollback
exists for a hypothetical future regression).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

CHANGELOG.md

@@ -7,6 +7,24 @@ and documentation**, not the underlying base model.
 
 ## [Unreleased]
 
+### Added
+- `scripts/heal_hf_pull.sh` now validates the rewritten manifest by
+  running `ollama show <tag>` immediately after the atomic mv into
+  place, with rollback-on-failure semantics. Before this, a buggy
+  rewrite that produced jq-parseable but ollama-rejected JSON (e.g.
+  layer order off, missing required mediaType, digest that no
+  longer matches the on-disk blob bytes) would only be discovered
+  at the user's `ollama run` step — and by then the old qwen36
+  blob had already been removed, leaving the tag in a half-broken
+  state with no easy recovery. Now: the script `cp`s the original
+  manifest to a `.heal-backup` sidecar before the rewrite, runs
+  `ollama show` against the rewritten manifest, and on failure
+  `mv`s the backup back into place and exits non-zero. The old
+  qwen36 blob cleanup (step 7, was step 6) only runs after
+  validation passes, so a rollback always lands on a consistent
+  state (original manifest + original blob still present). Backup
+  is deleted on success.
+
 ## [0.6.0] - 2026-05-19 — `c336f44`
 
 Headline changes since 0.5.0 (over a two-week burst on 2026-05-19):

scripts/heal_hf_pull.sh

@@ -135,6 +135,13 @@ trap - EXIT
 
 # ---- 5. Rewrite the manifest's model layer ----------------------------------
 
+# Keep a sidecar copy of the original manifest so we can roll back if
+# `ollama show` rejects the rewrite. The blob cleanup in step 7 only
+# happens AFTER validation passes, so a rollback always lands on a
+# consistent (original manifest, original blob still present) state.
+BACKUP_MANIFEST="${MANIFEST}.heal-backup"
+cp "${MANIFEST}" "${BACKUP_MANIFEST}"
+
 TMP_MANIFEST="$(mktemp -t thanatos-heal-manifest.XXXXXX.json)"
 trap 'rm -f "${TMP_MANIFEST}"' EXIT
 jq --arg new "sha256:${NEW_HASH}" \
@@ -152,12 +159,34 @@ NEW_DIGEST_IN_MANIFEST="$(jq -r '
 ' "${TMP_MANIFEST}")"
 if [[ "${NEW_DIGEST_IN_MANIFEST}" != "sha256:${NEW_HASH}" ]]; then
     red "[!] manifest rewrite failed (digest mismatch); not committing."
+    rm -f "${BACKUP_MANIFEST}"
     exit 1
 fi
 mv "${TMP_MANIFEST}" "${MANIFEST}"
 trap - EXIT
 
-# ---- 6. Remove the old qwen36 blob if no other manifest references it -------
+# ---- 6. Validate the rewritten manifest via ollama show ---------------------
+
+# `ollama show` parses the manifest, walks the layer digests, and reads
+# enough of the model blob to extract metadata (arch, params, etc.).
+# A buggy rewrite that produces jq-accepted JSON but breaks an ollama
+# invariant (layer order, mediaType set, digest-vs-blob-bytes
+# mismatch) trips here, before we lose the rollback path by removing
+# the old qwen36 blob. On failure we restore from BACKUP_MANIFEST.
+blue "[*] validating rewritten manifest with 'ollama show'..."
+if ! ollama show "${TAG}" >/dev/null 2>&1; then
+    red "[!] ollama show ${TAG} failed after the manifest rewrite."
+    blue "[*] rolling back: restoring original manifest from ${BACKUP_MANIFEST}"
+    mv "${BACKUP_MANIFEST}" "${MANIFEST}"
+    red "    Tag is back to its pre-heal (qwen36) state. The new qwen35"
+    red "    blob is left in the store; ollama auto-prunes unreferenced"
+    red "    blobs on next restart."
+    exit 1
+fi
+rm -f "${BACKUP_MANIFEST}"
+green "[+] manifest validates."
+
+# ---- 7. Remove the old qwen36 blob if no other manifest references it -------
 
 OLD_DIGEST="sha256:${MODEL_HASH}"
 if ! grep -rlF -- "${OLD_DIGEST}" "${OLLAMA_MODELS}/manifests/" >/dev/null 2>&1; then