[Feature]: per-connector schedules (targeted cron pause/resume/delete)

[colifran]

Summary

Support scheduling connectors independently so openwiki cron pause|resume|delete can target a single connector, not just all.

Motivation

Today OpenWiki keeps a single unified schedule (config.ingestionSchedule) backed by one OS-level job that ingests every enabled connector together. So openwiki cron pause|resume|delete is all-or-nothing — you can't pause just one connector.

This matters in practice:

• Temporarily silence one noisy or rate-limited source (e.g. pause Slack ingestion) while keeping the rest (git-repo, web-search) running on schedule.
• Stop an expensive connector without disabling your whole documentation pipeline.
• Give different connectors different cadences (e.g. git-repo hourly, web-search daily).

There's also an inconsistency users hit: openwiki ingest <source|all> is per-source (on-demand), so people reasonably expect cron to be too. The cron help even advertised <source|all> until #307 aligned it down to all to match what the implementation actually supports.

Proposed Solution

Introduce per-connector schedules so each connector can be scheduled and paused/resumed/deleted independently.

Likely scope (this is a feature, not a small fix):

• Data model: replace the single ingestionSchedule with per-connector schedule entries, keyed by connector id / source-instance.
• Installation & reconciliation: manage one OS-level job per scheduled connector instead of a single shared job (launchd on macOS, and the other supported platforms).
• Command layer: cron pause|resume|delete <source|all> targets one connector or all; cron list reports per-connector status.
• Migration: existing single-schedule configs migrate transparently; all keeps working.

Acceptance criteria:

• openwiki cron pause web-search pauses only that connector; others keep running.
• cron list shows per-connector state.
• all still applies to every connector.
• Existing configs migrate with no manual steps.

Alternatives Considered

No response

Additional Context

• fix: align cron schedule target help #307 aligned the cron help/parser down to all (the honest short-term fix) after it previously advertised <source|all> that never worked.
• Current behavior lives in src/schedules.ts: pauseConnectorSchedules/resumeConnectorSchedules/deleteConnectorSchedules all short-circuit unless target === "all", because there is only one config.ingestionSchedule to act on.
• The per-source ingest command (src/commands.ts, parseIngestionTarget) is the asymmetry that makes users expect per-source cron.

[himanshu231204]

/claim

[himanshu231204]

Implementation Complete

PR: #438 — feature/per-connector-schedules

---

What changed

Per-connector schedules so openwiki cron pause|resume|delete <source> targets a single connector, not just all.

Core changes:

• src/onboarding.ts — preserve sourceInstances[].schedule during normalization; migrate global ingestionSchedule to per-source instances
• src/commands.ts — accept <source|source-instance|all> for cron pause/resume/delete
• src/schedules.ts — rewrite list/pause/resume/delete to operate on individual source instances; per-connector launchd labels (com.openwiki.ingestion.<source-instance-id>)
• src/ingestion.ts — check per-source schedule.pausedAt instead of global
• src/cli.tsx — validate source-instance targets; show per-source results
• src/credentials.tsx — pass sourceInstanceId to installConnectorSchedule

Tests (4 files, 76 passing):

• test/commands.test.ts — updated cron tests to accept per-source targets
• test/schedules.test.ts — new per-connector schedule operation tests
• test/ingestion-scheduling.test.ts — new per-source scheduledOnly filtering tests
• test/onboarding.test.ts — migration and schedule preservation tests

---

Acceptance criteria

Criterion	Status
openwiki cron pause web-search pauses only that connector	✅
cron list shows per-connector state	✅
all still applies to every connector	✅
Existing configs migrate with no manual steps	✅
All tests pass	✅
Launchd jobs are per-connector	✅

---

Migration path

Existing single-schedule configs are handled automatically — normalizeOnboardingConfig copies the global schedule to every source instance on first read. No manual intervention required.