Roadmap #57, Phases 1–4 (complete). Vestige can now act as a durable, local, semantically-searchable retrieval layer over an external system of record — GitHub Issues and Redmine — without replacing it. The external system stays canonical; Vestige indexes, connects, retrieves, and cites back to the source record.

Unlike a live ticket-system MCP proxy (stateless, rate-limited per query, online-only), Vestige keeps a durable embedded index: searchable offline, semantically, joinable with the rest of your memory, temporally versioned, and re-syncable idempotently with no duplication.

Highlights

• source_sync MCP tool — index a GitHub repo ({"source":"github","repo":"owner/name"}) or Redmine project ({"source":"redmine","project":"<id>"}). Re-running updates changed issues in place (no duplicates); reconcile:true tombstones issues removed upstream. Tokens read from env only (GITHUB_TOKEN, REDMINE_URL/REDMINE_API_KEY).
• Source-aware investigation filters on search — by source_system, source_project, source_id, source_type, source_author, an updated-at date range, and source_status (valid/tombstoned/any).
• Source envelope on every connector memory (system, id, URL, content hash, project, type, author) — search results cite the canonical record URL.
• Migration V17 — additive provenance columns + a partial UNIQUE index (one memory per external record) + connector cursor checkpoints. Existing memories untouched.

Local-first and optional: with no source_sync call, behavior is unchanged. The connector HTTP client is on by default in the MCP server and off in the core library's default features.

See CHANGELOG.md and docs/CONNECTORS.md for full details.