docs: align with qwen36 re-stamp (973d7ef) — 3rd round trip, post-audit

Bundle is qwen36-stamped again as of `hf upload` 973d7ef. Aligning
docs and scripts so the workaround narrative is consistent with
that state, without retracting the upstream-evidence audit shipped
in a4d3b6e:

- README "Architecture" restructured into Stamp choice / Upstream
convention / History / Rebadge utility subsections. The
upstream evidence (Qwen3_5 HF classes, converter mapping,
qwen35.cpp's 64-layer branch) stays intact under "Upstream
convention — why qwen35 would also be valid". The current
qwen36 stamp is framed honestly as a project-owner choice
that departs from upstream convention, with the loader
friction documented up front.
- TL;DR Heads up callout re-added; canonical path is now two-step
(`ollama run` → 500 → `make heal-hf` → re-run → works).
- "What's here" intro paragraph + "Local apps" intro + Ollama
table cell restored to the qwen36 + heal-hf narrative.
- Modelfile, load_bundle.sh, heal_hf_pull.sh preambles flipped
back to describing the qwen36 stamp as the current state and
the rebadge as the primary use case.
- Makefile load-bundle help text restored to "qwen36-stamped
bundle, rebadged to qwen35" framing.
- History subsection logs all three stamp flips on this session
with commit refs.

CHANGELOG entry under [Unreleased] documents the 3rd round trip
honestly: undertaken at project-owner direction despite the
audit conclusion, because the owner prefers version-specific
labeling and accepts the heal-hf friction. The audit evidence
remains accurate — qwen35 *is* upstream-canonical — but the
current stamp departs from that convention deliberately.

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

CHANGELOG.md

@@ -7,8 +7,61 @@ and documentation**, not the underlying base model.
 
 ## [Unreleased]
 
-### Changed
-- **Bundle re-stamped `general.architecture: 'qwen36'` → `'qwen35'`**
+### Changed (3rd round trip — qwen35 → qwen36, user-directed despite audit)
+- **Bundle re-stamped `general.architecture: 'qwen35'` → `'qwen36'`**
+  in `hf upload` commit `973d7ef` (HF). Third stamp flip on the
+  2026-05-19 session, undertaken at project-owner direction after
+  the upstream-evidence audit (`a4d3b6e`) had already shipped.
+  The audit conclusion stands — `qwen35` is the upstream-canonical
+  label for the whole Qwen 3.5 / 3.6 hybrid family, with concrete
+  code-level evidence (Qwen's own `Qwen3_5*ForConditionalGeneration`
+  HF classes, llama.cpp's converter mapping, the explicit Qwen 3.6
+  type branches in `qwen35.cpp` / `qwen35moe.cpp`). The project
+  owner heard the evidence and chose the version-specific qwen36
+  stamp anyway, accepting the `make heal-hf` friction this creates
+  on every fresh `ollama run hf.co/FoolDev/Thanatos-27B`. New
+  bundle blob SHA is
+  `b2b63b941d714b0aff5e9afc9b337e7607b84e371ba991c182d92d0f7805c0e9`;
+  tensor data is byte-identical to the prior qwen35-stamped blob
+  (`5ed60d0a…`), only the `general.architecture` KV (and namespaced
+  KV keys) flipped.
+- README "Architecture" section restructured into three subsections:
+  - **Stamp choice** — leads with the bundle's qwen36 declaration,
+    states the tradeoff (loader friction in exchange for
+    version-specific labeling) up front.
+  - **Upstream convention — why `qwen35` would also be valid** —
+    keeps the three-source audit evidence intact (Qwen HF configs,
+    llama.cpp converter, llama.cpp model code) and explicitly says
+    a future maintainer can flip back via `make load-bundle` /
+    `make heal-hf`.
+  - **History** — logs all three flips on the 2026-05-19 session
+    with commit refs and rationale per flip; the new entry
+    annotates the choice as project-owner preference post-audit.
+- README "Heads up" callout re-added to TL;DR (`ollama run hf.co/...`
+  500s on first inference; `make heal-hf` rebadges the cached blob).
+  TL;DR ordering: heads-up callout → two-step pull-and-heal path →
+  optional unsloth-based alternative for users who don't want to
+  heal.
+- README "What's here" intro paragraph, "Local apps" intro, and
+  Ollama table cell restored to the qwen36 / heal-hf-needed
+  narrative.
+- `Modelfile`, `scripts/load_bundle.sh`, and `scripts/heal_hf_pull.sh`
+  preambles flipped back to describing the qwen36 bundle as the
+  current state and the rebadge as the primary use case (rather
+  than legacy recovery).
+- `Makefile` `load-bundle` help text + example comment restored to
+  the "qwen36-stamped bundle, rebadged to qwen35" phrasing.
+
+### Note
+- The audit shipped in `a4d3b6e` was not reverted. Its evidence
+  remains accurate: `qwen35` *is* the upstream-canonical family
+  label. The current stamp is a deliberate departure from that
+  convention, not a refutation of it. A maintainer who later
+  decides the friction isn't worth it can flip the bundle back to
+  qwen35 with a single `make load-bundle` invocation; the audit
+  evidence already explains why that flip would be valid.
+
+### Changed (upstream-evidence audit — qwen35 is canonical, not a workaround)
   in commit 964e418 (HF-direct `hf upload`). Reverses the v0.6.0
   `qwen36` stamp from e1f78fa, which itself flipped qwen35 → qwen36
   deliberately. The proximate trigger: today's subagent recheck

Makefile

@@ -13,7 +13,7 @@
 #   make build                          # Q4_K_M from unsloth (qwen35-stamped, loads today)
 #   make build QUANT=Q3_K_S             # smaller quant
 #   make build GGUF_PATH=~/models/Qwen3.6-27B-Q4_K_M.gguf
-#   make load-bundle                    # this repo's bundled GGUF -> local Ollama tag (smudge LFS if needed)
+#   make load-bundle                    # this repo's qwen36-stamped bundle, rebadged to qwen35 + loaded
 #   make smoke
 #   make check
 #   make clean
@@ -40,7 +40,7 @@ endif
 build:  ## Download qwen35-stamped GGUF from unsloth and run 'ollama create' (loads today).
 	GGUF_PATH=$(GGUF_PATH) TAG=$(TAG) ./scripts/build.sh $(QUANT)
 
-load-bundle:  ## Load THIS repo's bundled GGUF into a local Ollama tag (smudge LFS + ollama create).
+load-bundle:  ## Load THIS repo's qwen36-stamped bundle (smudge LFS + rebadge to qwen35 + ollama create).
 	TAG=$(TAG) ./scripts/load_bundle.sh
 
 heal-hf:  ## Heal an already-pulled hf.co/FoolDev/Thanatos-27B tag in-store (rebadge blob + manifest digest).

Modelfile

@@ -7,12 +7,14 @@
 # image input, or wait for the fix. See the Vision section in README.md.
 #
 # This repo bundles a single GGUF: Thanatos-27B.Q4_K_M.gguf (~17 GB),
-# stamped `general.architecture: 'qwen35'` — the arch entry every
-# released llama.cpp / Ollama loads under for the Qwen 3.6 hybrid
-# SSM + attention family. `ollama create thanatos-27b -f Modelfile &&
-# ollama run thanatos-27b` loads it directly. See README
-# "Architecture" for the qwen35 -> qwen36 -> qwen35 history through
-# v0.6.0.
+# stamped `general.architecture: 'qwen36'` — a version-specific label
+# that stock llama.cpp / Ollama do not yet recognise. Directly
+# `ollama create thanatos-27b -f Modelfile` against this bundle will
+# fail with `unknown model architecture: 'qwen36'`. Use
+# `make load-bundle` (which rebadges to qwen35 first), or rebadge the
+# bundle manually via `scripts/rename_arch.py`. See README
+# "Architecture" for the full stamp history (three flips between
+# qwen35 and qwen36, ending on the current qwen36 stamp at 973d7ef).
 #
 # For other quants (Q3_K_S, Q5_K_M, Q6_K, etc.), `make build QUANT=Q3_K_S`
 # downloads the chosen quant from unsloth/Qwen3.6-27B-GGUF and patches

README.md

@@ -63,30 +63,38 @@ A personal sibling to [`FoolDev/Janus-35B`](https://huggingface.co/FoolDev/Janus
 
 ## TL;DR
 
-One-liner via Hugging Face (pulls a GGUF + this repo's root-level
-`template` / `system` / `params` files, including the tool-calling
-template — HF's Ollama bridge ingests those three files, not
-`Modelfile`):
+> [!IMPORTANT]
+> **Heads up — the bundled GGUF is `qwen36`-stamped** (HF blob
+> SHA `b2b63b94…`, commit `973d7ef`), a version-specific label
+> stock loaders don't yet recognise. A direct `ollama run
+> hf.co/FoolDev/Thanatos-27B` will 500 on first pull with
+> `unable to load model`. `make heal-hf` rebadges the cached
+> blob in place (qwen36 → qwen35, metadata-only, ~5 s) so the
+> same tag loads. See [Architecture → Stamp choice](#stamp-choice)
+> for why this repo stamps qwen36 despite upstream using `qwen35`
+> as the canonical family label.
+
+Two-step pull-and-load (this is the canonical path while the
+bundle stays qwen36-stamped):
 
 ```bash
-ollama run hf.co/FoolDev/Thanatos-27B           # ~17 GB Q4_K_M, qwen35-stamped, loads on stock Ollama
+ollama run hf.co/FoolDev/Thanatos-27B    # pulls 17 GB Q4_K_M, then 500s on first inference
+git clone https://huggingface.co/FoolDev/Thanatos-27B
+cd Thanatos-27B && make heal-hf          # rebadges blob in store, tag loads from this point
+ollama run hf.co/FoolDev/Thanatos-27B    # works
 ```
 
-If you pulled the bundle while it was qwen36-stamped (v0.6.0
-through the early hours of 2026-05-19) the load will still 500 on
-that stale blob — `make heal-hf` rebadges it in place. Fresh
-pulls after this fix go straight through.
-
-For other quants (Q3_K_S ~12 GB, Q5_K_M ~20 GB, etc.):
+Or skip the heal step entirely by building from a qwen35-stamped
+unsloth quant (loads directly):
 
 ```bash
 git clone https://huggingface.co/FoolDev/Thanatos-27B && cd Thanatos-27B
-make build QUANT=Q3_K_S                  # downloads from unsloth/Qwen3.6-27B-GGUF
+make build QUANT=Q3_K_S                  # downloads from unsloth/Qwen3.6-27B-GGUF (qwen35-stamped)
 ollama run thanatos-27b
 ```
 
 For other quants (Q3_K_S ~12 GB, Q5_K_M ~20 GB, etc.), `make build
-QUANT=Q3_K_S` is the simplest path. See [Quick start](#quick-start)
+QUANT=...` is the simplest path. See [Quick start](#quick-start)
 below for the full matrix.
 
 For image input use llama.cpp directly — Ollama vision is broken for
@@ -122,8 +130,8 @@ The 27B is **dense**: every parameter participates in every forward pass. It's s
 | `template`, `system`, `params` | Used by HF's Ollama bridge when users `ollama run hf.co/FoolDev/Thanatos-27B` directly (the bridge does **not** read `Modelfile` — see [HF Ollama docs](https://huggingface.co/docs/hub/en/ollama)). Mirrors the `Modelfile`'s template / system prompt / sampling params. |
 | `examples/` | Ready-to-run Python clients for Ollama, Transformers, and llama-cpp-python |
 | `scripts/build.sh` | Pulls a qwen35-stamped GGUF from `unsloth/Qwen3.6-27B-GGUF` and runs `ollama create` (loads on today's llama.cpp / Ollama; see `make build`) |
-| `scripts/load_bundle.sh` | One-shot path from *this repo's* bundle → loadable local Ollama tag (smudges LFS pointer via `hf download` if needed, runs `ollama create`; see `make load-bundle`). Carries a qwen36 → qwen35 rebadge branch for legacy v0.6.0-era checkouts — no-op on the current qwen35-stamped bundle. |
-| `scripts/heal_hf_pull.sh` | Recovery for users who pulled `hf.co/FoolDev/Thanatos-27B` *before* the qwen35 re-stamp (commits `964e418` / `72259c1`) and still have the qwen36-stamped blob in their local Ollama store: rebadges the blob qwen36 → qwen35 and rewrites the manifest's model-layer digest so the same tag becomes loadable in place. See `make heal-hf`. Idempotent and a no-op on tags already on qwen35 — fresh pulls don't need it. |
+| `scripts/load_bundle.sh` | One-shot path from *this repo's* qwen36-stamped bundle → loadable local Ollama tag (smudges LFS pointer via `hf download` if needed, rebadges qwen36 → qwen35, runs `ollama create`; see `make load-bundle`). |
+| `scripts/heal_hf_pull.sh` | Heal an already-pulled `hf.co/FoolDev/Thanatos-27B:...` tag in-store after the first-pull 500: rebadges the cached blob qwen36 → qwen35 and rewrites the manifest's model-layer digest so the same tag becomes loadable in place. See `make heal-hf`. Idempotent — tags already on qwen35 are skipped. |
 | `scripts/smoke_test.sh` | Verifies an Ollama daemon + model, runs a round-trip, asserts no chat-template tokens leak into the response. With `TOOLS_TEST=1`, also exercises an end-to-end tool-call round-trip and checks the response shape |
 | `scripts/bench.sh` | Measures real tok/s using Ollama's `eval_count` / `eval_duration` metadata over a 3-prompt mix (run `make bench`) |
 | `scripts/fetch_vision.sh` | Pulls the vision projector (`mmproj-F16.gguf`) for llama.cpp (Ollama vision is broken upstream — see [Vision](#vision)). Renamed from `fetch_mmproj.sh` because HF's Ollama bridge auto-indexed the script as a vision projector layer (filename pattern match). |
@@ -136,15 +144,17 @@ The 27B is **dense**: every parameter participates in every forward pass. It's s
 | `README.md` | This file |
 
 This repo ships a single GGUF to back the HF/Ollama "Use this model"
-widget — `Thanatos-27B.Q4_K_M.gguf` (~17 GB, qwen35-stamped):
+widget — `Thanatos-27B.Q4_K_M.gguf` (~17 GB, qwen36-stamped):
 
 ```bash
-ollama run hf.co/FoolDev/Thanatos-27B           # 17 GB Q4_K_M, qwen35-stamped, loads on stock Ollama
+ollama run hf.co/FoolDev/Thanatos-27B           # 17 GB Q4_K_M, qwen36 — fails today, see Heads up above
 ```
 
-For 16 GB GPUs / unified-memory laptops, `make build QUANT=Q3_K_S`
-downloads the smaller ~12 GB Q3_K_S quant from
-`unsloth/Qwen3.6-27B-GGUF` and creates a local `thanatos-27b`
+For 16 GB GPUs / unified-memory laptops — and as a working-today
+fallback while the bundle stays qwen36-stamped — `make build
+QUANT=Q3_K_S` downloads the smaller ~12 GB Q3_K_S quant from
+`unsloth/Qwen3.6-27B-GGUF` (qwen35-stamped, loads on every current
+llama.cpp / Ollama build) and creates a local `thanatos-27b`
 Ollama tag. Does not redistribute via this repo.
 
 For other quants or local builds, pull from
@@ -174,11 +184,32 @@ If you want the safetensors for `transformers`, fetch them from [`Qwen/Qwen3.6-2
   current loader compatibility.
 - Multi-token prediction (MTP) head trained for speculative decoding
 
-**The bundled GGUF declares `general.architecture: 'qwen35'`** — not a
-workaround for an unimplemented `qwen36` arch, but the canonical
-upstream label for the entire Qwen 3.5 / 3.6 hybrid SSM + attention
-family. The naming convergence runs through three layers of the
-stack:
+### Stamp choice
+
+**The bundled GGUF declares `general.architecture: 'qwen36'`** — a
+version-specific label this project uses despite the upstream
+convention of `qwen35` for the whole Qwen 3.5 / 3.6 hybrid SSM +
+attention family. Tradeoff up front:
+
+- **What you give up by stamping qwen36:** stock `llama.cpp` and
+  Ollama don't recognise the arch and refuse to load. Fresh
+  `ollama run hf.co/FoolDev/Thanatos-27B` 500s on first inference;
+  `llama-server -m Thanatos-27B.Q4_K_M.gguf` errors with `unknown
+  model architecture: 'qwen36'`. Recovery: `make heal-hf`
+  (cached blob) or `make load-bundle` (working-copy GGUF), both
+  of which rebadge qwen36 → qwen35 in-place.
+- **What you get:** the GGUF metadata names the model by its
+  actual Qwen version (3.6) rather than the family label
+  upstream happens to use (3.5). Useful if you're indexing
+  models by their HF model_id, scripting against the arch tag,
+  or just prefer architectural-honesty per individual release.
+
+### Upstream convention — why `qwen35` would also be valid
+
+Even though this bundle stamps qwen36, the upstream-canonical
+name for the whole Qwen 3.5 / 3.6 hybrid SSM + attention family
+is `qwen35`. The naming convergence runs through three layers of
+the stack:
 
 - **Qwen's own HF configs.** `Qwen/Qwen3.6-27B/config.json` declares
   `"model_type": "qwen3_5"` and
@@ -198,43 +229,55 @@ stack:
   Qwen 3.6 weights, not just Qwen 3.5.
 
 There is no PR or tracking issue for a `qwen36` arch entry in
-`ggml-org/llama.cpp` or `ollama/ollama` because none is needed —
-`qwen35` already loads the model the upstream code path was
-designed to load.
-
-`ollama run hf.co/FoolDev/Thanatos-27B` and `llama-server -m
-Thanatos-27B.Q4_K_M.gguf` both load directly on current stock
-loaders.
-
-**History.** Through v0.6.0 the bundle was stamped `qwen36` as a
-version-specific label, on the theory that `qwen35` was a
-loader-side stand-in awaiting proper Qwen 3.6 support. Stock
-loaders rejected it; users needed `make load-bundle` or
-`make heal-hf` to rebadge before loading. The stamp was reverted
-to `qwen35` in commit `964e418` once daily friction outweighed
-the version-specificity. The upstream-evidence audit captured
-above (post-`72259c1`) then confirmed `qwen35` is in fact the
-canonical family label — not a workaround. Tensor data was
-byte-identical across both stamps; only the
-`general.architecture` KV (and namespaced KV keys) flipped. See
-the [CHANGELOG](CHANGELOG.md) entry for the full rationale.
-
-`scripts/rename_arch.py` is kept in the repo as a generic GGUF
-arch renamer (metadata only, tensors byte-identical), useful for
-the legacy qwen36 → qwen35 rebadge or any future arch flip:
+`ggml-org/llama.cpp` or `ollama/ollama` — and the evidence above
+shows there's no architectural need for one. A future maintainer
+who decides the friction isn't worth it can rebadge the bundle to
+`qwen35` in one `make load-bundle` / `make heal-hf` invocation;
+the tensor data is byte-identical across both stamps.
+
+### History
+
+The bundle has now flipped between the two stamps three times,
+each time after weighing the friction-vs-honesty tradeoff anew:
+
+- **v0.6.0 (e1f78fa, 2026-05-18):** initial qwen35 → qwen36
+  stamp, on the theory that qwen35 was a loader stand-in
+  awaiting proper Qwen 3.6 support. Upstream audit later
+  showed that theory was mistaken (see above).
+- **2026-05-19 morning (964e418):** flipped back to qwen35
+  after daily friction outweighed version-specificity for that
+  iteration; doc workaround narrative collapsed
+  (`83022eb`).
+- **2026-05-19 evening (07fa120, reverted `72259c1`):** brief
+  ~1-hour re-flip to qwen36 during a fresh-pull integration
+  test; reverted because the live friction was worse than the
+  doc prose suggested.
+- **2026-05-19 evening, again (`973d7ef`):** flipped to qwen36
+  one more time, after the upstream-evidence audit had been
+  shipped and the friction was a known quantity. Project owner
+  prefers the version-specific stamp despite the audit
+  conclusion. **This is the current state.**
+
+Tensor data was byte-identical across all stamps; only the
+`general.architecture` KV (and namespaced KV keys) flipped.
+See the [CHANGELOG](CHANGELOG.md) entries for each flip's
+rationale.
+
+### Rebadge utility
+
+`scripts/rename_arch.py` is the generic GGUF arch renamer
+(metadata only, tensors byte-identical) underpinning both
+`make heal-hf` and `make load-bundle`. For manual flips in
+either direction:
 
 ```bash
+# qwen36 -> qwen35 (the in-place recovery direction)
 python3 scripts/rename_arch.py \
     --from-arch qwen36 --to-arch qwen35 \
-    Thanatos-27B.Q4_K_M.qwen36.gguf \
-    Thanatos-27B.Q4_K_M.gguf
+    Thanatos-27B.Q4_K_M.gguf \
+    Thanatos-27B.Q4_K_M.qwen35.gguf
 ```
 
-If you pulled the bundle while it was still qwen36-stamped (v0.6.0
-through 2026-05-19) and have the broken blob in your local Ollama
-store, `make heal-hf` rebadges it in place so the same
-`hf.co/...` tag becomes loadable without re-pulling.
-
 ## Quick start
 
 ### Ollama
@@ -243,8 +286,11 @@ Three paths:
 
 ```bash
 # A. Pull straight from HF (gets the bundled Q4_K_M GGUF + the
-#    root-level template / system / params files in one step):
-ollama run hf.co/FoolDev/Thanatos-27B           # 17 GB Q4_K_M, qwen35-stamped
+#    root-level template / system / params files in one step).
+#    This 500s on first inference because the bundle is qwen36-stamped;
+#    `make heal-hf` rebadges the cached blob and the tag then loads.
+ollama run hf.co/FoolDev/Thanatos-27B           # 17 GB Q4_K_M, qwen36 (fails first; recover via heal-hf)
+make heal-hf                                     # rebadges cached blob qwen36 -> qwen35 in store
 
 # B. Build a local `thanatos-27b` tag from THIS repo's bundle
 #    (LFS smudge if needed, then `ollama create`). Useful if you
@@ -279,9 +325,15 @@ python examples/ollama_chat.py      # full demo: chat, streaming, tools, OpenAI-
 
 ### Local apps
 
+The bundled `Thanatos-27B.Q4_K_M.gguf` is `qwen36`-stamped — every row
+below assumes you've either run `make heal-hf` after pulling, or that
+you're loading a `qwen35`-stamped GGUF from `unsloth/Qwen3.6-27B-GGUF`
+instead. The "fails today with `unknown model architecture: 'qwen36'`"
+caveat applies to every row until that's done.
+
 | App | How to load this model |
 |---|---|
-| **Ollama** | `ollama run hf.co/FoolDev/Thanatos-27B` (default Q4_K_M). Pulls the GGUF + the root-level `template` / `system` / `params` files in one step (HF's Ollama bridge ingests these three files; it does **not** read `Modelfile`). For other quants, `make build QUANT=Q3_K_S` downloads from unsloth and creates a local Ollama tag using the `Modelfile`, which is kept in sync with the bridge files. |
+| **Ollama** | `ollama run hf.co/FoolDev/Thanatos-27B` (default Q4_K_M). Pulls the GGUF + the root-level `template` / `system` / `params` files in one step (HF's Ollama bridge ingests these three files; it does **not** read `Modelfile`); fails on first inference, then `make heal-hf` rebadges the cached blob. For other quants, or to bypass the qwen36 block entirely, `make build QUANT=Q3_K_S` downloads from unsloth (qwen35-stamped) and creates a local Ollama tag using the `Modelfile`, which is kept in sync with the bridge files. |
 | **LM Studio** | Search → `FoolDev/Thanatos-27B` → pick `Thanatos-27B.Q4_K_M.gguf`. Uses the GGUF's embedded jinja chat template (Qwen 3.6 ChatML); set the system prompt manually from the `SYSTEM` block in this repo's `Modelfile`. |
 | **Jan** | Hub → "Import from Hugging Face" → `FoolDev/Thanatos-27B`. Same template behavior as LM Studio. |
 | **llama.cpp** | `hf download FoolDev/Thanatos-27B Thanatos-27B.Q4_K_M.gguf --local-dir .` then `llama-server -m Thanatos-27B.Q4_K_M.gguf` (or `llama-cli`, `llama-mtmd-cli` for vision via the upstream `mmproj-F16.gguf`). |

scripts/heal_hf_pull.sh

@@ -1,22 +1,25 @@
 #!/usr/bin/env bash
-# Thanatos-27B — heal a previously pulled HF-bridge tag whose bundled
-# GGUF is `qwen36`-stamped (legacy v0.6.0-era pulls, before the
-# qwen35 re-stamp in 964e418 / 72259c1).
+# Thanatos-27B — heal a freshly pulled HF-bridge tag whose bundled GGUF
+# is `qwen36`-stamped.
 #
-# Fresh pulls of `ollama run hf.co/FoolDev/Thanatos-27B` now get the
-# qwen35-stamped bundle and load directly — this script is the
-# recovery path for users who pulled the qwen36-stamped blob into
-# their local Ollama store and haven't refreshed since.
+# Background. `ollama run hf.co/FoolDev/Thanatos-27B` (or any other
+# qwen36-stamped HF-bridge tag of this repo) pulls a fresh copy of the
+# bundled GGUF every time. Stock llama.cpp / Ollama don't recognise
+# the `qwen36` arch (see README "Architecture"), so every such pull
+# fails with `unable to load model: <blob>`. `make load-bundle` works
+# around this by building a *separate* local `thanatos-27b` tag from
+# a rebadged copy, but the canonical `hf.co/...` tag stays broken
+# until this script runs.
 #
-# It rebadges the HF-bridge tag's model blob in-place (qwen36 ->
-# qwen35, metadata-only, byte-identical tensors) and rewrites the
-# manifest's model-layer digest to point at the new blob. After
-# running, the cached `hf.co/FoolDev/Thanatos-27B` tag loads.
+# This script rebadges the HF-bridge tag's model blob in-place
+# (qwen36 -> qwen35, metadata-only, byte-identical tensors) and
+# rewrites the manifest's model-layer digest to point at the new
+# blob. After running it, `ollama run hf.co/FoolDev/Thanatos-27B`
+# loads.
 #
 # Idempotent: a tag already on qwen35 / qwen35moe is left untouched.
-# The current bundle is qwen35-stamped so this script is a no-op for
-# anyone who pulled after the re-stamp; it stays in the repo for the
-# legacy recovery case.
+# Re-runnable after a fresh HF pull (the pull resets the manifest
+# digest back to the qwen36 blob).
 #
 # Usage:
 #   ./scripts/heal_hf_pull.sh                                # default tag

scripts/load_bundle.sh

@@ -1,23 +1,24 @@
 #!/usr/bin/env bash
-# Thanatos-27B — load this repo's bundle into Ollama as a local tag.
+# Thanatos-27B — load the qwen36-stamped bundle on today's llama.cpp / Ollama.
 #
-# The bundled GGUF (Thanatos-27B.Q4_K_M.gguf) is qwen35-stamped and
-# loads directly on stock llama.cpp / Ollama. This script is the
-# one-shot path from "I just cloned this repo" to "I have a working
-# local Ollama tag":
+# The bundled GGUF (Thanatos-27B.Q4_K_M.gguf) ships with
+# `general.architecture: 'qwen36'`. No released llama.cpp / Ollama
+# recognizes that arch (see README "Architecture"), so a direct
+# `ollama create -f Modelfile` against the bundle fails with
+# `unknown model architecture: 'qwen36'`. This script handles the
+# rebadge workaround end-to-end so users don't have to copy-paste
+# from the README:
 #
 #   1. Resolve the bundle. If it's an LFS pointer (cloned without
 #      `git lfs pull`), download the real ~17 GB blob via `hf download`.
-#   2. Inspect `general.architecture`. If qwen35 / qwen35moe (current
-#      bundle), skip straight to step 3. If qwen36 (legacy v0.6.0-era
-#      checkout), rebadge to qwen35 via scripts/rename_arch.py
-#      (metadata-only, byte-identical tensors).
-#   3. Run `ollama create <tag> -f <temp Modelfile pointing at the
-#      resolved bundle>`.
+#   2. Inspect `general.architecture`. If qwen36 (current bundle),
+#      rebadge to qwen35 via scripts/rename_arch.py (metadata-only,
+#      byte-identical tensors). If already qwen35 (e.g. a previously
+#      rebadged copy), skip the rebadge step.
+#   3. Run `ollama create <tag> -f <temp Modelfile pointing at qwen35>`.
 #
 # Useful if you want a bare local tag (`thanatos-27b`) rather than
-# the `hf.co/FoolDev/Thanatos-27B` path. The legacy qwen36 rebadge
-# branch is kept for anyone working from a pre-964e418 checkout.
+# the `hf.co/FoolDev/Thanatos-27B` path.
 #
 # Usage:
 #   ./scripts/load_bundle.sh                 # default tag: thanatos-27b