[q] Switch Daily Storify mined-loop persistence from cache-memory to repo-memory - #55394
Conversation
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
@copilot resolve the merge conflicts on this branch. |
There was a problem hiding this comment.
Pull request overview
Moves Daily Storify’s long-term state from expiring cache memory to Git-backed repo memory.
Changes:
- Redirects Storify state files to repo-memory.
- Adds generated clone, artifact, and push wiring.
- Updates prompt guidance for durable persistence.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/daily-storify.md |
Enables and documents repo-memory storage. |
.github/workflows/daily-storify.lock.yml |
Adds compiled repo-memory runtime jobs. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 2
- Review effort level: Balanced
| - `/tmp/gh-aw/repo-memory/default/storify/state.json` | ||
| - `/tmp/gh-aw/repo-memory/default/storify/episodes.jsonl` | ||
| - `/tmp/gh-aw/repo-memory/default/storify/loops.jsonl` |
There was a problem hiding this comment.
Addressed in 79e7d5d. shared/aw-logs-24h-fetch.md still sets cache-memory: true, so /tmp/gh-aw/cache-memory is still restored alongside repo-memory — the legacy state is available at cutover. Added a one-time migration step to the start-up sequence that copies each of the three files from /tmp/gh-aw/cache-memory/storify/ only when the repo-memory target is missing, never overwriting an existing repo-memory file. After the first run persists them to the memory branch, the migration is a no-op.
Kept this in the workflow's own prompt rather than editing the shared import, since shared/aw-logs-24h-fetch.md is consumed by other workflows. Lock file recompiled (the body is runtime-imported, so this shows up as a body_hash change).
There was a problem hiding this comment.
Correction: the commit is 9c28e1d, not 79e7d5d.
| tools: | ||
| agentic-workflows: | ||
| cache-memory: true | ||
| repo-memory: true |
There was a problem hiding this comment.
Fixed in 79e7d5d. Replaced the boolean form with an object config carrying exact relative globs:
repo-memory:
file-glob:
- "storify/state.json"
- "storify/episodes.jsonl"
- "storify/loops.jsonl"Recompiled, and the generated push job now emits FILE_GLOB_FILTER: "storify/state.json storify/episodes.jsonl storify/loops.jsonl" instead of an empty filter, so the contents: write path on memory/daily-storify only accepts those three files. GH_AW_MEMORY_CONSTRAINTS also now surfaces the allowed-file list to the agent.
There was a problem hiding this comment.
Correction: the commit is 9c28e1d, not 79e7d5d.
|
@copilot this PR still needs forward progress. Please refresh the branch, resolve the remaining merge state, and then run the Run: https://github.com/github/gh-aw/actions/runs/32748984422
|
…ecompile daily-storify lock Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Merge conflicts resolved in 7478f87 (merge) + f20babb. The only conflict was in the generated |
…gacy cache state Co-authored-by: gh-aw-bot <259018956+gh-aw-bot@users.noreply.github.com>
Daily Storify currently persists mined loop state in
cache-memory, which can expire and break continuity across runs. This change moves Storify’s persistence torepo-memoryso loop taxonomy and historical context remain durable.Workflow configuration
.github/workflows/daily-storify.mdtool config fromcache-memorytorepo-memory.repo-memorypattern.Persistence path migration
state.jsonepisodes.jsonlloops.jsonlCompiled workflow sync
.github/workflows/daily-storify.lock.ymlso runtime wiring matches the markdown source (repo-memory bootstrap/push flow and prompt template inputs).