Skip to content

[plan] Expose memory stores to on.steps pre-activation filter for deterministic dispatch decisions #43945

Description

@github-actions

Objective

Make cache-memory, comment-memory, and repo-memory content available to on.steps: (the pre-activation job) so deterministic filter steps can make dispatch/activation decisions based on prior memory state — without an LLM turn.

Context

Issue #43924 describes how on.steps: runs in the pre_activation job (see pkg/workflow/compiler_pre_activation_job.go) but memory stores are only ever restored in the agent job. This forces authors to either burn an LLM turn just to read memory, or duplicate state in a separate actions/cache.

The on.steps: pre-activation job is the natural place for a deterministic "should I activate and what should I do?" filter — but only if it can read persisted memory.

Implementation Plan

Implementation Plan

Files to Modify

  • pkg/workflow/compiler_pre_activation_job.go — inject memory restore steps into the pre-activation job when memory is configured
  • pkg/workflow/cache.go — potentially refactor generateCacheMemorySteps to accept a target builder/context so it can be reused in the pre-activation job
  • Relevant tests — add tests that verify memory restore steps appear in the pre-activation job steps when on.steps: + memory are both configured

Approach

  1. In buildPreActivationJobSteps (in compiler_pre_activation_job.go), when data.CacheMemoryConfig, data.RepoMemoryConfig, or data.SafeOutputs.CommentMemory is set and on.steps is non-empty, emit the corresponding restore steps before the user on.steps entries.
  2. Reuse or extract the same restore step generation functions used by the agent job (generateCacheMemorySteps, generateRepoMemorySteps, comment-memory prepare step) — making them accept a generic target builder or returning step YAML strings.
  3. Ensure the pre-activation job runner environment has the necessary scripts available (they come from the setup action — check whether setup runs in the pre-activation job or only in the agent job).
  4. Make memory restore in on.steps opt-in (only injected when the workflow uses both memory and on.steps), not always-on.
  5. Add tests asserting restore steps precede user on.steps in the pre-activation job.

Acceptance Criteria

  • When a workflow has on.steps: and cache-memory:, cache-memory is restored before on.steps run in the pre-activation job
  • Same for repo-memory and comment-memory
  • Memory restore in pre-activation does not emit write-back/commit steps (read-only surface)
  • Existing on.steps tests continue to pass (make test)
  • New test covers the memory-in-pre-activation scenario
  • make recompile passes

Generated by 📋 Plan Command · 79.6 AIC · ⌖ 11.7 AIC · ⊞ 4.7K · ◷
Comment /plan to run again

  • expires on Jul 8, 2026, 10:39 PM UTC-08:00

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions