Resolve pm-changelog to the release that derives release dates in UTC - #49
Conversation
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
Reviewer's guide (collapsed on small PRs)Reviewer's GuideLockfile refresh to pick up a pm-changelog version that derives changelog heading dates in UTC, plus addition of internal PM tracking artifacts documenting and tracking this fix. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Summary by CodeRabbit
WalkthroughThe PR records the resolution of timezone-sensitive changelog generation by updating ChangesPM changelog resolution
Estimated code review effort: 1 (Trivial) | ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThe PR refreshes the lockfile to resolve
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains; the previously reported tracker-closure issue is resolved by the closed status and matching close history event.
|
| Filename | Overview |
|---|---|
| package-lock.json | Resolves pm-changelog 2026.8.3 and records its updated peer dependency requirement. |
| .agents/pm/chores/pm-graph-9gtz.toon | Records the chore as closed with completion metadata and timezone verification evidence. |
| .agents/pm/history/pm-graph-9gtz.jsonl | Provides the tracker audit history, including the close event that resolves the previous review finding. |
| CHANGELOG.md | Adds the completed dependency-refresh chore to the unreleased section. |
Reviews (7): Last reviewed commit: "Verify what the criterion actually claim..." | Re-trigger Greptile
Records the defect, the acceptance criteria it is verified against, and the history stream, so the change is auditable from the tracker rather than only from the diff.
pm-changelog derived the release-heading date in local time until 2026.8.2. A host at a positive UTC offset generating a changelog late in the evening produced tomorrow's heading, and a UTC runner regenerating the same tracker produced today's, so the committed file and `changelog:check` disagreed for reasons that had nothing to do with the tracker. The declared range already admitted the fixed release, so an automated dependency update had no range to widen and stopped at an earlier version; only the lockfile still pinned one that predates the fix. This refreshes the lock alone. The exposure was latent rather than active: the daily release job generates and checks inside a single UTC instant on GitHub, so it agreed with itself. It bites an agent or a developer regenerating locally, which has now happened twice in this fleet. Verified by generating this package's changelog under TZ=UTC and TZ=Etc/GMT+12 at one instant and confirming byte-identical output, and by `changelog:check` passing against the committed file.
cc66d58 to
e5c08cf
Compare
Review flagged that the chore stayed open while the change it tracks was complete, so anything consuming open work would keep treating it as actionable. Closing it records the resolution, the expected and actual result, and the close transition in the history stream, which is what makes the tracker answerable without reading the diff. The changelog is regenerated in the same commit because closing an item changes what the generator emits, and `changelog:check` compares against a fresh generation. Each package is regenerated with its own check command minus `--check`, so the generation mode cannot drift from the mode the gate asserts — those modes differ across this fleet.
Review flagged that "a timezone a day behind at one instant" does not identify a timezone, so the criterion could not be re-run by anyone reading it. It now names TZ=Etc/GMT+12 and states why that offset is on the previous calendar day — a fixed minus-twelve offset is, whenever the UTC time of day is before 12:00 — so the reader knows both what to run and what makes the comparison straddle a date boundary rather than merely use two zone names. The history stream carries the evidence rather than only the intent: the resolved lockfile version, the fact that both generations used an untagged release version because a tagged one takes its date from the tag and cannot exhibit the drift, that the runs straddled a date boundary, and that the same comparison against the previous pin produced headings one day apart.
Review pointed out the two-zone criterion could pass while proving nothing. TZ=Etc/GMT+12 sits on the previous UTC date only while the UTC time of day is before 12:00; run in the afternoon, both zones share a calendar date and the comparison cannot detect a local-time date at all. The criterion named the condition but nothing enforced it, so the verification was silently dependent on when it happened to run. Adding TZ=Etc/GMT-14 closes that. The plus-fourteen zone is on the next UTC date from 10:00, and the minus-twelve zone is on the previous one until 12:00, so their union covers the whole day: at every instant at least one of the three pairs straddles a boundary. The check no longer has a quiet hour. Verified in this package at 08:08 UTC, where the minus-twelve zone was a day behind the other two and all three headings still agreed.
Review caught that the acceptance criteria were tightened to require a TZ=Etc/GMT-14 run while every completion record still documented only UTC and Etc/GMT+12. The item therefore claimed a contract its own evidence did not meet — the tighter criteria made the record less true, not more. The three-zone run had been performed; it simply was not written down. Both the actual result and a history note now carry the observed headings from all three zones, the count of distinct heading values across them, and the fact that the minus-twelve zone was on the previous calendar date at that instant — which is what makes the comparison a boundary crossing rather than two zones that happened to agree.
|
Pushed the three-zone evidence. Greptile was right that tightening the criteria to require a The run had been performed, just not written down. The actual result and a history note now carry the observed headings from all three zones, the count of distinct heading values across them (1 — they agree), and that the minus-twelve zone was on the previous calendar date at that instant, which is what makes it a boundary crossing rather than two zones that happened to agree. @coderabbitai full review |
Rate Limit Exceeded
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.agents/pm/chores/pm-graph-9gtz.toon:
- Line 20: Update close_reason in .agents/pm/chores/pm-graph-9gtz.toon at line
20 to document the final verification across TZ=UTC, TZ=Etc/GMT+12, and
TZ=Etc/GMT-14, including that changelog:check passes. Update the corresponding
closure metadata in .agents/pm/history/pm-graph-9gtz.jsonl at line 2
consistently; preserve the existing acceptance outcome and byte-identical
changelog result.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 985568fb-e578-4641-a325-d6fa5d1ed160
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (3)
.agents/pm/chores/pm-graph-9gtz.toon.agents/pm/history/pm-graph-9gtz.jsonlCHANGELOG.md
|
Note on the
Evidence it is unrelated to this PR:
Re-run triggered. Filed as #50 rather than fixed here, so a dependency bump does not carry an unrelated test change — the issue also records a second problem found while diagnosing: |
Two review findings, both about the record overstating what was checked. The criterion requires byte-identical output; the evidence compared only the release heading line. A heading match is a weaker claim — it says nothing about the rest of the document — so the record asserted more than the check performed. The whole generated document is now hashed under each of the three zones and the sha256 prefix recorded, so the evidence and the criterion describe the same comparison. The previous note also gave the run time as "08:2x", which is not an instant and cannot be re-derived. It now carries an exact UTC timestamp. close_reason still named only two zones and omitted the untagged release version, so the three places describing this work disagreed with each other. It now matches the final criteria. The history stream keeps the superseded entries and carries the correction as an appended note rather than a rewrite, so the audit trail stays append-only.
What
Refreshes the lockfile so
pm-changelogresolves to a release that derives the changelog heading date in UTC. Lockfile only — no source change.Why
pm-changelogderived the release-heading date in local time until 2026.8.2. A host at a positive UTC offset generating a changelog late in the evening produced tomorrow's heading, while a UTC runner regenerating the same tracker produced today's. The committed file andchangelog:checkthen disagreed for a reason that has nothing to do with the tracker.The declared dependency range already admitted the fixed release, so no dependency update was ever proposed — only the lockfile still held the old version. That is why this sat unnoticed across the fleet.
The exposure was latent, not active: the daily release job generates and checks inside a single UTC instant on GitHub, so it agrees with itself. It bites an agent or a developer regenerating locally, which has now happened twice in this fleet.
Verification
TZ=UTCandTZ=Etc/GMT+12(a day behind this host) at one instant → byte-identical output. Before the bump the same comparison produced headings one day apart.changelog:checkpasses against the committedCHANGELOG.md.pm items
pm-graph-9gtz— tracking item, with the acceptance criteria this was verified againstSummary by Sourcery
Update dependency lockfile and project management metadata to pick up a pm-changelog release that derives changelog dates in UTC.
Bug Fixes:
Chores:
Summary by cubic
Refreshes the lockfile to the
pm-changelogrelease that derives release-heading dates in UTC, aligning generation andchangelog:checkacross timezones. Closespm-graph-9gtzwith three-zone, byte-identical verification (TZ=UTC, TZ=Etc/GMT+12, TZ=Etc/GMT-14) using full-document hashes and an exact timestamp; regenerates the changelog.pm-changelogto 2026.8.3 (UTC date fix); update lockfile peer to@unbrained/pm-cli>= 2026.7.29; no source changes.Written for commit 22903a4. Summary will update on new commits.