FlyEnv: Skill for Codex

FlyEnv Module Boundaries

Treat state ownership as an architecture decision. Assign an owner by lifetime, never by the button or page that first triggers the work.

Default Module Constraints

These are prohibitions unless the user explicitly authorizes an exception for the specific new module:

• Shared configuration: Never persist module-owned state in config.setup. Use StorageSetAsync/StorageGetAsync for module-owned persistence.
• Pinia: Do not create a new Pinia store for module-owned state. Use a normal module-local class or singleton and bind it with reactiveBind.
• Lifecycle duplication: Reuse ModuleInstalledItem.start(), stop(), and restart() whenever the public lifecycle supports the module. Supply module-specific values through startExtParam/stopExtParam, registered in the module (normally components/<Module>/aside.vue). Add a module-specific start/stop workflow only after proving the shared methods cannot express the required behavior.
• Public leakage: Keep module-only properties, types, policies, helpers, and methods in the module directory. Do not add them to shared service types, ModuleInstalledItem, BrewStore, or generic lifecycle helpers.

Record any explicit exception and its scope in the implementation plan. Existing code is not authorization for copying an older pattern.

Required Workflow

1. Read AGENTS.md, including Module Boundaries and Operation Ownership, before editing.
2. Classify every new state as view, domain, renderer operation, or fork process state.
3. Add an operation contract to the plan for every long-running renderer operation.
4. Check the Default Module Constraints above and document any explicit exception.
5. Implement only after the owner, terminal events, and tests are explicit.

State Owners