#3482: an include fragment that Claude Code loaded as an all-tools agent

Branch fix/3482-shared-fragments · closes #3482 · the last v10 beta gate

CC's plugin loader treats whatever it finds under agents/ and skills/ as a component, and offers no opt-out. Two shared fragments were parked inside those trees, so they were not co-located, they were loaded.

The status-protocol fragment carries no frontmatter at all. It still appeared in a live session's agent roster, and because it declares nothing, it declared no tool restrictions either:

ork:shared:status-protocol - Agent from ork plugin (Tools: All tools)

An include fragment was the single broadest tool surface in the roster, and selectable for real work.

The other half, and why it is invisible

path	problem
`agents/shared/status-protocol.md`	no frontmatter, loads as an agent with all tools
`skills/shared/`	a directory in the skills tree with no `SKILL.md`

A consumer running /plugin sees "1 error during load" with no detail, because CC does not write plugin load errors to disk. So this class cannot be diagnosed from outside and has to be caught by a repo test.

The fix is relocation, not frontmatter

Adding frontmatter to the fragment would stop the all-tools symptom while leaving an include masquerading as a component. The destination already existed: build-plugins.sh:383 copies src/shared/ to plugins/ork/shared/, a branch that had simply never had a source directory to act on.

src/agents/shared/status-protocol.md  ->  src/shared/status-protocol.md
src/skills/shared/{rules,assets,...}  ->  src/shared/{rules,assets,...}

Moved with git mv, so history follows the files. Then 198 references repointed across src/, tests/, scripts/, docs/site and CLAUDE.md.

Evidence

The test asserts the invariant, not the two known instances, so a third fragment cannot reintroduce the class. It checks both the source tree and the built plugin, because only the latter is what a consumer loads.

--- src/agents ---
  FAIL: shared/ is a directory inside agents/; CC loads its .md files as agents
  FAIL: status-protocol.md has no frontmatter, so it loads with no declared tools
--- plugins/ork/agents ---
  FAIL: shared/ is a directory inside agents/; CC loads its .md files as agents
  FAIL: status-protocol.md has no frontmatter, so it loads with no declared tools
--- src/skills ---
  FAIL: shared/ has no SKILL.md, so it is a directory in the skills tree that is not a skill
--- plugins/ork/skills ---
  FAIL: shared/ has no SKILL.md, so it is a directory in the skills tree that is not a skill
RESULT: FAIL                                                    exit 1

--- src/agents ---
  PASS: no subdirectories
  PASS: every agent .md carries frontmatter
--- plugins/ork/agents ---
  PASS: no subdirectories
  PASS: every agent .md carries frontmatter
--- src/skills ---
  PASS: every skills/ subdirectory has a SKILL.md
--- plugins/ork/skills ---
  PASS: every skills/ subdirectory has a SKILL.md
RESULT: PASS                                                    exit 0

Ran the directory I skipped last time

On #3461 I ran agents, ci, plugins, skills and manifests, all green, and pushed. CI then failed on tests/performance/, the one directory I had not run, and the change was reverted. So this time:

plugins 11/11   agents 16/16   skills 59/59   hooks 6/6
ci      2/2     performance 4/4   quality 1/1
manifests PASS  validate-counts PASS

One failure that is NOT from this change, checked rather than assumed

tests/orphans/test-unreachable-skills.sh reports 21 unreachable skills. Re-ran it in a clean worktree at origin/main (1aaf02287): identical 21. It is pre-existing and untouched here. Reporting the count rather than the word "unrelated", because the count is the thing that makes it checkable.

Two commits: the git mv, then the reference repoint. Generated plugins/ and docs/site output is staged with its source change per CLAUDE.md. Self-contained page: no external scripts, styles, or render proxies.