Gmer4Lfe
613634473a
Search is the one capability that fits the profile holding none: every other capability either reads this installation or changes it, and chat's whole contract is that it can do neither. The assistant deliberately does not get it — its contract is that answers come from this install's own documents, and a web result there is an answer that looks sourced and is not. A chat question about this machine hands off to the assistant before the search would run, so it never reaches the internet even with the box ticked. Off by default, and not because it is dangerous: searching sends the operator's question outside the house, which is theirs to decide. Asked for per turn as well as enabled in conf. Provider-agnostic, as asked — searxng, brave, tavily. Only whichever is configured here can be verified; all three read every field by name, so a shape that changes underneath yields no results rather than wrong ones. The explain fixtures asserted chat holds no capabilities at all, which is exactly the guarantee worth keeping. caps=only: now states the set rather than its emptiness, so the check still fails the day something else is granted there.
110 lines
8.5 KiB
Plaintext
110 lines
8.5 KiB
Plaintext
# ═══════════════════════════════════════════════════════════════════════════════════════════════
|
|
# Expected routing for the AI assistant, one case per line, checked by ai_explain_check.sh.
|
|
#
|
|
# Every line here is a bug that was found by reading an answer and noticing it was wrong. That is
|
|
# the expensive way to find them and it does not scale: the operator is the test suite, and the
|
|
# operator is busy. Written down, each one costs a second to re-check forever.
|
|
#
|
|
# These assert ROUTING, never wording. What a profile is allowed, which script a question names,
|
|
# which gates fire and what evidence gets attached are all decided before the model is involved,
|
|
# so they are identical every run. The prose is not and is deliberately not asserted — a test that
|
|
# depends on how the model phrases something fails for reasons nobody wants to read about.
|
|
#
|
|
# FORMAT
|
|
# question | profile | scope | kind | assertions
|
|
#
|
|
# Blank fields are allowed. Assertions are space-separated:
|
|
# profile=X the profile that ends up answering, after any handoff
|
|
# target=X resolved run target, or 'none'
|
|
# run=yes|no the run-outcome gate
|
|
# diag=yes|no the diagnostic gate
|
|
# caps=none the profile holds no capabilities at all
|
|
# caps=only:a,b it holds exactly these and nothing else
|
|
# caps=a it holds at least this
|
|
# has=a,b every one of these must be attached
|
|
# hasnt=a,b none of these may be attached
|
|
#
|
|
# Attachment keys: health warnings run_record log_tail log_missing incidents conf_keys
|
|
# ═══════════════════════════════════════════════════════════════════════════════════════════════
|
|
|
|
# ── Run-outcome questions must arrive with the run, not with directions to the log panel ───────
|
|
# The phrasing that started it. "went last" matched; "the run went" did not, one word order apart.
|
|
lets check the daily orch log and see how the run went | varaverk | Scheduler | | target=Orchestrators/daily_sync_maintenance run=yes has=run_record,log_tail
|
|
lets look at daily orch log and see how it went last run | varaverk | Scheduler | | run=yes has=run_record,log_tail
|
|
# Confirmed good in the WebGUI dock. Plural "logs", and "how it went" rather than "how the run
|
|
# went" — neither exact string was covered, and both are how the question actually gets typed.
|
|
lets check the daily orch logs and see how it went | varaverk | Scheduler | | target=Orchestrators/daily_sync_maintenance run=yes has=run_record,log_tail
|
|
how did the daily orch go | varaverk | | | target=Orchestrators/daily_sync_maintenance run=yes has=run_record,log_tail
|
|
how did the weekly orch go last run | varaverk | | | target=Orchestrators/weekly_sync_maintenance run=yes has=run_record
|
|
did the watchdog orchestrator run | varaverk | | | target=Orchestrators/watchdog_orchestrator run=yes
|
|
give me a rundown of the daily orch | varaverk | | | run=yes has=run_record
|
|
how long did the daily orch take | varaverk | | | run=yes has=run_record
|
|
|
|
# Works from the AI tab, which sends no scope at all — resolution is from the question, not the page.
|
|
how did the daily orch go last run | varaverk | | | target=Orchestrators/daily_sync_maintenance has=run_record
|
|
|
|
# ── A clean run earns the record and the log, and nothing else ─────────────────────────────────
|
|
# The health sweep and the recent-warning lines are ~660 tokens that answer nothing when the run
|
|
# exited 0, taken straight out of the passages' budget. They come back the moment it did not.
|
|
lets check the daily orch logs and see how it went | varaverk | Scheduler | | diag=no hasnt=health,warnings has=run_record,log_tail
|
|
how did the daily orch go | varaverk | | | diag=no hasnt=health,warnings
|
|
why did the daily orch fail | varaverk | | | diag=yes has=health,warnings,log_tail
|
|
why did the weekly orch fail | varaverk | | | diag=yes has=health,warnings
|
|
|
|
# ── Definitional questions must NOT be answered with last night's log ──────────────────────────
|
|
what does the daily orchestrator do | varaverk | | | target=Orchestrators/daily_sync_maintenance run=no hasnt=run_record,log_tail
|
|
how does the daily orch work | varaverk | | | run=no hasnt=run_record,log_tail
|
|
what is the daily orchestrator | varaverk | | | run=no hasnt=run_record
|
|
|
|
# ── Ambiguity resolves to nothing rather than guessing a script ────────────────────────────────
|
|
# A scored match here attaches the wrong log and answers confidently about a run nobody asked
|
|
# about, which is indistinguishable from a right answer unless you already knew.
|
|
how did sync go | varaverk | | | target=none run=no
|
|
what does RSYNC_ENABLED do | varaverk | | | target=none run=no has=conf_keys
|
|
# Whole words only. "fail" contains "ai", and ai.log is a real log id — a substring match here
|
|
# attached the AI's own log to questions about everything else.
|
|
why did this run fail | varaverk | | | target=none
|
|
is the mail relay working again | varaverk | | | target=none
|
|
|
|
# ── The Recent Activity buttons: one click from a row to an answer about that run ──────────────
|
|
# Both open the log first, so the dock is scoped to troubleshoot against that script's log id.
|
|
Why did this run fail? | troubleshoot | Orchestrators/daily_sync_maintenance | | diag=yes has=log_tail,run_record
|
|
How did this run go? | troubleshoot | Orchestrators/weekly_sync_maintenance | | has=log_tail,run_record
|
|
|
|
# ── General Chat holds nothing, and hands Varaverk questions up rather than deferring ──────────
|
|
how was your day | chat | | | profile=chat caps=only:web_search hasnt=health,log_tail,incidents,conf_keys
|
|
what does arr_sync.sh do | chat | | | profile=varaverk
|
|
is RSYNC_ENABLED on right now | chat | | | profile=varaverk has=conf_keys
|
|
how did the daily orch go | chat | | | profile=varaverk run=yes has=run_record
|
|
|
|
# Chat opened against a script must not be handed the operator's own incident notes about it.
|
|
how was your day | chat | Orchestrators/daily_sync_maintenance | | profile=chat hasnt=incidents
|
|
|
|
# ── Troubleshoot gets the log for whatever is open, plus the right to file a bug ───────────────
|
|
why did the weekly orch fail | troubleshoot | Orchestrators/weekly_sync_maintenance | | diag=yes has=log_tail,run_record
|
|
what is going on here | troubleshoot | Orchestrators/daily_sync_maintenance | | diag=yes has=log_tail
|
|
|
|
# ── The code profile answers from the model alone: no passages, no live state ──────────────────
|
|
write me a script that copies a folder | code | | | hasnt=health,log_tail,incidents,conf_keys
|
|
|
|
# ── General Chat routes to the profile that fits, not always to the Assistant ──────────────────
|
|
# Chat had one escalation target, so a fault report and a request for code both landed on the
|
|
# documentation assistant. Both were answered adequately; neither was answered well. Order is the
|
|
# policy — code is checked first because it is the only intent about a thing that does not exist
|
|
# yet, and troubleshoot requires diagnostic phrasing AND something here to diagnose.
|
|
why did the daily orch fail | chat | | | profile=troubleshoot diag=yes target=Orchestrators/daily_sync_maintenance
|
|
the daily orch is broken | chat | | | profile=troubleshoot diag=yes
|
|
why did arr_sync.sh error out | chat | | | profile=troubleshoot diag=yes
|
|
create a script to prune old logs | chat | | | profile=code hasnt=health,log_tail,incidents
|
|
make me a one-liner that counts files | chat | | | profile=code
|
|
write me a bash script for backups | chat | | | profile=code
|
|
|
|
# Diagnostic phrasing about nothing here stays in chat — "why" is not a Varaverk question on its
|
|
# own, and escalating adds capability, so a wrong escalation costs more than a missed one.
|
|
why is the sky blue | chat | | | profile=chat caps=only:web_search hasnt=health,log_tail,incidents,conf_keys
|
|
what is wrong with my car | chat | | | profile=chat caps=only:web_search
|
|
|
|
# Naming a script and asking what it does is documentation, not a request to write one. The code
|
|
# router is anchored on the verb for exactly this pair.
|
|
what does arr_sync.sh do | chat | | | profile=varaverk
|