docs(wiki): record response_format fix, Qwen2.5-3B default, ZeroGPU quota behaviour

- response_format must be {"type":"json_object","schema":...}; the OpenAI-style
"json_schema" is silently ignored by llama-cpp-python, leaving fuse/tweak
unconstrained and forcing every edit onto the keyword editor.
- Default model is now Qwen2.5-3B (6/7 schema incl. Chinese on the pinned
0.3.19; Llama-3.2-3B scored 0/7 even after the fix). Recorded the 3B-vs-7B
trade-off and that Qwen2.5 runs on 0.3.19 with no llama-cpp upgrade.
- Documented ZeroGPU quota-exhaustion symptoms (warmup failures, CPU drop to
~1.9 tok/s). Verified against live Space run logs.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

wiki/deployment-strategy.md

@@ -5,6 +5,7 @@ last_updated: 2026-06-14
 confidence: high
 sources:
   - src/buddy_fusion/runtime.py
+  - src/buddy_fusion/prompts.py
   - requirements.txt
   - README.md
   - scripts/start-local.sh
@@ -56,6 +57,20 @@ background while the player reads the intro. It runs once per container
 These are recipe-level JSON, not prose, so the budgets are small — keeping a
 playthrough's GPU seconds lean so a judge's first splice isn't spent on the JIT.
 
+### Schema enforcement (response_format) — load-bearing
+
+`_blocking_completion` constrains output with
+`response_format={"type": "json_object", "schema": ...}`. **The key must be
+`json_object`, not the OpenAI-style `json_schema`** — llama-cpp-python silently
+ignores `json_schema`, leaving the model completely unconstrained: it returns
+`type` instead of `kind`, bare strings like `["arm", "arm"]`, or a
+`{"genome": {...}}` wrapper. None of those survive `repair_genome`, so every
+edit falls through to the deterministic keyword editor — which is why tweaks
+looked like they "ignored the model" for so long. With `json_object` the schema
+is compiled to a GBNF grammar and enforced, so fuse / tweak output actually
+matches `GENOME_SCHEMA` / `GENOME_EDIT_SCHEMA`. This bug masked the real model
+behaviour; fix it before judging any model's capability.
+
 ## ZeroGPU vs CPU Basic — reference baseline
 
 Measured on the sibling project (`build-a-buddy-hf`) with the **identical**
@@ -84,6 +99,15 @@ ZeroGPU operational constraints worth remembering:
   hence the 30/90 split.
 - **Hosting needs a ZeroGPU grant** — the `build-small-hackathon` org has one
   (a personal free account gets a `403`).
+- **Quota exhaustion is visible in the run log** — when the org's daily ZeroGPU
+  quota runs out, `warmup()` logs `[zerogpu-warmup] failed: ... exceeded ZeroGPU
+  quota (... vs. 0s left)` and inference drops to CPU: `[zerogpu-bench] ... 1.9
+  tok/s` (vs ~200 on GPU), ~45s per tweak, fuse far worse. At that point tweaks
+  also fall to the keyword editor, so the model's real value (Chinese, complex,
+  out-of-schema approximations) can't be shown. Repeatedly opening the Space /
+  re-warming burns the budget — keep it in reserve before a demo. The
+  `duration=90` warmup reserves ~135s and retries on every page load while quota
+  is exhausted, a pure cost worth trimming or skipping when quota is low.
 
 ## Space build: the wheel pins (load-bearing)
 
@@ -117,22 +141,39 @@ Verification signal in the build log: it should print
 `Downloading llama_cpp_python-0.3.19-...-manylinux...whl`, **not** a
 `.tar.gz` followed by `Building wheel ... still running`.
 
-**chat-template ceiling:** `llama-cpp-python==0.3.19`'s template engine is old;
-newer model families need ≥0.3.26 or they throw a Jinja `unknown tag` error —
-but the cu124 cp312 index stops at 0.3.19. `Llama-3.2-3B` and `SmolLM2-1.7B`
-work; this caps model upgrades.
+**chat-template ceiling (narrower than feared):** the cu124 cp312 wheel index
+stops at `0.3.19`, and 0.3.19's Jinja engine is old enough that *some* newer
+model families throw an `unknown tag` error. But **Qwen2.5 (3B/7B/14B/32B) runs
+fine on 0.3.19** — verified locally against the Space-pinned version: the chat
+template loads and `json_object` schema enforcement works. So adopting Qwen2.5
+needs **no** llama-cpp-python upgrade and no wheel / README pin change. (If a
+future model ever does need a newer build: the cu124 index now ships a
+`py3-none-manylinux_2_35_x86_64` wheel for `0.3.29`, Linux-installable — the
+old "cp312 stops at 0.3.19" pin is no longer the only option.)
 
 ## Model strategy
 
-- Default real config (`runtime.py`): `Llama-3.2-3B-Instruct` GGUF Q4_K_M
-  primary, `SmolLM2-1.7B-Instruct` fallback.
-- `scripts/start-local-real-model.sh` preset `fast` swaps to SmolLM2-1.7B
-  primary for quicker local iteration; preset `llama` keeps Llama-3.2-3B
-  primary. Model loading is lazy — starting the app does not download a GGUF;
-  the first splice pays that cost (or pre-cache via `BUDDY_MODEL_PATH`).
-- The 32B competition cap is an upper bound, not a target: response speed and
-  demo stability matter more than parameter count, and a small model keeps the
-  `Tiny Titan` / `Off the Grid` bonus quests in reach (see
+- Default real config (`runtime.py`): **`Qwen2.5-3B-Instruct`** GGUF Q4_K_M
+  primary, `SmolLM2-1.7B-Instruct` fallback (the smaller download-failure
+  fallback, not a quality fallback).
+- Why Qwen2.5-3B — measured locally on the genome edit schema (0.3.19, *after*
+  the `json_object` fix above; before the fix every model scored ~0 because the
+  schema never applied):
+  - `Qwen2.5-7B` 7/7 (incl. Chinese), `Qwen2.5-3B` 6/7 — both follow the schema
+    and produce genuinely model-driven tweaks, in English and Chinese.
+  - `Llama-3.2-3B` (the previous default) **0/7 even with the fix** — it overran
+    the 200-token edit budget and produced truncated JSON. `SmolLM2-1.7B` 3/7.
+  - 3B is the cheapest that works and matches the old footprint (~2GB GGUF); 7B
+    is the safest (7/7, ~4.7GB). Chose 3B for cost parity; 7B is the upgrade if
+    schema misses ever matter.
+  - Out-of-schema instructions ("build a house", "turn it into a robot") still
+    no-op or approximate on every model — that is a schema/part-kind limit, not
+    a model limit.
+- `scripts/start-local-real-model.sh` presets still select SmolLM2 / Llama for
+  local iteration. Model loading is lazy — the first splice downloads the GGUF
+  (or pre-cache via `BUDDY_MODEL_PATH`).
+- The 32B competition cap is an upper bound, not a target: a small model keeps
+  the `Tiny Titan` / `Off the Grid` bonus quests in reach (see
   [hackathon-context](hackathon-context.md)).
 
 ## UX constraint

wiki/log.md

@@ -2,6 +2,22 @@
 
 ## 2026-06-14
 
+### deployment-strategy: response_format bug, Qwen2.5-3B default, ZeroGPU quota
+
+- Recorded the root-cause fix: `response_format` must be
+  `{"type":"json_object","schema":...}`; the OpenAI-style `"json_schema"` is
+  silently ignored by llama-cpp-python, so fuse/tweak ran unconstrained and every
+  edit fell to the keyword editor. Added a "Schema enforcement" subsection.
+- Updated Model strategy: default is now `Qwen2.5-3B-Instruct` (6/7 schema, incl.
+  Chinese; Llama-3.2-3B scored 0/7 even after the fix — truncated JSON). Recorded
+  the local 0.3.19 measurements and the 3B-vs-7B trade-off.
+- Corrected the chat-template ceiling: Qwen2.5 (3B–32B) runs on the Space-pinned
+  0.3.19, so adopting it needs no llama-cpp-python upgrade; noted the new
+  `py3-none-manylinux` 0.3.29 wheel as a future option.
+- Added ZeroGPU quota-exhaustion symptoms (warmup failures, CPU drop to ~1.9
+  tok/s) to the operational constraints. Verified against live Space run logs;
+  fix is committed (`d9eb5a7`) and deployed.
+
 ### Theme: switched from light-redirect lock to theme-independence
 
 - Rewrote `gradio-theme-locking.md` (and its `index.md` line): the app no longer