From 7695620a96f4f37d87c2441b517a40ffd68c42e5 Mon Sep 17 00:00:00 2001 From: claude Date: Tue, 4 Aug 2026 22:50:47 +0400 Subject: [PATCH] qa plan: presence arrives, and the state row that never gets written (V-287) 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 Claude-Session: https://claude.ai/code/session_011x5DgnExQ5XZy8TZPs5bot --- docs/qa.md | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/docs/qa.md b/docs/qa.md index adcda56..042aecb 100644 --- a/docs/qa.md +++ b/docs/qa.md @@ -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: