Throttle GitHub workflow sync to completion-based cadence

Context

Operator observed ProcessSupervisor logs for github workflow sync showing periodic-sync:1800000 and flagged that the sync feels like it runs every 10-20 minutes. The live task is expensive: the operator notes the GitHub workflow sync is roughly a 20-minute task duration, so a 30-minute start-to-start cadence leaves only about 10 minutes of quiet time.

Release classification: post-release/agent-OS stability; not a v13 release-board blocker by itself.

Live latest-open sweep: checked latest 20 open issues at 2026-06-21T23:41Z; no equivalent completion-cooldown/cadence ticket found. Related tickets present: #13626 wired the scheduled task, #13750 diagnosed Golden Path freeze/sync interaction, and #13624 covers the broader orchestrator heavy-maintenance drain issue.

A2A in-flight sweep: checked latest 30 A2A messages at 2026-06-21T23:41Z; no competing lane-claim or lane-intent for this exact cadence fix.

The Problem

githubWorkflowSync is currently configured as a 30-minute periodic task, but the scheduler measures that cadence from lastRunAt, which is recorded at task start. For a task that runs around 20 minutes, the effective quiet time after completion is about 10 minutes:

• start at T+0m
• complete around T+20m
• eligible again at T+30m
• quiet after completion: roughly 10m

That is too aggressive for a heavyweight GitHub content sync and contributes to local resource drain while the orchestrator is already under heavy-maintenance pressure.

The Architectural Reality

• ai/config.mjs and ai/config.template.mjs set githubWorkflowSyncMs to 30 * 60 * 1000 via NEO_ORCHESTRATOR_GITHUB_WORKFLOW_SYNC_INTERVAL_MS.
• ai/daemons/orchestrator/scheduling/registry.mjs makes githubWorkflowSync due when now - state.githubWorkflowSync.lastRunAt >= intervals.githubWorkflowSync.
• ai/daemons/orchestrator/services/TaskStateService.mjs sets lastRunAt = Date.now() in markStarted(), while lastSuccessAt is only written in markCompleted() / markReady().
• The Knowledge Base confirms #13626 documented this as intervalMs > 0 && now - lastRunAt >= intervalMs; no separate completion cooldown exists for this lane.

The Fix

1. Increase the default githubWorkflowSyncMs from 30 minutes to 2 hours. Keep the env var override intact so local operators can choose 1 hour if desired.
2. Change the githubWorkflowSync due calculation to prefer a terminal timestamp (lastSuccessAt or lastErrorAt) over lastRunAt so the cadence is effectively finish-to-start for this expensive child task.
3. Preserve bootstrap behavior: if no terminal timestamp exists, fall back to lastRunAt and then 0.
4. Add focused scheduler tests proving:
   • a completed 20-minute run is not due 30 minutes after start when the completion timestamp is only 10 minutes old;
   • the task becomes due after the configured completion cooldown elapses;
   • failed terminal timestamps also cool down the retry loop.
5. Update the config default test from 30 minutes to 2 hours.

Contract Ledger

Decision Record impact

Aligned with ADR 0019 (config SSOT) and ADR 0022 (heavy-maintenance scheduling fairness). This narrows one heavy-maintenance lane's cadence semantics without changing the overall scheduler taxonomy.

Acceptance Criteria

• githubWorkflowSyncMs defaults to 2 hours in both materialized and template config.
• githubWorkflowSync does not become due until the configured interval has elapsed after the latest terminal timestamp when one exists.
• failed terminal attempts also cool down retries instead of immediately re-entering a tight expensive loop.
• bootstrap / never-completed state still remains schedulable via lastRunAt / 0 fallback.
• Focused unit tests cover config default and scheduler cadence behavior.

Out of Scope

• Changing KB sync, primary-dev-sync, tenant-repo-sync, dream, or golden-path cadence.
• Redesigning the heavy-maintenance picker or lease semantics.
• Reworking GitHub sync content phases or incremental sync internals.
• Operator-local env override decisions beyond preserving the existing env var.

Avoided Traps

• Do not just raise the interval while keeping start-to-start semantics; long runtimes would still eat most of the quiet period.
• Do not apply completion-based cadence globally without auditing each task. Some lanes intentionally schedule from attempt/start time.
• Do not disable GitHub workflow sync entirely; #13750 shows stale graph/content sync can also derail the system.

Related

Related: #13626 Related: #13750 Related: #13624

Origin Session ID: 43e8ab91-e980-4303-b70f-898d8c4ae98e

Retrieval Hint: github workflow sync cadence start-to-start completion cooldown lastRunAt lastSuccessAt periodic-sync:1800000