Adaptive watcher exclusions: learn from repeated heuristic rejections

[CalebisGross]

Problem

Even with good defaults (#26) and auto-detection (#27), novel noise sources will always appear — a new app the user installs, a build tool that writes temp files to an unexpected path, a game launcher, etc. The system should learn to ignore these without manual config edits.

Currently, the heuristic filter correctly rejects these events (score 0.0), but each rejection still costs: the watcher fires the event, the perception agent processes it, the heuristic evaluates it, and an INFO log line is written. In one session, VS Code alone generated 948 rejected events before we added it to the exclusion list.

Proposal

Add a feedback loop from the heuristic filter to the watcher: if events from the same path prefix are repeatedly rejected, automatically promote that prefix to a watcher exclusion.

How it works

Tracking phase — In the heuristic filter, maintain a rolling counter of rejections per path prefix:

type rejectionTracker struct {
    mu       sync.Mutex
    counts   map[string]int       // path prefix → rejection count
    firstSeen map[string]time.Time // path prefix → first rejection time
}

Path prefix extraction: for a path like ~/.config/Code/WebStorage/QuotaManager-journal, extract ~/.config/Code/ (2 levels deep from a known base like ~/.config/ or ~/.local/share/).

Promotion threshold — When a prefix hits N rejections (e.g., 50) within a time window (e.g., 1 hour), it's a candidate for exclusion.

Promotion action:

1. Add the prefix to the watcher's in-memory exclusion list (immediate effect)
2. Log at INFO: "Auto-excluded noisy path: ~/.config/NewApp/ (52 rejections in 45 minutes)"
3. Publish an event: events.WatcherExclusionLearned{Prefix: "...", Rejections: 52}
4. Optionally persist to a file (e.g., ~/.mnemonic/learned-exclusions.yaml) so it survives restarts
5. The metacognition agent can observe these events and log them as meta-observations

Safety rails:

• Never auto-exclude paths inside the user's home project directories (detected from config.yaml watch_paths or git repos)
• Never auto-exclude paths that have ALSO produced accepted events (mixed signal/noise paths need the heuristic, not blanket exclusion)
• Cap at 20 auto-exclusions per session to prevent runaway
• User can review and override in ~/.mnemonic/learned-exclusions.yaml

Architecture

This lives primarily in the perception agent, bridging heuristic → watcher:

Watcher → Perception Agent → Heuristic Filter
                                  ↓ (rejection)
                            Rejection Tracker
                                  ↓ (threshold hit)
                            Watcher.AddExclusion()
                                  ↓
                            Event Bus (WatcherExclusionLearned)
                                  ↓
                            Metacognition (observes)

The watcher interface needs one new method:

AddExclusion(pattern string) // adds a runtime exclusion pattern

Interaction with other tiers

This is tier 3 of the noise suppression stack:

Tier	When	What	Catches
1. Static defaults	Always	config.yaml patterns	Known noisy apps (Chrome, VS Code, GNOME...)
2. Auto-detect	First startup	Scan installed apps	Installed apps not in defaults
3. Adaptive learning	Runtime	Heuristic rejection feedback	Novel noise sources, new installs, unexpected paths

Each tier handles what the previous tiers missed. Together they mean a new user gets good filtering from minute one, and the system gets smarter over time without manual intervention.

Metrics

The quality benchmark (#24) should include a scenario that tests this: inject events from an "unknown" noisy app prefix, verify that after enough rejections the watcher stops seeing them.

Related

• PR Add Linux desktop app exclusions to watcher config #26 — Static Linux desktop exclusions (tier 1)
• Auto-detect noisy app directories at first startup #27 — Auto-detect noisy app directories at startup (tier 2)
• Memory quality benchmark: scenario-based IR metrics with publishable report #24 — Quality benchmark (should test this)