discussion-task-miner: repo-memory never persists — Step 1/6 write to a subdirectory excluded by the default file-glob

[yskopets]

🤖 This issue was researched and written by Claude Code (Anthropic's CLI agent), while debugging a downstream copy of this workflow.

Summary

The discussion-task-miner workflow's repo-memory never persists across runs. Its dedup state (processed-discussions.json / extracted-tasks.json) is written to a subdirectory of the repo-memory root, but the file-glob configured by shared/repo-memory-standard.md only matches files at the root. push_repo_memory silently skips the nested files, so every run starts from empty history, re-mines the same recent discussions, and opens duplicate issues.

Runs still report success — the only visible symptom is that the memory/discussion-task-miner branch quietly stops advancing.

Affected files (on main)

• .github/workflows/discussion-task-miner.md — Step 1 (Load Memory) and Step 6 (Update Memory) read/write nested paths:

  memory/discussion-task-miner/processed-discussions.json
  memory/discussion-task-miner/extracted-tasks.json
  memory/discussion-task-miner/latest-run.md
  

• .github/workflows/shared/repo-memory-standard.md — configures a root-anchored glob:

  tools:
    repo-memory:
      file-glob: ["*.json", "*.jsonl", "*.csv", "*.md"]

Mechanism

push_repo_memory matches each candidate file's path relative to the repo-memory directory against the glob, and *.json compiles to a root-anchored regex ^[^/]*\.json$ — [^/]* cannot cross a /. The memory files the prompt writes land in a subdirectory of the repo-memory root (the agent resolves the relative memory/discussion-task-miner/… under …/repo-memory/<id>/), so they never match. The job log shows:

##[warning]Skipping file that does not match allowed patterns: discussion-task-miner/extracted-tasks.json
...
No changes detected after copying files

→ nothing is committed. Only files written flat at the repo-memory root are eligible for persistence.

Secondary issue: the prompt uses cat > memory/discussion-task-miner/<file>, which requires the subdirectory to already exist. mkdir is commonly outside the workflow's bash allowlist (I saw mkdir … was blocked), so these bash writes fail unless the agent happens to fall back to a file-write tool that creates parent dirs. Combined with the glob mismatch, persistence is doubly unreliable.

Impact

• Silent. Runs succeed; the memory branch just stops advancing (in the case I debugged, it was frozen ~10 days while daily runs kept "succeeding").
• Dedup depends entirely on that memory, so the miner re-processes the same last-N-days discussions each run and files duplicate issues — I observed the identical dependency-upgrade task issued twice, days after a PR had already merged the change.

Reproduce

1. Run discussion-task-miner (or any workflow importing shared/repo-memory-standard.md whose prompt writes memory under a memory/<name>/… subdirectory).
2. Inspect the push_repo_memory job log → Skipping file that does not match allowed patterns: <name>/… followed by No changes detected.
3. Observe the memory/<branch> branch does not advance even though the agent reported updating memory.

Suggested fix

Preferred — write memory flat at the repo-memory root. In Step 1/6, replace memory/discussion-task-miner/<file> with the repo-memory root (/tmp/gh-aw/repo-memory/<id>/<file>; default for a single memory), and add an explicit note that memory files must be stored flat at the root (no subdirectories, no mkdir) because only top-level files match the persist glob. This mirrors the fix already applied to copilot-pr-prompt-analysis in #40547, which moved history to repo-memory/default/ flat.

Alternative — keep the nested layout but make the glob match it, e.g. file-glob: ["discussion-task-miner/*.json", "discussion-task-miner/*.md"] (as some namespaced-memory workflows already do), and ensure the subdirectory is creatable. This is more fragile: it re-breaks silently if the glob and the paths ever drift, and it still needs the mkdir/parent-dir path to work.

Note

This likely affects any template that pairs shared/repo-memory-standard.md (root-anchored glob) with nested memory/<name>/… paths in the prompt body — worth a grep across the workflow set. Related prior instance of the same repo-memory-path class of bug: #40547.

Happy to send a PR for the flat-path fix if it'd help.

[yskopets]

🤖 This comment has been generated by Claude Code.

First-party corroboration from this repository's own Actions history. To be upfront: this is config + branch-state evidence, not a captured per-run trace — the relevant logs have aged out (see caveat) — so it is consistent with the failure mode rather than a direct capture of it.

• discussion-task-miner.lock.yml was deployed and scheduled in this repo (cron: "40 */6 * * *") and ran 103 times between 2026-01-09 and 2026-02-09 (99 success, 4 failure), after which the workflow was set to disabled_manually.
• Despite ~100 successful runs, there is no memory/discussion-task-miner branch in this repo — whereas 27 other memory/* branches do exist for sibling agentic workflows (memory/audit-workflows, memory/prompt-analysis, memory/token-audit, memory/code-metrics, memory/daily-news, …). push_repo_memory creates the branch on the first successful persist, so its absence across 100+ runs is what you'd expect if the memory files never matched the persist glob and were never committed — exactly the mechanism above. (Step 6 writes memory every run, including no-op runs, so a persisting workflow should have created the branch on run rejig docs #1.)

Caveat: those runs predate Actions' ~90-day log retention, so I can't attach the actual Skipping file … does not match allowed patterns / No changes detected after copying files lines from them. Re-enabling the workflow for a single workflow_dispatch would surface that log directly, if a maintainer wants a live capture.

For what it's worth, on a downstream copy I fixed this exact issue by moving the Step 1/6 memory files to the repo-memory root (flat) and adding an explicit "store flat, no subdirectories" instruction. After the change, push_repo_memory reported Successfully pushed instead of No changes detected, and the memory branch — which had been frozen for ~10 days while daily runs kept "succeeding" — began advancing again. Happy to open a PR here with the same fix.

[pelikhan]

@copilot fix file glob filter logic to match subfolder containing memory as root