Phase 4: Drift-watcher framework (per-source-category)

[mickdarling]

Part of MCPAQL/website#32 (Epic: MCPAQL 2026 product launch). Phase 4.

Status: Premature — recorded for durable reference. Activates when ≥10 adapters are in the catalog (need real drift signal).

What

Drift-watcher framework in MCPAQL/tools that detects when an upstream source (MCP server, OpenAPI spec, etc.) has changed in ways that affect existing MCPAQL adapters. Framework approach — per-source-category watchers, reused across all adapters in that category.

Initial watchers:

1. MCP server (polls tools/list, diffs against snapshot)
2. OpenAPI (fetches spec, diffs against snapshot)
3. (Future categories: macOS, SDKs, CLIs)

Why

Adapter drift is the single largest ongoing maintenance burden once the catalog grows. Without proactive detection, customers discover breaks in production. With proactive detection, we patch adapters before customers notice. Build-once-per-category means N source categories need ~N watcher implementations, not N×M per-adapter watchers.

How

• Source-snapshot storage (per-adapter, KV or D1)
• Polling framework (Cloudflare Cron Triggers)
• MCP-server watcher
• OpenAPI watcher
• Diff reporting (new ops, removed ops, schema changes, deprecations)
• Alert flow: customer notification + maintainer ticket
• Auto-regenerate on safe changes (additions); flag for review on breaking changes

Phase

4 (month 3).