feat(global-settings): short update notice that says what an update adds (v2.8.0)

[WilcoLouwerse]

Summary

The UPDATE REQUIRED notice comes back in every new session until the update is done, and Claude rendered it in full each time. It also named the versions but not what changed in them.

• Short notice at session start. It shows the header, the installed and latest version, what the update adds, a one-line reminder that unlocking takes sudo chattr -i plus chmod u+w and relocking takes sudo chattr +i, and that the user can ask how to update or for the details of the changes. There are no command blocks.
• Full form on request. Asking how to update shows steps 1 to 4, with each command in its own block and both relock options with their trade-off. After the update Claude always shows the relock step, even if the full form was never asked for. The relock rules are unchanged; they are now shared between the update and repair notices. The FILES OUT OF SYNC notice keeps its full form.
• "What this update adds". New global-settings/CHANGELOG.md (not installed) has one sentence per version. The notice shows the sentence for each version after the installed one, newest first, at most five, and counts the rest. A version without an entry is listed as such. If CHANGELOG.md can't be fetched, the block says so and the update still works.
• Details on request. When the user asks about the changes, Claude looks up the commit that set VERSION to each listed version, reads its message, changed files and pull request, and links that PR (or the commit if no PR merged it). The notice includes the gh api and git log commands for this.
• Complete changelog, 1.0.0 to 2.8.0, each entry dated the day the version reached main (## X.Y.Z — YYYY-MM-DD). 1.0.0 to 1.3.0 come from the archived claude-code-config repository. 1.2.1, 1.5.1 and 2.0.0 reached main together with the next version, and their entries say so. Numbers main never carried (1.5.0, 1.5.2, 1.5.3, 2.4.3) get a ### entry with a note on where their changes went; the notice reads only ## headings, so it does not list them. The 2.7.3 entry belongs to fix(global-settings): a hard deny beats every prompt; git aliases that push need the phrase (v2.7.3) #813, which is still open; it is dated 2026-10-02 like 2.8.0.
• Bump rule: every VERSION bump needs a dated CHANGELOG.md entry. The tests fail on a missing entry, on a heading without a date, and on dates out of order. VERSION → 2.8.0.

The notice is printed by the installed hook. The short form and the changes block therefore first appear when someone on v2.8.0 or later updates to a newer version, not on the update to 2.8.0 itself.

Example (session start)

GLOBAL CLAUDE SETTINGS: UPDATE REQUIRED
Installed: v2.8.0 ❌ (outdated). Latest: v2.8.1 ✅ (on origin/main)
What this update adds:
  v2.8.1 — <one sentence from CHANGELOG.md>
Unlocking takes two commands, sudo chattr -i and chmod u+w. Afterwards you must re-apply sudo chattr +i.
Ask me how to update for the full steps, or for more details about what these changes do.

Test plan

• test-check-settings-version.sh: 114 passed, 0 failed (new: dated headings newest first with a bad-file control, short form, full form on request, relock after the update, repair keeps the full form, pending range, order, cap, missing entry, missing file, lookup commands)
• test-block-write-commands.sh: 7630 / 7630; test-block-polling.sh: 29 / 29 (both files unchanged)
• Negative control: the changes-block tests run against the origin/main hook give 16 failures
• ShellCheck (shellcheck.yml, CI only; not installed locally): the first run flagged SC2028 and SC2319, fixed in 02fafed
• After merge: the next version bump shows the short notice on a 2.8.0 install

🤖 Generated with Claude Code

[WilcoLouwerse]

🟡 Concern — The 2.7.3 entry makes #808 depend on #813 merging first

This changelog carries a ## 2.7.3 entry for #813, which is still open (main is at 2.7.2; VERSION here goes to 2.8.0, and this PR does not touch block-write-commands.sh). If #808 merges first, a 2.7.2 install updating to 2.8.0 gets this sentence in its update notice for a hard-deny change it does not receive, and #813 would then set VERSION back to 2.7.3, below the installed 2.8.0. The PR body says the entry belongs to #813 but not that #813 has to merge first. Fix: state the merge order in the body (merge #813, then update this branch). If #808 has to go first, move this entry to #813 and have #813 bump to 2.8.1.

_{Verification: git show origin/main:global-settings/VERSION → 2.7.2; gh pr view 813 -R ConductionNL/.github --json state,files → OPEN, bumps VERSION to 2.7.3 and changes block-write-commands.sh; this PR's file list has no block-write-commands.sh.}

[WilcoLouwerse]

Verdict: APPROVE (Standard) — self-review posted as COMMENT (GitHub blocks self-APPROVE)

The notice code is sound: a failed CHANGELOG fetch cannot hang or fail session start, the version order is numeric and the dated headings parse. One concern on the merge order with #813.

🟡 Concerns (1)

• The 2.7.3 entry makes #808 depend on #813 merging first — global-settings/CHANGELOG.md:13. Merged first, 2.8.0 would announce #813's hard-deny change without containing it, and #813 would then set VERSION below 2.8.0.

Reviewed at: 17ecdf7 — the head moved three times during this review (c930f8a, b5924df, 17ecdf7).
Tests: bash global-settings/tests/test-check-settings-version.sh → 114 passed, 0 failed on 17ecdf7 (run in this review).
CI: Shared-workflow guard and Install from published location are green on 17ecdf7; the required Package invariants check was still running when this verdict was posted. Its run on c930f8a was cancelled by concurrency in favour of the newer push, not by a failure.