This is a critical finding. Line 162: (new $class())->handle($request, $next) — the MiddlewarePipeline instantiates middleware with new $class() — no constructor arguments are passed.

Looking at Router.php line 111 — the docblock shows an example: 'App\\Middleware\\RoleMiddleware:couple' — this is a colon-separated hint in the class name string.

This means RoleMiddleware must parse its own role constraint from the class name string — or the pipeline needs to handle the colon-suffix notation. Let me look more carefully at the wrap() method — it does new $class() directly from the raw class name string. If the string is 'App\\Middleware\\RoleMiddleware:couple', then class_exists('App\\Middleware\\RoleMiddleware:couple') would return false.

This is a documentation conflict: The Router docblock (line 111) shows 'App\\Middleware\\RoleMiddleware:couple' syntax but the MiddlewarePipeline wrap() does new $class() with the raw string — meaning the colon-suffix syntax isn't actually implemented.

Per the Conflict Rules, I must STOP, reference the conflict, and wait for approval before proceeding.

⛔ STOP — Documentation Conflict Detected
I have discovered a conflict between two kernel documents that affects the core design of RoleMiddleware. I cannot resolve this by guessing.

Conflict Reference
Document 1: app/core/Router.php — Line 111 (docblock example)

php
$router->group('/app/couple', function ($router) {
    $router->get('/dashboard', 'CoupleDashboardController@index', []);
    // Registers: GET /app/couple/dashboard
}, ['App\\Middleware\\AuthMiddleware', 'App\\Middleware\\RoleMiddleware:couple']);
This shows a colon-suffix notation — RoleMiddleware:couple — implying RoleMiddleware receives its allowed role via a colon-separated suffix in the class name string.

Document 2: app/core/MiddlewarePipeline.php — Line 162

php
(new $class())->handle($request, $next);
The pipeline instantiates middleware using new $class() with the raw class name string — no argument parsing, no colon handling. If $class = 'App\\Middleware\\RoleMiddleware:couple', then class_exists('App\\Middleware\\RoleMiddleware:couple') returns false and the middleware fails to load.

The Conflict Explained
Aspect	Router docblock	MiddlewarePipeline wrap()
Class name format in route array	'RoleMiddleware:couple' (colon-suffix)	new $class() — expects a clean FQN only
Constructor args for roles	Implied via colon suffix	Not supported — zero-arg new $class()
Effect if colon-suffix is used	Routes registered with role:couple syntax	class_exists('Class:couple') → false → error logged → request dies
Possible Resolutions — I need your decision
Option A — Ignore the colon syntax in the docblock (treat it as an illustrative-only example) RoleMiddleware reads the allowed role(s) from the session path prefix (e.g., parses /app/couple/ from $request->getPath()). No constructor argument. The route docblock example is non-normative.

Option B — Extend MiddlewarePipeline::wrap() to support colon-suffix parsing wrap() splits 'RoleMiddleware:couple' into class 'RoleMiddleware' and arg 'couple', then calls new $class($arg)->handle(...). However, this would modify a frozen kernel file (MiddlewarePipeline.php) — which is explicitly prohibited by SPRINT2_PLANNING §7.

Option C — RoleMiddleware is registered with a dedicated class per role Create CoupleRoleMiddleware, CrewRoleMiddleware, AdminRoleMiddleware as separate classes. Each hardcodes its own allowed role internally. No constructor args needed. However, this would create files not listed in AUTH-004's documented scope — also prohibited without approval.

Option D — RoleMiddleware infers the allowed role from the URL prefix /app/couple/* → role must be couple; /app/crew/* → crew; /app/admin/* → super_admin. The middleware reads $request->getPath() and resolves the required role from the URL structure. No constructor arguments needed. This is the simplest zero-kernel-modification approach.

I cannot proceed until you select a resolution. Which option do you approve?