Repository navigation
fix(init): say when the rules need update --rules, including between nightlies - #590
Conversation
…nightlies The ledger walk compares CLI versions on their numeric core, so two nightlies of one release owe no walk, while the engine gate compares exact engine versions. An ast-grep or Vale bump between nightlies left info and update reporting nothing to walk while check refused with RULES_ENGINE_MISMATCH. Decide whether a reconcile is due once, from the walk and the same engine comparison check makes, and report it from init (every run, human and --json), info --json and update --json. The update recipe reads it so a null walk no longer ends the walk before update --rules.
|
@claude /review |
|
Claude finished @theCodeDrift's task in 5m 7s —— View job Review:
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Thanks. No correctness findings to act on; the one inline note on the JSON shapes is handled in its own thread. — AI Coding Agent |
init --json carried the status as a flat `rules`, info --json as
`rules.reconcile`, and update --json as a narrower `reconcile`, so the same
answer had three field paths and `rules` meant two different things. All
three now build `reconcile: { required, engines, ruleMigrations }` from one
function.
A nightly user upgraded with
init, went straight tocheck, and hitRULES_ENGINE_MISMATCH.inithad pointed them toupdate, which ends inupdate --rules, so the flow works if you follow it. But reaching a runnablechecktook two hops, and nothing ininitsaidcheckwould refuse in the meantime.Looking into it turned up a real bug underneath. The ledger walk compares CLI versions on their numeric core, so two nightlies of one release owe no walk. The engine gate compares exact engine versions, and ast-grep 0.51.0 and Vale 3.24.0 both landed between nightlies. In that case
infoandupdatereportedwalk: null(the recipe reads that as "nothing to do") whilecheckrefused.What changed
rules/reconcile-status.ts: decides once whether a reconcile is due. It is due when there is a ledger walk, or when an engine with rules is recorded behind the bundled one. That second check is the same comparisoncheckmakes, so the advice and the enforcement cannot disagree again.init: on every run where a reconcile is due (not only on a version move), prints what moved, sayscheckandverifywill refuse until it is recorded, and namesupdatethrough toupdate --rules.init --jsoncarries the same answer asrules. When the notice prints, the upgrade trailer states only the version move, so the reader is not sent toupdatetwice.info --jsonaddsrules.reconcile, andupdate --jsonaddsreconcile.walkkeeps its narrower meaning: the ledger sections to read.updaterecipe (topic v22): anullwalk does not end the walk. Readrules.reconcile.required.Example, for a project at 0.11.2 with older engines:
Not changed
initstill does not runupdate --rulesitself. That command records that the ledger walk was done, and parts of the walk need judgment. Ifinitrecorded it, the marker would claim work nobody did.Testing
pnpm typecheck,pnpm lint, andpnpm test(2833 passed). New tests cover a nightly-style project (same CLI version, older ast-grep recorded):info,updateandinit(including a re-run) all report the reconcile as due, the notice does not duplicate the trailer's pointer, and it clears onceupdate --rulesruns.