A job killed hard never corrects its own record, so 'running' outlives the
process and the pid can since belong to something else; array-start jobs get
setsid too, so Stop can reach past their direct children.
git installs the new file by rename, so the running bash finishes on the inode
it started with and every step after the sync used the previous version.
The pull substituted only HOSTN_, so bare HOSTN in comments kept tripping
conf_upgrade's own guard and no host conf had upgraded since the guard landed.
UI-launched jobs inherited php-fpm's process group, so stopping one that was
actually running group-killed the WebGUI; setsid makes the job its own group
leader and stop.php now refuses to signal any group it does not lead.
Run was the only mutating control here that did not confirm, and it is the one that executes
shell as root — the library holds cleaners that delete files, and six Run buttons sit a row apart
in a dense tree.
vv_cache_clear() went in without it, so every start and stop fatalled on the line after the
docker command had already run — the action succeeded and the page was told it failed.
Every poll after the first asked for ?live=1, so the page paid a full collection — partner SSH
timeouts included — every two seconds while the tmpfs cache it was built around went unused.
Polls are now guarded against overlap and stop while the tab is hidden, repeated failures say so
instead of leaving the last good reading on screen, and two functions nothing called are gone.
The response was discarded, so a refused stop looked like a completed one, and the payload the
card redraws from is cached for 300s with no invalidation — the container carried on showing as
running until the once-a-minute writer caught up. Stop now confirms; start still does not.
The page interpolated media titles, partner hostnames read over the mesh, and docker folder
names straight into innerHTML — its own header claimed otherwise, and the helpers that would
have fixed it were defined in a page it never loads. Container WebUI values now get a scheme
check before they reach window.open().
The Tools card adopted the AI scripts on the host check alone, and api/ai.php only
tested AI_ENABLED in front of ask, so a disabled subsystem still had rows to run and
an endpoint that answered.
AI_INDEX_ON_PULL was designed, defaulted false, and never read by anything —
so nothing has ever rebuilt the index automatically. A pull is the only thing
that changes tracked files on a server, which makes it the only moment the
index can go stale, and a timer would do nothing 23 times a day while still
drifting from the pull that matters.
Staleness is invisible in the answers: the index keeps returning the old text
with confident, correct-looking citations. Gated on pull success, on
AI_INDEX_ON_PULL and on AI_ENABLED, and never fatal — a git pull must not fail
because an embedding call timed out.
"What is Varaverk" matched the PURPOSE intent, so retrieval returned every
script's one-line purpose and the model answered that the context does not
define the system — while README.md sat in the index unread. A definitional
question with no explicit filter now goes to kind=readme.
Varaverk is a coined word with no spell-check, so it arrives as varavrk,
veraverk, varavek. Edit distance catches those without a pattern that needs
extending per typo. This is search, not identity — a near-miss only widens a
document search, unlike hostname resolution where it must never resolve.
Custom Scripts run as root on a schedule, so the expensive mistake is not
tangled logic — it is a simple script aimed one directory too high. The prompt
now asks for the dry-run form and an explicit line on what gets destroyed, and
a scan of the generated code blocks raises a banner regardless of whether the
model bothered to warn. Scans fenced code only, so prose mentioning rm does not
trip it.
Given its own broken script and the real error, it produced the correct fix but
explained --no-overwrite away as 'introduced in a later version of rsync'. No
rsync version has ever had that flag, and the operator is on current 3.4.4 — so
the repair was right and the diagnosis was a second fabrication that would send
someone hunting a nonexistent upgrade.
The pattern required three underscore-separated segments, so RSYNC_ENABLED and
AI_ENABLED slipped through — exactly the names most likely to be asked about.
Also dropped the case-insensitive flag, which made the SCREAMING_CASE branch
match ordinary lowercase words containing underscores.
Asked what mover_stop.sh does, it invented a description and dressed it in
real memory facts so it read as authoritative — the exact failure the profile
split exists to prevent. A polite instruction in a system prompt is not a
guard. The rule now leads and is absolute, and a deterministic check repeats
it immediately before the message whenever the question names a shell script,
a SCREAMING_CASE conf key, or Varaverk itself. Detection can only make the
model more cautious, so a false positive costs a redirect, not an answer.
Explicit buttons rather than an automatic router. Misclassifying a Varaverk
question as chat produces a confident invention about the user's system, which
is exactly what retrieval exists to prevent — with buttons there is no hidden
heuristic to be wrong and the strict profile is the default you land on.
Only Varaverk Assistant retrieves; the other two would be carrying passages
that cannot help write a folder-copy script. Memory goes to all three, since
that is what lets chat know the setup without claiming authority over it.
History depth is per profile and set server-side: retrieval costs ~2500 of
16384, so the profiles that skip it can hold a real conversation. Code
Sketcher is told to flag flags it is unsure of, after it invented
rsync --no-overwrite.
A small operator-written file handed to the model at the start of every
conversation — who you are, how this install is set up, what has already been
decided. Injected ahead of the retrieved passages and marked operator-authored
so it outranks anything they contradict, and never cited as a source.
Deliberately not indexed and deliberately under DATA_DIR: it changes
constantly, vector similarity is the wrong way to retrieve things you were
told to remember, and gitignoring it keeps personal notes out of a pushed
repository. The character cap is a context budget — this text costs its share
of 16k on every single turn.
The pattern required a tier prefix, so the master gate the rsync page renders
alongside the tier toggles was rejected as an invalid flag name and sprang
back to off. There was no way to enable syncing from the UI. Masked until now
because every POST to this endpoint was being swallowed as multipart.
A multipart POST to the plugin API hangs and never completes on this host: no
status code, and no server-side trace of any kind. The correlation was exact —
every page using URLSearchParams worked, every page using FormData hung, which
is why scheduler and partnership appeared fine while docker, rsync, settings,
auth, arrs, fallback and monitor did not. URLSearchParams has the same append
API and fetch sets the urlencoded content type for it, so each site is a
one-token change with the payload logic untouched.
A multipart POST to this endpoint hangs: no status code is ever returned, and
the request never reaches PHP — no CSRF termination, no fatal, no entry log —
despite leaving the browser with a valid token and a correct body. Every POST
on this host that demonstrably works, including Unraid's own, is
x-www-form-urlencoded. Same fields and same $_POST server-side.
A POST the browser demonstrably sent — correct token, correct body — left no
trace: no CSRF termination, no fatal, and no action log. Rejected-before-PHP
and died-inside-the-include are indistinguishable from outside, so the first
statement now records that execution arrived.
The build-stamp edit replaced the header block's closing tag instead of
keeping it, opening a second php block inside the first. Deployed broken
because the lint in that commit printed OK unconditionally rather than
gating on php -l.
The tab bar uses Unraid's localURL, which swaps content by AJAX without
tearing down the previous page's JavaScript, so old copies keep their timers
and their state. That makes "is the browser running what I deployed"
unanswerable from the server, and explains banner polls arriving far faster
than the 30s timer. The page now stamps its build, says plainly when its own
script is not the one running, and stops the previous copy's timers.
A turn that ended without finish() left busy=true, so send() returned at line
one for every subsequent click — no fetch, no error, and the original
"starting…" still on screen. That is a hang which produces no request and so
no server-side trace of any kind. It now says what happened, and the pending
indicator carries an elapsed counter so stalled and merely slow look different.
GET reaches the endpoint and POST does not, with nothing in the request log,
no CSRF termination and no PHP error — so it fails in the browser before the
request goes out, and the only symptom was the pending indicator sitting
there. Reads the response as text before parsing so an empty body reports as
rejected-before-execution rather than a JSON error, wraps the synchronous
path, and surfaces script errors into the transcript.
There is no nginx access log on this host and the CSRF prepend exits with an
empty body, so a request that never arrived and one that arrived and failed
were indistinguishable — the page just sat at "starting…". The job-file write
was also suppressed with @, which would produce exactly that hang: a token
returned for a job that can never report.
Asked what was wrong, it answered "AI_ENABLED=false" — read from the conf
template, which records the shipped default, while the live value was true.
Passing checks are what tell the model the current value of a setting;
without them a documented default fills the silence. The prompt now states
explicitly that live state overrides any documented default.
Gmer4Lfe