worktree: path-scoped rule inheritance in nested worktrees has no open upstream issue — decide whether to file one

[kyle-sexton]

What

plugins/source-control/skills/worktree/SKILL.md now states, as of 2.1.224 /
2026-08-07, that the nesting invariant rests on a leak with no open upstream
issue behind it:

• #16600 is OPEN, labeled enhancement and memory, and asks that memory
  traversal respect worktree boundaries. 2.1.224 already handles memory files
  correctly, so it does not describe the live defect.
• #29599 is CLOSED (labeled duplicate, closed COMPLETED). It reported the eager
  double-load that v2.1.69 fixed.
• #23565 is CLOSED NOT_PLANNED.

The surface still leaking is path-scoped rules: from a session inside a
worktree nested in a repository's tree, a read matching a paths: glob emits one
path_glob_match naming the PARENT checkout's rule file, loading it alongside the
worktree's own copy. Measured with an InstructionsLoaded hook trace.

So the skill's recheck trigger currently points at an issue that, if it were
closed tomorrow, would tell us nothing about whether our invariant still holds.

Open question

Is the path-scoped-rule inheritance a bug worth reporting upstream, or intended
behavior we should simply document and design around permanently?

Three measured facts bear on it, and they read more like a deliberate design than
an oversight — which is why this is a question rather than a bug report:

• Session-start ancestor traversal is suppressed for ancestors of the
  worktree's own repository, but not for a different repository. Someone
  implemented a suppression and scoped it.
• path_glob_match discovery is suppressed in neither case.
• A worktree nested inside an unrelated repository inherits all three
  surfaces — CLAUDE.md and unconditional rules at session_start too.

If the asymmetry is intended, the invariant is permanent and the skill should say
so instead of carrying a recheck trigger. If it is an oversight, an upstream issue
naming the three facts above is worth filing, and its number becomes the trigger.

Not blocking

The convention already avoids the leak by placing worktrees outside every
repository, and that placement is enforced at creation. This is about whether the
skill's recheck trigger is honest, not about a live risk.

Also unresolved from the same investigation

• Does the leak scale with the parent's rule count, or only with rules whose glob
  matches? Probe: add ten scoped rules to the parent and re-read the hook log.
• Why is session-start suppression repo-scoped but path_glob_match not? This is
  the mechanism the placement rule rests on, so a change to it is the real recheck
  trigger.

Filed from #1970.

[kyle-sexton]

Read-only / upstream-draft: the worktree skill now documents the measured path-scoped-rule inheritance behavior and the absence of a matching open upstream issue (2026-08-07). Whether to file upstream remains an operator decision with no bounded local fix in this repo. Closing so the drain lane does not re-triage a decision record.