Skip to content

Separate bundle flow seeds from live runtime overlays #1844

@chubes4

Description

@chubes4

Problem

Agent bundle upgrade previews currently diff one persisted flow artifact that mixes two different ownership domains:

  • bundle-owned seed config: source lane defaults, handler/source params, schedule seed, package versioned intent
  • live runtime state: prompt/config patch queues, queue mode, consumed queue revision, burn-in throttles, local schedule posture

This makes legitimate site-local burn-in/runtime changes appear as package drift. Even with --rebase-local --policy=burn-in-safe, operators still get noisy PendingActions because the planner is trying to merge seed config and runtime overlays inside one payload.

Current symptom

On intelligence-chubes4, wordpress-com-wiki bundle upgrades correctly apply clean pipeline/package changes, but still stage approval-required flow artifacts for live Flow 2/10/11 because runtime state differs from the packaged seed:

  • config_patch_queue
  • queue_mode
  • _queue_consume_revision
  • local max_items: 1 burn-in throttles
  • paused/manual scheduling posture

These are not necessarily package drift. They are runtime overlays.

Desired direction

Make runtime overlays first-class so a bundle flow artifact can remain stable while the site carries local runtime state separately.

Conceptually:

bundle flow seed
  package-owned defaults and source-lane intent

runtime overlay
  site-local queue/schedule/throttle/consume state

effective flow
  derived seed + overlay for execution

Acceptance shape

  • Bundle upgrade planning can distinguish package drift from runtime overlay drift.
  • Runtime queues and consumed revisions do not force bundle artifact approval.
  • Burn-in safety throttles can be intentionally preserved without making future upgrades noisy.
  • Operators can still preview runtime overlay drift when they ask for it.
  • Existing burn-in-safe rebase behavior remains a bridge, but becomes less central once overlays are explicit.

Related context

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions