Expose memory stores to on.steps in pre-activation for deterministic dispatch gating

.github/workflows/daily-cli-performance.md

@@ -3,6 +3,7 @@ private: true
 emoji: "⚡"
 description: Daily CLI Performance - Runs benchmarks, tracks performance trends, and reports regressions
 on:
+  restore-memory: true
   schedule: daily
   workflow_dispatch:
   permissions:

.github/workflows/smoke-codex.md

@@ -3,6 +3,7 @@ private: true
 emoji: "🧪"
 description: Smoke test workflow that validates Codex engine functionality by reviewing recent PRs twice daily
 on:
+  restore-memory: true
   slash_command:
     name: smoke-codex
     strategy: centralized

.github/workflows/smoke-copilot.md

@@ -2,7 +2,8 @@
 private: true
 emoji: "🧪"
 description: Smoke Copilot
-on: 
+on:
+  restore-memory: true
   slash_command:
     name: smoke-copilot
     strategy: centralized

docs/adr/44015-expose-memory-stores-to-on-steps-pre-activation.md

@@ -0,0 +1,48 @@
+# ADR-44015: Expose Memory Stores to `on.steps` in Pre-Activation
+
+**Date**: 2026-07-07
+**Status**: Draft
+**Deciders**: Unknown
+
+---
+
+### Context
+
+The gh-aw workflow engine compiles workflows into a `pre_activation` job and an agent job. Custom dispatch-gating steps defined via `on.steps` execute in `pre_activation`, but all three memory stores (cache-memory, repo-memory, comment-memory) were previously only restored in the agent job. This meant that any `on.steps` logic requiring prior memory state — for example, a gate step that reads a cached value to decide whether to proceed — either had to forgo memory access or consume an additional LLM turn in the agent phase to hydrate state. The inability to access memory in pre-activation limited the expressiveness of deterministic, non-LLM dispatch gates.
+
+### Decision
+
+We will restore all configured memory stores (cache-memory, repo-memory, comment-memory) in the pre-activation job before `on.steps` gates execute. The restore is **read-only**: it reuses the existing restore/load paths for each memory type and does not add cache-commit or repo-push write-back steps to pre-activation. Hydration is gated on the presence of `on.steps` in the workflow definition so that workflows without custom steps are unaffected.
+
+### Alternatives Considered
+
+#### Alternative 1: Execute `on.steps` in the Agent Job Instead of Pre-Activation
+
+Move the `on.steps` execution point from `pre_activation` to the agent job, where memory is already available.
+
+This would avoid the need to restore memory in a second location, but it would break the architectural contract that `on.steps` runs before the LLM is invoked. The entire purpose of `on.steps` is to gate activation deterministically and cheaply; running it in the agent job would consume a full LLM turn even when the gate rejects the request, negating the cost benefit.
+
+#### Alternative 2: Require Workflows to Declare Their Own Memory Restoration Steps
+
+Leave pre-activation unchanged and let workflow authors manually add memory restore steps before their `on.steps` gates via explicit YAML.
+
+This avoids centralizing the restore logic in the compiler, but it places the burden on every workflow author to know the correct restore incantation for each memory type. It also creates drift risk: if the restore steps change, all affected workflows must be updated. The compiler already owns the pattern for generating memory steps; extending it is the consistent approach.
+
+### Consequences
+
+#### Positive
+- `on.steps` gates can now read prior memory state to make deterministic dispatch decisions without spending an LLM turn.
+- Reusing the existing restore/load paths ensures memory-type-specific details (branch names, cache keys, token handling) remain in a single authoritative location.
+- The read-only constraint prevents pre-activation from accidentally mutating memory, preserving the invariant that only the agent job writes back.
+
+#### Negative
+- Every pre-activation run for a workflow with `on.steps` now executes additional restore steps, adding latency even when the gate does not use memory.
+- The pre-activation job compiler gains a new code path (`buildPreActivationMemoryRestoreSteps`), increasing the surface area that must be maintained as memory store implementations evolve.
+
+#### Neutral
+- The change is scoped to workflows that define `on.steps`; workflows without `on.steps` are compiled identically to before.
+- The `.github/workflows/daily-cli-performance.lock.yml` lock file is regenerated as a side effect of the compiler change, reflecting the new restore step.
+
+---
+
+*ADR created by [adr-writer agent]. Review and finalize before changing status from Draft to Accepted.*

docs/src/content/docs/reference/frontmatter.md

@@ -79,6 +79,7 @@ The `on:` section uses standard GitHub Actions syntax to define workflow trigger
 - `skip-if-match:` - Skip execution when a search query has matches (supports `scope: none`; use top-level `on.github-token` / `on.github-app` for custom auth)
 - `skip-if-no-match:` - Skip execution when a search query has no matches (supports `scope: none`; use top-level `on.github-token` / `on.github-app` for custom auth)
 - `steps:` - Inject custom deterministic steps into the pre-activation job (saves one workflow job vs. multi-job pattern)
+- `restore-memory:` - Opt in to restoring memory stores before `on.steps` in pre-activation (default: `false`)
 - `permissions:` - Grant additional GitHub token scopes to the pre-activation job (for use with `on.steps:` API calls)
 - `needs:` - Add custom job dependencies that both `pre_activation` and `activation` must wait for
 - `github-token:` - Custom token for activation job reactions, status comments, and skip-if search queries

docs/src/content/docs/reference/triggers.md

@@ -682,6 +682,7 @@ Inject custom deterministic steps directly into the pre-activation job. Steps ru
 on:
   issues:
     types: [opened]
+  restore-memory: true
   steps:
     - name: Check issue label
       id: label_check
@@ -708,6 +709,8 @@ if: needs.pre_activation.outputs.has_bug_label == 'true'
 
 Explicit outputs in `jobs.pre-activation.outputs` take precedence over auto-wired `<id>_result` outputs on key collision.
 
+Set `on.restore-memory: true` to restore memory stores (`cache-memory`, `repo-memory`, `comment-memory`) before `on.steps` run. The default is `false`.
+
 ### Pre-Activation and Activation Dependencies (`on.needs:`)
 
 Add custom jobs that both `pre_activation` and `activation` should depend on. Use this when `on.github-app` credentials come from a job output (for example, a secret-manager fetch job).

pkg/parser/schemas/main_workflow_schema.json

@@ -2152,6 +2152,10 @@
               "default": [],
               "examples": [["secrets_fetcher"]]
             },
+            "restore-memory": {
+              "type": "boolean",
+              "description": "When true, restore cache-memory, repo-memory, and comment-memory stores before on.steps in pre_activation. Defaults to false."
+            },
             "steps": {
               "type": "array",
               "description": "Steps to inject into the pre-activation job. These steps run after all built-in checks (membership, stop-time, skip-if, etc.) and their results are exposed as pre-activation outputs. Use 'id' on steps to reference their results via needs.pre_activation.outputs.<id>_result.",