store-module-architecture

Store Module Architecture

Applicable Scenarios

Publishing or managing store components such as plugins, templates, and images
Handling review, listing, delisting, installation, and upgrade
Understanding component types, state transitions, and statistics logic in the store
Handling store extension points, category tags, members, comments, and other capabilities

Only the execution logic of a single plugin, not involving the store lifecycle
Only the internal logic of the template module, not involving store distribution
Only image running or artifact archiving, not involving store management

First determine which main line the problem belongs to:
- Store basics and component types: see reference/1-store-foundation.md
- Publishing, installation, review, and extension: see reference/2-release-install-extension.md
Store The focus is not on how components "execute", but on how components "enter the marketplace, get reviewed, get installed, and get counted".
Plugins, templates, and images share the store mindset, but their lifecycle details differ, so do not force one approach for all.
If the problem has already landed on template instances or plugin execution itself, switch to the corresponding module skill next.

Store Is responsible for component lifecycle and distribution, not for the specific execution engine
Component state transitions are usually more critical than a single business action
Store capabilities often stack categories, tags, members, comments, statistics, and review
For installation and upgrade issues, look at both the source component version and the target project's landing state

Treating plugins, templates, and images completely as the same type of component
Looking only at the publishing process, not at the review and delisting recovery chain
Assuming the target project is fully usable just because store installation succeeded
Only troubleshooting component metadata, not resource synchronization after installation