[Feature] Define a compact namespace/Driver core and isolate optional feature dependencies without deleting user workflows #3149

Please confirm the following

• I have read and agree to AGPL-3.0 Section 15. The program is provided "as is" without any warranties; you bear all risks of using it.
• I have read and agree to AGPL-3.0 Section 16. The copyright holders and distributors are not liable for any damages resulting from the use or inability to use the program.
• I confirm my description is clear, polite, helps developers quickly locate the issue, and complies with community rules.
• I have read the OpenList documentation.
• I confirm there are no duplicate issues or discussions.
• I believe this issue must be handled by OpenList and not by a third party.
• I confirm this feature has not been implemented yet.
• I confirm this feature is reasonable and has general demand, not just my personal need.
• I have not read these checkboxes and therefore I just ticked them all, Please close this issue.

Feature Description

OpenList exposes file browsing, writes, admin setup, search, previews, archives,
shares, offline tasks and several protocol frontends. These are not all
orthogonal. internal/fs owns virtual-path behavior while internal/op loads
and dispatches Drivers; internal/bootstrap/run.go composes optional services
into one process. In the frontend, src/app/App.tsx initializes the plugin
engine at startup, even though plugin administration is gated to TS-Worker;
src/pages/home/uploads/uploads.ts selects multiple real transport paths.

Please establish a small, testable semantic core—identity/authorization,
virtual namespace, Driver capability admission, file operations and transfer
lifetime—while isolating optional product features from mandatory startup and
dependency paths. “Peripheral” should mean outside this minimum kernel, not
unimportant, deprecated, or automatically removable.

Suggested Solution

1. Produce a feature/dependency map that traces one browse/read/write path and
   the admin configuration path across API, frontend, storage and persistence.
   Classify each feature as kernel authority, control plane, optional consumer,
   protocol adapter or implementation variation; record shared policy edges.
2. Retain one owner each for authorization, path identity, mutation and cache
   invalidation. Optional search, archive, preview, sharing, offline tasks and
   protocol listeners may consume core operations/events but should not create
   duplicate authority.
3. Make only proven optional initialization and dependencies conditional. Audit
   Go plugin-engine startup and the apparently unimported frontend
   src/pages/home/uploads/chunked.ts before considering removal. Do not
   collapse direct/stream/form/multipart uploads simply because they overlap:
   they serve different Driver and transport capabilities. Similarly, both
   FolderTree variants have live callers.
4. Accept changes only with preserved API/UI behavior for enabled features,
   a measured dependency/startup or deletion benefit, and tests covering
   authorization, paths and upload fallback. Prefer a sequence of small changes
   over a core facade that leaves old and new owners both alive.

Additional Information

Relevant source: internal/fs, internal/op, internal/driver/driver.go,
internal/bootstrap/run.go; frontend src/app/App.tsx,
src/pages/home/uploads/uploads.ts, src/utils/plugin_engine.ts, and manage
route/menu gating. hide_files appears to be presentation filtering in the
inspected source, not an authorization boundary. This issue asks for a product
and ownership classification before deleting any feature. Coordinate with
the prior architecture reduction PR queue to avoid duplicate refactors.
PRs #3131–#3136 are still open as of the pre-submission check and address
link ownership, authorization, Driver capabilities/catalog, range scheduling,
and namespace projections. This issue should track only the remaining
cross-feature boundary, not duplicate those diffs.

AI Generated Content

• I used AI tools to generate this content
• I did not use AI tools to generate this content

AI model used

OpenAI Codex (exact model identifier not exposed to the agent)