kami/Maven
1
0
Fork 0
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

qa plan: presence arrives, and the state row that never gets written (V-287)

Browse Source 
The desk_active poster is live on workpc, so 15 no longer blocks session 1
steps 7 and 8. What blocks them is that no rule's predicate is true: water
needs 3h since the fact step 2 just wrote, meal and break have no anchor.

Separately, SavePresenceState has no caller outside tests. The gate reads the
in-memory bucket so delivery is unaffected, but hysteresis never engages and
every presence readout shows away at score 0.00. Filed as 532.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011x5DgnExQ5XZy8TZPs5bot
This commit is contained in:
claude
2026-08-04 22:50:47 +04:00
parent 758fb6a3f0
commit 7695620a96
1 changed files with 26 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/qa.md
+26 -6
View File
@@ -105,12 +105,32 @@ That covers audio in → STT → router → phrasing → TTS audio out. It leave
browser microphone capture needing a person, and the wake path needing a machine.
Do not post `en_act.wav` without deciding first: it is a mutating act.
**Steps 7 and 8 cannot run at all**, and the reason is not the microphone. They
need a nudge to arrive, and the only rule that fires is the morning routine,
which the dispatcher drops every time: `dropped morning:утро (sev1,
presence=away)`. No `desk_active` fact has ever been written, so presence never
reads present. That is **15**, and it blocks these two steps as hard as it blocks
the presence half of session 3.
**Steps 7 and 8 still cannot run, but 15 is no longer the reason** (04-08-2026).
The desk presence poster is installed on workpc. It is a `maven-desk` systemd
user timer on a 60s cadence, gated by hypridle at 120s idle. `desk_active` facts
now arrive, and the first landed at 18:43.
What blocks the two steps now is that no rule wants to fire. `/trace` shows all
five at `predicate`, none inert:
| rule | sev | why it is false |
|---|---|---|
| water | 1 | needs ≥3h since the last `water` fact; step 2's `ru_fact` wrote one |
| meal | 1 | needs ≥6h since a `meal` fact; none exists |
| break | 2 | needs both `desk_active` and a `break` fact; `break` has never been written |
| service_down | 4 | no kuma monitor is down |
| netdata_critical | 3 | nothing critical |
So the honest way to run step 8 is to wait three hours after the last `water`
fact, or to write one antedated. Do not read the water rule's silence as a defect.
**Presence itself has a real defect, filed as 532.** `SavePresenceState` has no
caller outside tests, so the singleton row is never written. The gate is fine,
because it reads the bucket `GatherState` computes in memory each tick. Two
things follow. Hysteresis is dead, because `lastBucket` is always cold-start `Away`
and the 0.30-0.55 hold band never applies. And every presence readout lies:
`/dash` shows `away — score 0.00 (never)` with fresh `desk_active` facts arriving
every 60s. Do not trust that number while checking anything else here.
Steps 1 and 3-6 do not need a browser. `POST /api/chat` takes a form-encoded
`text=` field and a cookie jar, and answers with the rendered `/chat` page: