8616839cab
CHANGELOG promotion was a manual operator step that was never run, so 463 fragments for work already shipped in <=1.3.1 accumulated in .changeset/. Their notes were already hand-curated into the dated [1.2.0]/[1.3.0]/[1.3.1] CHANGELOG sections (#690 backfill, PR #694). Rendering them now would duplicate and mis-attribute shipped work. Move them to .changeset/archived/ (read non-recursively by all changeset tooling, so never rendered), keeping only the 3 genuinely-unreleased fragments at the top level. Prep for wiring `render` into the release finalize job (#690 follow-up). Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
1.1 KiB
type
| type |
|---|
| Enhancement |
/gsd-graphify status surfaces graphify v0.7+ commit-based staleness (#3170) — graphifyStatus() now reads built_at_commit from graph.json (written by graphify v0.7+ at build time), compares it against git HEAD, and returns four new fields: built_at_commit, current_commit, commits_behind, and commit_stale. The commit_stale flag is tri-state — true / false / null, where null means the signal is unavailable (pre-v0.7 graph, non-git checkout, or unreachable commit) and callers should fall back to the existing mtime-based stale flag. The skill renders Source commit: <hash> (N commits behind HEAD | current | freshness unknown) when the signal is present, and omits the line entirely for pre-v0.7 graphs. The built_at_commit value is validated as 4–40 hex chars before reaching git, so a hostile graph.json cannot smuggle dashed options (e.g. --upload-pack=…) into the argv. Also documents graphify hook install in docs/CONFIGURATION.md for multi-dev teams who would otherwise hit graph.json merge conflicts on parallel rebuilds.