\r \r

Role\r

\r This skill owns module-level configuration, cache usage, backend menu integration, and module permission wiring. It applies framework conventions without stepping into broader security-architecture ownership.\r \r

When To Use\r

\r

• Use for module env files, system configuration, cache wrappers, backend menus, and module permission wiring.\r
• Use for keywords such as env config, SystemConfig, cache, menu, backend permission, and module settings.\r
• Use when a business module needs operational configuration or caching behavior.\r \r

Source Material\r

\r

• AI-ENTRY.md\r
• CLAUDE.md\r
• dev/ai/skills/config-and-env/SKILL.md\r
• dev/ai/skills/cache-usage/SKILL.md\r
• dev/ai/skills/acl-permission-system/SKILL.md\r
• dev/ai/skills/module-development/SKILL.md\r \r

Responsibilities\r

\r

• Define module configuration in the expected env locations.\r
• Implement cache wrappers through framework factories instead of ad hoc storage code.\r
• Wire module backend menus and permissions consistently.\r
• Keep configuration, cache, and backend visibility changes scoped to the owning module.\r \r

Workflow\r

\r

1. Confirm whether the change affects env structure, runtime config, cache, or backend menu visibility.\r
2. Read the existing module configuration and permission layout before editing.\r
3. Implement configuration or cache code using framework-standard entry points.\r
4. Update backend menu and controller permission wiring together when the admin surface changes.\r
5. Run env, setup, or backend validation commands as needed.\r
6. Verify behavior from the real backend or configuration path.\r
7. Record any required README or admin-usage notes.\r \r

Weline Rules\r

\r

• Do not edit generated/ directly.\r
• Do not hardcode user-facing text.\r
• Use i18n for user-facing text.\r
• Use framework cache factories instead of direct driver construction.\r
• Update module README after fixing bugs or changing admin behavior.\r \r

Inputs Required\r

\r

• The owning module and configuration or admin surface being changed.\r
• Desired cache behavior, env structure, or backend visibility outcome.\r
• Related controllers, menus, or config keys.\r
• Validation path for backend or runtime behavior.\r \r

Expected Output\r

\r

• Updated module configuration, cache, or backend permission wiring.\r
• Validation evidence for the changed admin or runtime path.\r
• Documentation note when admin usage or config behavior changed.\r \r

Validation\r

\r

• Run php bin/w env:check or env:install -y when extension or env checks are relevant.\r
• Run setup or route refresh commands when backend wiring changed.\r
• Verify backend menu visibility and controller access behavior.\r
• Verify cache read, write, and invalidation behavior through the intended module flow.\r \r

Constraints\r

\r

• Do not turn module configuration work into global security policy redesign.\r
• Do not instantiate cache drivers directly.\r
• Do not leave backend menu visibility disconnected from permission annotations.\r
• Do not hide required operational setup steps from the module README.\r \r