v0.2.2

Release v0.2.2

Statically color the installed-plugin icon instead of following MOS's
theme "primary" color. manifest.json's icon field was the bare string
"mdi-robot-outline", which plugins.vue renders as a live-themed
<v-icon color="primary"> glyph - correct-looking on this instance only
because its theme primary happens to be the same orange (#E65100) the
plugin is meant to use, but not guaranteed for any other theme. Now
ships its own colored icon.svg (same asset/color as the Hub catalog
fix) at /plugins/ai-template-maker/icon.svg, served from staticfiles/
alongside the rest of the built frontend - so the icon renders the same
regardless of the viewer's theme.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

v0.2.1

Release v0.2.1

Tighten the analyze system prompt for four ambiguous cases that were
sending reasoning-capable models into long, unresolved deliberation
(confirmed via a real reasoning_content trace against paperless-ngx):
- no compose file provided despite the README recommending one -> use
  docker mode instead of guessing sidecar services
- a Dockerfile that only builds an image, with no pull reference stated
  anywhere -> fall back to ghcr.io/<owner>/<repo>:latest rather than
  weighing registries
- multiple Dockerfile VOLUME paths -> include all of them instead of
  guessing which are "essential"
- orchestration-only .env keys like COMPOSE_PROJECT_NAME -> skip them,
  they aren't app configuration

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

v0.2.0

Release v0.2.0

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

v0.1.23

Release v0.1.23

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

v0.1.22

Update default Gemini model: gemini-2.5-flash -> gemini-3.6-flash

gemini-2.5-flash is no longer available to new API keys (confirmed via a
real "Gemini API request failed" -> now-diagnostic error from the
previous fix, which correctly surfaced Google's actual rejection message
this time instead of a generic one). Updated the default everywhere it
appears: settings.json, the script's fallback, and the Settings tab's
default form value.

Existing installs with a saved (now-stale) model value aren't affected by
this default change - Settings' "Test connection" dropdown already lists
whatever's actually available to a given key, so switching is a Test +
pick-from-dropdown + Save rather than needing a code update.

Bumps to v0.1.22.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

v0.1.21

Fix opaque "Gemini/Claude API request failed" errors

Both call_anthropic() and call_gemini() were still on the original
curl -sf ... || fail "<generic message>" form from before the exit-code/
HTTP-body capturing pattern existed (built out for call_ollama() and
call_openai() since). A real API-level failure - bad model name, quota
exceeded, bad key - came through as a bare "Gemini API request failed" or
"Claude API request failed" with zero indication of what actually went
wrong, which is exactly what was just reported.

Both now match the other two providers: distinguish curl exit code (host
unreachable) from an HTTP error status with the actual error.message body
surfaced directly. Verified against mocked 400/429 responses - both now
report the real cause instead of the generic message.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

v0.1.20

Fix reasoning models silently failing on OpenAI-compatible servers

Real failure from testing: a local reasoning model (Qwen3-family, served
via llama.cpp based on the response's "timings" field) burned its entire
8192-token budget writing to a separate "reasoning_content" field, hit
finish_reason:"length", and left "content" empty - which just produced a
generic, unhelpful "OpenAI-compatible server returned no content".

- call_openai() now checks for this specific signature (empty content +
  finish_reason "length" + non-empty reasoning_content) and reports
  exactly what happened instead of a generic failure.
- Gives openai its own completion budget (openai_budget, default 16384,
  separate from the shared $budget Anthropic/Gemini use) rather than the
  8192 that was exhausted here - reasoning-capable models are common on
  exactly the kind of local/self-hosted server this provider is also
  meant to cover, and their reasoning traces alone can be substantial on
  a prompt this size.

Verified both against the user's actual failure response (correctly
detected) and a normal successful response (unaffected, no false
positive).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

v0.1.19

Move history/job data off the USB boot device onto the storage pool

MOS boots from a USB drive into RAM and only writes back to that same USB
for things meant to persist across reboots - limited write endurance,
meant for occasional config writes, not history.json (rewritten on every
single analysis, and now holds full embedded results, making it bigger
than before) or the jobs/ directory (several small files per analysis,
pruned on every -start call).

All five scripts (ai-template-maker-analyze, -history, -analyze-start,
-analyze-status, -analyze-cancel) now resolve their data directory
against /boot/config/docker.json's .appdata - the same real storage-pool
location ai-template-maker-analyze's own remap_appdata_paths() already
resolves docker host paths against - falling back to the boot-resident
plugin directory only if no pool is configured yet. settings.json stays
on the boot device, since MOS's own plugin settings API controls that
path directly and it's only written on an explicit Save, not per
analysis.

Verified the resolution logic against three cases: pool configured, no
pool configured, and docker.json missing entirely (first boot) - all
resolve correctly, with the last two falling back safely rather than
erroring.

Note: existing history.json entries from before this change live at the
old boot-resident path and won't carry over - a clean cutover rather than
a migration, given this is still pre-1.0 with a small deployment.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

v0.1.18

Release v0.1.18

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

v0.1.17

Release v0.1.17

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>