f4ccc45a3b
The Ollama URL was leaking via:
- prose in /en/, /de/, /ja/, /es/, /fr/ docs (oracle, deployment,
local-testing, ai/module/{overview,embed,training})
- code blocks teaching users to curl the host directly
- .env.example, Dockerfile, docker-compose.yml defaults
- providers.mjs, translate-docs.mjs, build-oracle-index.mjs defaults
- LandingScripts.astro comment
- lora-runbook.md prose + SSH host
- the GET handler at /api/oracle which echoed `ollamaUrl` back to public callers
- the "Oracle is silent" fallback message at /api/oracle POST
Replacements:
- prose: "neuronetz.ai" → "your Ollama instance"
- example URLs in code blocks: https://api.neuronetz.ai → https://your-ollama-host.example
- code-level defaults: → http://localhost:11434 (Ollama's standard local port)
- GET /api/oracle: dropped the `ollamaUrl` field; provider + model still exposed
- runbook SSH host: neuronetz@cloud.neuronetz.ai → <gpu-user>@<gpu-host>
Production chat is unaffected: docs/.env (gitignored) on the production
host still pins OLLAMA_BASE_URL=https://api.neuronetz.ai. The only
change in the running container is that the GET handler no longer
echoes the URL.
analytics.neuronetz.ai (Umami tracking) is intentionally left intact —
it's a public, brand-owned subdomain meant to be visible.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Training nibiru-coder
This folder contains everything needed to register a Nibiru-flavoured chat
model on your Ollama server (defaults to http://localhost:11434; override
via the OLLAMA_BASE_URL env var or in application/module/ai/settings/ai.production.ini).
What the model is
nibiru-coder is a system-prompt-customised Qwen 2.5 Coder 14B. It's not
a fine-tune in the LoRA sense — it's the same weights as the base model but
with a baked-in system prompt that:
- explains MMVC, modules, the dispatcher, and Nibiru's singletons,
- enforces the framework's conventions (
pageAction,navigationAction,View::assign,Form::create), - pushes the model toward Nibiru-idiomatic answers instead of generic Laravel / Symfony advice.
System-prompt customisation runs instantly (no GPU training time) and gives ~80 % of the value of a real LoRA at zero training cost. When you have budget for a real LoRA, the corpus exporter produces the JSONL you'd train on.
Build it
./application/module/ai/training/build.sh # builds nibiru-coder:1.0
./application/module/ai/training/build.sh 1.1 # bump tag
The script:
- Reads the
Modelfilenext to it. - POSTs to
${OLLAMA_BASE_URL}/api/create. - Runs a smoke-test chat call to confirm the new tag responds.
After it succeeds, set the model in application/module/ai/settings/ai.ini:
[AI]
chat.model = "nibiru-coder:1.0"
…and every \Nibiru\Module\Ai\Ai instance in your app talks to it.
Iterate on the system prompt
The Modelfile's SYSTEM """ ... """ block is the lever. Tighten the
conventions, add new examples, or add citations to specific framework files.
Re-run build.sh with a new tag (1.1, 1.2) and A/B against the previous
tag in your app.
Real LoRA path (when you're ready)
- Run
npm run build:corpusindocs/— producesdist/corpus/chat.jsonl. - Use Axolotl / Unsloth / LLaMA-Factory with that JSONL as your sharegpt training set.
- Convert the resulting LoRA to GGUF (
llama.cpp'sconvert-hf-to-gguf.py). - Build an Ollama Modelfile with
FROM ./your-lora.ggufand re-register asnibiru-coder:2.0.
The framework code doesn't need to change — flip the model tag in
ai.ini and you're on the new weights.