// Use when adding or refactoring EasyPostman modules, shared code, plugin contracts, UI utilities, i18n, settings, theme/font handling, or deciding where a class belongs.
| name | module-architecture-boundaries |
| description | Use when adding or refactoring EasyPostman modules, shared code, plugin contracts, UI utilities, i18n, settings, theme/font handling, or deciding where a class belongs. |
Use this skill before adding shared code or moving code between modules. The goal is to keep EasyPostman's Maven modules small enough to reason about and strict enough that future changes do not turn into a catch-all common layer.
Read docs/ARCHITECTURE_MODULES_zh.md first when the task is about module placement, architecture cleanup, shared UI, plugin contracts, i18n, theme, font, settings, startup, update, welcome/help, API core, or performance core.
Put non-UI base capabilities in easy-postman-foundation.
Examples: shared DTOs, enums, constants, config paths, JSON helpers, system utilities, user-setting helpers, i18n mechanism, base message keys, and generic parsing/formatting helpers such as Cron, JSON Path, XML, file-size, file-extension, time-display, and HTTP header constants.
Put plugin extension contracts in easy-postman-plugin-api.
Examples: EasyPostmanPlugin, PluginContext, PluginDescriptor, service interfaces, toolbox/script/snippet contracts.
Put shared Swing design-system code in easy-postman-ui.
Examples: FontsUtil, IconUtil, NotificationUtil, EditorThemeUtil, ModernColors, reusable toolbar buttons/search/table/dialog/form controls such as EditButton, SaveButton, WrapToggleButton, EasyComboBox, EasyJSpinner, EasyPasswordField, and the icons/resources those reusable components directly reference.
UI singleton framework classes such as UiSingletonFactory, UiSingletonPanel, UiSingletonMenuBar, plus Swing refresh/save helpers such as IRefreshable and DebouncedSaveSupport, also belong here.
Generic action/control/status icons such as save, copy, paste, search, clear, cancel, close, delete, duplicate, eye, info, warning, arrows, chevrons, wrap, start, stop, send, connect, collapse, expand, more, detail, import, and export belong here. Do not duplicate the same icons/*.svg resource path in easy-postman-app, and do not make official plugins depend on app-only icon resources.
Put plugin loading mechanics in easy-postman-plugin-runtime.
Examples: plugin scanning, descriptor parsing, classloaders, registry, lifecycle, disabled/uninstall state.
Put performance domain core contracts in easy-postman-performance-core: editable plan data, executable plan.json, runtime contracts, stats/report snapshots, worker assignments, and asset references. Keep concrete GUI/headless execution adapters in easy-postman-app until the app execution semantics can be extracted without pulling in Swing, workspace services, or app-only state.
Put host platform framework capabilities in easy-postman-platform when they can be separated from concrete app UI.
Current examples: the custom IOC container under com.laker.postman.ioc, and update discovery core under com.laker.postman.platform.update (version comparison, update source selection, asset resolution, changelog fetching/formatting, update result models).
Future examples: startup orchestration, welcome/help, settings center, and theme/font application orchestration.
Keep concrete host UI and composition in easy-postman-app.
Examples: App, MainFrame, menus, app-only panels, settings pages, update dialogs, update download/install/exit flow, welcome/help pages, and concrete startup wiring that still depends on app UI.
platform: UpdateInfo, UpdateCheckFrequency, VersionChecker, VersionComparator, UpdateSourceSelector, release sources, asset resolvers, changelog service/formatter, and Windows registry/package-mode helpers.app: AutoUpdateManager, UpdateUIManager, UpdateDownloader, update dialogs/notifications, manual-download/open-browser commands, install prompts, and app shutdown for installation.platform update code must not import app SettingManager; inject a minimal provider such as UpdateSettingsProvider and adapt it in app with SettingManager::getUpdateSourcePreference.foundation: I18nUtil, CommonI18n, CommonMessageKeys, and common-messages*.ui (ui-messages*); host strings in app (messages_*); plugin strings in each plugin.ui; startup application of font settings belongs in platform once decoupled from app-specific wiring.ui; FlatLaf installation and theme switching belong in platform once decoupled from app-specific wiring. FlatLaf properties tied to app LAF classes can stay in app until those classes move.common module as the default destination.foundation.foundation.app.ui-messages* or plugin message bundles when CommonMessageKeys already owns them.easy-postman-app.easy-postman-ui.icons/*.svg resources between easy-postman-app and easy-postman-ui; shared control icons belong in ui, app/domain icons stay with their owning app/plugin module. If a plugin references an icon, it must be plugin-owned or UI-owned.For module-boundary changes, run:
mvn -q -pl easy-postman-app -am -Dtest=ModuleArchitectureBoundaryTest -Dsurefire.failIfNoSpecifiedTests=false test
mvn -q -pl easy-postman-platform -am -Dtest=UpdateSourceSelectorTest,PlatformDownloadUrlResolverTest,AppReleaseSelectorTest -Dsurefire.failIfNoSpecifiedTests=false test
mvn -q -DskipTests compile
Use when modifying EasyPostman Swing forms that use FlatLaf and MigLayout, especially when layout refactors introduce clipped focus rings, truncated text, clipped status badges, dense spacing, border conflicts, or inconsistent form structure.
Use when modifying EasyPostman Swing UI fonts, especially when dialogs, labels, tables, tabs, or renderers look too large or too small, or when a change needs to stay consistent with the user's configured UI font size.
Use when adding or updating EasyPostman Swing/TestNG UI tests that may run in headless CI or no-display Linux environments.