[plan] Add memory restore support to custom jobs: via a restore-memory step injection

[github-actions]

Objective

Allow custom jobs: defined in workflow frontmatter to declare that they need read access to memory stores (cache-memory, repo-memory, comment-memory), so a deterministic orchestrator job can compute a dispatch list from memory without the agent job.

Context

Issue #43924 describes the ideal OrchestratorOps pattern: a scheduled deterministic job reads cache-memory (e.g., { "<pr>": "<last-reviewed-sha>" }), diffs against current state, builds a dispatch list, then fan-outs. Today this is impossible because memory stores are exclusively restored in the agent job.

Custom jobs: are defined in the jobs: frontmatter section and compiled by pkg/workflow/compiler_custom_jobs.go. They currently support setup-steps, steps, pre-steps, and needs: — but no mechanism to inject memory restore steps.

Implementation Plan

Implementation Plan

Files to Modify

• pkg/workflow/compiler_custom_jobs.go — detect a new optional memory: or restore-memory: field on custom job configs, and inject the corresponding restore steps before the user steps:
• pkg/workflow/cache.go — refactor/extract restore-only variants of generateCacheMemorySteps and generateRepoMemorySteps that do not emit write-back steps, for reuse in custom jobs and pre-activation
• Schema/docs — update the custom jobs schema if applicable
• Tests — add a test verifying that a custom job with memory: cache-memory gets the restore step injected

Approach

1. Design the frontmatter shape. A minimal option: custom jobs support a restore-memory: true (or a list of store names) field that opts in to memory restore injection. Alternatively, auto-inject when memory is configured and the job does not explicitly opt out.
2. In buildCustomJob (in compiler_custom_jobs.go), check for the memory-restore opt-in and prepend memory restore steps before the job's user steps:.
3. Extract a read-only restore step generator from generateCacheMemorySteps / generateRepoMemorySteps (these currently also emit git integrity setup steps that are agent-specific). The extracted version should only emit the actions/cache restore step and directory creation.
4. For comment-memory, emit the "Prepare comment memory files" step before user steps (token must be available — ensure the custom job has github-token access).
5. Add a compiler validation error if a custom job tries to write to memory (guard against misuse).

Notes

• Memory restore in custom jobs is read-only — write-back/commit steps must not be injected. Only the agent job writes back to memory.
• Related to issue Allow frontmatter to augment the needs list of any compiler-generated job #43918 (needs-wiring for compiler-generated jobs): if a restore-memory job is introduced as a shared job in the future, custom jobs could needs: it instead of each injecting their own restore steps.

Acceptance Criteria

• A custom jobs: entry can opt into reading cache-memory content at its documented path
• Same for repo-memory and comment-memory
• No write-back/commit steps are emitted for memory in custom jobs
• Compiler validation rejects custom jobs that attempt to write to memory
• Existing custom jobs tests continue to pass (make test)
• New test covers custom job with memory restore
• 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

[github-actions]

🍪 Issue Monster selected this for Copilot

I have identified this issue as a good candidate for automated resolution and requested assignment to the Copilot coding agent.

If assignment succeeds, the Copilot coding agent will analyze the issue and create a pull request with the fix.

Om nom nom! 🍪

🍪 Om nom nom by Issue Monster · 1.69 AIC · ⌖ 4.03 AIC · ⊞ 3.6K · ◷