Problem Description

Current copy hook configuration in .wtp.yml requires both from and to fields to be explicitly defined, even when the source and destination paths are identical. This creates unnecessary verbosity for common cases where a directory or file should simply be mirrored from the main worktree into the new worktree using the same relative path.

Example of the current requirement:

hooks:
  post_create:
    - type: copy
      from: ".idea"
      to: ".idea"

If to is omitted, wtp fails to load the configuration with the following error:

failed to load configuration from '~/user/project/.wtp.yml'

Original error: invalid configuration: invalid hook 2: copy hook requires both 'from' and 'to' fields

Expected Behavior

Allow a shorter, more ergonomic syntax for the common case where from and to paths are the same. Two possible options:

1. Implicit to value when omitted:

hooks:
  post_create:
    - type: copy
      from: ".idea"   # 'to' implicitly treated as ".idea"

2. Dedicated shorthand field copy to express "copy to the same path":

hooks:
  post_create:
    - type: copy
      copy: ".idea"   # equivalent to from: ".idea", to: ".idea"

The second option feels more intuitive and consistent with the command hook syntax, which also uses a single, clearly named field for the main operation.

Actual Behavior

Currently, both from and to are required for every copy hook, even when they point to the same path. Omitting to results in a configuration error and prevents wtp from loading the .wtp.yml file.

Additional Information

The shorthand would:

• Reduce boilerplate in .wtp.yml for common "same path" copy operations such as .idea, .env, .claude, or .cursor/.
• Improve readability and maintainability of hook configuration.
• Make copy hooks more intuitive by aligning them conceptually with command hooks, which already have a concise primary field (command).

A potential implementation detail could be:

• If copy is defined: treat it as from: <value>, to: <value>.
• Else, if only from is defined: treat to as equal to from.
• Preserve current behavior when both from and to are explicitly set, ensuring backward compatibility.