> ## Documentation Index
> Fetch the complete documentation index at: https://slopsentral.michne.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Source ownership and plugin composition

> Keep canonical source, generated provider output, and installed consumers distinct.

Each invariant and procedure has one authored owner.
A plugin selects that owner by reference. It does not own another copy of the procedure.

## From primitive to consumer

`source/adaptable.marketplace.json` declares the marketplace identities.
`source/plugins/*/plugin.json` composes skills, agents, hooks, instructions, and resources.
Profiles select those compositions for a task without implicit installation.
The [catalog](https://slopsentral.michne.com/reference/catalog.md) exposes the resolved identities and references.

The [source graph gate](https://github.com/amichne/slopsentral/blob/main/tools/validate-source-graph.mjs) examines the declared paths and schemas before projection.
It rejects conflicting identities, missing paths, dependency cycles, and duplicate hook selection within a profile.
A profile can share skills and instructions across plugins. Its dependency closure selects each hook through one plugin.
That packaging rule does not prove one invocation in a live host.

The [projector](https://slopsentral.michne.com/knowledge/architecture/projection.md) consumes the accepted graph and freezes its authored bytes.
Pkl owns provider shapes. Generated trees and installed caches remain consumers.
A repair belongs in the primitive or projector that owns the behavior, followed by regeneration.

## Select the procedure owner

| Plugin | Responsibility |
| - | - |
| Software Engineering | Shared invariants, proof, Python automation, Git, PRs, and CI |
| Kotlin Engineering | Kotlin implementation, review, compiler proof, application libraries, and Gradle |
| IntelliJ Plugin Development | Plugin delivery, PSI, indexing, platform tests, and live diagnostics |
| Developer Tooling | CLIs, agent resources, schemas, OpenAPI, Pkl, and personal configuration |
| Repository Knowledge | Source-backed explanations, navigation, prose assessment, and HTML artifacts |

Software Engineering remains the default.
Knowledge maintenance forms part of its engineering baseline, while Repository Knowledge supplies the specialized procedures.
Repository Knowledge composes documentation, navigation, prose assessment, and visual artifact skills.
Use `interactive-views` for a standalone HTML visualization or UI experiment.
Use `reviewable-artifacts` for an HTML proposal or report that needs review or revision.
An ordinary code task gives no authority for automatic knowledge generation.
Read [evidence and freshness](https://slopsentral.michne.com/knowledge/concepts/evidence.md) before a claim that a page is current.

## Reuse one executable without its workflow

A `RESOURCE` names one regular executable or data file.
It excludes directories, symlinks, destination aliases, and `SKILL.md` entry points.
Its dependencies can select only resources.

This variant lets a hook consume a runtime helper without installing the helper's entire authoring procedure.
The source identity, bytes, mode, and digest remain part of the graph.
Use the [resource guide](https://slopsentral.michne.com/guides/workflows.md) for declaration examples and focused checks.

## Distribute the practice that this repository uses

Code Knowledge Base owns the portable documentation runtime and its dependency lock.
Its package also includes a configuration schema, adoption procedure, and complete independent-project template.
Slopsentral's `bin/slopsentral-docs` points to that same runtime.
Project roots, backend selection, and fingerprint exceptions stay in `docs/coverage.json`.

The [portable procedure](https://slopsentral.michne.com/maintainers/portable-documentation.md) supports another project without a Slopsentral checkout.
The [package proof](https://slopsentral.michne.com/knowledge/testing/validation.md) exercises unchanged shipped bytes through all four provider projections.
A copied runtime remains a pinned consumer with explicit upstream provenance.
Do not fork project-specific policy into another runtime implementation.

## Change an owner safely

Find the primitive and its direct consumers before a change.
Keep task-specific detail in the skill's local references.
Change its composition only when the consumer needs another capability.
Then examine the graph, catalog, fresh projections, and affected knowledge together.
The [authoring workflow](https://slopsentral.michne.com/knowledge/workflows/authoring.md) selects the necessary gates.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.