Problem
Both the emotional-state store debounce (STORE_DEBOUNCE_MS) and the newer auto-trace debounce (TRACE_DEBOUNCE_MS) are hardcoded to 3 minutes each, not exposed via config. Different setups have very different conversation rhythms — a household with sparse, occasional deep check-ins versus one with near-constant chatter would plausibly want different debounce windows, and 3 minutes is a guess tuned (reasonably) for one specific real deployment, not necessarily right for others.
What we could do
Expose both as optional config keys with the current 3-minute values kept as defaults, so operators can tune them without patching source.
How we'd test it
Set a custom value in config, confirm via logs/tests that the debounce window used at runtime actually reflects the configured value rather than the hardcoded constant, for both the emotional-state and auto-trace paths independently.
Problem
Both the emotional-state store debounce (
STORE_DEBOUNCE_MS) and the newer auto-trace debounce (TRACE_DEBOUNCE_MS) are hardcoded to 3 minutes each, not exposed via config. Different setups have very different conversation rhythms — a household with sparse, occasional deep check-ins versus one with near-constant chatter would plausibly want different debounce windows, and 3 minutes is a guess tuned (reasonably) for one specific real deployment, not necessarily right for others.What we could do
Expose both as optional config keys with the current 3-minute values kept as defaults, so operators can tune them without patching source.
How we'd test it
Set a custom value in config, confirm via logs/tests that the debounce window used at runtime actually reflects the configured value rather than the hardcoded constant, for both the emotional-state and auto-trace paths independently.