defaults guard: name a stamp a base merge kept as the pull request's own red

Merged
TE
15d ago
+46-4

defaults_guard.py check-stamp --base now says plainly when a stale settings stamp is the pull request's own red, even though the stale entries are base sources.

Why

#22762 merged with its stamp holding older digests for two base sources (Schema/DiffViewerSettingsSchema.swift, Schema/SettingsSchema.swift). A local base merge with the cmux-generated-v1 driver keeps this branch's stamp; that part is by design (.gitattributes: a line-merged stamp would call one-sided exports fresh). The guard already failed the head for it ("defaults stamp" in fast gates and defaults-snapshot). Its output listed only base files, though, so I read it as a base red and merged, and the squash (d881a7e6) put the old digests back on feat-cmux-next.

What changes

  • In stamp_freshness, with a base: a stale entry whose source bytes match the base's but whose stamp entry does not is the head's. It is now listed under an ::error annotation, "this pull request's red, not the base's", which says what happened and how to fix it: apply this head's pr-autofix-patch artifact, or regenerate the exports.
  • Base staleness (source and stamp entry both the base's) stays a warning note, and sources the head changed keep the existing message.
  • The merge driver is unchanged.

Changelog

none

Tests

Test first: tests/test_defaults_guard.py gets test_a_base_merge_that_keeps_the_branchs_stamp_is_named_as_the_pull_requests_red. Its fixture: base edits and restamps Beta; a branch from before that edits Alpha; a local merge with the driver keeps the branch's stamp. The command for both runs, from tests/:

python3 test_defaults_guard.py SettingsExportStampTests.test_a_base_merge_that_keeps_the_branchs_stamp_is_named_as_the_pull_requests_red

  • On 026a8157 (the test alone): fails. Beta is listed only as "changed", with no label.
  • On 2e4c2e50 (with the fix): passes. The whole file passes too (python3 test_defaults_guard.py, 38 tests).

Observed / Not run

  • Observed: the red and green runs above; check-stamp consumers (cmux-next-guards.yml, cmux-next.yml, cmux_next_fast_gates.py) read only its exit code, which is unchanged.
  • Not run: the CI workflows themselves on this head (CI runs them).

Agent session: cosmic-gray

🤖 Generated with Claude Code

View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need.

Summary by cubic

defaults_guard.py check-stamp --base now names stale settings stamp entries kept from a local base merge as this pull request's red, instead of listing them as base staleness.

After #22762 merged with old digests for two base sources, the guard's output named only base files, so the red read as the base's and the squash put the old digests back on feat-cmux-next.

  • A stale entry whose source matches the base but whose stamp entry does not is now an ::error annotation, "this pull request's red, not the base's", including the fix: apply the head's pr-autofix-patch artifact or regenerate the exports.
  • Base staleness (source and stamp entry both from the base) stays a warning note, and sources the head changed keep the existing message.
  • Adds a fixture test reproducing the #22762 merge scenario.