\r \r

Role\r

\r This skill owns backend ACL structure, menu visibility rules, and administrative access safety in WelineFramework. It ensures backend surfaces are exposed only through consistent permission wiring and predictable menu behavior.\r \r

When To Use\r

\r

• Use for backend ACL design, menu.xml, permission annotations, menu visibility, and admin-surface access review.\r
• Use for keywords such as ACL, menu, backend permission, admin access, source id, and menu hierarchy.\r
• Use when an admin feature must be protected or an existing permission path behaves incorrectly.\r \r

Source Material\r

\r

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

Responsibilities\r

\r

• Design and repair admin permission paths and menu relationships.\r
• Keep controller permission annotations aligned with menu source definitions.\r
• Distinguish menu-visible permissions from permission-only controls.\r
• Prevent accidental admin exposure caused by missing or inconsistent ACL wiring.\r \r

Workflow\r

\r

1. Identify the target backend feature, menu path, and required access scope.\r
2. Read the current menu.xml structure and controller permission annotations together.\r
3. Align menu nesting, source identifiers, and controller-level ACL declarations.\r
4. Confirm whether the permission should be menu-visible or control-only.\r
5. Validate backend visibility and denied-access behavior through the real admin path.\r
6. Record any admin documentation updates if behavior changed.\r
7. Escalate broader auth or session design concerns to the relevant security or runtime role.\r \r

Weline Rules\r

\r

• Keep module boundaries intact.\r
• Do not hardcode user-facing text.\r
• Use i18n for user-facing text.\r
• Prefer small, isolated, testable changes.\r
• Provide HTTP or backend validation evidence where relevant.\r \r

Inputs Required\r

\r

• The owning module, backend page, and intended permission scope.\r
• Existing menu structure and controller annotations.\r
• Expected role-based access behavior.\r
• Validation path for allowed and denied access.\r \r

Expected Output\r

\r

• Corrected or newly defined ACL and backend menu wiring.\r
• Evidence showing both visibility and access-control behavior.\r
• Any required documentation note for admin behavior changes.\r \r

Validation\r

\r

• Check that menu.xml hierarchy and controller permission annotations align.\r
• Verify admin users with and without the permission see the correct behavior.\r
• Verify menu-visible items use the correct permission type.\r
• Verify the backend path fails safely when access is denied.\r \r

Constraints\r

\r

• Do not treat menu visibility as a substitute for real controller permission control.\r
• Do not leave source identifiers inconsistent across menu and controller layers.\r
• Do not redesign session or auth internals under this skill unless the task explicitly requires it.\r
• Do not expose new admin surfaces without validation.\r \r