Repository navigation
Resolve pm-changelog to the release that derives release dates in UTC - #27
Merged
Merged
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 GuideUpdates the pm-changelog dependency via package-lock refresh to pick up a version that derives changelog release-heading dates in UTC, and adds corresponding pm tracking and history records for this chore. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Summary by CodeRabbit
WalkthroughThe pull request adds closed PM records for resolving Changespm-changelog dependency chore
Estimated code review effort: 1 (Trivial) | ~2 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 SummaryThis PR refreshes
Confidence Score: 5/5Safe to merge — lockfile-only change with no source modifications and well-documented verification. The change touches only package-lock.json and PM tracking artifacts. The pm-changelog version bump is within the already-declared ^2026.7.25 range so package.json requires no edit. The tightened peer dependency lower bound (>=2026.7.29) is satisfied by the @unbrained/pm-cli@2026.7.29 that is already locked. Verification evidence — byte-identical sha256 output across UTC, GMT+12, and GMT-14 with an untagged release version — is thorough and directly targets the defect path. Files Needing Attention: No files require special attention.
|
| Filename | Overview |
|---|---|
| package-lock.json | Resolves pm-changelog 2026.7.28 → 2026.8.3; peer dep range for @unbrained/pm-cli tightens to >=2026.7.29, which is satisfied by the currently-locked 2026.7.29. |
| .agents/pm/chores/pm-github-9m6j.toon | New PM tracking item documenting the lockfile chore; records acceptance criteria, three-zone verification results (sha256 match under UTC/GMT+12/GMT-14), and close reason. |
| .agents/pm/history/pm-github-9m6j.jsonl | Append-only JSONL audit trail for the PM item; 9 entries covering create → close → criteria refinement → three-zone verification corrections. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[pm-changelog invoked\nno release tag found] --> B{Derive heading date}
B -- "Before 2026.8.2\n(local time)" --> C["new Date()\n→ local timezone"]
B -- "2026.8.3+\n(UTC)" --> D["new Date().toISOString()\n→ UTC date"]
C --> E["Heading: today in\nhost local time"]
D --> F["Heading: today in UTC\nregardless of host TZ"]
E --> G{"Host TZ offset?"}
G -- "UTC" --> H[2026-08-03]
G -- "UTC+12 after 12:00 UTC" --> I[2026-08-04 ⚠️\nnext day]
F --> J[2026-08-03 ✅\nconsistent everywhere]
H --> K["changelog:check may\ndisagree on different hosts"]
I --> K
J --> L["changelog:check\nalways agrees"]
Reviews (11): Last reviewed commit: "Verify what the criterion actually claim..." | Re-trigger Greptile
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
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.
unbraind
force-pushed
the
chore/pm-changelog-utc-release-dates
branch
from
August 3, 2026 07:25
fd1ed77 to
ba8cbff
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.
Owner
Author
|
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 |
|
✏️ Learnings added
✅ Action performedFull review finished. Your included review limit is currently reached under our Fair Usage Limits Policy. This review may still proceed through usage-based billing if eligible. Your next included review will be available in 57 minutes. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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-github-9m6j.toon:
- Line 20: Update the close_reason entry to align with the acceptance criteria
by including verification for TZ=UTC, TZ=Etc/GMT+12, and TZ=Etc/GMT-14, or
reference actual_result as the complete evidence; retain the existing
byte-identical output and changelog:check results.
- Line 16: Replace the invalid 2026-08-03T08:2x UTC placeholder with the same
exact actual UTC timestamp in the actual_result at
.agents/pm/chores/pm-github-9m6j.toon lines 16-16 and the historical update at
.agents/pm/history/pm-github-9m6j.jsonl lines 6-6.
🪄 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: 6a297d9e-6c9f-49b5-bfcd-a2fa22e1923b
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (2)
.agents/pm/chores/pm-github-9m6j.toon.agents/pm/history/pm-github-9m6j.jsonl
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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-github-9m6j— tracking item, with the acceptance criteria this was verified againstSummary by Sourcery
Refresh the package lockfile to pick up a pm-changelog release that derives changelog heading dates in UTC and add the corresponding PM tracking artifacts.
Build:
Chores:
Summary by cubic
Refreshes the lockfile to resolve
pm-changelogto 2026.8.3 so changelog release dates are derived in UTC across time zones. Updates the PM item/history to require UTC,TZ=Etc/GMT+12, andTZ=Etc/GMT-14runs, records byte-identical whole-file hashes with an exact UTC timestamp, and syncs the close reason with the final criteria.pm-changelog2026.7.28 → 2026.8.3.@unbrained/pm-clito >=2026.7.29; no source changes.Written for commit 485808f. Summary will update on new commits.