Jules reviewer flags current dates as "future date" typos, repeatedly and unpersuadably

[dem-extra1]

Symptom

The Jules reviewer (.github/workflows/jules-review.yml, added in 348d948) reports today's date as a future-dated typo, and re-reports it every round regardless of rebuttal.

On #365, across three separate reviews on three different head commits:

CLAUDE.md, line 972: The date 2026-07-29 is in the future and appears to be a typo (likely for 2024-07-29 or similar).

CLAUDE.md, line 983: The date 2026-07-29 is in the future and appears to be a typo (likely meant to be 2024-07-29 or similar).

CLAUDE.md, line 989: The date "2026-07-29" in the example log appears to be a typo for a future date (likely 2024-07-29).

The date is correct. It is today. Three independent confirmations:

1. The cited run's own API timestamp: run 30471653690 has "created_at": "2026-07-29T16:38:18Z".
2. main's CLAUDE.md already carries 2026-07-24 and 2026-07-12 in pre-existing entries.
3. c50e847 (Retarget the built-in ai-config plugin ref to the Morrison-Lab marketplace #359), which the new section documents, is itself dated 2026-07-29.

Why this matters beyond one PR

Two properties make it more than a one-off annoyance:

• It will fire on essentially every PR here. This repo's CLAUDE.md convention is to date each entry with the day it was learned, and changelog.d/ fragments do the same. Every such entry is a standing trigger.
• It survives rebuttal. A detailed rebuttal with three citations was posted after round 1; rounds 2 and 3 re-raised the identical finding without engaging it. So it is not self-correcting, and each round costs a reply.

The likely mechanism is that the model's training cutoff predates the current date, so it treats any later date as impossible rather than as information it lacks. That is a property of the reviewer, not of the diff — which is exactly why it can't be fixed on our side by rewording.

Note this is the same class of error the Claude reviewer's own prompt already guards against for product names ("don't assume it's fabricated just because it's unfamiliar --- your training data has a cutoff"). Dates need the same carve-out and don't have one here.

Options

1. Inject the current date into the Jules prompt, if jules-review.yml exposes a prompt/context input, so it has a reference point instead of inferring one.
2. Instruct it to treat dates as out of scope unless internally inconsistent with another date in the same diff.
3. Accept as known noise and document it, so future sessions rebut once and hold rather than re-litigating. (That is what #365 did.)
4. Report upstream to Google. Not done autonomously, per upstream-issues --- filing here instead so someone can decide whether to escalate.

Worth checking whether the newer gemini-code-review.yml / ai-code-review.yml reviewers in #357 share the behavior before #363 wires them up, since that would multiply the noise.

Found while driving #365 to clean.

[dem-extra1]

The remedy is settled: ai-config's extra_instructions fix works, and gha lacks it

First post-fix data point, from the sibling issue's repo. It resolves this issue's open Options list, and it picks a variant of option 2 that does not go stale.

The fix

ai-config#817 (closing ai-config#815) added an extra_instructions block to ai-config's own jules-review.yml, whose last paragraph is exactly this issue's subject:

You cannot reliably know today's date, so never report a date as a
typo or as being in the future.

Phrased as an epistemic limit rather than by naming a year, so it needs no future maintenance. That is better than this issue's option 1 (inject the current date), which would need the date kept current, and more targeted than option 3 (accept as known noise).

Note it deliberately uses extra_instructions, not the rules_file input. Per the action's src/prompt.ts at the pinned SHA, the rules file is injected under # UNTRUSTED: Project-specific rules and the prompt's preamble tells the model to ignore instructions found there and to raise them as a [BLOCKING] "Prompt injection attempt" finding. extra_instructions is injected under # Trusted: Additional instructions (from workflow config), reachable only by someone who can edit the workflow. So the obvious lever is the wrong one; ai-config#817's body has the full reasoning.

The evidence, with a negative control

extra_instructions merged to ai-config's main at 2026-07-29T21:30:51Z. That splits the observations cleanly:

PR	Time (UTC)	Config	Triggers in diff	Jules verdict
ai-config#812	~19:2x	pre-fix	imperative prose	block + date nit
ai-config#820	19:43	pre-fix	- **Do:**/- **Don't:**	block
ai-config#827	22:51	post-fix	both, verified	approve, zero findings

Both triggers were confirmed present in #827's added lines rather than assumed, by grepping the diff itself:

$ git diff origin/main | grep -cE '^\+- \*\*(Do|Don.t):\*\*'
4
$ git diff origin/main | grep -cE '^\+.*2026-07-29'
1

The date half is the load-bearing part for this issue: pre-fix it fired on three consecutive rounds on #365 and survived a three-citation rebuttal, so its silence on a dated post-fix entry is a real signal rather than a review that happened not to mention dates.

What gha needs

gha runs its own copy of the workflow, at the same pinned SHA, with no extra_instructions at all:

$ git show origin/main:.github/workflows/jules-review.yml | grep -nE "uses:|extra_instructions"
20:        uses: sanjay3290/jules-pr-reviewer@fc66a7c78b499bfa2e16235b55574e458c6551d6 #v1.0.0

So the port is the fix here. gha's CLAUDE.md is dated-entry-per-learning the same way ai-config's is, and changelog.d/ fragments are too, so the trigger is equally standing.

Limits, stated plainly

One post-fix run, in a different repository. Same pinned action SHA and same prompt builder, so the behaviour should transfer, but this is evidence about the action's response to a trusted-section instruction rather than proof about gha's own config until gha's copy actually carries the block and a dated PR passes through it. Worth confirming on the first gha PR after the port rather than assuming.

Also worth checking before #363 wires them up, per this issue's own closing note: whether gemini-code-review.yml / ai-code-review.yml share the behaviour, and whether they expose an equivalent trusted injection point.

One practical note for whoever implements it: this is a .github/workflows/ edit, which is the one class of change that needs WORKFLOW_TOKEN to be pushed by a bot (#292).

---

Generated by Claude Code

[dem-extra1]

Addendum: the "one post-fix run" limit in my comment above is now understated --- it is two.

ai-config#827 went through a second Jules review on a second head (288b911) after a review fix, with both triggers still present in the diff, and approved clean again with zero findings.

Nothing else changes: same recommendation, same caveat that this is evidence about the action's response to a trusted-section instruction in a different repository, still worth confirming on gha's first dated PR after the port.

---

Generated by Claude Code

[d-morrison]

Working on this --- paws off until I'm done.

[d-morrison]

Implemented in #371.

Ported ai-config#817's extra_instructions block, keeping only the date paragraph -- phrased as an epistemic limit ("you cannot reliably know today's date") rather than by injecting the current date, so it needs no upkeep.

Verified the trust-boundary reasoning against src/prompt.ts at the pinned SHA rather than assuming it: rules_file lands under # UNTRUSTED: Project-specific rules where the preamble tells the model to report it as a [BLOCKING] injection attempt, while extra_instructions lands under # Trusted: Additional instructions (from workflow config).

Deliberately did not port ai-config's second paragraph (the imperative-prose injection carve-out). gha has no memories//skills//shared/ corpus, and that paragraph's own rule turns on who the text addresses -- gha's CLAUDE.md "Code review guidelines" section is addressed to a reviewer, so it falls on the other side of the line. No injection finding has been seen here; if one shows up it gets its own issue.

On this issue's closing note about the Gemini reviewers: gha does not dogfood gemini-code-review.yml on its own PRs (no caller stub in .github/workflows/, only the reusable workflow), so the noise is not multiplied here today. If it is wired up later, that workflow already exposes an equivalent trusted injection point in its prompt-addendum input, appended last. ai-code-review.yml is a dispatcher with no prompt of its own.

Option 4 (report upstream to Google) is untouched and still open for you to decide on.