Key-aware YAML replacement may match wrong key at different nesting levels

Start by reading extractKeyFromPath and the key-aware YAML replacement introduced in #22. Reproduce the metadata.version/spec.version scenario, then choose an approach that targets the requested path without matching the same key at another nesting level; done means the intended occurrence alone is replaced.

Summary

The key-aware YAML replacement introduced in #22 extracts only the final key name from a path (e.g., metadata.version → version). This works well for distinguishing between different keys like version and appVersion, but could match the wrong occurrence when the same key name exists at different nesting levels.

Scenario

Given a YAML file:

metadata:
  version: 0.9.0
spec:
  version: 0.9.0

If we want to update metadata.version, the current implementation generates a pattern like version:\s*0\.9\.0 which would match both occurrences. The first match would be replaced, which may or may not be the intended one depending on file structure.

Current Behavior

extractKeyFromPath("metadata.version") returns "version", losing the parent context.

Potential Solutions

1. Line-number aware replacement - Use the YAML library to find the exact line number of the target path, then only replace on that specific line
2. Full path matching - For nested paths, include parent keys in the pattern (though this gets complex with varying indentation)
3. YAML AST modification - Parse, modify, and re-serialize the YAML (would lose formatting/comments)

Impact

This is likely a low-priority edge case since:

• Most version files (Chart.yaml, package.json) don't have duplicate key names at different levels
• The common case (version vs appVersion) is now handled correctly

Related

• Fixed in #22 for the version/appVersion case

🤖 Generated with Claude Code