qol-shared-libslisted

# Shared library check Before adding a capability to a plugin, prove whether the workspace already owns it and decide whether the new behavior is plugin-specific or reusable. ## Discover the maintained library set The workspace `Cargo.toml` and `cargo metadata --no-deps` own Rust membership. Directories under `libs/` are candidates, not proof that a crate is active. JavaScript/shared-asset libraries are owned by their import graph and package metadata. For the requested capability: 1. Search `libs/` and plugin consumers by behavior/type/function names. 2. Read candidate crate roots and public re-exports, not a prose module list. 3. Inspect `cargo metadata` plus consumer manifests to understand the dependency graph. 4. Read tests/examples to verify semantics rather than inferring them from a crate name. 5. Extend an existing owner when its abstraction and lifecycle match; do not create a near-duplicate helper. Useful discovery commands: ```bash cargo metadata --no-deps --format-version 1 find libs -maxdepth 2 -name Cargo.toml -print rg -n '<capability|type|function>' libs plugins ``` ## Placement decision Put code in an existing shared library when it extends that library's established capability contract and does not introduce plugin-specific policy. Create or expand a shared capability when independent consumers need the same semantics, lifecycle, error model, and platform behavior. Similar-looking call sites are insufficient; normalize the actual contract first.