<?php

use App\Models\Operator;
use App\Models\User;
use Illuminate\Support\Facades\Auth;

it('signs the operator out without destroying a portal session sharing the same browser', function () {
    // Shared/fallback mode (this suite's default, ADMIN_HOSTS="" — also this
    // VM's own mode) is exactly where this bites: the console and the portal
    // answer on the same host, so both guards keep their login key in ONE
    // session. A customer signed in beforehand, in the same browser, must
    // not be silently logged out just because an operator elsewhere in that
    // same session signs out of the console.
    //
    // Auth::guard(...)->login() rather than actingAs(): actingAs() only sets
    // an in-memory user on the guard object, it never writes to the session
    // — so it cannot tell session()->invalidate() and session()->regenerate()
    // apart. login() does the same session write a real sign-in performs.
    $operator = Operator::factory()->role('Owner')->create();
    $customer = User::factory()->create();

    Auth::guard('web')->login($customer);
    Auth::guard('operator')->login($operator);

    $this->post(route('admin.logout'))->assertRedirect(route('admin.login'));

    // Auth::guard('web') is still the SAME cached guard instance from the
    // login() call above — its check() would say "authenticated" from its
    // own in-memory $user property regardless of what happened to the
    // session, which is exactly the blind spot that would make this
    // assertion pass whether the fix is there or not. forgetGuards() drops
    // that cache, forcing the next guard() call to rebuild from the CURRENT
    // session data — the same thing a genuinely new request would do.
    Auth::forgetGuards();

    expect(Auth::guard('operator')->check())->toBeFalse()
        ->and(Auth::guard('web')->check())->toBeTrue()
        ->and(Auth::guard('web')->id())->toBe($customer->id);
});