Skip to content

Resolve pm-changelog to the release that derives release dates in UTC - #49

Merged
unbraind merged 7 commits into
mainfrom
chore/pm-changelog-utc-release-dates
Aug 3, 2026
Merged

Resolve pm-changelog to the release that derives release dates in UTC#49
unbraind merged 7 commits into
mainfrom
chore/pm-changelog-utc-release-dates

Conversation

@unbraind

@unbraind unbraind commented Aug 3, 2026

Copy link
Copy Markdown
Owner

What

Refreshes the lockfile so pm-changelog resolves to a release that derives the changelog heading date in UTC. Lockfile only — no source change.

Why

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, while a UTC runner regenerating the same tracker produced today's. The committed file and changelog:check then 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

  • Generated this package's changelog under TZ=UTC and TZ=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:check passes against the committed CHANGELOG.md.

pm items

  • pm-graph-9gtz — tracking item, with the acceptance criteria this was verified against

Summary by Sourcery

Update dependency lockfile and project management metadata to pick up a pm-changelog release that derives changelog dates in UTC.

Bug Fixes:

  • Align changelog generation dates across environments by refreshing the lockfile to a pm-changelog version that uses UTC-based release headings.

Chores:

  • Add PM tracking and history artifacts for the pm-graph-9gtz chore.

Summary by cubic

Refreshes the lockfile to the pm-changelog release that derives release-heading dates in UTC, aligning generation and changelog:check across timezones. Closes pm-graph-9gtz with 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.

  • Dependencies
    • Resolve pm-changelog to 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.

Review in cubic

@gemini-code-assist

Copy link
Copy Markdown

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

@sourcery-ai

sourcery-ai Bot commented Aug 3, 2026

Copy link
Copy Markdown
Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Lockfile 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

Change Details Files
Refresh dependency lockfile so pm-changelog resolves to a UTC-date-aware release.
  • Updated the resolved version and integrity metadata for pm-changelog and any affected transitive dependencies in the lockfile.
  • Ensured the lockfile now matches the already-declared dependency range that includes the fixed pm-changelog release.
package-lock.json
Add PM tracking and history records for the changelog UTC-date bug fix.
  • Added a PM chore/toon file describing the tracking item and its acceptance criteria.
  • Added a PM history JSONL entry documenting execution/closure of the tracking item.
.agents/pm/chores/pm-graph-9gtz.toon
.agents/pm/history/pm-graph-9gtz.jsonl

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@coderabbitai

coderabbitai Bot commented Aug 3, 2026

Copy link
Copy Markdown

Review Change Stack

Summary by CodeRabbit

  • Chores
    • Improved release changelog consistency by standardizing date handling in UTC.
    • Ensured changelog output remains identical across different time zones, including date-boundary scenarios.
    • Added verification to confirm generated changelogs are current and correctly formatted.
    • Documented the resolution and validation results in the release history for improved traceability.

Walkthrough

The PR records the resolution of timezone-sensitive changelog generation by updating pm-changelog to 2026.8.3. It documents verification across UTC, GMT-12, and GMT+14, and adds an Unreleased changelog entry.

Changes

PM changelog resolution

Layer / File(s) Summary
Dependency chore records
.agents/pm/chores/pm-graph-9gtz.toon, .agents/pm/history/pm-graph-9gtz.jsonl
Records the stale-lockfile defect, pm-changelog 2026.8.3 resolution, three-timezone acceptance criteria, and verification results.
Changelog entry
CHANGELOG.md
Adds an Unreleased entry for UTC-based release-date resolution in pm-changelog.

Estimated code review effort: 1 (Trivial) | ~3 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Title check ✅ Passed The title clearly states that the PR resolves pm-changelog to a release that derives release dates in UTC.
Description check ✅ Passed The description directly explains the lockfile update, timezone defect, verification, and related PM metadata changes.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch chore/pm-changelog-utc-release-dates

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've reviewed your changes and they look great!


Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@greptile-apps

greptile-apps Bot commented Aug 3, 2026

Copy link
Copy Markdown

Greptile Summary

The PR refreshes the lockfile to resolve pm-changelog 2026.8.3, regenerates the changelog, and records completion of the associated tracking chore.

  • Updates pm-changelog from 2026.7.27 to 2026.8.3.
  • Adds the completed chore and its closure history.
  • Adds the change to the unreleased changelog.

Confidence Score: 5/5

The 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.

Important Files Changed

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

Comment thread .agents/pm/chores/pm-graph-9gtz.toon Outdated
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
unbraind force-pushed the chore/pm-changelog-utc-release-dates branch from cc66d58 to e5c08cf Compare August 3, 2026 07:26
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.
@unbraind

unbraind commented Aug 3, 2026

Copy link
Copy Markdown
Owner Author

Pushed the three-zone evidence. Greptile was right that tightening the criteria to require a TZ=Etc/GMT-14 run while the completion record documented only UTC and Etc/GMT+12 left the item claiming a contract its own evidence did not meet — the tighter criteria made the record less true until the evidence caught up.

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

@coderabbitai

coderabbitai Bot commented Aug 3, 2026

Copy link
Copy Markdown

Rate Limit Exceeded

@unbraind have exceeded the limit for the number of chat messages per hour. Please wait 0 minutes and 26 seconds before sending another message.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between cc66d58 and 9fb25ad.

⛔ Files ignored due to path filters (1)
  • package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (3)
  • .agents/pm/chores/pm-graph-9gtz.toon
  • .agents/pm/history/pm-graph-9gtz.jsonl
  • CHANGELOG.md

Comment thread .agents/pm/chores/pm-graph-9gtz.toon Outdated
@unbraind

unbraind commented Aug 3, 2026

Copy link
Copy Markdown
Owner Author

Note on the test (26) failure here — it is a fixture flake, not this change.

test/id-resolution.test.ts:59 failed on its setup assertion (test setup expected a unique non-exact prefix), not on any behaviour of pm-graph. The test creates three items and requires that one of the random ids has a proper prefix unique among them; ids are pm- plus four random base36 characters, so that fails whenever two of the three share their first three random characters — roughly 6.4e-5 per run, measured at 16/400,000 in simulation.

Evidence it is unrelated to this PR:

  • The only source change here is a lockfile refresh of pm-changelog, which this test does not use.
  • test (22) passed on the same commit.
  • Three earlier runs on this same branch passed.
  • I confirmed the id generator is uniformly distributed (60 real ids, 30–32 distinct values per character position), so this is genuine chance rather than a biased generator introduced by anything here.

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: uniqueNonExactPrefix computes uniqueness against the three fixture ids while the resolver resolves against every item in the workspace, which only coincide because the fixture has exactly three items.

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.
@unbraind
unbraind merged commit 158a60e into main Aug 3, 2026
9 checks passed
@unbraind
unbraind deleted the chore/pm-changelog-utc-release-dates branch August 3, 2026 08:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant