Include stable branch identity in structured hook-log entries

[NathanaelRea]

Motivation

wt config state logs --format=json provides useful branch labels, but branch names can be reused. External tools can safely use the label for display preference, but not to associate a log with a particular worktree incarnation.

Request

Include a stable identity in each structured hook-log entry, such as the branch OID captured for the hook run and/or another Worktrunk-defined invocation identity. Preserve the human-readable branch label separately.

This would allow log viewers to prefer exact historical entries without treating a reusable branch name as identity.

[worktrunk-bot]

Thanks for the suggestion — the premise checks out. Today a hook-log entry carries no stable identity: the branch field is a sanitized name derived purely from the on-disk directory path, and it can be reused, exactly as you say.

Where this lives in the code:

• The JSON entry is built in LogRow::to_json from HookStructure. The full set of emitted fields is file, path, size, modified_at, plus (for hook entries) branch, source, hook_type, name — all four hook fields are the sanitized path segments, documented here.
• Those segments come straight from the log path, which is {branch}/{source}/{hook-type}/{name}.log — see HookLog::path. No OID or invocation ID is captured at hook-run time; the .log file holds only the hook's output text.

Two things worth flagging before this gets designed:

1. The SHA already exists at hook-run time — it's just discarded. Hooks are handed commit / short_commit as template variables (with_active_commit), so the source data is right there at spawn time. The gap is purely persistence: identity today is 100% path-derived — the JSON is reconstructed by walking the directory tree, and nothing is stored alongside each log. Capturing the OID (or an invocation ID) would mean recording it at write time, either in a sidecar next to each .log or by moving from plain-text logs to a structured (e.g. JSONL) format that can carry per-entry metadata.

2. The current model overwrites, so there isn't a per-incarnation entry to identify. Per the docs, "same operation on same branch overwrites the previous log" — each entry is the latest run of a given hook for a branch name, not a history. So distinguishing worktree incarnations isn't only a matter of adding a field; it also touches whether entries accumulate per invocation at all. Preserving the human-readable label separately (as you request) is the easy part; the identity itself is the design decision.

I'll leave it for a maintainer to weigh the shape and prioritize — this is one of a few related structured-output asks (#3696, #3697, #3700), so it may be worth deciding on a consistent identity convention across them.