Settings files with two owners: picking a source of truth

## Spark

alunduil-chezmoi#66 — chezmoi treated `~/.claude/settings.json` as authoritative source-of-truth and managed it as a templated file. Claude Code and claustre rewrite that same file at runtime to record state. Result: `chezmoi apply` kept reverting Claude's runtime writes, and Claude's writes silently diverged the deployed file from the chezmoi source.

## Why it could be interesting

This is a recurring class of problem — a config file with two would-be owners, one declarative (configuration manager, dotfiles framework) and one imperative (the runtime that mutates state). The default outcome is "both, hopefully they don't fight," which produces drift, lost state, and confusing debug sessions. The actual fix isn't a tool; it's a deliberate decision about which side owns which keys, with the loser of that decision either reading from the winner or being scoped out of the file entirely. The post would name the pattern, give the resolution shape (split file, scoped overrides, hand-off via hook), and use the chezmoi-Claude case as the worked example.

## Open questions

- [ ] Are there cleaner generalisations? (e.g. base-template + runtime-overrides as a separate file.)
- [ ] How does this compare with similar problems in zellij/vim/emacs configs that runtime sometimes touches?
- [ ] What does Claude Code itself document about `settings.json` ownership and the expected precedence?
- [ ] Is the right pattern always "scope by keys" or sometimes "scope by file"?

## Source material

- alunduil/alunduil-chezmoi#66 — chezmoi apply stays a no-op after Claude Code or claustre rewrites ~/.claude/settings.json (closed)
- alunduil/alunduil-chezmoi#65 — Sync Claude settings to claustre+zellij state
- alunduil/alunduil-chezmoi#54 — tighten Claude settings: ask gates, MCP reads