fix(update): keep re-checking a formerly-frozen capability until its files land - #217
Merged
Merged
Conversation
…files land
When `update` keeps a capability it cannot parse upstream ("frozen"), it
leaves that capability's files out of the plan and moves `skillsVersion`
on. The next run that can parse it again removed it from
`frozenCapabilities` unconditionally. If one of its files was skipped on
that run (a user edit, or an unrecorded file), withholding the bump held
back nothing, because the bump had already happened. Every later
`update` then early-returned "Already up to date", and the file stayed at
the old version even after the user reverted the edit as advised.
A key from the previous `frozenCapabilities` now stays listed while any
file under that capability's directory was skipped this run. Keys are
drawn from the merged capabilities, so an entry the merge drops cannot
linger. `update` also no longer writes a `pendingSkillsVersion` equal to
the withheld `skillsVersion`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0199owRmYfskqYQVQrVP679o
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 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 |
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
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 this changes
PHARN-13 (#207) made
updatere-open its same-version gate whilefrozenCapabilitiesis non-empty. A frozen capability is one pharn can't parse upstream, soupdatekeeps it and leaves its files alone.The bug: the run that can parse such a capability again removed it from the list unconditionally. The version bump had already happened on the run that froze it (that run left the capability's files out of its plan). So if one of its files was skipped on the re-check run (a user edit, or an unrecorded file), withholding the bump held back nothing. Every later
updatethen printed "Already up to date" without fetching. The review reproduced this: the file stayed at the old version even after the user reverted their edit, and only--forcerecovered it.src/commands/update.ts:frozenCapabilitiesnow stays listed while any file under that capability's directory was skipped this run. The check uses the same<subtree>/<name>/prefix thatrecordsUnderCapabilitiesuses.pendingSkillsVersionis no longer written when it would equal the withheldskillsVersion. That happened on a same-version re-check and toldaddnothing new.src/types.ts: thefrozenCapabilitiescomment now describes both reasons a key is listed, and that a re-runinitwrites it too (fix(init): a re-run init keeps what update would keep, and re-checks the config under its lock #216). Comment only.docs/commands/update.mdanddocs/reference/pharn-config.mdstate when the field clears. CHANGELOG[Unreleased]→ Fixed.Third of the four fixes from the 18-commit review (#213, #216).
Type of change
feat— new stack option, wizard step, or command capabilityfix— bug fixdocs— docs-only changechore/refactor— tooling or internal restructure, no behavior changeArea(s) touched
commands/update | types (comment) | docs
Checklist
.js-extension import convention.tests/*.test.ts. The three-run case (skip → fetch again → revert → upgrade and clear) fails against the baseupdate.ts; I checked by stashing it.docs/pages.frozenCapabilitiesis still validated at ingest, and only keys that match a merged config entry are written back.Quality gates
npm run checkpasses locally (format:check+lint+typecheck+test): 1498 tests.npm run buildsucceeds.npm run test:coveragepasses (coverage thresholds met).Floor workflow tests: 754/754 passed.
validate.mjs: GREEN. Pharn-dev verdicts: regressno-regressions, verifyPASS, review GREEN (2 minor advisory findings). I ran all gates with the same CI-equivalent setup as #213.Notes for the reviewer
updatefetches again until you resolve the edit or pass--force. The non-frozen path already behaves this way (a user edit withholds the bump), andupdate.mdnow says so.frozenCapabilities, so it installs only on the nextSKILLS_VERSIONbump.🤖 Generated with Claude Code
https://claude.ai/code/session_0199owRmYfskqYQVQrVP679o
Generated by Claude Code