apply_new_key_cluster

Consolidate a duplicate group onto a BRAND-NEW canonical key (NK1) - the BACKEND does the atomic data transaction so no translation is lost: it creates the new key (type/description/context inherited from the group's most-complete key), COPIES every language value from that most-complete key, and TRASHES all the old keys. Address it by source_value + new_key {name, namespace} (the namespace must exist and the name must be free). Returns {new_key_uuid, name, namespace, copied_from_key_uuid, copied_languages, trashed_key_uuids}. YOUR job after this is the CODE only: repoint every t() usage of the trashed keys onto new_key_uuid, and record those edits in files_modified (accepted right here, union-merged). You do NOT create_key or delete_keys_bulk yourself - the backend owns that. Author the new_key cluster in the merge plan first (on the dev's acceptance).

Paramètres

Nom	Type		Description
project_uuid	string	optionnel	Project UUID. Required when multiple projects are configured (SONENTA_PROJECTS); defaults to the single configured project otherwise.
source_value	string	requis	The shared source-language value identifying the duplicate group.
new_key	object	requis	The new canonical key to create and consolidate the group onto.
files_modified	array	optionnel	Optional audit trail of the t() repoints you made while resolving this group: each {path (required), line?, found_key, replacement_key, occurrences?}. found_key = the key string that WAS in the code at this spot (the old, redundant one); replacement_key = the canonical you repointed it to (an existing survivor, OR the new_key from apply_new_key_cluster). Accepted on every resolution path and MERGED (union + dedup by the full normalized entry) - record edits at whatever step you make them and they accumulate; omit to preserve the existing list. Always pass the STRUCTURED field, never just a note.

Exemple

{
  "tool": "apply_new_key_cluster",
  "arguments": {
    "source_value": "<source_value>",
    "new_key": {}
  }
}