Interface LoadedPlugin

Files to materialize in the sandbox (CLAUDE.md, skills, agents, commands).

settings' hooks block as the file wrote it — no root variable expanded. settings writes the plugin root in so the shipped wiring runs; a READER of a hook line (what it names, which hook it is) needs the line the author wrote, or every message quotes a machine path. Absent when settings holds no hooks.

A .claude/settings.json-shaped object with hooks resolved.

The project settings' hooks block when a plugin manifest or hooks.json supplied settings instead — undefined otherwise (including when the settings ARE what settings holds, so nothing is counted twice).

🔴 A REPO CAN BE BOTH, AND BOTH ARE LIVE. A plugin's manifest hooks run for whoever INSTALLS it; its .claude/settings.json hooks run for whoever works IN it. The loader picks one source for settings (the sandbox runs the plugin), so the other was never looked at: the vigiles repository's own compiled nudges pointed at a runtime that did not exist for three weeks and hook-script-exists never read the file they were wired in (measured 2026-10-11). Raw — no token is expanded — and only PATH-CHECKED; the deterministic tier never runs it.

Map from a materialized files key to the ABSOLUTE on-disk path it was read from. A surface can be materialized under a canonical key (.claude/skills/ foo/SKILL.md) while living on disk at a different root (the repo-root skills/ OR the project-level .claude/skills/), so a consumer that needs the real dir (e.g. resolving a skill's bundled resources) must reverse-map through this instead of guessing from the key. Present for every surface file.

Surfaces that are present in the plugin but cannot be exercised at the deterministic tier (subagents and slash commands need a real model; MCP servers aren't wired by the loader). Empty when the plugin is fully covered. Surfaced so "load the whole plugin" never silently tests nothing — read it in a test, or just to know what the deterministic run won't reach.