fix(dreaming): do not compute approval friction against a missing denominator (v0.281.5)

[vikasprogrammer]

Found by checking whether the approval nag the live tenants are serving is actually true. On instapods it is not.

instapods, last 7 days (from the audit log):
  approved=35  rejected=2  → true rejection rate 5.4%

instapods guidance, injected into every agent's system prompt:
  • Recent actions were rejected at human approval — `policy_check` before risky effects…

Cause

v0.280.0 (#492) made friction a rate and started recording the approved count to divide by. Per-pass recent entries written before that carry rejected with no approved field — and recentTally summed them regardless, so approved stayed 0 while rejections accumulated. Six of instapods' seven window entries are legacy, so the computed rate was ~100% against a denominator that doesn't exist.

This was flagged as a known one-pass caveat in #492. It is worse than that in practice: the window holds 7 entries, so a tenant keeps mis-firing until legacy entries roll off — and it fires in the wrong direction, telling agents to expect rejection on a workspace that approves ~95% of requests.

Fix

An entry without the denominator contributes to neither side of the ratio. Its budget/error signals still count — only the approval ratio skips it.

Verified against both tenants' real window shapes

Window	before	after
instapods (true 5.4%)	nag on	nag off
instawp (true 37.1%)	nag on, policy.review on	quiet — only 3 decisions carry a denominator
genuine friction, good sample	on	on

instawp going quiet is the conservative direction: its true rate does warrant the nag, but the recorded evidence is 3 decisions, and it re-fires once enough passes have recorded the denominator. Silence beats confidently wrong advice in every agent's prompt.

137/137 governance + 18/18 tier-A policy.

🤖 Generated with Claude Code