repo-assist: Task 8 (Monthly Activity Summary) does not run deterministically despite being marked mandatory

Inizia con repo-assist.md Task 8, quindi confronta le sette esecuzioni del workflow collegate, le relative tracce, i manifesti di safe-outputs e state.json con la cronologia dell’issue #50956. Determina dove l’aggiornamento obbligatorio può essere saltato o eliminato silenziosamente; completato significa che Task 8 viene eseguito in modo deterministico e che un output non riuscito o mancante viene rilevato o ritentato.

Summary

In repo-assist.md, Task 8 (Update Monthly Activity Summary Issue) is documented as mandatory every run:

"Always do Task 8 (Update Monthly Activity Summary Issue) every run."

In practice, on the tenstorrent/tt-metal deployment, it is not running deterministically. Over the last 7 daily scheduled runs (2026-07-24 through 2026-07-30, all completed successfully), the monthly summary issue (#50956) was only actually updated on 2 of them.

Evidence

Issue #50956's updated_at has been stuck at 2026-07-27T07:02:56Z since — three consecutive daily runs produced zero visible output on it, despite each run's own reasoning trace explicitly citing "Task 8" as a planned step.

Root cause (best guess)

"Always do Task 8" is a prose instruction competing for attention/turn budget against the round-robin task selection in the same prompt, not a structurally-guaranteed step in the compiled workflow. Nothing fails or flags the run if the write doesn't happen. The agent's own repo-memory (state.json) isn't validated against ground truth either — it records task8_monthly_summary: done even on runs where no comment/edit actually reached the issue. On 07-24, the update_issue safe-output specifically appears to fail silently (logged as processed, but no visible effect and no error).

Question

Is there a supported pattern for making a task like this deterministic — e.g.:

• Splitting it into its own workflow/job that always runs, decoupled from the round-robin agent turn
• A safe-outputs guarantee/verification step that fails the run (or retries) if a declared "always do" output type wasn't actually emitted
• Reconciling agent-reported state.json progress against actual GitHub state rather than trusting the agent's self-report

Happy to help test a fix if there's a preferred approach.