[Feature Request] Add source/target placeholders for hooks and defaults

[gander]

Problem Description

wtp currently offers powerful configuration via .wtp.yml and hooks, but there is no support for dynamic placeholders derived from the source and target branches or their directories. This limits how precisely worktree directories can be structured and how advanced hook commands can be written, especially when they need to reference both the original worktree and the newly created one.

Proposed Feature

Introduce a set of built-in placeholders that can be used in:

• defaults.base_dir
• all hook definitions (e.g. hooks.post_create.*.command, hooks.*.work_dir, etc.)

New placeholders

• ${PATHNAME} – Absolute path of the directory where the source branch worktree lives.
• ${DIRNAME} – Directory name (basename) of the source branch worktree path.
• ${SOURCE_BRANCH} – Raw name of the source branch (e.g. main, feature/auth).
• ${SOURCE_SLUG} – Slugified source branch name (e.g. feature/auth → feature-auth).
• ${TARGET_BRANCH} – Raw name of the newly created target branch.
• ${TARGET_SLUG} – Slugified target branch name.

The “source branch” here is the branch/worktree from which wtp add is executed or from which the new worktree is derived. The “target branch” is the branch created or checked out for the new worktree.

Example Usage

1. Structured worktree base_dir

Example context:

• DIRNAME = symfony-startup
• TARGET_BRANCH = feature/auth
• TARGET_SLUG = feature-auth

Allow using placeholders in defaults.base_dir:

version: "1.0"

defaults:
  # Result example: ../symfony-startup___feature-auth
  base_dir: ../${DIRNAME}___${TARGET_SLUG}

This makes it easy to:

• Keep worktrees grouped by project directory name.
• Encode branch information in the worktree path in a consistent, machine-readable way.

2. Advanced hook commands referencing the source worktree

Enable placeholders in hook commands, for example to clean up containers related to the source worktree:

hooks:
  post_create:
    - type: command
      command: cd ${PATHNAME} && docker compose down --remove-orphans && cd -

This allows:

• Running cleanup or side-effects in the original worktree when creating a new one.
• Reusing the same .wtp.yml across different projects and branches thanks to dynamic path and branch interpolation.

Expected Behavior

• When wtp add ... runs, wtp resolves all placeholders to concrete values for the current operation (source worktree, source branch, target branch, target worktree path).
• Placeholders are expanded in:
  • defaults.base_dir
  • hook command strings
  • hook work_dir
  • any other string fields where paths or commands are interpreted.
• If a placeholder cannot be resolved in a given context (e.g. no target branch yet), wtp should either:
  • fail with a clear error message, or
  • document which placeholders are guaranteed to be available at which phase.

Additional Information

This feature would:

• Improve consistency and discoverability of worktree directories.
• Enable more powerful automation in hooks (especially commands that need both source and target contexts).
• Keep configuration DRY by avoiding hardcoded paths and branch names in .wtp.yml.

[satococoa]

I’d like to cover this as part of the ongoing direction in #56 (default base_dir refactor).
If we move toward a default like ../wtp/<repo>/, we’ll likely need placeholders (e.g., ${REPO} / ${DIRNAME}), so I’d prefer to design and ship them together rather than separately.

[tmas]

Something that could be a pretty cool companion to this would be higher-level configs with inheritance.

Let's say somebody has 10 different repos with worktrees in ../worktrees/ and none of them have config files yet. Instead of creating 10 separate config files for each repo to suppress the warning when #56 changes the directory structure, they could place a .wtp.yml file in the folder that contains those projects, which could then apply rules for all the project subfolders. If they wanted to move an individual project to the new folder structure, they could add a .wtp.yml file to that individual project folder and override the settings from the config file in the parent directory.