Revert "docs: align README + CHANGELOG + Modelfile + examples with the qwen36 re-stamp (07fa120)"

This reverts commit e9c7366, restoring the collapsed-workaround
narrative now that the HF bundle is back on qwen35 (upload 72259c1).
A fresh-pull integration test on the Strix Halo reference machine
reproduced the heal-hf friction end-to-end; the friction was worse
in practice than the architectural-honesty payoff. CHANGELOG
[Unreleased] picks up a "Round trip" bullet documenting the
qwen35 -> qwen36 -> qwen35 sequence; net blob is 5ed60d0a... again,
same as before the round trip.

CHANGELOG.md

@@ -8,43 +8,58 @@ and documentation**, not the underlying base model.
 ## [Unreleased]
 
 ### Changed
-- **Bundle re-stamped `general.architecture: 'qwen35'` → `'qwen36'`**
-  in commit `07fa120` (HF-direct `hf upload`). Re-reverses 964e418,
-  returning to the v0.6.0 stamp choice from `e1f78fa`. Tensor data
-  is byte-identical across all three flips; only the
-  `general.architecture` KV (and the namespaced KV keys) moves.
-  The new blob SHA
-  `b2b63b941d714b0aff5e9afc9b337e7607b84e371ba991c182d92d0f7805c0e9`
-  is **bit-identical to the original v0.6.0 qwen36 bundle** —
-  content-addressed return to a known artifact, so anyone who pulled
-  v0.6.0 still has a usable cached blob; `make heal-hf` will skip
-  the re-fetch if their old blob is still in the store.
-  The flip restores the architecturally-honest label even though
-  upstream `qwen36` arch support is still not present in
-  `ggml-org/llama.cpp` or `ollama/ollama` as of 2026-05-19 (verified
-  by recheck; no open PR adds it). Day-to-day cost of the qwen36
-  stamp is back: a fresh `ollama run hf.co/FoolDev/Thanatos-27B`
-  pulls 17 GB and 500s with `unable to load model: <blob>`,
-  requiring one `make heal-hf` to rebadge in place before the same
-  tag loads. The trade-off here favors honesty + matching the
-  upstream Qwen 3.6 family identity over no-rebadge ergonomics
-  on the HF-bridge path.
-- README "Heads up" callout, three-path TL;DR, Architecture
-  workaround prose, Modelfile preamble, and `examples/README.md`
-  Ollama setup all restored to the pre-collapse form (i.e. the
-  v0.6.0-era doc surface, updated for the new SHA and the third
-  flip). `scripts/rename_arch.py` example direction in
-  Architecture flipped back to qwen36 → qwen35 — the rebadge
-  direction users actually run to make the bundle loadable, not
-  the future-honesty direction.
+- **Bundle re-stamped `general.architecture: 'qwen36'` → `'qwen35'`**
+  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
+  found no PR or tracking issue for a `qwen36` arch entry in either
+  `ggml-org/llama.cpp` or `ollama/ollama`, and the actual Qwen 3.6
+  family upstream already loads under `qwen35moe` — so the qwen36
+  stamp was going to stay ahead-of-upstream indefinitely, not for a
+  release or two. Day-to-day cost (every fresh
+  `ollama run hf.co/FoolDev/Thanatos-27B` hitting a 500, every user
+  needing `make heal-hf` to recover) outweighed the
+  architectural-honesty benefit. Tensor data stays byte-identical;
+  only the `general.architecture` KV (and the namespaced KV keys)
+  flips. New bundle blob SHA is
+  `5ed60d0af4650a854b1755bd392f9aef4872643dc25a254bc68043fa638392a0`
+  — the same hash `make load-bundle` and `make heal-hf` have been
+  producing locally this whole session.
+- README "Heads up" callout (qwen36 load-failure warning) removed.
+  TL;DR collapsed back from "three paths around it" to a single
+  one-liner: `ollama run hf.co/FoolDev/Thanatos-27B` now loads on
+  stock Ollama. `make heal-hf` is mentioned as the recovery path
+  for anyone who pulled the v0.6.0 bundle and still has the qwen36
+  blob in their store.
+- README "Architecture" section, Quick start option A,
+  `examples/README.md` Ollama setup, and `Modelfile` preamble all
+  collapsed back to the pre-qwen36 single-path narrative. The
+  long "qwen36 is unloadable / here are the workarounds" prose
+  was replaced with a one-paragraph history note pointing at
+  commit 964e418 + the [CHANGELOG](CHANGELOG.md) entry. Net -39
+  lines across the three doc surfaces. `scripts/rename_arch.py`
+  example in Architecture flipped from qwen36 → qwen35 to qwen35
+  → qwen36 to match its new "tool kept around for future flips"
+  framing.
+- **Round trip (2026-05-19 evening).** The bundle briefly flipped
+  back to `qwen36` in commit `07fa120` plus the doc re-expansion
+  in `e9c7366`, on the theory that architectural-honesty was worth
+  the heal-hf friction. A fresh-pull integration test on the
+  Strix Halo box reproduced the friction end-to-end (`ollama run`
+  500 on first pull, recover via `make heal-hf`, smoke-test then
+  passed) — and the friction was worse in practice than the doc
+  prose suggested. Reverted to qwen35 in `hf upload` commit
+  `72259c1` + the present commit (revert of `e9c7366`). Net
+  bundle state: same `5ed60d0a...` blob as before the round
+  trip; no user-facing impact unless a user happened to pull in
+  the ~1 hour window when the bundle was qwen36-stamped (for
+  them, one `make heal-hf` is the recovery).
 
 ### Note
 - `make heal-hf`, `make load-bundle`, and `scripts/rename_arch.py`
-  are now back to load-bearing rather than dormant.
-  `make heal-hf` is the canonical recovery path; `make load-bundle`
-  builds a separate local tag without touching the HF-bridge
-  manifest; `make build` bypasses the bundle entirely (downloads
-  qwen35-stamped from unsloth).
+  stay in the repo and stay useful. heal-hf is idempotent on qwen35
+  (skips early); load-bundle does a no-op rebadge on a qwen35 bundle
+  and runs `ollama create` as normal.
 
 ### Added
 - `scripts/check.sh` now greps for the `VAR="$(cmd 2>/dev/null | filter)"`

Modelfile

@@ -7,28 +7,18 @@
 # 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: 'qwen36'` — the architecturally-honest
-# label for the Qwen 3.6 family. No released llama.cpp / Ollama
-# recognizes that string yet; both register the stack as
-# `qwen35` / `qwen35moe`. A direct `ollama create -f Modelfile`
-# against the bundle therefore fails with
-# `unknown model architecture: 'qwen36'`. Two recovery paths:
-#
-#   make load-bundle    # one-shot: smudge LFS pointer, rebadge a local
-#                       # copy qwen36 -> qwen35, run `ollama create`.
-#   make heal-hf        # rebadge an already-pulled `hf.co/...` tag's
-#                       # blob in place (qwen36 -> qwen35) and rewrite
-#                       # the manifest digest.
-#
-# See README "Architecture" for the qwen35 -> qwen36 -> qwen35 ->
-# qwen36 stamp history through commit 07fa120.
+# 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.
 #
 # 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 (qwen35-stamped,
-# loads on stock loaders, no rebadge needed) and patches FROM in a temp
-# Modelfile copy. The Q3_K_S used to ship in this repo; it was removed so
-# HF's Ollama bridge picks Q4_K_M as the default `:latest` tag instead of
-# Q3_K_S (alphabetically-first heuristic).
+# downloads the chosen quant from unsloth/Qwen3.6-27B-GGUF and patches
+# FROM in a temp Modelfile copy. The Q3_K_S used to ship in this repo;
+# it was removed so HF's Ollama bridge picks Q4_K_M as the default
+# `:latest` tag instead of Q3_K_S (alphabetically-first heuristic).
 #
 # Other GGUF sources (use with `make build GGUF_PATH=...`):
 #     https://huggingface.co/unsloth/Qwen3.6-27B-GGUF

README.md

@@ -61,51 +61,33 @@ pipeline_tag: image-text-to-text
 
 A personal sibling to [`FoolDev/Janus-35B`](https://huggingface.co/FoolDev/Janus-35B). Same teacher (Claude Opus 4.7), same dataset family, but built on the **dense** [Qwen/Qwen3.6-27B](https://huggingface.co/Qwen/Qwen3.6-27B) base instead of the 35B-A3B MoE. Smaller, easier to deploy, no expert-routing surprises.
 
-> **Heads up** — the bundled GGUF is stamped
-> `general.architecture: 'qwen36'`, the architecturally-honest
-> label for the Qwen 3.6 family. **No released llama.cpp / Ollama
-> recognizes it yet** (`ggml-org/llama.cpp` and `ollama/ollama`
-> register the hybrid SSM + attention stack as `qwen35` /
-> `qwen35moe`; verified 2026-05-19). A fresh
-> `ollama run hf.co/FoolDev/Thanatos-27B` pulls ~17 GB and then
-> 500s with `unable to load model: <blob>`. Run `make heal-hf`
-> once after the failure to rebadge the cached blob qwen36 →
-> qwen35 in place — subsequent runs load. Or skip the bundle
-> entirely with `make build` (qwen35-stamped from unsloth, loads
-> on stock Ollama). See [Architecture](#architecture) for the
-> stamp history and trade-off.
-
 ## TL;DR
 
-Three paths, in increasing order of disk re-use:
+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`):
 
 ```bash
-# A. Pull from HF (gets the bundled qwen36 GGUF + root-level
-#    template / system / params files). First `ollama run` 500s
-#    on the qwen36 blob; `make heal-hf` rebadges it in place.
-ollama run hf.co/FoolDev/Thanatos-27B           # 17 GB Q4_K_M, qwen36
-git clone https://huggingface.co/FoolDev/Thanatos-27B && cd Thanatos-27B
-make heal-hf                                    # rebadge cached blob -> qwen35
-ollama run hf.co/FoolDev/Thanatos-27B           # now loads
+ollama run hf.co/FoolDev/Thanatos-27B           # ~17 GB Q4_K_M, qwen35-stamped, loads on stock Ollama
+```
 
-# B. Build a local `thanatos-27b` tag from THIS repo's bundle
-#    (smudges the LFS pointer via `hf download`, rebadges
-#    qwen36 -> qwen35 in a local copy, runs `ollama create`):
-git clone https://huggingface.co/FoolDev/Thanatos-27B && cd Thanatos-27B
-make load-bundle                                # creates local tag thanatos-27b
-ollama run thanatos-27b
+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.
 
-# C. Bypass the bundle: download a qwen35-stamped GGUF from
-#    unsloth/Qwen3.6-27B-GGUF and build locally — no rebadge
-#    needed. Loads on every current llama.cpp / Ollama.
+For other quants (Q3_K_S ~12 GB, Q5_K_M ~20 GB, etc.):
+
+```bash
 git clone https://huggingface.co/FoolDev/Thanatos-27B && cd Thanatos-27B
-make build                                      # Q4_K_M -> thanatos-27b
+make build QUANT=Q3_K_S                  # downloads from unsloth/Qwen3.6-27B-GGUF
 ollama run thanatos-27b
 ```
 
-For other quants (Q3_K_S ~12 GB, Q5_K_M ~20 GB, etc.) path **C**
-is simplest: `make build QUANT=Q3_K_S`. See
-[Quick start](#quick-start) below for the full matrix.
+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)
+below for the full matrix.
 
 For image input use llama.cpp directly — Ollama vision is broken for
 this architecture upstream (see [Vision](#vision)).
@@ -157,7 +139,7 @@ This repo ships a single GGUF to back the HF/Ollama "Use this model"
 widget — `Thanatos-27B.Q4_K_M.gguf` (~17 GB, qwen36-stamped):
 
 ```bash
-ollama run hf.co/FoolDev/Thanatos-27B           # 17 GB Q4_K_M, qwen36 — fails today, see Heads up above
+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 — and as a working-today
@@ -194,46 +176,43 @@ 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: 'qwen36'`** — the
-architecturally-honest label for the Qwen 3.6 family. The cost is
-that no released `ggml-org/llama.cpp` or `ollama/ollama` registers
-that string yet: both register the hybrid SSM + attention stack as
-`qwen35` / `qwen35moe`, including for actual Qwen 3.6-family weights
-(the upstream `Qwen3.6-35B-A3B_Q8_0` GGUFs load under `qwen35moe`).
-No `qwen36` arch entry exists in either repo, and as of 2026-05-19
-there's still no open PR or tracking issue adding one. A
-`qwen36`-stamped GGUF therefore fails to load on stock loaders with
-`unknown model architecture: 'qwen36'` until the metadata is
-rebadged.
-
-`scripts/rename_arch.py` does the rebadge: a metadata-only flip
-that leaves all tensor bytes intact. `make heal-hf` automates it
-for an already-pulled `hf.co/FoolDev/Thanatos-27B` tag (rewrites
-the blob + the manifest's model-layer digest, idempotent on
-already-rebadged tags); `make load-bundle` builds a separate
-local `thanatos-27b` tag from a rebadged copy without touching the
-HF-bridge manifest. Both produce a tag that loads on stock Ollama:
+**The bundled GGUF declares `general.architecture: 'qwen35'`** — the
+arch entry every released llama.cpp / Ollama loads the Qwen 3.6
+hybrid SSM + attention family under. Upstream `ggml-org/llama.cpp`
+and `ollama/ollama` register the stack as `qwen35` / `qwen35moe`,
+including for actual Qwen 3.6-family weights (the upstream
+`Qwen3.6-35B-A3B_Q8_0` GGUFs load under `qwen35moe`); no `qwen36`
+arch entry exists, and there's no open PR or tracking issue for
+one — `qwen35` is the canonical load-time label.
+
+`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` — the
+architecturally-honest label, but unloadable on stock loaders.
+Users needed `make load-bundle` or `make heal-hf` to rebadge
+before loading. The stamp was reverted to `qwen35` in commit
+`964e418` to stop forcing the workaround on every fresh pull;
+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) for future
+flips:
 
 ```bash
 python3 scripts/rename_arch.py \
-    --from-arch qwen36 --to-arch qwen35 \
+    --from-arch qwen35 --to-arch qwen36 \
     Thanatos-27B.Q4_K_M.gguf \
-    Thanatos-27B.Q4_K_M.qwen35.gguf
+    Thanatos-27B.Q4_K_M.qwen36.gguf
 ```
 
-**History.** The bundle has flipped stamp three times. v0.6.0
-shipped `qwen36` (commit `e1f78fa`, architecturally-honest).
-Commit `964e418` (2026-05-19) reverted to `qwen35` to stop forcing
-the rebadge workaround on every fresh pull. Commit `07fa120`
-(same day) flipped it back to `qwen36` — restoring the honest
-label and accepting that stock Ollama users need one `make
-heal-hf` after the first failed run. Tensor data is byte-identical
-across all three states; only the `general.architecture` KV (and
-namespaced KV keys) flips. The current bundle blob SHA is
-`b2b63b941d714b0aff5e9afc9b337e7607b84e371ba991c182d92d0f7805c0e9`,
-identical to the original v0.6.0 qwen36 blob — content-addressed
-return to a known artifact. See the
-[CHANGELOG](CHANGELOG.md) entry for the trade-off rationale.
+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
 
@@ -242,25 +221,18 @@ return to a known artifact. See the
 Three paths:
 
 ```bash
-# A. Pull straight from HF (gets the bundled qwen36 Q4_K_M GGUF +
-#    the root-level template / system / params files in one step).
-#    The first `ollama run` will 500 on the qwen36 blob —
-#    `make heal-hf` rebadges it in place so the same tag loads.
-ollama run hf.co/FoolDev/Thanatos-27B           # 17 GB pull, then 500
-make heal-hf                                    # rebadge cached blob in store
-ollama run hf.co/FoolDev/Thanatos-27B           # now loads
+# 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
 
 # B. Build a local `thanatos-27b` tag from THIS repo's bundle
-#    (smudges LFS pointer via `hf download` if needed, rebadges
-#    qwen36 -> qwen35 in a local copy, runs `ollama create`).
-#    Useful if you want a bare local tag rather than the
-#    hf.co/... path:
+#    (LFS smudge if needed, then `ollama create`). Useful if you
+#    want a bare local tag rather than the `hf.co/...` path:
 make load-bundle                                 # creates local tag thanatos-27b
 ollama run thanatos-27b
 
 # C. Bypass the bundle: download a qwen35-stamped GGUF from unsloth
-#    and build locally. Loads on every current llama.cpp / Ollama
-#    with no rebadge step.
+#    and build locally. Loads on every current llama.cpp / Ollama.
 make build                                              # Q4_K_M  -> thanatos-27b
 make build QUANT=Q3_K_S                                 # 12 GB smaller quant
 make build QUANT=Q5_K_M                                 # 20 GB higher quality
@@ -288,15 +260,14 @@ python examples/ollama_chat.py      # full demo: chat, streaming, tools, OpenAI-
 
 The bundled `Thanatos-27B.Q4_K_M.gguf` is `qwen36`-stamped — every row
 below assumes you've rebadged it to `qwen35` per
-[Architecture](#architecture) (via `make heal-hf` or `make load-bundle`),
-or that you're pulling a `qwen35`-stamped GGUF from
-`unsloth/Qwen3.6-27B-GGUF` instead. The "fails today with
+[Architecture](#architecture), or that you're pulling 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`). The first `ollama run` 500s on the qwen36 blob — run `make heal-hf` once to rebadge it in place, after which the same tag loads. To skip the rebadge entirely, `make build QUANT=Q4_K_M` (or another quant) downloads a qwen35-stamped GGUF 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`). For other quants, or to bypass the qwen36 block today, `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`). |

examples/README.md

@@ -19,26 +19,24 @@ from the `Modelfile` / bridge files.
 
 ### Ollama
 
-The bundle is stamped `general.architecture: 'qwen36'` and no
-released llama.cpp / Ollama recognizes that string yet (both
-register the Qwen 3.6 stack as `qwen35` / `qwen35moe` — see
-[../README.md#architecture](../README.md#architecture)). The first
-`ollama run` against the HF-bridge tag pulls 17 GB and then 500s
-with `unable to load model: <blob>`. Run `make heal-hf` once
-after the failure to rebadge the cached blob in place — the same
-tag loads on subsequent runs:
+Pull straight from HF (gets the bundled Q4_K_M GGUF + this repo's
+root-level `template` / `system` / `params` files via HF's Ollama
+bridge):
 
 ```bash
 ollama pull hf.co/FoolDev/Thanatos-27B           # 17 GB Q4_K_M (only bundled quant)
-cd ..  &&  make heal-hf  &&  cd examples         # rebadge cached blob qwen36 -> qwen35
 pip install requests
 MODEL=hf.co/FoolDev/Thanatos-27B python ollama_chat.py
 ```
 
-For a non-bundled quant (e.g. Q3_K_S ~12 GB, Q5_K_M ~20 GB) — or
-to skip the rebadge entirely — `make build QUANT=...` downloads
-a qwen35-stamped GGUF from `unsloth/Qwen3.6-27B-GGUF` and creates
-a local `thanatos-27b` tag:
+If you pulled before commit `964e418` (the qwen35 re-stamp) and
+still have the broken qwen36 blob in your Ollama store, run
+`cd .. && make heal-hf` once to rebadge it in place. Fresh pulls
+after the re-stamp go straight through.
+
+For a non-bundled quant (e.g. Q3_K_S ~12 GB, Q5_K_M ~20 GB),
+`make build QUANT=...` downloads from `unsloth/Qwen3.6-27B-GGUF`
+and creates a local `thanatos-27b` tag:
 
 ```bash
 cd ..  &&  make build QUANT=Q3_K_S  &&  cd examples