# Exemplo de trecho e de análise (formato esperado)

Ilustração do nível de detalhe exigido. Não é documento de unidade; é referência de
forma. Trechos abaixo foram lidos no código atual.

## Exemplo 1 — ordem de registro do fallback

```php
// V2/Core/Providers/V2ServiceProvider.php:174-191 — serviços registram migrations,
// views no namespace v2-service-<slug> e rotas próprias.
foreach ($services as $servicePath) {
    // ...
    $this->loadViewsFrom($viewPath, 'v2-service-' . $serviceNamespace);
    $this->mapServiceRoutes($serviceName, $servicePath);
}
```

```php
// V2/Core/Providers/V2ServiceProvider.php:135-142 — o fallback é registrado depois dos
// módulos e antes dos serviços; os lookups de nome são atualizados ao final do boot.
// 1.5 Fallback Route (deve ser registrado APÓS todos os módulos,
//     para que NUNCA bloqueie rotas específicas como /noticias, /busca, etc.)
$this->mapFallbackRoutes();

$this->app->booted(function () {
    $this->app['router']->getRoutes()->refreshNameLookups();
    $this->app['router']->getRoutes()->refreshActionLookups();
});
```

**Efeito.** `GET /{slug}` (`V2/Core/Routes/fallback.php:19-22`) só é consultada se nenhum
módulo registrou aquele slug; nesse caso `BasicPagePortalController@runtime` tenta
resolver uma página dinâmica e, se não existir, o 404 natural acontece.

**Abordagem.** O provider varre `V2/Modules` por grupo e módulo, registra views no
namespace `v2-<slug>` (`:123`), carrega migrations e rotas e só então registra o
catch-all (`:137`). Ao final, `refreshNameLookups()`/`refreshActionLookups()` (`:141-142`)
reconstroem os mapas de `route()`/ação, substituindo o comportamento padrão do
`RouteServiceProvider`.

**Particularidade.** A ordem é o contrato: registrar o fallback antes produziria
sombreamento de rotas de módulo. Serviços entram **depois** do fallback (`:169-191`);
como suas rotas usam prefixos (`cms/...`, `api/...`), não colidem com `/{slug}` — mas a
ordem é uma dependência implícita que a reimplementação precisa preservar. O `where('slug', '[a-z0-9-]+')` impede que o catch-all
capture caminhos com barras. É um caso em que "funciona nos testes" e "funciona em
produção" dependem da mesma ordem de boot documentada aqui.

**Integrabilidade.** Um módulo novo não precisa declarar nada para ser resolvido antes do
fallback — basta registrar rotas em `Routes/web.php`. Já uma página que dependa de slug
livre deve ser criada como `BasicPage` (tabela `v2_basic_pages`), não como rota estática.
Anti-uso: registrar `/{slug}` dentro de um módulo; o resultado depende da ordem alfabética
e quebra ao renomear módulos.

---

## Exemplo 2 — filtragem da sidebar por grupo e permissão

```php
// V2/Core/ViewComposers/SidebarComposer.php:35-65 — o menu esconde grupos e aplica RBAC.
if (strtoupper($group) === 'API') {          // módulos de API nunca aparecem
    unset($moduleConfigs[$moduleName]);
    continue;
}
if (strtoupper($group) === 'SUPPORT') {      // suporte só para o e-mail configurado
    if ($user->email !== config('v2.support.email')) {
        unset($moduleConfigs[$moduleName]);
        continue;
    }
}
// ...
$userPermissions = $permissionService->getUserPermissions($user);
$permission = $userPermissions[$moduleName] ?? 'none';
if ($permission === 'none') {
    unset($moduleConfigs[$moduleName]);
}
```

**Efeito.** O usuário vê apenas grupos/módulos permitidos; `API` é sempre oculto;
`SUPPORT` é visível apenas para `config('v2.support.email')`; `super-admin` ignora o RBAC.
Módulo sem permissão explícita cai em `none` e desaparece.

**Abordagem.** O `ModuleProvider` de cada módulo fornece `group`, `title`, `route` e
submenus; o composer agrupa, ordena por título e achata módulos com um único submenu sem
nível 2 (`flattenSingleSubmodules`).

**Particularidade.** A chave de permissão é o **nome do módulo**, não o slug da rota; um
módulo renomeado perde a permissão existente. `active_pattern` é usado pela view, não pelo
composer.

**Integrabilidade.** Para expor um módulo: implementar `ModuleProviderInterface`, escolher
`group` diferente de `API`, definir `position`/`route` e conceder a permissão com chave
igual ao nome do diretório do módulo. Anti-uso: criar módulo com `group => 'Support'`
esperando acesso geral — ele fica restrito ao e-mail de suporte.