[P1] Implement ActivityWatch metadata adapter #16

New issue

Closed

opened 2026-07-18 00:00:17 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-07-18 00:00:17 +00:00

(Migrated from github.com)

Goal

Use an existing local ActivityWatch installation as an optional source of active-window and AFK context.

Requirements

Query only the local ActivityWatch API.
Discover compatible buckets without hard-coding user-specific names.
Normalize application, title, URL-domain where explicitly enabled, and AFK status.
Do not copy ActivityWatch history wholesale; query only the time window needed for capture correlation.
Apply Local Recall redaction and exclusion policies regardless of ActivityWatch’s own storage behavior.
Timeouts and unavailability must degrade to another metadata source.

Acceptance criteria

No ActivityWatch data is sent to a remote provider by default.
Adapter handles absent, stale, malformed, and duplicate events.
URL collection is disabled by default and can be reduced to domain-only.
Contract tests use a synthetic local API fixture.

Depends on

## Goal Use an existing local ActivityWatch installation as an optional source of active-window and AFK context. ## Requirements - Query only the local ActivityWatch API. - Discover compatible buckets without hard-coding user-specific names. - Normalize application, title, URL-domain where explicitly enabled, and AFK status. - Do not copy ActivityWatch history wholesale; query only the time window needed for capture correlation. - Apply Local Recall redaction and exclusion policies regardless of ActivityWatch’s own storage behavior. - Timeouts and unavailability must degrade to another metadata source. ## Acceptance criteria - No ActivityWatch data is sent to a remote provider by default. - Adapter handles absent, stale, malformed, and duplicate events. - URL collection is disabled by default and can be reduced to domain-only. - Contract tests use a synthetic local API fixture. ## Depends on - #13