repo-fleet-hygiene: no conformance report against the configured worktree root, so ~245 misplaced worktrees are invisible

[kyle-sexton]

Context: #2597

Problem

The fleet already has a declared, configured worktree convention, and the audit does not check against it. It reports worktree-nested-in-repository for a handful of cases but has no notion of "where should this worktree be", so it cannot say that essentially the entire fleet is non-conforming.

Reading one config key turns a scattering of placement findings into a single actionable verdict.

Evidence

source-control:worktree declares itself "the canonical owner of the parallel-session worktree convention for this plugin fleet": worktrees live at an external worktree_root, layout <root>/<owner>-<repo>-<slug>, never nested inside any repository's tree. It even documents the collision this fleet has walked into — "ghq list reports each worktree as a repository of its own, and a leading dot does not hide it. Choose a configured root accordingly."

worktree_root is configured on the measured machine as D:/worktrees.

Measured by enumerating git worktree list --porcelain across all 19 canonical repositories and excluding each repository's own main worktree — 292 linked worktrees across ten conventions:

n	Convention
108	ghq flat sibling <repo>-<suffix>
82	home loop root
37	Codex tool-owned
36	central dev-drive root, inside ghq root
10	raw temp (C:/tmp, D:/tmp)
7	nested <repo>/.claude/worktrees/
6	nested sibling <repo>-worktrees/<branch>
3	session scratchpad under %TEMP%
2	nested <repo>/.claude-worktrees/
1	Cursor tool-owned
0	the configured worktree_root

The audit reported 9 of these as placement findings. The other ~245 non-conforming worktrees are invisible to it.

Two details that matter for the check:

• The 108 flat siblings are the largest bucket and are name-indistinguishable from clones — they are why discovery reported 127 "repositories" for 19.
• The 7 under <repo>/.claude/worktrees/ are produced by the harness's EnterWorktree(name:) primitive, which the owning skill explicitly routes around. They are tool-created but non-conforming by the fleet's own rule.

Proposed change

• Read the configured worktree root and report conformance per worktree: conforming, non-conforming (with the expected location), or tool-owned.
• Never define or default the convention here. Read the key; if it is unset, say so and report placement descriptively rather than inventing a standard.
• Report the fleet-level summary even when there are no other findings — "N of M worktrees are outside the configured root" is the headline this fleet needed and did not get.
• Treat migration as the normal case rather than an edge case; on the measured fleet essentially every worktree is non-conforming.

Required for correctness of any config read: gate on git -C <path> rev-parse --git-dir first. Under dubious ownership (safe.directory), git -C <repo> config --get <key> returns the global default as though it were the repository's answer — rc=0, no stderr, --show-scope reporting global — while repo-local keys read as unset. A fleet tool iterating repositories it does not own would read the wrong root with no signal. Verified in a hermetic lab on git 2.55.0.

Attribution should use --show-origin, not --show-scope: a conditionally-included file collapses to global under --show-scope, so only origin can tell an operator which rule supplied the root.

Acceptance criteria

• The report states, per repository and for the fleet, how many worktrees conform to the configured root.
• A non-conforming worktree names its expected location.
• Tool-owned locations are distinguished from misplaced ones rather than both being "non-conforming".
• With no configured root, the skill reports placement without asserting a convention.
• Every config read is gated on rev-parse --git-dir, and attribution uses --show-origin.