feat(framework): resolve resources shipped with installed plugins #994

Problem to solve

A skill cannot reliably locate a resource shipped with its plugin across installation modes and hosts.

This surfaced in project-memory sync: the skill invoked node hooks/update_memory.js --check from the consumer project, although the script belongs to the installed plugin. This relative invocation incorrectly assumes that the plugin's hook is available under the consumer project's working directory. Marketplace caches, managed installs, and flat layouts can place plugin files elsewhere.

Draft PR #992 handles the immediate workflow with explicit manual sync instructions. Those instructions do not claim the executable hook’s protections against hard links or path substitution. A general resource lookup contract remains useful to other skills and plugin resources.

Proposed solution

Define a documented way for a skill or other plugin component to request a plugin-owned resource by plugin identity and source-relative path. It should return a verified installed resource or an explicit unsupported, missing, or ambiguous result.

Leave the architectural boundary open for maintainer input: the contract may involve the CLI, plugin metadata, host integration, or a combination. A CLI command is one option, but it may not cover host-managed installs where the CLI or its provenance is unavailable.

Additional context

Acceptance criteria

• Document the supported installation modes and how plugin-owned resources are located in each.
• Require resource resolution only for installation modes where trustworthy installation provenance or origin can be established. Modes without that evidence must fail explicitly rather than guess.
• For managed installs, use recorded source-to-installed-path provenance where it exists; do not reconstruct historical destinations from current profile settings.
• Resolve resources when invoked from a consumer project outside the framework source tree. Never treat the consumer project root as the plugin root.
• Reject absolute paths, traversal, or symlink resolution that escapes the selected plugin resource boundary.
• Do not execute the target or write to the project as a side effect of resolving it.
• Define explicit behavior for missing resources, incomplete or stale provenance, absent CLI, standalone skills, multiple installed versions, and shared destinations. Ambiguous contexts must fail explicitly rather than guess.
• Cover supported host and installation combinations, plus failure and boundary cases, with reproducible tests.
• Keep resource location distinct from execution-time filesystem safety; resolution alone must not weaken existing hook protections or claim equivalent guarantees.

Prior art in this repo

• 04-sync.md — the workflow where the working-directory assumption surfaced; Draft PR feat(aidd-context): add Kilo-native generation targets #992 replaces the immediate invocation.
• #914 — Kilo-native generation, where the issue surfaced; this proposal is a separate framework capability.
• #698 and PR #706 — hook delivery and host-specific plugin-root tokens. These address hook installation and hook command paths, not a general way for a skill to locate plugin resources.
• #859 — global installation and distribution concerns. It is closed; its maintainer conclusion assigns host-specific installation surfaces to their owning integrations. It does not define a resource lookup contract.
• PR #778 — documents the boundary between event hooks and capabilities invoked by a person or skill; it does not resolve installed resource paths.
• Draft PR #979 — its standalone rule writer resolves its own script beside the loaded skill. That is relevant precedent, but not a general contract across resource types, installation origins, and versions.

Out of scope

• Expanding Kilo generation in feat(aidd-context): add Kilo-native generation targets #914 or changing Draft PR feat(aidd-context): add Kilo-native generation targets #992.
• Adding another rule writer alongside Draft PR fix(aidd-context): generate rules through a standalone skill script #979.
• Hard-coding host-specific directories into generic skills.
• Promising support for every host-managed marketplace without evidence.
• Treating path resolution as proof that later script execution is race-safe.
• Requiring a full architecture redesign before the supported cases are established.