update commit prev

docs/CHANGELOG.md

@@ -5,5 +5,5 @@
 - **docs:** Add `docs/provider_authoring.md` with a Quick Start, examples, and testing guidance for providers that integrate with the strict `ResultTable` API (ResultModel/ColumnSpec/selection_fn).
 - **docs:** Add link to `docs/result_table.md` pointing to the provider authoring guide.
 - **tests:** Add `tests/test_provider_author_examples.py` validating example provider registration and adapter behavior.
-- **notes:** Existing example providers (`Provider/example_provider.py`, `Provider/vimm.py`) are referenced as canonical patterns.
+- **notes:** Existing example plugins (`plugins/example_provider.py`, `plugins/vimm/__init__.py`) are referenced as canonical patterns.
 

docs/provider_authoring.md

@@ -84,7 +84,7 @@ class MyTableProvider(TableProviderMixin, Provider):
         return self.search_table_from_url(url, limit=limit)
 ```
 
-`TableProviderMixin.search_table_from_url` returns `ProviderCore.base.SearchResult` entries. If you want to integrate this plugin with the strict `ResultTable` registry, add a small adapter that converts `SearchResult` -> `ResultModel` and register it using `register_plugin` (see `Provider/vimm.py` for a real example).
+`TableProviderMixin.search_table_from_url` returns `ProviderCore.base.SearchResult` entries. If you want to integrate this plugin with the strict `ResultTable` registry, add a small adapter that converts `SearchResult` -> `ResultModel` and register it using `register_plugin` (see `plugins/vimm/__init__.py` for a real example).
 
 ---
 
@@ -115,7 +115,7 @@ class MyTableProvider(TableProviderMixin, Provider):
 
 ```py
 from SYS.result_table_adapters import get_provider
-from Provider import example_provider
+from plugins import example_provider
 
 
 def test_example_provider_registration():
@@ -132,10 +132,10 @@ def test_example_provider_registration():
 
 ## References & examples
 
-- Read `Provider/example_provider.py` for a compact example of a strict adapter and dynamic columns.
-- Read `Provider/vimm.py` for a table-provider that uses `TableProviderMixin` and converts `SearchResult` → `ResultModel` for registration.
+- Read `plugins/example_provider.py` for a compact example of a strict adapter and dynamic columns.
+- Read `plugins/vimm/__init__.py` for a table-provider that uses `TableProviderMixin` and converts `SearchResult` → `ResultModel` for registration.
 - See `docs/provider_guide.md` for a broader provider development checklist.
 
 ---
 
-If you want, I can also add a small `Provider/myprovider_template.py` file and unit tests for it — say the word and I'll add them and wire up tests. 🎯
+If you want, I can also add a small `plugins/myprovider_template.py` file and unit tests for it.

docs/provider_guide.md

@@ -3,7 +3,7 @@
 ## 🎯 Purpose
 This guide describes how to write, test, and register a plugin so the application can discover and use it as a pluggable component.
 
-> Keep plugin code small, focused, and well-tested. Built-in plugins live in `Provider/` and external drop-in plugins live under `plugins/`.
+> Keep plugin code small, focused, and well-tested. Bundled plugins and drop-in plugins share the same `plugins/` layout.
 
 ---
 
@@ -125,8 +125,9 @@ pytest -q
 ---
 
 ## 📦 Registration & packaging
-- Built-in plugins live under `Provider/` and are auto-discovered from that package.
+- Bundled plugins live under `plugins/` and are auto-discovered from that package.
 - External user plugins can be dropped into `plugins/` or any directory listed in `MM_PLUGIN_PATH` / `MEDEIA_PLUGIN_PATH`.
+- Package directories are preferred so plugin-specific files can travel with the plugin.
 - Plugin authors should import from `ProviderCore.*`.
 
 ---
@@ -146,19 +147,19 @@ pytest -q
 - [ ] Provide `URL` / `URL_DOMAINS` or `url_patterns()` for routing
 - [ ] Add `download()` or `download_url()` for piped/passed URL downloads
 - [ ] Add tests under `tests/`
-- [ ] Add the plugin module to `Provider/` for built-ins, or drop it into `plugins/` for plug-and-play user installs
+- [ ] Add the plugin under `plugins/<name>/` for bundled or plug-and-play installs
 
 ---
 
 ## 🔗 Further reading
-- See existing built-in plugins in `Provider/` for patterns and edge cases.
+- See existing bundled plugins in `plugins/` for patterns and edge cases.
 - Check `API/` helpers for HTTP and debrid clients.
 
 
 ---
 
 If you'd like, I can:
-- Add an example plugin file under `Provider/` as a template (see `Provider/hello_provider.py`), and
+- Add an example plugin file under `plugins/` as a template (see `plugins/hello/__init__.py`), and
 - Create unit tests for it (see `tests/test_provider_hello.py`).
 
-I have added a minimal example provider and tests in this repository; use them as a starting point for new providers.
+I have added a minimal example plugin and tests in this repository; use them as a starting point for new plugins.

docs/result_table_selector.md

@@ -13,7 +13,7 @@ Example:
 
 What plugins must implement
 - An adapter that yields `ResultModel` objects (breaking API).
-- Optionally supply a `columns` factory and `selection_fn` (see `Provider/example_provider.py`).
+- Optionally supply a `columns` factory and `selection_fn` (see `plugins/example_provider.py`).
 
 Implementation notes
 - `plugin-table` emits dicts like `{ 'title': ..., 'path': ..., 'metadata': ..., '_selection_args': [...] }`.