\r \r

Role\r

\r This skill owns session configuration safety, area isolation, and protection of sensitive request or user state. It focuses on preventing state leakage, unsafe session handling, and configuration patterns that weaken data protection.\r \r

When To Use\r

\r

• Use for session configuration, auth-area separation, sensitive state handling, and session-backed data protection.\r
• Use for keywords such as session config, login isolation, session key, AreaConfig, state leak, and sensitive data.\r
• Use when user state or admin state may leak across areas or requests.\r \r

Source Material\r

\r

• AI-ENTRY.md\r
• CLAUDE.md\r
• dev/ai/skills/session-development/SKILL.md\r
• dev/ai/skills/config-and-env/SKILL.md\r
• dev/ai/skills/weline-framework-runtime/SKILL.md\r \r

Responsibilities\r

\r

• Keep frontend, backend, and other areas isolated in session behavior.\r
• Review session and config changes for state-leak or privilege-leak risk.\r
• Protect sensitive data from unsafe storage or request-scope leakage.\r
• Require framework abstractions instead of direct global session manipulation.\r \r

Workflow\r

\r

1. Confirm the area, user state, and sensitive data affected by the task.\r
2. Read the current session and config path before changing behavior.\r
3. Implement fixes through framework session factories, area config, and controlled config paths.\r
4. Check whether state-reset or runtime isolation expectations are relevant under WLS.\r
5. Validate through real login, logout, or protected-path behavior.\r
6. Record residual risk if data retention or session migration concerns remain.\r
7. Coordinate with runtime and QA roles for high-risk validation paths.\r \r

Weline Rules\r

\r

• Do not pollute global state.\r
• Use framework session abstractions instead of raw $_SESSION.\r
• Keep module boundaries intact.\r
• Prefer small, isolated, testable changes.\r
• Provide HTTP or runtime validation evidence where relevant.\r \r

Inputs Required\r

\r

• The affected session or auth area.\r
• The sensitive data or state boundary at risk.\r
• Existing configuration keys and session classes involved.\r
• Validation path for allowed and denied access or state transitions.\r \r

Expected Output\r

\r

• A safer session or config implementation that preserves area isolation.\r
• Evidence showing state is correctly isolated and protected.\r
• Notes about residual risk or migration impact if relevant.\r \r

Validation\r

\r

• Test login and protected-path behavior across the affected areas.\r
• Confirm state does not leak across frontend, backend, or request boundaries.\r
• Confirm no direct raw session manipulation bypasses framework abstractions.\r
• Confirm sensitive config behavior is exercised through the real flow.\r \r

Constraints\r

\r

• Do not weaken isolation for convenience in shared flows.\r
• Do not store or move sensitive state through ad hoc globals.\r
• Do not skip runtime-aware validation when state persistence is part of the issue.\r
• Do not change auth behavior silently without documenting the effect on consumers.\r \r