Fix #29, #30, #31: codev update stops reporting things it never checked

[pseudoseed]

Closes #29, closes #30, closes #31.

Three issues filed separately; one defect wearing three hats. Each states a conclusion nothing established.

#31 — --dry-run wrote to disk

It printed (dry run - no files will be changed) and then created CLAUDE.md.codev-new and AGENTS.md.codev-new. Only the copySkills call was guarded by dryRun; copyRootFiles was not.

A dry run that writes is worse than no dry run at all, because it is the one mode an operator trusts specifically on the promise that it touches nothing. copyRootFiles now takes dryRun and reports what it would do.

#30 — "Content differs from template", where nothing compared content

A conflict was declared whenever the destination merely existed:

if (fs.existsSync(destPath)) {
  if (handleConflicts) {
    fs.writeFileSync(destPath + ".codev-new", content);
    conflicts.push(file);
  }
}

...and reported as reason: "Content differs from template". Every update handed the operator a merge task that was usually a no-op.

It now compares — after template substitution, so a correctly-substituted {{PROJECT_NAME}} is not a false conflict — and returns unchanged for a byte-identical file. An unreadable destination counts as differing: that direction surfaces the file for a human rather than silently calling it clean.

#29 — needed more than a comparison

Once .claude/skills/<name>/ existed, its contents were frozen at install time forever. --force never helped; that branch only wrapped copyRootFiles.

The comment said "without replacing customizations". With nothing compared, the code could not tell a customization from a stale copy, so it preserved both — which in practice means it preserved rot. The issue's examples: a vendored afx skill claiming there is no --branch flag (there is), and an arch-save skill claiming delayed sends are not persisted (they are).

Comparing against the current skeleton does not fix this. It answers "same or different", not "customized or stale" — which is the actual question, and re-guessing it would repeat the original sin. So copySkills now keeps a per-provider .codev-skill-manifest.json recording the hash it installed:

State	Action
dest == skeleton	already current — backfill the hash so the next update can tell
dest == installed hash	unmodified but stale — refresh
dest != installed hash	local edits — leave alone, and say so
no manifest entry, or unreadable	cannot tell — leave alone, and say so

The last row is the one that matters. "I cannot tell" must not be spelled the same way as "safe to overwrite", or the first update after this ships eats a year of someone's local edits. Projects vendored before manifests existed land there and are held back on purpose.

Customized skills are now reported, not silently skipped — a customization quietly blocking every update is exactly what an operator needs told:

  ~ (refreshed) .claude/skills/afx/
  ! (local edits, not refreshed) .claude/skills/consult/

init and adopt keep the old semantics. Only update opts in via refreshUnmodified.

Tests

15 new. The #30 and #31 cases fail against the old implementation directly; the #29 ones exercise the new API.

Worth calling out three:

• substitution-aware comparison — {{PROJECT_NAME}} expanded to the same value must read as unchanged, not as a conflict.
• dry run predicts the real run — the reported copied / conflicts / unchanged from a dry run must equal the real one. That is the entire point of the mode.
• unknown provenance is customized — a skill vendored before manifests must be held back, never overwritten.

update + scaffold + template-delivery + new: 83 passed. adopt: 8. doctor: 25.

(Note: src/__tests__/init.test.ts is in the vitest exclude list, so codev init has no suite running in CI. Not touched here, but worth knowing.)

🤖 Generated with Claude Code