feat: prepare Dokploy staging and production deploy pipeline

Publish immutable FrankenPHP images to GHCR, auto-deploy staging after CI, and promote the same digest to production with smoke, backup, and rollback docs. Co-authored-by: Cursor <cursoragent@cursor.com>
2026-08-01 23:39:32 -03:00
225 changed files with 907 additions and 9101 deletions
--- a/.env.example
+++ b/.env.example
@@ -8,7 +8,7 @@ APP_URL=http://localhost
 APP_LOCALE=pt_BR
 APP_FALLBACK_LOCALE=pt_BR
 APP_FAKER_LOCALE=pt_BR
-APP_TIMEZONE=America/Sao_Paulo
+APP_TIMEZONE=America/Fortaleza
 # Freeze application clock outside production (visual regression / deterministic seeds).
 # Example: APP_FROZEN_NOW=2026-03-15T12:00:00-03:00
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -14,7 +14,7 @@ env:
  APP_KEY: base64:NXm/6jIyFcDGHoMKGc5QZuSaq0dRZFYPg1Isuy1fNvE=
  APP_LOCALE: pt_BR
  APP_FALLBACK_LOCALE: pt_BR
-  APP_TIMEZONE: America/Sao_Paulo
+  APP_TIMEZONE: America/Fortaleza
  BCRYPT_ROUNDS: 4
  CACHE_STORE: database
  DB_CONNECTION: pgsql
@@ -31,8 +31,7 @@ jobs:
    name: static
    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v4
      - run: cp .env.example .env
      - uses: shivammathur/setup-php@v2
        with:
@@ -40,7 +39,7 @@ jobs:
          extensions: dom, curl, libxml, mbstring, zip, pcntl, pdo, pdo_pgsql, bcmath, intl, sodium, gd
          coverage: none
-      - uses: actions/cache@v5
+      - uses: actions/cache@v4
        with:
          path: ~/.composer/cache/files
          key: composer-${{ runner.os }}-${{ hashFiles('**/composer.lock') }}
@@ -51,70 +50,29 @@ jobs:
      - run: composer pint:check
      - run: composer phpstan
      - run: composer audit
      # audit-level=high: package.json has no runtime `dependencies` today (npm
      # itself reports prod:1, 0 vulnerabilities), so this is currently a
      # vacuous forward guard rather than an active protection. `high` is
      # chosen deliberately over `low`/`moderate` so that once a real runtime
      # JS dependency is added, the gate flags exploitable issues without
      # becoming noisy on every transitive dev-only advisory.
      - run: npm audit --omit=dev --audit-level=high
  unit:
    name: unit
    runs-on: ubuntu-latest
    # Postgres is required here (not just in `feature`) because the
    # Domain/Application coverage gate below runs the Feature suite too: the
    # App\Application\Queries\Marketing\* classes are only exercised through
    # Feature (HTTP) tests today, so a Unit-only coverage run would undercount
    # them well under the 80% threshold.
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_DB: amare_test
          POSTGRES_USER: amare
          POSTGRES_PASSWORD: secret
        ports:
          - 5432:5432
        options: >-
          --health-cmd "pg_isready -U amare -d amare_test"
          --health-interval 5s
          --health-timeout 5s
          --health-retries 10
    steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v4
      - run: cp .env.example .env
      - uses: shivammathur/setup-php@v2
        with:
          php-version: "8.4"
          extensions: dom, curl, libxml, mbstring, zip, pcntl, pdo, pdo_pgsql, bcmath, intl, sodium, gd
-          coverage: pcov
+          coverage: none
-      - uses: actions/cache@v5
+      - uses: actions/cache@v4
        with:
          path: ~/.composer/cache/files
          key: composer-${{ runner.os }}-${{ hashFiles('**/composer.lock') }}
          restore-keys: composer-${{ runner.os }}-
      - uses: actions/cache@v5
        with:
          path: ~/.npm
          key: npm-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: npm-${{ runner.os }}-
      - run: composer install --no-interaction --prefer-dist
      - run: npm ci
      - run: npm run build
      - run: composer test:unit
      - run: php artisan migrate --force
      # Domain/Application coverage gate (SPEC.md L2351, 80% minimum). Scoped
      # via phpunit.coverage.xml rather than editing the project-wide
      # phpunit.xml <source> block, which stays covering all of app/ for
      # every other test/coverage invocation. app/Domain currently holds only
      # the DomainModule placeholder (zero executable lines), so in practice
      # this gates app/Application until Domain gains real logic.
      - run: composer test:coverage
  feature:
    name: feature
@@ -134,8 +92,7 @@ jobs:
          --health-timeout 5s
          --health-retries 10
    steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v4
      - run: cp .env.example .env
      - uses: shivammathur/setup-php@v2
        with:
@@ -143,13 +100,13 @@ jobs:
          extensions: dom, curl, libxml, mbstring, zip, pcntl, pdo, pdo_pgsql, bcmath, intl, sodium, gd
          coverage: none
-      - uses: actions/cache@v5
+      - uses: actions/cache@v4
        with:
          path: ~/.composer/cache/files
          key: composer-${{ runner.os }}-${{ hashFiles('**/composer.lock') }}
          restore-keys: composer-${{ runner.os }}-
-      - uses: actions/cache@v5
+      - uses: actions/cache@v4
        with:
          path: ~/.npm
          key: npm-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
@@ -179,8 +136,7 @@ jobs:
          --health-timeout 5s
          --health-retries 10
    steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v4
      - run: cp .env.example .env
      - uses: shivammathur/setup-php@v2
        with:
@@ -188,13 +144,13 @@ jobs:
          extensions: dom, curl, libxml, mbstring, zip, pcntl, pdo, pdo_pgsql, bcmath, intl, sodium, gd
          coverage: none
-      - uses: actions/cache@v5
+      - uses: actions/cache@v4
        with:
          path: ~/.composer/cache/files
          key: composer-${{ runner.os }}-${{ hashFiles('**/composer.lock') }}
          restore-keys: composer-${{ runner.os }}-
-      - uses: actions/cache@v5
+      - uses: actions/cache@v4
        with:
          path: ~/.npm
          key: npm-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
@@ -221,7 +177,7 @@ jobs:
            -e APP_URL=http://127.0.0.1:8000 \
            -e APP_LOCALE=pt_BR \
            -e APP_FALLBACK_LOCALE=pt_BR \
-            -e APP_TIMEZONE=America/Sao_Paulo \
+            -e APP_TIMEZONE=America/Fortaleza \
            -e APP_FROZEN_NOW="${APP_FROZEN_NOW}" \
            -e DB_CONNECTION=pgsql \
            -e DB_HOST=host.docker.internal \
@@ -268,7 +224,7 @@ jobs:
    name: container
    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v4
      - name: Build production image
        run: docker build -t amare-app:ci .
--- a/.gitignore
+++ b/.gitignore
@@ -18,7 +18,6 @@
 /public/fonts-manifest.dev.json
 /public/hot
 /public/storage
 /tests/Browser/Screenshots
 /storage/*.key
 /storage/pail
 /vendor
--- a/.husky/pre-commit
+++ b/.husky/pre-commit
@@ -1,3 +0,0 @@
 #!/usr/bin/env sh
 composer pint:check && composer phpstan
--- a/.husky/pre-push
+++ b/.husky/pre-push
@@ -1,33 +0,0 @@
 #!/usr/bin/env sh
 # Abort push when the test database is unreachable, so broken code never
 # reaches CI. Test DB settings come from phpunit.xml.
 php -r '
 $xml = @simplexml_load_file("phpunit.xml");
 if ($xml === false) {
    fwrite(STDERR, "phpunit.xml not found — aborting pre-push.\n");
    exit(1);
 }
 $defaults = ["DB_HOST" => "127.0.0.1", "DB_PORT" => "5432", "DB_DATABASE" => "amare_test", "DB_USERNAME" => "amare", "DB_PASSWORD" => "secret"];
 $env = [];
 foreach ($xml->php->env as $node) {
    $name = (string) $node["name"];
    if (isset($defaults[$name])) {
        $env[$name] = (string) $node["value"];
    }
 }
 $config = array_merge($defaults, $env);
 $dsn = sprintf("pgsql:host=%s;port=%s;dbname=%s", $config["DB_HOST"], $config["DB_PORT"], $config["DB_DATABASE"]);
 try {
    new PDO($dsn, $config["DB_USERNAME"], $config["DB_PASSWORD"], [PDO::ATTR_TIMEOUT => 3]);
 } catch (PDOException $e) {
    fwrite(STDERR, "\033[31mPostgreSQL is unreachable on {$config["DB_HOST"]}:{$config["DB_PORT"]} (db: {$config["DB_DATABASE"]}).\033[0m\n");
    fwrite(STDERR, "Start it with: docker compose up -d postgres\n");
    fwrite(STDERR, "Then retry the push.\n");
    exit(1);
 }
 ' || exit 1
 composer test:unit && composer test:feature
--- a/.impeccable/surfaces/resources-views-pages-home-blade-php.md
+++ b/.impeccable/surfaces/resources-views-pages-home-blade-php.md
@@ -12,6 +12,5 @@ related_targets: ["resources/views/pages/services/index.blade.php","resources/vi
 - **Action, proof, and constraints:** ação principal é enviar briefing inicial. Prova disponível: cinco depoimentos reais de casamentos, com nomes e datas; publicação depende de autorização final. Não inventar cases corporativos, credenciais ou resultados. Fotografias permanecem ilustrativas e marcadas até chegada de acervo autorizado.
 - **Chosen direction:** “Dossiê Editorial do Evento”. Home funciona como capa e índice; serviços viram capítulos, portfólio vira cadernos de caso, sobre vira perfil editorial e contato vira ficha de briefing. Sistema visual global segue Heritage Editorial em DESIGN.md.
 - **Memorable moment:** coração facetado atua como selo editorial enquanto índice discreto acompanha capítulos e deixa serviço, método e próximo passo visíveis sem transformar página em dashboard.
 - **Motion thesis (Dossiê vivo):** Home recebe abertura autoral (selo → título → recorte de imagem → CTAs, ≤800ms). Índice lateral no desktop e linha de progresso no mobile acompanham capítulos. Serviços, portfólio e sobre usam abertura curta e revelações discretas; contato, privacidade e erros permanecem quase estáticos. Sem parallax, loops, bounce ou scroll-jacking. `prefers-reduced-motion` entrega estado final imediato.
 - **Responsive and interaction:** spreads assimétricos no desktop; sequência linear no mobile. CTAs recorrentes, navegação clara, formulário com loading, erro e sucesso, foco visível e suporte a movimento reduzido.
 - **Unresolved:** logo transparente ou vetorial; fotografias autorizadas; WhatsApp, e-mail e Instagram oficiais; textos jurídicos; autorização dos depoimentos; provas reais de eventos corporativos.
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -7,26 +7,14 @@ This is a Laravel 13 application for an event-planning consultancy. Application
 ## Build, Test, and Development Commands
 - `composer setup` installs PHP and npm dependencies, creates `.env`, migrates, and builds assets.
- `docker compose up -d postgres` starts the local PostgreSQL service. `docker compose up -d` (no service name) also builds and starts the `app` service — a local FrankenPHP container for parity with staging/production, see README.md.
+- `docker compose up -d` starts the local PostgreSQL service.
 - `composer dev` runs Laravel, the queue listener, logs, and Vite together.
 - `npm run build` creates the production frontend bundle.
- `composer quality` runs formatting checks, PHPStan level 5, PHP + npm dependency audits, and every test suite.
+- `composer quality` runs formatting checks, PHPStan level 5, dependency audit, and every test suite.
 - `composer test:unit`, `composer test:feature`, or `composer test:browser` run focused suites.
 - `composer test:coverage` runs the Domain/Application coverage gate (80% minimum, scoped via `phpunit.coverage.xml`) used by CI's `unit` job. Requires a coverage driver (`pcov` or `xdebug`); fails with "No code coverage driver available" without one — that's an environment gap, not a broken repo.
 Feature and browser tests require the `amare_test` PostgreSQL database configured in `phpunit.xml`.
 ## Worktrees
 Always work in a git worktree created from the `main` ref — never modify `main` directly and never commit from the primary working tree. Create a dedicated worktree per feature/branch with `git worktree add -b <branch> <path> main`. On finishing work, create a PR, watch CI until green, then merge it. Clean up the worktree with `git worktree remove` after merge.
 ## Git Hooks (husky)
 Hooks live in `.husky/` and auto-install on any plain `npm install` via the `prepare` script. Note `composer setup` runs `npm install --ignore-scripts`, which skips hook installation — after setup, run `npm install` once (or `npx husky`) to activate hooks.
 - `pre-commit`: runs `composer pint:check` and `composer phpstan`.
 - `pre-push`: gates on the `amare_test` database (settings parsed from `phpunit.xml`), blocks the push with a `docker compose up -d postgres` hint when Postgres is unreachable, then runs `composer test:unit` and `composer test:feature`. Browser tests are CI-only (FrankenPHP container).
 ## Coding Style & Naming Conventions
 Follow PSR-4 and Laravel conventions: PascalCase classes, camelCase methods, and snake_case database columns. Use four spaces (two in YAML, except four in Compose files), LF endings, and UTF-8 as defined by `.editorconfig`. Every project-owned PHP file must place `declare(strict_types=1);` immediately after `<?php`. Keep domain code independent of Filament and Livewire. Run `composer pint` to format and `composer phpstan` before review.
@@ -42,23 +30,3 @@ History follows Conventional Commit-style subjects, for example `feat: Fase 0
 ## Security & Configuration
 Copy `.env.example`; never commit secrets or production credentials. Development seed credentials are local-only. Validate uploads and authorization through Laravel policies, and run `composer security-audit` after dependency changes.
 ## Design Context
 Amare: refined, humane, precise — Heritage Editorial. Trust-first, both private + corporate audiences. Never generic wedding decor (hearts/gold/script) or AI-slop. Real proof only.
 The design system lives in `DESIGN.md` (palette, typography, layout, do's and don'ts) and positioning in `PRODUCT.md`; tokens are implemented in `resources/css/tokens.css` and asserted by `tests/Feature/PublicSite/HeritageEditorialTokensTest.php`. Per-surface briefs live in `.impeccable/surfaces/`. The Impeccable skill itself is vendored at `.github/skills/impeccable/SKILL.md` — its setup step reads `PRODUCT.md`, `DESIGN.md`, and the matching surface brief.
 ## Agent skills
 ### Issue tracker
 Issues live in Linear, driven through the Linear MCP tools. See `docs/agents/issue-tracker.md` for workspace, team, and tool conventions. The repo ships no `.mcp.json`, so the Linear MCP has to be enabled for the session before those tools exist — if it isn't, report that instead of silently falling back to another tracker.
 ### Triage labels
 Default vocabulary: `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`. See `docs/agents/triage-labels.md`.
 ### Domain docs
 Single-context repo. There is no `CONTEXT.md` — the domain is documented in `SPEC.md` (§8 is the domain model and database schema) and `PRODUCT.md`, with current capabilities described per-capability under `openspec/specs/`. `docs/adr/README.md` is an index only: ADR-001 through ADR-010 are decided in `SPEC.md` §21, and there are no standalone ADR files. `docs/agents/domain.md` describes the generic `CONTEXT.md`/`CONTEXT-MAP.md` layout that the engineering skills look for and instructs them to proceed silently when it's absent, which is the case here.
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1,81 +0,0 @@
 # CLAUDE.md
 This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
@AGENTS.md
 If the import above did not load, read `AGENTS.md` at the repo root now — it is the primary contract.
 `AGENTS.md` (imported above) is the primary contract: structure, commands, style, testing, husky hooks, commit/PR rules. This file records the cross-file architecture and environment facts that are not obvious from any single file.
 ## Non-negotiables (repeated from AGENTS.md because breaking them is expensive)
 - Never modify or commit from the primary working tree on `main`. Create a worktree per branch: `git worktree add -b <branch> <path> main`.
 - Every project-owned PHP file starts with `declare(strict_types=1);` immediately after `<?php`.
 - Browser tests are CI-only (they run against a FrankenPHP container built by `docker build`, not `artisan serve`).
 ## Environment note
 PHP and Composer are **not on PATH** in this environment, and `vendor/` and `node_modules/` are absent. Every `composer …` / `php artisan …` command in `AGENTS.md` and `README.md` assumes a PHP 8.4+ runtime with Composer 2 installed. Verify the toolchain before promising a command ran.
 ## Git remote auth — two GitHub accounts
 `origin` is `git@github.com:manoel-freitas/amore-site.git`, owned by the **`manoel-freitas`** account. The machine's default SSH identity is a different account (`manoel-freitas-neto`) that cannot see this repo, so pushes fail with `ERROR: Repository not found.` — an access error that reads like a missing repo.
 - Correct key: `~/.ssh/id_github_pessoal`. Verify with `ssh -i ~/.ssh/id_github_pessoal -o IdentitiesOnly=yes -T git@github.com` → should greet `Hi manoel-freitas!`.
 - The repo has `core.sshCommand = ssh -i ~/.ssh/id_github_pessoal -o IdentitiesOnly=yes` set locally, so plain `git push` works. If that config is lost, restore it instead of editing the remote URL.
 - **`gh` authenticates separately**, by token rather than SSH key. As of 2026-08-10 it is logged in as `manoel-freitas`, so `gh pr create` / `gh repo view` work. Confirm with `gh auth status` before assuming: if it reports `manoel-freitas-neto`, that account cannot see this repo and every `gh` call fails on it. Recovering needs an interactive `gh auth login` (or `gh auth switch` with both accounts added), so ask the user to run it.
 ## Request spine for the public site
 Adding or changing a public page follows one path — controllers never query models directly:
 ```
 routes/web.php
  → App\Http\Controllers\PublicSite\*Controller   (thin; injects a query object)
    → App\Application\Queries\Marketing\*         (invokable, final; owns all Eloquent access)
      → App\Application\Data\*                    (DTO: HomeContent, PageMeta)
        → resources/views/pages/*.blade.php
 ```
 `HomeController` + `GetHomeContent` together show the shape. Page-level SEO is built with `PageMeta::forPage(canonical:, settings:, jsonLd:)`.
 `AppServiceProvider::boot()` registers a **View composer on `layouts.public`** that auto-injects `siteSettings` and `pageMeta` when the view didn't supply them — new pages do not have to pass them manually.
 Site-wide content is a singleton row reached via `SiteSetting::instance()`. Publication state comes from the `HasPublication` concern (`->published()` scope).
 ## Architecture boundary — what is actually enforced
 `tests/Architecture/DomainBoundariesTest.php` enforces only:
 - `App\Domain` uses strict types and never `dd`/`dump`/`die`.
 - `App\Domain` never depends on `App\Filament` or `App\Livewire`.
 `App\Application` is **not** covered by that rule. `app/Domain/` currently holds a single placeholder (`DomainModule.php`); business reads live in `app/Application/Queries`. Extend the arch test when you add a boundary.
 ## Visual regression — read before touching baselines
 - Baselines are committed `.snap` files under `tests/.pest/snapshots/Browser/VisualRegressionTest/`.
 - `tests/Browser/Screenshots/` is gitignored — it only holds diff output.
 - Regenerate with `composer visual:update`.
 - **Baselines are CI-parity artifacts.** CI runs the browser suite against a `docker build`-produced FrankenPHP container (see the `browser` job in `.github/workflows/ci.yml`), so baselines regenerated on macOS against a local server will be rejected by CI. Commit `4578457` exists because of this.
 Determinism relies on three cooperating pieces:
 - `APP_FROZEN_NOW` → `CarbonImmutable::setTestNow()` in `AppServiceProvider::freezeClockWhenConfigured()` (no-op in production).
 - `Database\Seeders\VisualContentSeeder::FROZEN_NOW` — the value the browser tests and the CI job both pin to.
 - `Tests\Support\StableScreenshot` — forces Arial, disables transitions/animations, scrolls the page to settle lazy images, and avoids the flaky `networkidle` wait.
 ## Other things that bite
 - **Livewire/Filament temp uploads are pinned to the `local` disk** when `FILESYSTEM_DISK=r2`, because the S3 driver would make the browser PUT straight to R2 and hit CORS. Final media still lands on `r2` via `App\Support\PublicImageUploadRules`. Set `LIVEWIRE_TEMPORARY_FILE_UPLOAD_DISK` explicitly to override.
 - **Contact form is rate limited**: named limiter `contact-briefing`, 5/min per IP, registered in `AppServiceProvider` and applied in `routes/web.php`.
 - **Filament 5 nested resource layout**: resources are split into `app/Filament/Resources/<Resource>/{Pages,Schemas,Tables,RelationManagers}` rather than a flat resource class. Follow the existing shape in `Resources/PortfolioCases/`.
 - **Everything user-facing is pt-BR**: routes are `/servicos`, `/portfolio`, `/portfolio/{slug}`, `/sobre`, `/privacidade`, `/contato`. `APP_LOCALE=pt_BR`, `APP_TIMEZONE=America/Sao_Paulo` (`config/app.php:68`).
 - **Design tokens** live in `resources/css/tokens.css` (Heritage Editorial; see `DESIGN.md`). `tests/Feature/PublicSite/HeritageEditorialTokensTest.php` reads that file and asserts the exact hex values, `EB Garamond`, zero border radii, `--amare-container-max: 1120px`, and the *absence* of shadow tokens — so any token edit is a deliberate test change too. Motion lives in `resources/js/motion.js` and is asserted by `tests/Feature/PublicSite/MotionMarkupTest.php` + `tests/Browser/MotionTest.php`.
 ## Navigating the normative docs
 - `SPEC.md` is the product source of truth and is ~2600 lines. **Never read it whole** — `grep -n '^## ' SPEC.md` and read the numbered section you need (e.g. 7 functional requirements, 8 domain model/DB, 9 technical architecture, 13 test strategy, 15 FrankenPHP deploy).
 - `openspec/` is the channel for planned change: `openspec/specs/<capability>/spec.md` for current capabilities, `openspec/changes/<change>/{proposal,design,tasks}.md` for in-flight work. `openspec/config.yaml` holds the precedence rule (product owner > `SPEC.md` > ADRs > tests > conventions) and repo-wide constraints (YAGNI, money as BIGINT centavos, no generic repositories/BaseService).
 - `PRODUCT.md` for positioning, `DESIGN.md` for the design system, `docs/conventions/php-strict-types.md`, `docs/deployment/dokploy.md` for the deploy runbook.
--- a/4
+++ b/4
@@ -23,10 +23,6 @@ RUN npm ci
 COPY vite.config.js ./
 COPY resources ./resources
 COPY public ./public
 # resources/css/filament/admin/theme.css imports Filament's own uncompiled CSS,
 # so the Vite build needs those files present. Only Filament's subtree is copied
 # rather than all of vendor/, to keep this stage's context small.
 COPY --from=composer /app/vendor/filament ./vendor/filament
 RUN npm run build
 FROM dunglas/frankenphp:1-php${PHP_VERSION}-bookworm AS runtime
--- a/README.md
+++ b/README.md
@@ -4,7 +4,7 @@ Aplicação Laravel 13 para assessoria de eventos (Fase 0 — Fundação).
 ## Requisitos
- PHP 8.4 com extensões `pdo_pgsql`, `intl`, `mbstring`, `zip`, `sodium` (canônico do `Dockerfile` e do CI; `composer.json` aceita `^8.3`)
+- PHP 8.5+ com extensões `pdo_pgsql`, `intl`, `mbstring`, `zip`, `sodium`
 - Composer 2.x
 - Node.js 22+ e npm
 - Docker e Docker Compose
@@ -18,10 +18,10 @@ cp .env.example .env
 php artisan key:generate
 ```
-2. Suba o PostgreSQL (requer o `.env` do passo 1 — o serviço `app` referencia esse arquivo via `env_file`, e o Compose valida todo o `docker-compose.yml` mesmo ao subir só o `postgres`):
+2. Suba o PostgreSQL:
 ```bash
-docker compose up -d postgres
+docker compose up -d
 ```
 3. Instale dependências e rode migrations:
@@ -49,24 +49,12 @@ Painel interno: `/admin`
 Healthcheck: `GET /up`
 ## Paridade local com produção (FrankenPHP via Docker Compose)
 Além do fluxo host-side acima, `docker-compose.yml` tem um serviço `app` que builda a mesma imagem FrankenPHP usada em staging/produção (`Dockerfile`), útil para testar o comportamento real do container antes do deploy:
 ```bash
 docker compose up -d        # sobe postgres + app
 php artisan migrate         # rode migrations (o entrypoint do container não migra sozinho)
 curl localhost:8000/up
 ```
 O serviço `app` depende de `postgres` estar saudável (`depends_on: condition: service_healthy`) e sobrescreve `DB_HOST`/`DB_PORT` do `.env` para apontar para o serviço `postgres` pelo nome (o padrão `127.0.0.1` do `.env` só funciona para processos rodando no host). Não há job de CI dedicado a este smoke — o job `container` do CI já builda e healthcheca a mesma imagem.
 ## Variáveis principais
 | Variável | Valor local |
 |---|---|
 | `APP_LOCALE` | `pt_BR` |
-| `APP_TIMEZONE` | `America/Sao_Paulo` |
+| `APP_TIMEZONE` | `America/Fortaleza` |
 | `DB_CONNECTION` | `pgsql` |
 | `SESSION_DRIVER` | `database` |
 | `CACHE_STORE` | `database` |
@@ -75,7 +63,7 @@ O serviço `app` depende de `postgres` estar saudável (`depends_on: condition:
 ## Comandos de qualidade
 ```bash
-composer quality      # Pint + PHPStan + audit (composer + npm) + testes
+composer quality      # Pint + PHPStan + audit + testes
 composer test:unit    # Unit + Architecture
 composer test:feature # Feature + Livewire + Filament
 composer test:browser # E2E browser
@@ -137,7 +125,6 @@ Após `php artisan db:seed`:
 - [SPEC.md](SPEC.md) — especificação do produto
 - [docs/adr/](docs/adr/) — ADRs aceitas
 - [docs/conventions/php-strict-types.md](docs/conventions/php-strict-types.md) — convenção de strict types
 - [docs/operations/atualizacao-de-conteudo.md](docs/operations/atualizacao-de-conteudo.md) — runbook de atualização de conteúdo do site pelo painel admin
 - [docs/deployment/dokploy.md](docs/deployment/dokploy.md) — deploy staging/produção no Dokploy + GHCR
 ## Deploy (Dokploy)
--- a/SPEC.md
+++ b/SPEC.md
@@ -14,13 +14,12 @@
 | Estágio | MVP |
 | Status da especificação | Aprovada para implementação |
 | Idioma da interface | Português do Brasil (`pt-BR`) |
-| Timezone padrão | `America/Sao_Paulo` |
+| Timezone padrão | `America/Fortaleza` |
 | Cidade de atuação | São Paulo (capital) |
 | Moeda | BRL, sem conversão entre moedas |
 | Princípio principal | YAGNI — implementar somente o necessário para validar o produto |
 | Arquitetura | Monólito modular Laravel |
 | Área interna | Filament |
-| Área pública | Blade + JS vanilla progressivo (Livewire é dependência do Filament, não usada no site público — ver ADR-015) |
+| Área pública | Livewire + Blade |
 | Servidor de aplicação | FrankenPHP em modo regular |
 | Banco de dados | PostgreSQL |
 | Testes | Pest, Pest Browser/Playwright e testes visuais |
@@ -45,8 +44,6 @@ Em caso de conflito, seguir esta ordem:
 O agente **NÃO DEVE** alterar silenciosamente uma decisão deste documento. Uma alteração de escopo ou arquitetura deve atualizar esta especificação ou criar uma ADR.
 Mudanças incrementais são planejadas em `openspec/changes/` e, após arquivadas, este documento DEVE ser revalidado para incorporar decisões ratificadas (back-sync). Este arquivo permanece a fonte de verdade do produto.
 ---
 ## 1. Contrato de operação para agentes
@@ -194,24 +191,11 @@ Não instalar sistema de permissões granular no MVP.
 ## 4. Escopo
 > **Recorte vigente do lançamento (ADR-016).** O escopo aprovado para o lançamento de 31/08/2026 é o **site institucional**: Fases 0 e 1. As Fases 2 a 5 — CRM de leads, conversão de lead em evento, eventos, tarefas, fornecedores, orçamento, pagamentos manuais, documentos, dashboard orientado a exceções e auditoria — permanecem especificadas neste documento mas ficam **adiadas**, sem data.
 >
 > A §4.1 abaixo descreve o produto completo, não o recorte do lançamento. Os itens marcados como adiados estão fora do que se constrói agora. Ver §18 para a divisão por fase e §23 para as condições de conclusão de cada recorte.
 ### 4.1 Incluído no MVP
 No recorte do lançamento (Fases 0–1):
 - site público;
 - CMS interno do site;
 - formulário de briefing;
 - usuários internos e papéis simples;
 - SEO básico;
 - acessibilidade e testes visuais;
 - CI/CD e deploy em contêiner com FrankenPHP.
 Adiados para depois do lançamento (Fases 2–5, ver ADR-016):
 - CRM de leads;
 - conversão de lead em evento;
 - cadastro e visão consolidada de eventos;
@@ -221,10 +205,12 @@ Adiados para depois do lançamento (Fases 2–5, ver ADR-016):
 - pagamentos inseridos manualmente;
 - documentos vinculados a leads e eventos;
 - dashboard orientado a exceções;
 - usuários internos e papéis simples;
 - notificações internas e por e-mail para novos leads;
- auditoria de ações críticas.
+- auditoria de ações críticas;
-
+- SEO básico;
-Adiado **não** é o mesmo que fora do MVP: os itens acima seguem especificados neste documento e continuam sendo o produto pretendido. A §4.2 lista o que **NÃO DEVE** ser implementado em nenhum momento.
+- acessibilidade e testes visuais;
 - CI/CD e deploy em contêiner com FrankenPHP.
 ### 4.2 Fora do MVP
@@ -326,8 +312,8 @@ Administração
 - Dashboard: `Filament Page` customizada com widgets orientados a exceção.
 - Detalhe do evento: página customizada do Resource com resumo operacional.
- Briefing público: Blade + Controller (`POST /contato`), ver §11.2.
+- Briefing público: componente Livewire próprio.
- Home: Blade com componentes de design reutilizáveis.
+- Home: Blade/Livewire com componentes de design reutilizáveis.
 ### 5.4 Decisões de UX YAGNI
@@ -363,14 +349,13 @@ A home DEVE conter, nesta ordem aproximada:
 1. header e navegação;
 2. hero com proposta de valor e CTA;
-3. manifesto da marca;
+3. prova visual por eventos em destaque;
-4. resumo dos serviços em destaque;
+4. resumo dos serviços;
-5. casos selecionados do portfólio;
+5. método de trabalho;
-6. método de trabalho (4 passos);
+6. casos selecionados;
 7. depoimentos;
-8. posicionamento/perfil;
+8. CTA final para briefing;
-9. CTA final para briefing;
+9. footer com contato, redes e links legais.
 10. footer com contato, redes e links legais.
 A ordem pode variar apenas se a revisão de UX justificar a mudança.
@@ -389,15 +374,6 @@ Centralizar tokens de:
 Não espalhar valores visuais arbitrários por componentes.
 O MVP adota o sistema de design **Heritage Editorial** (ver DESIGN.md e ADR-013):
 - tipografia serifada auto-hospedada (EB Garamond) com escala de display a label;
 - paleta papel/oliva/sálvia/tinta com superfícies tonais; hierarquia sem sombras de card;
 - raio de borda zero para superfícies interativas e de conteúdo;
 - largura de container 1120px e ritmo de espaçamento de 8px;
 - `prefers-reduced-motion` respeitado;
 - contraste WCAG AA (tinta sobre papel e oliva sobre papel).
 ### 6.4 Requisitos de mídia
 - Imagens públicas DEVERÃO possuir texto alternativo.
@@ -407,7 +383,6 @@ O MVP adota o sistema de design **Heritage Editorial** (ver DESIGN.md e ADR-013)
 - Dimensões DEVERÃO ser reservadas para evitar layout shift.
 - Não armazenar blobs de imagem no PostgreSQL.
 - Não depender do disco efêmero do contêiner em produção.
 - O logotipo da marca DEVE possuir texto alternativo e variantes claro/escuro; `site_settings.logo_path` sobrescreve o asset padrão quando preenchido.
 ### 6.5 Acessibilidade
@@ -559,10 +534,12 @@ Campos públicos:
 - validar no servidor;
 - usar honeypot e rate limiting;
 - impedir duplo envio acidental;
 - criar Lead com status `new`;
 - registrar origem `website`;
 - notificar administradores;
 - exibir sucesso sem revelar dados internos;
 - enviar e-mail de confirmação quando o serviço de e-mail estiver configurado;
- exibir sucesso sem revelar dados internos.
+- falha no e-mail não pode apagar o lead já criado.
 > **Estado atual (Fases 0–1):** o formulário usa Blade + Controller e envia apenas e-mails informativos (para a assessoria e confirmação ao visitante), sem criar Lead. A criação de Lead (status `new`, origem `website`), a notificação aos administradores e o registro de aceite de privacidade entram na **Fase 2**, quando o formulário passa a criar o Lead via `CaptureWebsiteLead`. A falha de e-mail não pode apagar dados já criados.
 **Aceite:**
@@ -1276,19 +1253,10 @@ Singleton:
 - `id` bigint PK;
 - `brand_name`;
 - `logo_path` nullable;
 - `logo_alt` nullable;
 - `hero_eyebrow` nullable;
 - `hero_title`;
 - `hero_subtitle`;
 - `hero_cta_label`;
 - `hero_cta_secondary_label` nullable;
 - `hero_note` nullable;
 - `manifesto_title`;
 - `manifesto_lead`;
 - `manifesto_body`;
 - `method_steps` jsonb (4 passos tipados);
 - `principles` jsonb (lista tipada);
 - `about_summary` nullable;
 - `email`;
 - `phone`;
@@ -1297,8 +1265,7 @@ Singleton:
 - `default_meta_title`;
 - `default_meta_description`;
 - `default_og_image_path` nullable;
- `default_og_image_alt` nullable;
+- analytics fields nullable;
 - `analytics_enabled` boolean default false;
 - timestamps.
 #### `services`
@@ -1564,12 +1531,12 @@ Constraints de banco devem proteger:
 | Runtime | PHP com versão minor fixada no Docker |
 | Framework | Laravel 13 |
 | Admin | Filament 5 |
-| UI pública | Blade + Tailwind + JS vanilla progressivo (sem framework reativo; Livewire 4 confinado ao Filament — ver ADR-015 e §22) |
+| UI pública | Livewire 4 + Blade + Alpine + Tailwind |
 | Banco | PostgreSQL |
 | Servidor | FrankenPHP + Caddy |
 | Assets | Vite |
 | Testes | Pest 4 + Pest Browser/Playwright |
-| Arquivos | Laravel Filesystem + Cloudflare R2 (S3-compatible) em produção |
+| Arquivos | Laravel Filesystem + storage S3-compatible em produção |
 | Fila | Database queue |
 | Scheduler | Laravel Scheduler em processo separado |
@@ -1785,21 +1752,19 @@ Usar componentes/Widgets menores e testáveis.
 ---
-## 11. Site público e interatividade
+## 11. Livewire e site público
-### 11.1 Estado atual e componentes candidatos
+### 11.1 Componentes sugeridos
-O site público **não usa Livewire nem Alpine hoje**. As páginas são Blade renderizado no servidor mais JavaScript vanilla progressivo (`resources/js/app.js` e `resources/js/motion.js`). O `layouts.public` carrega apenas `@vite(['resources/css/app.css', 'resources/js/app.js'])` — nenhum `@livewireScripts`. O pacote `livewire/livewire` existe no projeto apenas como dependência transitiva de `filament/support` e opera somente dentro do painel `/admin`.
+- `ContactBriefingForm`;
 - `FeaturedPortfolioCases` se houver necessidade de consulta dinâmica;
 - `PublishedServices` se houver necessidade de consulta dinâmica.
-Se surgir a necessidade de consulta dinâmica, os candidatos naturais a Livewire seriam `FeaturedPortfolioCases` e `PublishedServices`. Essa adoção está condicionada ao gatilho registrado em §22.
+Não transformar todas as seções estáticas em componentes Livewire. Usar Blade quando não houver estado ou interação.
 Não transformar seções estáticas em componentes Livewire. Usar Blade quando não houver estado ou interação.
 ### 11.2 Formulário de briefing
-> **Estado atual:** o formulário é implementado em Blade + Controller (`POST /contato`, `ContactBriefingRequest`), conforme WEB-05, e essa é a abordagem aceita — não um estágio provisório. Os requisitos abaixo valem independentemente da tecnologia; a criação de Lead segue para a Fase 2.
+O componente deve:
 O formulário deve:
 - ter estado tipado ou Form Object quando útil;
 - validar no servidor;
@@ -1808,16 +1773,15 @@ O formulário deve:
 - preservar acessibilidade;
 - limpar dados após sucesso;
 - evitar exposição de exceção;
- suportar teste de submissão sem navegador (feature test);
+- suportar teste Livewire sem browser;
 - suportar jornada E2E em navegador real.
 ### 11.3 JavaScript
- manter o site público em JS vanilla progressivo;
+- usar Alpine apenas para interações pequenas;
 - não introduzir framework SPA;
- não usar dependência JS quando CSS e HTML resolverem;
+- não usar dependência JS quando CSS/HTML/Livewire resolverem;
- toda interação crítica deve funcionar sem estado global complexo;
+- toda interação crítica deve funcionar sem estado global complexo.
 - Alpine só entra junto com Livewire, se o gatilho de §22 disparar.
 ---
@@ -2006,7 +1970,7 @@ Determinismo obrigatório:
 - Chromium e imagem Linux fixos;
 - viewport fixo;
- timezone `America/Sao_Paulo`;
+- timezone `America/Fortaleza`;
 - locale `pt-BR`;
 - fontes instaladas na imagem;
 - relógio congelado;
@@ -2088,7 +2052,7 @@ quality        → Pint check + PHPStan/Larastan + audits + testes
 | Job | Responsabilidade | Bloqueia merge |
 |---|---|---:|
-| `static` | Pint, PHPStan/Larastan, Composer validate, Composer e npm audit | Sim |
+| `static` | Pint, PHPStan/Larastan, Composer validate e audits | Sim |
 | `unit` | Unitários, arquitetura e cobertura | Sim |
 | `feature` | PostgreSQL, migrations, Livewire, Filament e integração | Sim |
 | `browser` | Vite, FrankenPHP, E2E, smoke, acessibilidade e visual | Sim |
@@ -2109,11 +2073,11 @@ quality        → Pint check + PHPStan/Larastan + audits + testes
 ### 14.3 Branches e ambientes
 - PR: testes e preview opcional;
- `main`: build imutável por SHA publicado no GHCR e deploy automático em staging via Dokploy;
+- `main`: build imutável por SHA e deploy automático em staging;
- staging: Dokploy Compose executa migração, healthcheck `/up` e smoke pós-deploy (`/up`, `/`, `/admin/login`);
+- staging: migration, cache warmup e smoke pós-deploy;
- produção: promoção da mesma imagem aprovada, sem rebuild (retag do digest em `:production`);
+- produção: promoção da mesma imagem aprovada, sem rebuild;
- produção requer aprovação humana explícita no MVP (`workflow_dispatch` com confirmação);
+- produção requer aprovação humana explícita no MVP;
- rollback usa imagem anterior (SHA anterior, sem rebuild);
+- rollback usa imagem anterior;
 - migrations devem ser backward-compatible quando possível.
 ### 14.4 Definition of Done
@@ -2195,7 +2159,7 @@ APP_DEBUG=false
 APP_URL
 APP_LOCALE=pt_BR
 APP_FALLBACK_LOCALE=pt_BR
-APP_TIMEZONE=America/Sao_Paulo
+APP_TIMEZONE=America/Fortaleza
 DB_CONNECTION=pgsql
 DB_HOST
@@ -2208,16 +2172,19 @@ CACHE_STORE=database ou file conforme ambiente
 QUEUE_CONNECTION=database
 SESSION_DRIVER=database ou cookie conforme decisão
-FILESYSTEM_DISK=r2 em produção
+FILESYSTEM_DISK=s3 em produção
-R2_ACCESS_KEY_ID
+AWS_ACCESS_KEY_ID
-R2_SECRET_ACCESS_KEY
+AWS_SECRET_ACCESS_KEY
-R2_BUCKET
+AWS_DEFAULT_REGION
-R2_ENDPOINT
+AWS_BUCKET
-R2_URL (domínio próprio opcional)
+AWS_ENDPOINT opcional
-AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION, AWS_BUCKET, AWS_ENDPOINT, AWS_USE_PATH_STYLE_ENDPOINT — opcionais, apenas se o disk s3 for usado
+AWS_USE_PATH_STYLE_ENDPOINT opcional
-MAIL_MAILER=resend em produção (mailer nativo Laravel)
+MAIL_MAILER
-RESEND_API_KEY
+MAIL_HOST
 MAIL_PORT
 MAIL_USERNAME
 MAIL_PASSWORD
 MAIL_FROM_ADDRESS
 MAIL_FROM_NAME
 ```
@@ -2312,7 +2279,7 @@ O seed deve criar:
 - configurações do site;
 - 3 serviços;
 - 3 casos de portfólio;
- depoimentos reais: os 5 casais de `depoimentos.md` (Jeniffer e Maick, Quesia e Jhonata, Milena e Weslley, Raquel e Pedro, Victoria e Pedro), preservando texto e datas; autores fictícios de demonstração removidos; em produção permanecem não publicados até autorização explícita de publicação;
+- 3 depoimentos;
 - leads em estados variados;
 - 2 eventos futuros e 1 concluído;
 - tarefas vencidas e futuras;
@@ -2336,8 +2303,6 @@ Para visual e browser tests:
 ## 18. Backlog de implementação
 > **Recorte vigente (ADR-016).** Fases 0 e 1 são o escopo do lançamento e estão concluídas. **Fases 2 a 5 estão adiadas, sem data.** Não iniciar nenhuma delas sem uma decisão nova do responsável pelo produto — a §1.1 manda trabalhar uma fase por vez, e a fase corrente é o acabamento e a publicação do site.
 O agente deve implementar na sequência, salvo instrução explícita.
 ### Fase 0 — Fundação
@@ -2360,13 +2325,6 @@ O agente deve implementar na sequência, salvo instrução explícita.
 - [x] design tokens mínimos;
 - [x] healthcheck;
 - [x] seed de admin local.
 - [x] verificação de e-mail e reset seguro (MustVerifyEmail);
 - [x] npm audit no `composer quality` e no job `static`;
 - [x] gate de cobertura `Domain`/`Application` ≥ 80%;
 - [x] serviço de aplicação FrankenPHP no Compose local;
 - [x] hello-world implantado em staging (critério de saída) — run [31395107465](https://github.com/manoel-freitas/amore-site/actions/runs/31395107465) em `7e68c0e`, com `Dokploy deployment succeeded` e smoke verde em `/up`, `/` e `/admin/login`.
 > Os itens pendentes acima são tratados pela mudança OpenSpec `complete-foundation-parity`; o critério de saída da fase só é atingido com staging implantado.
 **Critério de saída:** pipeline verde e hello-world implantado em staging.
@@ -2388,7 +2346,7 @@ O agente deve implementar na sequência, salvo instrução explícita.
 **Critério de saída:** conteúdo gerenciável no Filament e site público aprovado visualmente (baselines em `tests/.pest/snapshots/`; aprovação humana do diff visual no PR).
-### Fase 2 — Leads — ADIADA (ADR-016)
+### Fase 2 — Leads
 - [ ] migration/model/factory de Lead;
 - [ ] LeadActivity;
@@ -2405,7 +2363,7 @@ O agente deve implementar na sequência, salvo instrução explícita.
 **Critério de saída:** jornada visitante → lead → tratamento interna totalmente verde.
-### Fase 3 — Eventos e tarefas — ADIADA (ADR-016)
+### Fase 3 — Eventos e tarefas
 - [ ] Event;
 - [ ] EventTask;
@@ -2420,7 +2378,7 @@ O agente deve implementar na sequência, salvo instrução explícita.
 **Critério de saída:** lead é convertido e evento pode ser administrado.
-### Fase 4 — Fornecedores e financeiro — ADIADA (ADR-016)
+### Fase 4 — Fornecedores e financeiro
 - [ ] Vendor;
 - [ ] EventVendor;
@@ -2436,7 +2394,7 @@ O agente deve implementar na sequência, salvo instrução explícita.
 **Critério de saída:** assessora acompanha orçamento e pagamentos sem integração bancária.
-### Fase 5 — Documentos, hardening e lançamento — ADIADA (ADR-016)
+### Fase 5 — Documentos, hardening e lançamento
 - [ ] documentos privados;
 - [ ] auditoria completa;
@@ -2514,7 +2472,7 @@ Toda operação financeira deve:
 | ADR | Decisão | Status |
 |---|---|---|
 | ADR-001 | Monólito modular Laravel, sem microserviços | Aceita |
-| ADR-002 | Filament para área interna (Livewire é dependência interna do Filament); site público em Blade — ver ADR-015 | Aceita |
+| ADR-002 | Filament para área interna e Livewire/Blade para área pública | Aceita |
 | ADR-003 | PostgreSQL como único banco transacional | Aceita |
 | ADR-004 | Pagamentos somente manuais | Aceita |
 | ADR-005 | Pest unifica unit, feature, browser e visual | Aceita |
@@ -2523,12 +2481,6 @@ Toda operação financeira deve:
 | ADR-008 | Database queue; Redis adiado | Aceita |
 | ADR-009 | Dinheiro em BRL armazenado como centavos inteiros | Aceita |
 | ADR-010 | Home com estrutura fixa e CMS tipado, sem page builder | Aceita |
 | ADR-011 | Cloudflare R2 (S3-compatible) como storage de objetos em produção | Aceita |
 | ADR-012 | E-mail transacional via Resend (mailer nativo Laravel) | Aceita |
 | ADR-013 | Design system Heritage Editorial para o site público | Aceita |
 | ADR-014 | Deploy via Dokploy Compose com imagem imutável por SHA no GHCR | Aceita |
 | ADR-015 | Site público permanece Blade + JS vanilla; Livewire e Alpine ficam restritos ao Filament até o gatilho de §22. Emenda o texto da ADR-002 | Aceita |
 | ADR-016 | Lançamento de 31/08/2026 entrega apenas o site institucional (Fases 0–1); Fases 2–5 seguem especificadas e adiadas, sem data | Aceita |
 ---
@@ -2545,7 +2497,6 @@ Toda operação financeira deve:
 | API pública | existe consumidor real e contrato de integração |
 | Kanban | tabela de leads demonstra limitação frequente observada |
 | Editor de checklist | diferentes tipos de evento exigem manutenção frequente do seed |
 | Livewire no site público | portfólio ou serviços exigem consulta ou filtro dinâmico que Blade + JS vanilla não resolvem de forma simples |
 ---
@@ -2553,39 +2504,24 @@ Toda operação financeira deve:
 O MVP está concluído somente quando:
 A ADR-016 divide estas condições em dois recortes. Cada um se fecha por conta própria; o segundo não bloqueia o lançamento.
 ### 23.1 Lançamento do site (Fases 0–1)
 O lançamento está concluído somente quando:
 - site público está publicado e visualmente aprovado;
 - assessora edita os conteúdos essenciais sem desenvolvedor;
- briefing envia o pedido de proposta de forma segura, com proteção contra abuso e aceite de privacidade registrado;
+- briefing cria leads de forma segura;
 - usuários e Policies estão corretos;
 - testes unit, feature, visuais e arquitetura estão verdes;
 - CI bloqueia regressões;
 - imagem FrankenPHP é reproduzível;
 - staging e produção usam a mesma imagem promovida;
 - backup, restauração e monitoramento estão documentados;
 - nenhum item explicitamente fora do MVP (§4.2) foi introduzido.
 Note a diferença em relação à versão anterior desta seção: o critério do briefing é **enviar o pedido**, não "criar leads". Criar Lead é Fase 2 e está adiado; o formulário atual envia e-mail e não persiste nada.
 ### 23.2 Produto completo (Fases 2–5, adiado)
 Além de tudo em §23.1:
 - pipeline e próxima ação funcionam;
 - briefing cria leads de forma segura e persistente;
 - lead é convertido uma única vez em evento;
 - checklist é criado automaticamente;
 - evento possui visão consolidada;
 - fornecedores podem ser cadastrados e vinculados;
 - orçamento e pagamentos manuais possuem totais consistentes;
 - dashboard mostra pendências do dia;
 - usuários e Policies estão corretos;
 - auditoria registra operações críticas;
- jornadas E2E das fases correspondentes estão verdes.
+- testes unit, feature, E2E, visuais e arquitetura estão verdes;
 - CI bloqueia regressões;
 - imagem FrankenPHP é reproduzível;
 - staging e produção usam a mesma imagem promovida;
 - backup, restauração e monitoramento estão documentados;
 - nenhum item explicitamente fora do MVP foi introduzido.
 ---
--- a/app/Application/Data/PageMeta.php
+++ b/app/Application/Data/PageMeta.php
@@ -21,8 +21,6 @@ final readonly class PageMeta
        public ?string $ogImageUrl = null,
        public ?string $ogImageAlt = null,
        public ?array $jsonLd = null,
        public string $siteName = '',
        public string $robots = 'index, follow',
    ) {}
    /**
@@ -46,7 +44,6 @@ final readonly class PageMeta
            ogImageUrl: $ogImageUrl ?? self::defaultOgImageUrl($settings),
            ogImageAlt: $ogImageAlt ?? $settings->default_og_image_alt,
            jsonLd: $jsonLd,
            siteName: (string) $settings->brand_name,
        );
    }
@@ -80,53 +77,9 @@ final readonly class PageMeta
            ogImageUrl: $ogImageUrl,
            ogImageAlt: $ogImageAlt,
            jsonLd: $jsonLd,
            siteName: (string) $settings->brand_name,
        );
    }
    /**
     * Build the metadata for branded error pages.
     *
     * Error pages carry no canonical, are excluded from search indexes and use
     * the page name suffixed with the brand name as their title.
     */
    public static function forErrorPage(
        SiteSetting $settings,
        int $status = 404,
    ): self {
        [$title, $description] = match ($status) {
            500 => ['Algo deu errado', 'Não foi possível concluir o pedido. Tente novamente em instantes.'],
            419 => ['Sessão expirada', 'Sua sessão expirou. Volte e tente enviar novamente.'],
            429 => ['Muitas solicitações', 'Você enviou muitas solicitações em pouco tempo. Aguarde um instante e tente novamente.'],
            503 => ['Em manutenção', 'Estamos realizando uma breve manutenção. Tente novamente em instantes.'],
            default => ['Página não encontrada', 'A página que você procura não existe ou foi movida.'],
        };
        return new self(
            title: trim($title).' - '.$settings->brand_name,
            description: $description,
            canonical: '',
            robots: 'noindex, nofollow',
            siteName: (string) $settings->brand_name,
        );
    }
    /**
     * Append the brand name to a page title when it is not already present.
     */
    public static function withBrandSuffix(string $title, SiteSetting $settings): string
    {
        $brand = filled($settings->default_meta_title)
            ? (string) $settings->default_meta_title
            : (string) $settings->brand_name;
        if (str_contains($title, $brand)) {
            return $title;
        }
        return trim($title).' - '.$brand;
    }
    private static function defaultTitle(SiteSetting $settings): string
    {
        return filled($settings->default_meta_title)
--- a/app/Console/Commands/MediaGenerateVariantsCommand.php
+++ b/app/Console/Commands/MediaGenerateVariantsCommand.php
@@ -56,9 +56,6 @@ final class MediaGenerateVariantsCommand extends Command
        if ($settings && filled($settings->default_og_image_path)) {
            $paths[] = (string) $settings->default_og_image_path;
        }
        if ($settings && filled($settings->about_image_path)) {
            $paths[] = (string) $settings->about_image_path;
        }
        foreach (Service::query()->whereNotNull('cover_image_path')->pluck('cover_image_path') as $path) {
            $paths[] = (string) $path;
--- a/app/Domain/Contact/BrazilianPhoneNumber.php
+++ b/app/Domain/Contact/BrazilianPhoneNumber.php
@@ -1,85 +0,0 @@
 <?php
 declare(strict_types=1);
 namespace App\Domain\Contact;
 /**
 * Normalizes a raw phone/WhatsApp number typed into the public briefing
 * form into a canonical, human-readable Brazilian format.
 *
 * The briefing e-mail simply prints the field value in a table, so the
 * canonical form must stay legible for the staff member reading it —
 * "(11) 98888-7777" rather than an opaque "11988887777" digit string.
 */
 final class BrazilianPhoneNumber
 {
    /**
     * Formats to "(DD) 9XXXX-XXXX" for an 11-digit mobile number or
     * "(DD) XXXX-XXXX" for a 10-digit landline number, stripping a
     * leading "+55"/"55" country code when present.
     *
     * A 10- or 11-digit string is only formatted when it is structurally
     * plausible as a Brazilian number: the first two digits must be a
     * possible DDD (`[1-9][1-9]`, since Brazilian area codes run 11-99
     * and never carry a '0' in either position), and an 11-digit number
     * must additionally have a '9' as its third digit (mandatory on all
     * Brazilian mobile numbers since 2012). An explicit "+55" prefix that
     * leaves no digits for a DDD (e.g. "+55 98888-7777") is treated as a
     * number missing its area code, not as DDD 55.
     *
     * When the digit count does not match either shape, or the shape
     * fails the checks above (foreign numbers, partial input, extensions,
     * etc.), the original text is preserved — only whitespace is
     * collapsed — so no information the recipient might need is
     * discarded or silently fabricated.
     */
    public static function normalize(string $raw): string
    {
        $trimmed = trim($raw);
        $collapsed = preg_replace('/\s+/', ' ', $trimmed) ?? $trimmed;
        // Only reformat when the text is made exclusively of phone
        // characters. Anything else — "(WhatsApp)", "falar com João",
        // a ramal — is information the recipient needs, so it is left
        // untouched rather than stripped away by the digit extraction.
        if (preg_match('/^[0-9()+\-.\/ ]+$/', $collapsed) !== 1) {
            return $collapsed;
        }
        $digits = preg_replace('/\D+/', '', $collapsed) ?? '';
        if (in_array(strlen($digits), [12, 13], true) && str_starts_with($digits, '55')) {
            $digits = substr($digits, 2);
        } elseif (str_starts_with($digits, '55') && preg_match('/^\+\s*55\b/', $collapsed) === 1) {
            // An explicit "+55" was written, but the total digit count
            // never reached 12/13, meaning nothing precedes it that could
            // be a DDD — e.g. "+55 98888-7777" is a mobile number missing
            // its area code, not DDD 55 with a coincidentally-matching
            // subscriber number. Guessing a DDD here would fabricate one.
            return $collapsed;
        }
        return match (strlen($digits)) {
            11 => self::isPlausibleDdd($digits) && $digits[2] === '9'
                ? sprintf('(%s) %s-%s', substr($digits, 0, 2), substr($digits, 2, 5), substr($digits, 7))
                : $collapsed,
            10 => self::isPlausibleDdd($digits)
                ? sprintf('(%s) %s-%s', substr($digits, 0, 2), substr($digits, 2, 4), substr($digits, 6))
                : $collapsed,
            default => $collapsed,
        };
    }
    /**
     * A Brazilian DDD (area code) runs 11-99: the first digit is never
     * '0' (not a valid leading digit) and the second is never '0' either
     * (no DDD like "10", "20", "30" exists). This does not check that the
     * DDD is one of the officially assigned codes — only that its shape
     * is plausible enough to distinguish it from a foreign number.
     */
    private static function isPlausibleDdd(string $digits): bool
    {
        return preg_match('/^[1-9][1-9]/', $digits) === 1;
    }
 }
--- a/app/Domain/Contact/MarketingOrigin.php
+++ b/app/Domain/Contact/MarketingOrigin.php
@@ -1,181 +0,0 @@
 <?php
 declare(strict_types=1);
 namespace App\Domain\Contact;
 /**
 * Captures the marketing origin of a visit (SPEC.md WEB-05, "origem de
 * marketing capturada quando disponível") from raw, untrusted request
 * data and turns it into a short, human-readable pt-BR label for the
 * internal briefing e-mail.
 *
 * Deliberately framework-free (no Illuminate\Http\Request dependency) so
 * it stays a pure transformation, mirroring BrazilianPhoneNumber: callers
 * in the HTTP layer extract the query string / referrer and hand them in
 * as primitives.
 */
 final class MarketingOrigin
 {
    /**
     * Session key both the capturing middleware and the controller read
     * from — kept here so there is exactly one name for the concept.
     */
    public const string SESSION_KEY = 'marketing_origin';
    /**
     * Caps every captured value. This is marketing metadata, not user
     * content — a crafted query string must not be able to bloat the
     * session (SPEC.md §12.5 LGPD).
     */
    private const int MAX_LENGTH = 100;
    /**
     * @var list<string>
     */
    private const array UTM_KEYS = [
        'utm_source',
        'utm_medium',
        'utm_campaign',
        'utm_term',
        'utm_content',
    ];
    /**
     * pt-BR labels for the UTM keys, in the order they should be
     * displayed when composing the briefing e-mail row.
     *
     * @var array<string, string>
     */
    private const array LABELS = [
        'utm_source' => 'origem',
        'utm_medium' => 'mídia',
        'utm_campaign' => 'campanha',
        'utm_term' => 'termo',
        'utm_content' => 'conteúdo',
    ];
    /**
     * Reads UTM parameters from the query string, falling back to the
     * HTTP referrer when none are present. Returns an empty array when
     * neither is available — capturing nothing is a valid outcome
     * ("capturada quando disponível").
     *
     * A referrer pointing back at this same host is not a marketing
     * origin — it is the visitor clicking from one internal page to
     * another (common once the original session has expired and a
     * fresh one starts mid-visit) — so it is discarded rather than
     * stored as noise (SPEC.md §12.5, "coletar apenas dados
     * necessários").
     *
     * @param  array<string, mixed>  $queryParams
     * @return array<string, string>
     */
    public static function capture(array $queryParams, ?string $referrer, ?string $requestHost): array
    {
        $utm = [];
        foreach (self::UTM_KEYS as $key) {
            $value = $queryParams[$key] ?? null;
            if (is_string($value) && trim($value) !== '') {
                $utm[$key] = self::sanitize($value);
            }
        }
        if ($utm !== []) {
            return $utm;
        }
        if (is_string($referrer) && trim($referrer) !== '' && ! self::isSameHost($referrer, $requestHost)) {
            $origin = self::originOf($referrer);
            if ($origin !== null) {
                return ['referrer' => self::sanitize($origin)];
            }
        }
        return [];
    }
    /**
     * Reduces a referrer URL to its scheme+host identity, dropping the
     * path, query string, fragment, and any userinfo. The referrer is
     * only ever used as a marketing-origin *site* label (SPEC.md WEB-05)
     * — the query string can carry data that identifies an individual
     * (e.g. a personalized campaign link's `?email=...`), which would
     * exceed "coletar apenas dados necessários" (SPEC.md §12.5) once it
     * lands in the session and the internal briefing e-mail.
     */
    private static function originOf(string $referrer): ?string
    {
        $host = parse_url($referrer, PHP_URL_HOST);
        if (! is_string($host) || $host === '') {
            return null;
        }
        $scheme = parse_url($referrer, PHP_URL_SCHEME);
        $prefix = is_string($scheme) && $scheme !== '' ? "{$scheme}://" : '';
        return "{$prefix}{$host}";
    }
    private static function isSameHost(string $referrer, ?string $requestHost): bool
    {
        if ($requestHost === null || $requestHost === '') {
            return false;
        }
        $referrerHost = parse_url($referrer, PHP_URL_HOST);
        return is_string($referrerHost) && strcasecmp($referrerHost, $requestHost) === 0;
    }
    /**
     * Composes the single-row, pt-BR display value for the internal
     * briefing e-mail. Returns null when nothing was captured, letting
     * the caller fall back to the same "—" convention already used for
     * other optional briefing fields.
     *
     * Accepts loosely-typed input on purpose: this reads back whatever
     * was put in the session, so it is treated as untrusted rather than
     * assumed to still match the shape `capture()` produced.
     *
     * @param  array<string, mixed>  $origin
     */
    public static function describe(array $origin): ?string
    {
        if (isset($origin['referrer']) && is_string($origin['referrer']) && $origin['referrer'] !== '') {
            return $origin['referrer'];
        }
        $parts = [];
        foreach (self::LABELS as $key => $label) {
            if (isset($origin[$key]) && is_string($origin[$key]) && $origin[$key] !== '') {
                $parts[] = "{$label}: {$origin[$key]}";
            }
        }
        return $parts === [] ? null : implode(' | ', $parts);
    }
    /**
     * Untrusted input (query string, HTTP referrer) that ends up in an
     * HTML e-mail: strip any markup, drop control characters (also
     * closes off header-injection-style newline tricks), trim, and cap
     * the length before it ever reaches storage.
     */
    private static function sanitize(string $value): string
    {
        $withoutTags = strip_tags($value);
        // No /u flag: this is a byte-wise scrub of ASCII control bytes, so
        // it cannot land mid-sequence in valid UTF-8 (continuation bytes
        // are all >= 0x80) — unlike the Unicode-mode regex, it never
        // blanks the whole string just because one byte is malformed.
        $withoutControlChars = preg_replace('/[\x00-\x1F\x7F]/', '', $withoutTags) ?? '';
        return mb_substr(trim($withoutControlChars), 0, self::MAX_LENGTH);
    }
 }
--- a/app/Filament/Pages/Auth/RequestPasswordReset.php
+++ b/app/Filament/Pages/Auth/RequestPasswordReset.php
@@ -1,43 +0,0 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Pages\Auth;
 use Filament\Auth\Pages\PasswordReset\RequestPasswordReset as BaseRequestPasswordReset;
 use Filament\Notifications\Notification;
 use Illuminate\Support\Facades\Password;
 /**
 * Overrides Filament's stock request-reset page to close an account
 * enumeration leak (SPEC 12.1 / ADM-01 "reset seguro"). The vendor page
 * shows a distinguishable danger notification for two statuses that only
 * ever occur for existing users, letting an attacker tell registered emails
 * apart from unregistered ones:
 *
 * - Password::INVALID_USER — no such user at all.
 * - Password::RESET_THROTTLED — Illuminate\Auth\Passwords\PasswordBroker
 *   only returns this when a token was already recently created for that
 *   user, which requires the user to exist. Two requests for the same
 *   registered email (allowed by this page's own rate limit of 2) would
 *   otherwise flip from "sent" to "throttled" while an unknown email stays
 *   "sent" both times — the same leak, reached a different way. The
 *   tradeoff: a legitimate user requesting twice sees "sent" again instead
 *   of "please wait", which is an acceptable UX cost on an admin-only panel.
 *
 * Existing-but-ineligible users (inactive, or since this panel now requires
 * a verified email) already resolve to Password::RESET_LINK_SENT with no
 * mail sent — see the vendor callback in the base class — so only these two
 * branches need normalizing here.
 */
 class RequestPasswordReset extends BaseRequestPasswordReset
 {
    protected function getFailureNotification(string $status): ?Notification
    {
        if (in_array($status, [Password::INVALID_USER, Password::RESET_THROTTLED], true)) {
            return $this->getSentNotification(Password::RESET_LINK_SENT);
        }
        return parent::getFailureNotification($status);
    }
 }
--- a/app/Filament/Pages/ManageSiteSettings.php
+++ b/app/Filament/Pages/ManageSiteSettings.php
@@ -10,8 +10,6 @@ use BackedEnum;
 use Filament\Actions\Action;
 use Filament\Actions\ActionGroup;
 use Filament\Forms\Components\KeyValue;
 use Filament\Forms\Components\Repeater;
 use Filament\Forms\Components\TagsInput;
 use Filament\Forms\Components\Textarea;
 use Filament\Forms\Components\TextInput;
 use Filament\Forms\Components\Toggle;
@@ -137,8 +135,6 @@ class ManageSiteSettings extends Page
                            ->label('Nome da marca')
                            ->required()
                            ->maxLength(255),
                        PublicImageUploadRules::fileUpload('logo_path', 'Logo da marca', 'content/logo'),
                        PublicImageUploadRules::altTextField('logo_alt', 'logo_path', 'Texto alternativo do logo'),
                        TextInput::make('hero_eyebrow')
                            ->label('Eyebrow do hero')
                            ->maxLength(255),
@@ -151,62 +147,14 @@ class ManageSiteSettings extends Page
                            ->required()
                            ->rows(3),
                        TextInput::make('hero_cta_label')
-                            ->label('Texto do CTA principal')
+                            ->label('Texto do CTA')
                            ->required()
                            ->maxLength(255),
                        TextInput::make('hero_secondary_cta_label')
                            ->label('Texto do CTA secundário')
                            ->maxLength(255),
                        Textarea::make('hero_note')
                            ->label('Nota do hero')
                            ->rows(2),
                        Textarea::make('about_summary')
                            ->label('Resumo institucional')
                            ->rows(3),
                    ])
                    ->columns(2),
                Section::make('Manifesto editorial')
                    ->schema([
                        TextInput::make('manifesto_title')
                            ->label('Título do manifesto')
                            ->maxLength(255),
                        Textarea::make('manifesto_lead')
                            ->label('Lead do manifesto')
                            ->rows(3),
                        Textarea::make('manifesto_body')
                            ->label('Corpo do manifesto')
                            ->rows(4),
                    ]),
                Section::make('Método')
                    ->schema([
                        Textarea::make('method_intro')
                            ->label('Introdução do método')
                            ->rows(2),
                        Repeater::make('method_steps')
                            ->label('Passos do método')
                            ->schema([
                                TextInput::make('title')
                                    ->label('Título')
                                    ->required()
                                    ->maxLength(255),
                                Textarea::make('body')
                                    ->label('Descrição')
                                    ->required()
                                    ->rows(2),
                            ])
                            ->defaultItems(0)
                            ->maxItems(4)
                            ->reorderable()
                            ->columnSpanFull(),
                    ]),
                Section::make('Princípios')
                    ->schema([
                        TagsInput::make('principles')
                            ->label('Princípios')
                            ->placeholder('Adicionar princípio')
                            ->helperText('Até quatro princípios editoriais.')
                            ->columnSpanFull(),
                    ]),
                Section::make('Contato')
                    ->schema([
                        TextInput::make('email')
@@ -228,12 +176,6 @@ class ManageSiteSettings extends Page
                            ->addActionLabel('Adicionar rede'),
                    ])
                    ->columns(2),
                Section::make('Página Sobre')
                    ->schema([
                        PublicImageUploadRules::fileUpload('about_image_path', 'Imagem da página Sobre', 'content/about'),
                        PublicImageUploadRules::altTextField('about_image_alt', 'about_image_path'),
                    ])
                    ->columns(2),
                Section::make('SEO padrão')
                    ->schema([
                        TextInput::make('default_meta_title')
--- a/app/Filament/Resources/PortfolioCases/Pages/CreatePortfolioCase.php
+++ b/app/Filament/Resources/PortfolioCases/Pages/CreatePortfolioCase.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\PortfolioCases\Pages;
 use App\Filament\Resources\PortfolioCases\PortfolioCaseResource;
--- a/app/Filament/Resources/PortfolioCases/Pages/EditPortfolioCase.php
+++ b/app/Filament/Resources/PortfolioCases/Pages/EditPortfolioCase.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\PortfolioCases\Pages;
 use App\Filament\Resources\PortfolioCases\PortfolioCaseResource;
--- a/app/Filament/Resources/PortfolioCases/Pages/ListPortfolioCases.php
+++ b/app/Filament/Resources/PortfolioCases/Pages/ListPortfolioCases.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\PortfolioCases\Pages;
 use App\Filament\Resources\PortfolioCases\PortfolioCaseResource;
--- a/app/Filament/Resources/Services/Pages/CreateService.php
+++ b/app/Filament/Resources/Services/Pages/CreateService.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\Services\Pages;
 use App\Filament\Resources\Services\ServiceResource;
--- a/app/Filament/Resources/Services/Pages/EditService.php
+++ b/app/Filament/Resources/Services/Pages/EditService.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\Services\Pages;
 use App\Filament\Resources\Services\ServiceResource;
--- a/app/Filament/Resources/Services/Pages/ListServices.php
+++ b/app/Filament/Resources/Services/Pages/ListServices.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\Services\Pages;
 use App\Filament\Resources\Services\ServiceResource;
--- a/app/Filament/Resources/Testimonials/Pages/CreateTestimonial.php
+++ b/app/Filament/Resources/Testimonials/Pages/CreateTestimonial.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\Testimonials\Pages;
 use App\Filament\Resources\Testimonials\TestimonialResource;
--- a/app/Filament/Resources/Testimonials/Pages/EditTestimonial.php
+++ b/app/Filament/Resources/Testimonials/Pages/EditTestimonial.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\Testimonials\Pages;
 use App\Filament\Resources\Testimonials\TestimonialResource;
--- a/app/Filament/Resources/Testimonials/Pages/ListTestimonials.php
+++ b/app/Filament/Resources/Testimonials/Pages/ListTestimonials.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\Testimonials\Pages;
 use App\Filament\Resources\Testimonials\TestimonialResource;
--- a/app/Filament/Resources/Users/Pages/CreateUser.php
+++ b/app/Filament/Resources/Users/Pages/CreateUser.php
@@ -1,38 +1,11 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\Users\Pages;
 use App\Filament\Resources\Users\UserResource;
 use App\Models\User;
 use Filament\Resources\Pages\CreateRecord;
 use Illuminate\Database\Eloquent\Model;
 class CreateUser extends CreateRecord
 {
    protected static string $resource = UserResource::class;
    /**
     * Verification stays admin-managed only (no self-service verify route is
     * registered): a user created here by an admin is, by that act, verified.
     * Without this, `email_verified_at` would stay null forever and
     * canAccessPanel() would permanently lock the new user out with no
     * in-app path to recover — the password-reset callback skips notifying
     * users that fail canAccessPanel() while still reporting success.
     *
     * `email_verified_at` is deliberately not added to User's #[Fillable]
     * list (it isn't a UserForm field either) so it can never be set via
     * mass assignment from form/API input — `forceFill()` bypasses that
     * guard here on purpose, after construction.
     */
    protected function handleRecordCreation(array $data): Model
    {
        /** @var User $record */
        $record = new (static::getModel())($data);
        $record->forceFill(['email_verified_at' => now()]);
        $record->save();
        return $record;
    }
 }
--- a/app/Filament/Resources/Users/Pages/EditUser.php
+++ b/app/Filament/Resources/Users/Pages/EditUser.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\Users\Pages;
 use App\Filament\Resources\Users\UserResource;
--- a/app/Filament/Resources/Users/Pages/ListUsers.php
+++ b/app/Filament/Resources/Users/Pages/ListUsers.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Filament\Resources\Users\Pages;
 use App\Filament\Resources\Users\UserResource;
--- a/app/Http/Controllers/Controller.php
+++ b/app/Http/Controllers/Controller.php
@@ -1,7 +1,5 @@
 <?php
 declare(strict_types=1);
 namespace App\Http\Controllers;
 abstract class Controller
--- a/app/Http/Controllers/PublicSite/ContactController.php
+++ b/app/Http/Controllers/PublicSite/ContactController.php
@@ -1,140 +0,0 @@
 <?php
 declare(strict_types=1);
 namespace App\Http\Controllers\PublicSite;
 use App\Domain\Contact\MarketingOrigin;
 use App\Http\Controllers\Controller;
 use App\Http\Requests\PublicSite\ContactBriefingRequest;
 use App\Mail\ContactBriefing;
 use App\Mail\ContactBriefingConfirmation;
 use App\Models\SiteSetting;
 use Illuminate\Http\RedirectResponse;
 use Illuminate\Support\Facades\Log;
 use Illuminate\Support\Facades\Mail;
 use Throwable;
 final class ContactController extends Controller
 {
    private const string DUPLICATE_SESSION_KEY = 'contact_briefing_hash';
    public function store(ContactBriefingRequest $request): RedirectResponse
    {
        if (filled($request->input('empresa'))) {
            return $this->success();
        }
        $validated = $request->validated();
        unset($validated['privacidade']);
        if ($this->isDuplicate($validated)) {
            return $this->success();
        }
        $this->rememberSubmission($validated);
        $settings = SiteSetting::instance();
        $fields = $this->buildFields($validated, $this->resolveMarketingOrigin($request));
        $this->dispatchEmails($settings, $validated['nome'], $validated['email'], $fields);
        return $this->success();
    }
    /**
     * @param  array<string, mixed>  $validated
     */
    private function buildFields(array $validated, ?string $marketingOrigin): array
    {
        return [
            'Nome' => (string) $validated['nome'],
            'E-mail' => (string) $validated['email'],
            'Telefone/WhatsApp' => (string) $validated['telefone'],
            'Tipo de evento' => (string) $validated['tipo_evento'],
            'Data ou período desejado' => isset($validated['data_periodo']) ? (string) $validated['data_periodo'] : null,
            'Cidade' => (string) $validated['cidade'],
            'Número estimado de convidados' => isset($validated['convidados']) ? (string) $validated['convidados'] : null,
            'Serviço de interesse' => isset($validated['servico_interesse']) ? (string) $validated['servico_interesse'] : null,
            'Mensagem' => (string) $validated['mensagem'],
            'Origem de marketing' => $marketingOrigin,
        ];
    }
    /**
     * Reads the origin captured on arrival (SPEC.md WEB-05) so it can
     * ride along with the internal briefing e-mail only — never the
     * confirmation sent to the visitor. Fail-open: any problem reading
     * or interpreting the session value must never block the
     * submission, so it degrades to "not captured" instead.
     */
    private function resolveMarketingOrigin(ContactBriefingRequest $request): ?string
    {
        try {
            $origin = $request->session()->get(MarketingOrigin::SESSION_KEY, []);
            return is_array($origin) ? MarketingOrigin::describe($origin) : null;
        } catch (Throwable $exception) {
            Log::warning('Falha ao ler origem de marketing armazenada (ignorada; fail-open)', [
                'exception' => $exception::class,
            ]);
            return null;
        }
    }
    /**
     * @param  array<string, mixed>  $validated
     */
    private function isDuplicate(array $validated): bool
    {
        $hash = $this->hash($validated);
        return session()->get(self::DUPLICATE_SESSION_KEY) === $hash;
    }
    /**
     * @param  array<string, mixed>  $validated
     */
    private function rememberSubmission(array $validated): void
    {
        session()->put(self::DUPLICATE_SESSION_KEY, $this->hash($validated));
    }
    /**
     * @param  array<string, mixed>  $validated
     */
    private function hash(array $validated): string
    {
        return hash('sha256', serialize($validated));
    }
    /**
     * @param  array<string, mixed>  $fields
     */
    private function dispatchEmails(SiteSetting $settings, string $name, string $email, array $fields): void
    {
        $attempt = function () use ($settings, $name, $email, $fields): void {
            if (filled($settings->email)) {
                Mail::to($settings->email)->send(new ContactBriefing($fields));
            }
            if (filled(config('mail.default'))) {
                Mail::to($email)->send(new ContactBriefingConfirmation($name, (string) $settings->brand_name));
            }
        };
        try {
            $attempt();
        } catch (Throwable $exception) {
            Log::error('Falha ao enviar briefing de contato', [
                'exception' => $exception,
            ]);
        }
    }
    private function success(): RedirectResponse
    {
        return redirect()->route('contact')->with('status', 'briefing-sent');
    }
 }
--- a/app/Http/Controllers/PublicSite/PageController.php
+++ b/app/Http/Controllers/PublicSite/PageController.php
@@ -20,7 +20,7 @@ final class PageController extends Controller
            'pageMeta' => PageMeta::forPage(
                canonical: route('about'),
                settings: $settings,
-                title: PageMeta::withBrandSuffix('Sobre', $settings),
+                title: 'Sobre',
                description: $settings->about_summary ?: ('Conheça a '.$settings->brand_name.'.'),
            ),
        ]);
@@ -35,7 +35,7 @@ final class PageController extends Controller
            'pageMeta' => PageMeta::forPage(
                canonical: route('privacy'),
                settings: $settings,
-                title: PageMeta::withBrandSuffix('Política de privacidade', $settings),
+                title: 'Política de privacidade',
                description: 'Política de privacidade da '.$settings->brand_name.'.',
            ),
        ]);
@@ -50,7 +50,7 @@ final class PageController extends Controller
            'pageMeta' => PageMeta::forPage(
                canonical: route('contact'),
                settings: $settings,
-                title: PageMeta::withBrandSuffix('Contato', $settings),
+                title: 'Contato',
                description: 'Fale com a '.$settings->brand_name.'.',
            ),
        ]);
--- a/app/Http/Controllers/PublicSite/PortfolioController.php
+++ b/app/Http/Controllers/PublicSite/PortfolioController.php
@@ -32,7 +32,7 @@ final class PortfolioController extends Controller
            'pageMeta' => PageMeta::forPage(
                canonical: route('portfolio.index'),
                settings: $settings,
-                title: PageMeta::withBrandSuffix('Portfólio', $settings),
+                title: 'Portfólio',
                description: 'Casos reais de eventos conduzidos pela '.$settings->brand_name.'.',
            ),
        ]);
--- a/app/Http/Controllers/PublicSite/ServiceController.php
+++ b/app/Http/Controllers/PublicSite/ServiceController.php
@@ -23,7 +23,7 @@ final class ServiceController extends Controller
            'pageMeta' => PageMeta::forPage(
                canonical: route('services.index'),
                settings: $settings,
-                title: PageMeta::withBrandSuffix('Serviços', $settings),
+                title: 'Serviços',
                description: 'Conheça os serviços de assessoria de eventos da '.$settings->brand_name.'.',
            ),
        ]);
--- a/app/Http/Middleware/CaptureMarketingOrigin.php
+++ b/app/Http/Middleware/CaptureMarketingOrigin.php
@@ -1,85 +0,0 @@
 <?php
 declare(strict_types=1);
 namespace App\Http\Middleware;
 use App\Domain\Contact\MarketingOrigin;
 use Closure;
 use Illuminate\Http\Request;
 use Illuminate\Support\Facades\Log;
 use Symfony\Component\HttpFoundation\Response;
 use Throwable;
 /**
 * Captures the marketing origin (UTM parameters, or the HTTP referrer as
 * a fallback) on the first public page load of a visit and stores it in
 * the session, so it can later travel with a contact briefing submission
 * (SPEC.md WEB-05).
 *
 * First *informative* touch wins: nothing is written until a page load
 * actually carries a UTM parameter or an external referrer, and once
 * that happens later page views never overwrite it — navigating to
 * another page without UTM parameters must not erase what arrived with
 * the visitor. A page load with no signal at all is left unrecorded so a
 * later, informative page load in the same session can still be
 * captured.
 *
 * Fail-open by construction: any failure here is caught and logged
 * without request data, and the request proceeds untouched. This path
 * must never be able to block a page load or, downstream, a conversion.
 */
 final class CaptureMarketingOrigin
 {
    /**
     * Technical routes that share the `web` middleware group but are never a
     * human arriving at the site. A crawler fetching `/sitemap.xml?utm_source=…`
     * would otherwise consume the first-touch slot with traffic that will never
     * submit a briefing.
     *
     * @var list<string>
     */
    private const IGNORED_ROUTES = ['sitemap', 'robots'];
    public function handle(Request $request, Closure $next): Response
    {
        if (in_array($request->route()?->getName(), self::IGNORED_ROUTES, true)) {
            return $next($request);
        }
        try {
            $this->captureFirstTouch($request);
        } catch (Throwable $exception) {
            Log::warning('Falha ao capturar origem de marketing (ignorada; fail-open)', [
                'exception' => $exception::class,
            ]);
        }
        return $next($request);
    }
    private function captureFirstTouch(Request $request): void
    {
        if (! $request->hasSession()) {
            return;
        }
        $session = $request->session();
        if ($session->has(MarketingOrigin::SESSION_KEY)) {
            return;
        }
        $origin = MarketingOrigin::capture(
            $request->query(),
            $request->headers->get('referer'),
            $request->getHost(),
        );
        if ($origin === []) {
            return;
        }
        $session->put(MarketingOrigin::SESSION_KEY, $origin);
    }
 }
--- a/app/Http/Requests/PublicSite/ContactBriefingRequest.php
+++ b/app/Http/Requests/PublicSite/ContactBriefingRequest.php
@@ -1,73 +0,0 @@
 <?php
 declare(strict_types=1);
 namespace App\Http\Requests\PublicSite;
 use App\Domain\Contact\BrazilianPhoneNumber;
 use Illuminate\Foundation\Http\FormRequest;
 final class ContactBriefingRequest extends FormRequest
 {
    /**
     * Normaliza e-mail e telefone antes da validação (SPEC.md §12.3),
     * mantendo o valor legível para quem recebe o briefing por e-mail.
     */
    protected function prepareForValidation(): void
    {
        $email = $this->input('email');
        $telefone = $this->input('telefone');
        $this->merge([
            'email' => is_string($email) ? mb_strtolower(trim($email)) : $email,
            'telefone' => is_string($telefone) ? BrazilianPhoneNumber::normalize($telefone) : $telefone,
        ]);
    }
    /**
     * @return array<string, array<int, string>>
     */
    public function rules(): array
    {
        return [
            'nome' => ['required', 'string', 'max:120'],
            'email' => ['required', 'email', 'max:254'],
            'telefone' => ['required', 'string', 'max:40'],
            'tipo_evento' => ['required', 'string', 'max:80'],
            'data_periodo' => ['nullable', 'string', 'max:80'],
            'cidade' => ['required', 'string', 'max:80'],
            'convidados' => ['nullable', 'integer', 'min:1', 'max:100000'],
            'servico_interesse' => ['nullable', 'string', 'max:120'],
            'mensagem' => ['required', 'string', 'max:3000'],
            'privacidade' => ['accepted'],
        ];
    }
    /**
     * @return array<string, string>
     */
    public function messages(): array
    {
        return [
            'nome.required' => 'Informe seu nome completo.',
            'nome.max' => 'O nome deve ter no máximo :max caracteres.',
            'email.required' => 'Informe seu e-mail.',
            'email.email' => 'Informe um e-mail válido.',
            'email.max' => 'O e-mail deve ter no máximo :max caracteres.',
            'telefone.required' => 'Informe um telefone ou WhatsApp.',
            'telefone.max' => 'O telefone deve ter no máximo :max caracteres.',
            'tipo_evento.required' => 'Selecione o tipo de evento.',
            'tipo_evento.max' => 'O tipo de evento deve ter no máximo :max caracteres.',
            'data_periodo.max' => 'A data ou período deve ter no máximo :max caracteres.',
            'cidade.required' => 'Informe a cidade do evento.',
            'cidade.max' => 'A cidade deve ter no máximo :max caracteres.',
            'convidados.integer' => 'Informe um número de convidados válido.',
            'convidados.min' => 'O número de convidados deve ser maior que zero.',
            'convidados.max' => 'O número de convidados informado é inválido.',
            'servico_interesse.max' => 'O serviço deve ter no máximo :max caracteres.',
            'mensagem.required' => 'Conte brevemente o que você precisa.',
            'mensagem.max' => 'A mensagem deve ter no máximo :max caracteres.',
            'privacidade.accepted' => 'Você precisa aceitar a política de privacidade.',
        ];
    }
 }
--- a/app/Mail/ContactBriefing.php
+++ b/app/Mail/ContactBriefing.php
@@ -1,40 +0,0 @@
 <?php
 declare(strict_types=1);
 namespace App\Mail;
 use Illuminate\Bus\Queueable;
 use Illuminate\Contracts\Queue\ShouldQueue;
 use Illuminate\Mail\Mailable;
 use Illuminate\Mail\Mailables\Content;
 use Illuminate\Mail\Mailables\Envelope;
 use Illuminate\Queue\SerializesModels;
 final class ContactBriefing extends Mailable implements ShouldQueue
 {
    use Queueable;
    use SerializesModels;
    /**
     * @param  array<string, mixed>  $fields
     */
    public function __construct(
        public readonly array $fields,
    ) {}
    public function envelope(): Envelope
    {
        return new Envelope(
            subject: 'Novo briefing de contato — Amare Assessoria',
        );
    }
    public function content(): Content
    {
        return new Content(
            html: 'emails.contact-briefing',
            text: 'emails.contact-briefing-text',
        );
    }
 }
--- a/app/Mail/ContactBriefingConfirmation.php
+++ b/app/Mail/ContactBriefingConfirmation.php
@@ -1,38 +0,0 @@
 <?php
 declare(strict_types=1);
 namespace App\Mail;
 use Illuminate\Bus\Queueable;
 use Illuminate\Contracts\Queue\ShouldQueue;
 use Illuminate\Mail\Mailable;
 use Illuminate\Mail\Mailables\Content;
 use Illuminate\Mail\Mailables\Envelope;
 use Illuminate\Queue\SerializesModels;
 final class ContactBriefingConfirmation extends Mailable implements ShouldQueue
 {
    use Queueable;
    use SerializesModels;
    public function __construct(
        public readonly string $name,
        public readonly string $brandName,
    ) {}
    public function envelope(): Envelope
    {
        return new Envelope(
            subject: 'Recebemos sua mensagem — '.$this->brandName,
        );
    }
    public function content(): Content
    {
        return new Content(
            html: 'emails.contact-briefing-confirmation',
            text: 'emails.contact-briefing-confirmation-text',
        );
    }
 }
--- a/app/Models/SiteSetting.php
+++ b/app/Models/SiteSetting.php
@@ -11,35 +11,17 @@ use Illuminate\Database\Eloquent\Model;
 /**
 * @property array<string, string|null> $social_links
 * @property list<array{title?: string, body?: string}>|null $method_steps
 * @property list<string>|null $principles
 * @property bool $analytics_enabled
 * @property string|null $default_og_image_path
 * @property string|null $default_og_image_alt
 * @property string|null $about_image_path
 * @property string|null $about_image_alt
 * @property string|null $logo_path
 * @property string|null $logo_alt
 */
 #[Fillable([
    'brand_name',
    'logo_path',
    'logo_alt',
    'hero_eyebrow',
    'hero_title',
    'hero_subtitle',
    'hero_cta_label',
    'hero_secondary_cta_label',
    'hero_note',
    'about_summary',
    'about_image_path',
    'about_image_alt',
    'manifesto_title',
    'manifesto_lead',
    'manifesto_body',
    'method_intro',
    'method_steps',
    'principles',
    'email',
    'phone',
    'city',
@@ -58,67 +40,21 @@ class SiteSetting extends Model
    {
        return static::query()->firstOrCreate([], [
            'brand_name' => 'Amare Assessoria',
-            'hero_eyebrow' => 'Assessoria e produção de eventos · São Paulo',
+            'hero_eyebrow' => 'Assessoria de eventos',
            'hero_title' => 'Celebrações com propósito',
            'hero_subtitle' => 'Planejamento completo para casamentos e eventos corporativos.',
-            'hero_cta_label' => 'Solicitar proposta',
+            'hero_cta_label' => 'Solicitar orçamento',
-            'hero_secondary_cta_label' => 'Conheça nosso olhar',
+            'about_summary' => 'Assessoria boutique em Fortaleza.',
-            'hero_note' => 'Planejamento cuidadoso, comunicação clara e execução segura — do primeiro encontro ao último detalhe.',
+            'email' => 'contato@amare.local',
-            'about_summary' => 'Assessoria boutique em São Paulo - SP.',
+            'phone' => '(85) 99999-9999',
-            'manifesto_title' => 'Sofisticação que também se traduz em organização.',
+            'city' => 'Fortaleza, CE',
            'manifesto_lead' => 'Um evento memorável não nasce apenas de uma boa estética. Ele depende de decisões bem conduzidas, fornecedores alinhados e atenção constante ao que realmente importa.',
            'manifesto_body' => 'A Amare combina sensibilidade e precisão para criar encontros coerentes com cada cliente, marca e ocasião — sem fórmulas prontas, excessos ou ruído.',
            'method_intro' => 'Clareza em cada etapa. Tranquilidade durante todo o processo.',
            'method_steps' => self::defaultMethodSteps(),
            'principles' => self::defaultPrinciples(),
            'email' => 'amareassessoriaeventos@gmail.com',
            'phone' => '(11) 99999-9999',
            'city' => 'São Paulo - SP',
            'social_links' => [],
            'default_meta_title' => 'Amare Assessoria de Eventos',
-            'default_meta_description' => 'Assessoria premium para casamentos e eventos corporativos em São Paulo.',
+            'default_meta_description' => 'Assessoria premium para casamentos e eventos corporativos.',
            'analytics_enabled' => false,
        ]);
    }
    /**
     * @return list<array{title: string, body: string}>
     */
    public static function defaultMethodSteps(): array
    {
        return [
            [
                'title' => 'Escuta',
                'body' => 'Entendimento do contexto, das prioridades, do público e do que o evento precisa comunicar.',
            ],
            [
                'title' => 'Direção',
                'body' => 'Definição de escopo, próximos passos, responsabilidades e critérios para orientar decisões.',
            ],
            [
                'title' => 'Produção',
                'body' => 'Coordenação de cronograma, fornecedores, detalhes, alinhamentos e contingências.',
            ],
            [
                'title' => 'Execução',
                'body' => 'Presença atenta no evento para que o planejado aconteça com ritmo, cuidado e segurança.',
            ],
        ];
    }
    /**
     * @return list<string>
     */
    public static function defaultPrinciples(): array
    {
        return [
            'Personalização sem complicação desnecessária',
            'Comunicação clara e decisões bem orientadas',
            'Atenção à experiência de clientes e convidados',
            'Execução responsável do início ao fim',
        ];
    }
    /**
     * @return array<string, string|class-string>
     */
@@ -126,8 +62,6 @@ class SiteSetting extends Model
    {
        return [
            'social_links' => 'array',
            'method_steps' => 'array',
            'principles' => 'array',
            'analytics_enabled' => 'boolean',
        ];
    }
--- a/app/Models/User.php
+++ b/app/Models/User.php
@@ -8,8 +8,6 @@ use App\Enums\UserRole;
 use Database\Factories\UserFactory;
 use Filament\Models\Contracts\FilamentUser;
 use Filament\Panel;
 use Illuminate\Auth\MustVerifyEmail;
 use Illuminate\Contracts\Auth\MustVerifyEmail as MustVerifyEmailContract;
 use Illuminate\Database\Eloquent\Attributes\Fillable;
 use Illuminate\Database\Eloquent\Attributes\Hidden;
 use Illuminate\Database\Eloquent\Factories\HasFactory;
@@ -22,14 +20,14 @@ use Illuminate\Notifications\Notifiable;
 */
 #[Fillable(['name', 'email', 'password', 'role', 'is_active'])]
 #[Hidden(['password', 'remember_token'])]
-class User extends Authenticatable implements FilamentUser, MustVerifyEmailContract
+class User extends Authenticatable implements FilamentUser
 {
    /** @use HasFactory<UserFactory> */
-    use HasFactory, MustVerifyEmail, Notifiable;
+    use HasFactory, Notifiable;
    public function canAccessPanel(Panel $panel): bool
    {
-        return $this->is_active && $this->hasVerifiedEmail();
+        return $this->is_active;
    }
    public function isAdmin(): bool
--- a/app/Providers/AppServiceProvider.php
+++ b/app/Providers/AppServiceProvider.php
@@ -7,9 +7,6 @@ namespace App\Providers;
 use App\Application\Data\PageMeta;
 use App\Models\SiteSetting;
 use Carbon\CarbonImmutable;
 use Illuminate\Cache\RateLimiting\Limit;
 use Illuminate\Http\Request;
 use Illuminate\Support\Facades\RateLimiter;
 use Illuminate\Support\Facades\View;
 use Illuminate\Support\ServiceProvider;
 use Illuminate\View\View as ViewInstance;
@@ -29,9 +26,7 @@ class AppServiceProvider extends ServiceProvider
     */
    public function boot(): void
    {
        $this->configureLivewireTemporaryUploads();
        $this->freezeClockWhenConfigured();
        $this->configureRateLimiters();
        View::composer('layouts.public', function (ViewInstance $view): void {
            $settings = $view->offsetExists('siteSettings')
@@ -51,29 +46,6 @@ class AppServiceProvider extends ServiceProvider
        });
    }
    /**
     * Keep Livewire/Filament temp uploads on the local disk.
     *
     * When FILESYSTEM_DISK=r2, Livewire would otherwise use the S3 driver and
     * browser-PUT straight to R2 (CORS). Final media still uses the r2 disk via
     * PublicImageUploadRules. Explicit LIVEWIRE_TEMPORARY_FILE_UPLOAD_DISK wins.
     */
    private function configureLivewireTemporaryUploads(): void
    {
        if (filled(config('livewire.temporary_file_upload.disk'))) {
            return;
        }
        config(['livewire.temporary_file_upload.disk' => 'local']);
    }
    private function configureRateLimiters(): void
    {
        RateLimiter::for('contact-briefing', function (Request $request): Limit {
            return Limit::perMinute(5)->by($request->ip().'|contact-briefing');
        });
    }
    private function freezeClockWhenConfigured(): void
    {
        if ($this->app->environment('production')) {
--- a/app/Providers/Filament/AdminPanelProvider.php
+++ b/app/Providers/Filament/AdminPanelProvider.php
@@ -1,11 +1,7 @@
 <?php
 declare(strict_types=1);
 namespace App\Providers\Filament;
 use App\Filament\Pages\Auth\RequestPasswordReset;
 use Filament\FontProviders\LocalFontProvider;
 use Filament\Http\Middleware\Authenticate;
 use Filament\Http\Middleware\AuthenticateSession;
 use Filament\Http\Middleware\DisableBladeIconComponents;
@@ -13,7 +9,7 @@ use Filament\Http\Middleware\DispatchServingFilamentEvent;
 use Filament\Pages\Dashboard;
 use Filament\Panel;
 use Filament\PanelProvider;
-use Filament\View\PanelsRenderHook;
+use Filament\Support\Colors\Color;
 use Filament\Widgets\AccountWidget;
 use Filament\Widgets\FilamentInfoWidget;
 use Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse;
@@ -25,137 +21,6 @@ use Illuminate\View\Middleware\ShareErrorsFromSession;
 class AdminPanelProvider extends PanelProvider
 {
    /**
     * Heritage Editorial — Oliva Herança primary ramp.
     *
     * Filament needs an explicit 11-stop shade array to preserve exact brand
     * hexes (a bare string/`Color::hex()` runs the value through
     * `Color::generatePalette()`, which discards its lightness and maps a
     * fixed per-shade lightness/chroma table instead — see MAN-118 survey).
     * Shade 600 pins `#556B2F` (Oliva Herança) and shade 700 pins `#3E5219`
     * (Oliva Profundo). `Filament\Support\View\Components\ColorMaps\
     * ButtonComponentColorMap` was used to verify empirically (not assumed)
     * that a solid primary button resolves to `bg: 600, hover:bg: 500, text:
     * 50` at 5.42:1 / 4.57:1 contrast (WCAG AA). Shade 50 is a pale olive
     * tint rather than pure white deliberately: `BadgeComponent`/
     * `badge.css` apply `bg-color-50` directly as a badge's background
     * (independent of the button map above), and a pure-white 50 would
     * render a "primary" badge as an all-but-invisible pill against the
     * Papel Marfim (`#FBF9F4`) panel body.
     *
     * @return array<int, string>
     */
    private function primaryColor(): array
    {
        return [
            50 => '#F3F5EC',
            100 => '#E7EBDA',
            200 => '#D4DCBE',
            300 => '#8B9D77', // Sálvia Silenciosa
            400 => '#6E8354',
            500 => '#61763A',
            600 => '#556B2F', // Oliva Herança
            700 => '#3E5219', // Oliva Profundo
            800 => '#2E3D13',
            900 => '#1F290D',
            950 => '#141B08',
        ];
    }
    /**
     * Heritage Editorial — paper/ink neutral ramp, replacing Filament's
     * stock Zinc gray so panel chrome (sidebar, topbar, body background,
     * borders) matches the public site's paper tones instead of true gray.
     * Anchored at the exact tokens where DESIGN.md defines them (50/100/200
     * = Papel Marfim/Profundo/Arquivo, 300 = Linha Botânica, 500 = Tinta
     * Suave, 900 = Tinta Oliva); the remaining stops are interpolated to
     * keep the ramp monotonic.
     *
     * @return array<int, string>
     */
    private function grayColor(): array
    {
        return [
            50 => '#FBF9F4', // Papel Marfim
            100 => '#F0EEE9', // Papel Profundo
            200 => '#E4E2DD', // Papel Arquivo
            300 => '#C5C8B8', // Linha Botânica
            400 => '#919486',
            500 => '#5D6155', // Tinta Suave
            600 => '#43453D',
            700 => '#32342E',
            800 => '#252622',
            900 => '#1B1C19', // Tinta Oliva
            950 => '#121210',
        ];
    }
    /**
     * Semantic ramps built the same way as the primary/gray ramps above:
     * an explicit 11-stop array (never `Color::hex()`) anchored so the
     * existing `--amare-color-{success,warning,error}` hex lands exactly on
     * shade 600 — verified against `ButtonComponentColorMap` to resolve to
     * `bg: 600` with white text at WCAG AA contrast, same as primary.
     *
     * @return array<int, string>
     */
    private function dangerColor(): array
    {
        return [
            50 => '#F7EDED',
            100 => '#EBD1D1',
            200 => '#D8A8A8',
            300 => '#C88484',
            400 => '#B85F5F',
            500 => '#A73B3B',
            600 => '#991B1B',
            700 => '#7D1616',
            800 => '#651212',
            900 => '#4C0E0E',
            950 => '#3A0A0A',
        ];
    }
    /**
     * @return array<int, string>
     */
    private function warningColor(): array
    {
        return [
            50 => '#F6F0EC',
            100 => '#E9D9CF',
            200 => '#D6B6A3',
            300 => '#C4987D',
            400 => '#B37956',
            500 => '#A15B30',
            600 => '#92400E',
            700 => '#78340B',
            800 => '#602A09',
            900 => '#492007',
            950 => '#371805',
        ];
    }
    /**
     * @return array<int, string>
     */
    private function successColor(): array
    {
        return [
            50 => '#ECF3EF',
            100 => '#D0E0D6',
            200 => '#A6C4B2',
            300 => '#81AC91',
            400 => '#5C9371',
            500 => '#377B50',
            600 => '#166534',
            700 => '#12532B',
            800 => '#0F4322',
            900 => '#0B321A',
            950 => '#082614',
        ];
    }
    public function panel(Panel $panel): Panel
    {
        return $panel
@@ -163,47 +28,9 @@ class AdminPanelProvider extends PanelProvider
            ->id('admin')
            ->path('admin')
            ->login()
            ->passwordReset(requestAction: RequestPasswordReset::class)
            ->brandName('Amare Assessoria')
            ->brandLogo(fn (): string => asset('brand/lockup-on-light.webp'))
            ->brandLogoHeight('2rem')
            ->colors([
-                'primary' => $this->primaryColor(),
+                'primary' => Color::Amber,
                'gray' => $this->grayColor(),
                'danger' => $this->dangerColor(),
                'warning' => $this->warningColor(),
                'success' => $this->successColor(),
            ])
            // Heritage Editorial is a single paper palette by design (see
            // DESIGN.md) — no dark-mode variant exists, so the switcher is
            // removed rather than left pointing at an unstyled dark theme.
            ->darkMode(false)
            // Self-hosted EB Garamond, same family as the public site.
            // LocalFontProvider is pinned explicitly: HasFont::getFontProvider()
            // otherwise defaults a custom family to BunnyFontProvider, which
            // would emit a live request to fonts.bunny.net from the panel.
            // LocalFontProvider renders no <link>/@font-face itself (no $url
            // given), so the actual face comes from the render hook below,
            // reusing the public site's own <x-fonts /> component/manifest.
            //
            // The monospace and serif faces are set too, not just the base
            // (sans) family: Filament exposes them via the separate
            // ->monoFont()/->serifFont() calls below, and the `KeyValue`
            // field (used in ManageSiteSettings) renders in the monospace
            // face directly — left unset, that field would silently fall
            // back to a system monospace stack instead of EB Garamond,
            // breaking Heritage Editorial's single-voice typography.
            ->font('EB Garamond', provider: LocalFontProvider::class)
            ->monoFont('EB Garamond', provider: LocalFontProvider::class)
            ->serifFont('EB Garamond', provider: LocalFontProvider::class)
            ->renderHook(
                PanelsRenderHook::HEAD_END,
                fn (): string => view('components.fonts')->render(),
            )
            // Compiled Filament theme entry — sharp corners, flat surfaces
            // (see resources/css/filament/admin/theme.css for the full
            // rationale and the two vendored-CSS exceptions it can't reach).
            ->viteTheme('resources/css/filament/admin/theme.css')
            ->discoverResources(in: app_path('Filament/Resources'), for: 'App\Filament\Resources')
            ->discoverPages(in: app_path('Filament/Pages'), for: 'App\Filament\Pages')
            ->pages([
--- a/bootstrap/app.php
+++ b/bootstrap/app.php
@@ -1,6 +1,5 @@
 <?php
 use App\Http\Middleware\CaptureMarketingOrigin;
 use Illuminate\Foundation\Application;
 use Illuminate\Foundation\Configuration\Exceptions;
 use Illuminate\Foundation\Configuration\Middleware;
@@ -15,13 +14,6 @@ return Application::configure(basePath: dirname(__DIR__))
    ->withMiddleware(function (Middleware $middleware): void {
        // Trust Traefik/Dokploy (and local reverse proxies) for X-Forwarded-* headers.
        $middleware->trustProxies(at: '*');
        // Public-site request spine only (routes/web.php uses the "web"
        // group; the Filament admin panel defines its own middleware
        // stack in AdminPanelProvider and never touches this group).
        $middleware->web(append: [
            CaptureMarketingOrigin::class,
        ]);
    })
    ->withExceptions(function (Exceptions $exceptions): void {
        $exceptions->shouldRenderJsonWhen(
--- a/composer.json
+++ b/composer.json
@@ -65,9 +65,6 @@
        "test:browser": [
            "@php artisan test --testsuite=Browser"
        ],
        "test:coverage": [
            "vendor/bin/pest -c phpunit.coverage.xml --testsuite=Unit,Architecture,Feature --coverage --min=80"
        ],
        "pint": [
            "vendor/bin/pint"
        ],
@@ -84,7 +81,6 @@
            "@pint:check",
            "@phpstan",
            "composer audit --no-interaction",
            "npm audit --omit=dev --audit-level=high",
            "@test"
        ],
        "visual:update": [
--- a/composer.lock
+++ b/composer.lock
@@ -2802,16 +2802,16 @@
        },
        {
            "name": "league/commonmark",
-            "version": "2.9.0",
+            "version": "2.8.3",
            "source": {
                "type": "git",
                "url": "https://github.com/thephpleague/commonmark.git",
-                "reference": "5703d83ba3da3b2e356a5fedc848ed6d8ffb6529"
+                "reference": "1902f60f984235023acbe03db6ad614a37b3c3e7"
            },
            "dist": {
                "type": "zip",
-                "url": "https://api.github.com/repos/thephpleague/commonmark/zipball/5703d83ba3da3b2e356a5fedc848ed6d8ffb6529",
+                "url": "https://api.github.com/repos/thephpleague/commonmark/zipball/1902f60f984235023acbe03db6ad614a37b3c3e7",
-                "reference": "5703d83ba3da3b2e356a5fedc848ed6d8ffb6529",
+                "reference": "1902f60f984235023acbe03db6ad614a37b3c3e7",
                "shasum": ""
            },
            "require": {
@@ -2848,7 +2848,7 @@
            "type": "library",
            "extra": {
                "branch-alias": {
-                    "dev-main": "2.10-dev"
+                    "dev-main": "2.9-dev"
                }
            },
            "autoload": {
@@ -2905,7 +2905,7 @@
                    "type": "tidelift"
                }
            ],
-            "time": "2026-08-03T13:42:31+00:00"
+            "time": "2026-07-12T15:29:16+00:00"
        },
        {
            "name": "league/config",
--- a/config/app.php
+++ b/config/app.php
@@ -65,7 +65,7 @@ return [
    |
    */
-    'timezone' => env('APP_TIMEZONE', 'America/Sao_Paulo'),
+    'timezone' => env('APP_TIMEZONE', 'America/Fortaleza'),
    /*
    |--------------------------------------------------------------------------
--- a/database/factories/PortfolioCaseFactory.php
+++ b/database/factories/PortfolioCaseFactory.php
@@ -26,7 +26,7 @@ class PortfolioCaseFactory extends Factory
            'slug' => str($title)->slug()->toString(),
            'summary' => fake()->sentence(),
            'event_type' => 'Casamento',
-            'city' => 'São Paulo',
+            'city' => 'Fortaleza',
            'venue' => fake()->company(),
            'event_date' => fake()->date(),
            'challenge' => fake()->paragraph(),
--- a/database/fixtures/images/about-image.jpg
+++ b/database/fixtures/images/about-image.jpg
--- a/database/fixtures/images/case-casamento-ana-lucas.jpg
+++ b/database/fixtures/images/case-casamento-ana-lucas.jpg
--- a/database/fixtures/images/case-lancamento-verano.jpg
+++ b/database/fixtures/images/case-lancamento-verano.jpg
--- a/database/fixtures/images/case-mini-wedding-marina.jpg
+++ b/database/fixtures/images/case-mini-wedding-marina.jpg
--- a/database/fixtures/images/gallery-casamento-ana-lucas-1.jpg
+++ b/database/fixtures/images/gallery-casamento-ana-lucas-1.jpg
--- a/database/fixtures/images/gallery-casamento-ana-lucas-2.jpg
+++ b/database/fixtures/images/gallery-casamento-ana-lucas-2.jpg
--- a/database/fixtures/images/gallery-lancamento-verano-1.jpg
+++ b/database/fixtures/images/gallery-lancamento-verano-1.jpg
--- a/database/fixtures/images/gallery-lancamento-verano-2.jpg
+++ b/database/fixtures/images/gallery-lancamento-verano-2.jpg
--- a/database/fixtures/images/gallery-mini-wedding-marina-1.jpg
+++ b/database/fixtures/images/gallery-mini-wedding-marina-1.jpg
--- a/database/fixtures/images/gallery-mini-wedding-marina-2.jpg
+++ b/database/fixtures/images/gallery-mini-wedding-marina-2.jpg
--- a/database/fixtures/images/og-default.jpg
+++ b/database/fixtures/images/og-default.jpg
--- a/database/fixtures/images/service-casamentos.jpg
+++ b/database/fixtures/images/service-casamentos.jpg
--- a/database/fixtures/images/service-celebracoes-intimistas.jpg
+++ b/database/fixtures/images/service-celebracoes-intimistas.jpg
--- a/database/fixtures/images/service-eventos-corporativos.jpg
+++ b/database/fixtures/images/service-eventos-corporativos.jpg
--- a/database/migrations/2026_08_01_224956_add_editorial_fields_to_site_settings_table.php
+++ b/database/migrations/2026_08_01_224956_add_editorial_fields_to_site_settings_table.php
@@ -1,44 +0,0 @@
 <?php
 declare(strict_types=1);
 use Illuminate\Database\Migrations\Migration;
 use Illuminate\Database\Schema\Blueprint;
 use Illuminate\Support\Facades\Schema;
 return new class extends Migration
 {
    public function up(): void
    {
        Schema::table('site_settings', function (Blueprint $table): void {
            $table->string('logo_path')->nullable()->after('brand_name');
            $table->string('logo_alt')->nullable()->after('logo_path');
            $table->string('hero_secondary_cta_label')->nullable()->after('hero_cta_label');
            $table->text('hero_note')->nullable()->after('hero_secondary_cta_label');
            $table->string('manifesto_title')->nullable()->after('about_summary');
            $table->text('manifesto_lead')->nullable()->after('manifesto_title');
            $table->text('manifesto_body')->nullable()->after('manifesto_lead');
            $table->text('method_intro')->nullable()->after('manifesto_body');
            $table->jsonb('method_steps')->nullable()->after('method_intro');
            $table->jsonb('principles')->nullable()->after('method_steps');
        });
    }
    public function down(): void
    {
        Schema::table('site_settings', function (Blueprint $table): void {
            $table->dropColumn([
                'logo_path',
                'logo_alt',
                'hero_secondary_cta_label',
                'hero_note',
                'manifesto_title',
                'manifesto_lead',
                'manifesto_body',
                'method_intro',
                'method_steps',
                'principles',
            ]);
        });
    }
 };
--- a/database/migrations/2026_08_06_000000_add_about_image_to_site_settings_table.php
+++ b/database/migrations/2026_08_06_000000_add_about_image_to_site_settings_table.php
@@ -1,25 +0,0 @@
 <?php
 declare(strict_types=1);
 use Illuminate\Database\Migrations\Migration;
 use Illuminate\Database\Schema\Blueprint;
 use Illuminate\Support\Facades\Schema;
 return new class extends Migration
 {
    public function up(): void
    {
        Schema::table('site_settings', function (Blueprint $table): void {
            $table->string('about_image_path')->nullable()->after('about_summary');
            $table->string('about_image_alt')->nullable()->after('about_image_path');
        });
    }
    public function down(): void
    {
        Schema::table('site_settings', function (Blueprint $table): void {
            $table->dropColumn(['about_image_path', 'about_image_alt']);
        });
    }
 };
--- a/database/migrations/2026_08_10_120000_verify_existing_user_emails.php
+++ b/database/migrations/2026_08_10_120000_verify_existing_user_emails.php
@@ -1,42 +0,0 @@
 <?php
 declare(strict_types=1);
 use Illuminate\Database\Migrations\Migration;
 use Illuminate\Support\Facades\DB;
 /**
 * Backfills `email_verified_at` for users that already exist.
 *
 * `User` now implements MustVerifyEmail and `canAccessPanel()` requires
 * `hasVerifiedEmail()`. Every account created before this change has
 * `email_verified_at` as null, so without this backfill they are locked out of
 * `/admin` the moment the change deploys — and there is no way back in from
 * inside the app: no self-service verification route is registered, and the
 * password-reset flow deliberately skips notifying users that fail
 * `canAccessPanel()` while still reporting success. Recovery would need shell
 * access to the container.
 *
 * Verifying them is the correct default, not a shortcut. There is no public
 * registration: every existing account was created by an admin, through the
 * panel or the tinker snippet in docs/deployment/dokploy.md. That act is the
 * verification — which is exactly the reasoning CreateUser applies to accounts
 * created from now on.
 */
 return new class extends Migration
 {
    public function up(): void
    {
        DB::table('users')
            ->whereNull('email_verified_at')
            ->update(['email_verified_at' => DB::raw('COALESCE(created_at, NOW())')]);
    }
    public function down(): void
    {
        // Deliberately not reversed. Nulling these columns would lock every
        // existing user out of the panel, which is the failure this migration
        // exists to prevent — and the pre-migration null/non-null split is not
        // recorded anywhere, so it could not be restored faithfully anyway.
    }
 };
--- a/database/seeders/ContentSeeder.php
+++ b/database/seeders/ContentSeeder.php
@@ -8,10 +8,9 @@ use App\Models\PortfolioCase;
 use App\Models\PortfolioImage;
 use App\Models\Service;
 use App\Models\SiteSetting;
-use App\Support\PublicImageUploadRules;
+use App\Models\Testimonial;
 use Illuminate\Database\Seeder;
 use Illuminate\Support\Carbon;
 use Illuminate\Support\Facades\App;
 use Illuminate\Support\Facades\File;
 use Illuminate\Support\Facades\Storage;
@@ -19,65 +18,31 @@ class ContentSeeder extends Seeder
 {
    private const SEED_TIMESTAMP = '2026-01-15 10:00:00';
    /**
     * Demo/fixture content is meant for local dev, automated testing, and
     * staging visual review only. It must never overwrite owner-edited
     * SiteSetting, Service, and PortfolioCase records, never re-upload
     * fixture images to the production storage disk, and never auto-publish
     * the fictional portfolio cases or (via TestimonialsSeeder) the real
     * testimonials.
     *
     * This is deliberately an allow-list of the known-safe environments
     * ('local', 'staging', 'testing') rather than a deny-list of
     * 'production'. APP_ENV is a free-text value hand-typed into the
     * Dokploy environment UI with no validation — a blank value, a typo, or
     * an unexpected casing (e.g. '', 'Production', 'staginng') must fail
     * closed (skip seeding) rather than fail open (seed/overwrite
     * production data). Only the three recognized values run this seeder;
     * everything else, including 'production' itself, is a no-op.
     *
     * Publishing testimonials in production remains a deliberate, manually
     * triggered step — see docs/deployment/dokploy.md.
     */
    public function run(): void
    {
        if (! App::environment(['local', 'staging', 'testing'])) {
            return;
        }
        $this->seedSiteSettings();
        $this->seedServices();
        $this->seedPortfolioCases();
-        $this->call(TestimonialsSeeder::class);
+        $this->seedTestimonials();
    }
    private function seedSiteSettings(): void
    {
        SiteSetting::query()->updateOrCreate([], [
            'brand_name' => 'Amare Assessoria',
-            'hero_eyebrow' => 'Assessoria e produção de eventos · São Paulo',
+            'hero_eyebrow' => 'Assessoria de eventos',
            'hero_title' => 'Celebrações com propósito',
-            'hero_subtitle' => 'Planejamento completo para casamentos e eventos corporativos em São Paulo.',
+            'hero_subtitle' => 'Planejamento completo para casamentos e eventos corporativos em Fortaleza.',
-            'hero_cta_label' => 'Solicitar proposta',
+            'hero_cta_label' => 'Solicitar orçamento',
-            'hero_secondary_cta_label' => 'Conheça nosso olhar',
+            'about_summary' => 'Assessoria boutique especializada em experiências memoráveis.',
-            'hero_note' => 'Planejamento cuidadoso, comunicação clara e execução segura — do primeiro encontro ao último detalhe.',
+            'email' => 'contato@amare.local',
-            'about_summary' => 'Assessoria boutique especializada em experiências memoráveis em São Paulo.',
+            'phone' => '(85) 99999-9999',
-            'about_image_path' => $this->copyFixture('about-image.jpg', 'content/about/about-image.jpg'),
+            'city' => 'Fortaleza, CE',
            'about_image_alt' => 'Mesa de planejamento com caderno, café e guardanapos de pano',
            'manifesto_title' => 'Sofisticação que também se traduz em organização.',
            'manifesto_lead' => 'Um evento memorável não nasce apenas de uma boa estética. Ele depende de decisões bem conduzidas, fornecedores alinhados e atenção constante ao que realmente importa.',
            'manifesto_body' => 'A Amare combina sensibilidade e precisão para criar encontros coerentes com cada cliente, marca e ocasião — sem fórmulas prontas, excessos ou ruído.',
            'method_intro' => 'Clareza em cada etapa. Tranquilidade durante todo o processo.',
            'method_steps' => SiteSetting::defaultMethodSteps(),
            'principles' => SiteSetting::defaultPrinciples(),
            'email' => 'amareassessoriaeventos@gmail.com',
            'phone' => '(11) 99999-9999',
            'city' => 'São Paulo - SP',
            'social_links' => [
                'instagram' => 'https://instagram.com/amare',
            ],
            'default_meta_title' => 'Amare Assessoria de Eventos',
-            'default_meta_description' => 'Assessoria premium para casamentos e eventos corporativos em São Paulo.',
+            'default_meta_description' => 'Assessoria premium para casamentos e eventos corporativos.',
            'default_og_image_path' => $this->copyFixture('og-default.jpg', 'content/og/og-default.jpg'),
            'default_og_image_alt' => 'Identidade visual da Amare Assessoria de Eventos',
            'analytics_enabled' => false,
@@ -119,7 +84,7 @@ class ContentSeeder extends Seeder
                ['slug' => $service['slug']],
                [
                    ...$service,
-                    'cover_image_path' => $this->copyFixture('service-'.$service['slug'].'.jpg', 'content/services/'.$service['slug'].'.jpg'),
+                    'cover_image_path' => $this->copyFixture('service-cover.jpg', 'content/services/'.$service['slug'].'.jpg'),
                    'cover_image_alt' => 'Capa do serviço '.$service['title'],
                    'published_at' => Carbon::parse(self::SEED_TIMESTAMP),
                ],
@@ -133,9 +98,9 @@ class ContentSeeder extends Seeder
            [
                'title' => 'Casamento Ana e Lucas',
                'slug' => 'casamento-ana-lucas',
-                'summary' => 'Cerimônia ao ar livre em São Paulo.',
+                'summary' => 'Cerimônia ao ar livre em Fortaleza.',
                'event_type' => 'Casamento',
-                'city' => 'São Paulo',
+                'city' => 'Fortaleza',
                'venue' => 'Espaço Jardim Atlântico',
                'event_date' => '2025-11-20',
                'challenge' => 'Integrar cerimônia e recepção em áreas distintas.',
@@ -148,7 +113,7 @@ class ContentSeeder extends Seeder
                'slug' => 'lancamento-verano',
                'summary' => 'Evento corporativo de lançamento de coleção.',
                'event_type' => 'Corporativo',
-                'city' => 'São Paulo',
+                'city' => 'Fortaleza',
                'venue' => 'Centro de Convenções',
                'event_date' => '2025-09-10',
                'challenge' => 'Ativar marca em ambiente multiestação.',
@@ -159,10 +124,10 @@ class ContentSeeder extends Seeder
            [
                'title' => 'Mini wedding Marina',
                'slug' => 'mini-wedding-marina',
-                'summary' => 'Celebração intimista em São Paulo.',
+                'summary' => 'Celebração intimista à beira-mar.',
                'event_type' => 'Mini wedding',
-                'city' => 'São Paulo',
+                'city' => 'Caucaia',
-                'venue' => 'Espaço intimista',
+                'venue' => 'Pousada da Praia',
                'event_date' => '2025-06-02',
                'challenge' => 'Clima e logística em área externa.',
                'solution' => 'Plano B estruturado e fornecedores locais alinhados.',
@@ -176,7 +141,7 @@ class ContentSeeder extends Seeder
                ['slug' => $caseData['slug']],
                [
                    ...$caseData,
-                    'cover_image_path' => $this->copyFixture('case-'.$caseData['slug'].'.jpg', 'content/portfolio/'.$caseData['slug'].'-cover.jpg'),
+                    'cover_image_path' => $this->copyFixture('portfolio-cover.jpg', 'content/portfolio/'.$caseData['slug'].'-cover.jpg'),
                    'cover_image_alt' => 'Capa do caso '.$caseData['title'],
                    'is_featured' => true,
                    'published_at' => Carbon::parse(self::SEED_TIMESTAMP),
@@ -188,7 +153,7 @@ class ContentSeeder extends Seeder
            foreach ([1, 2] as $index) {
                PortfolioImage::query()->create([
                    'portfolio_case_id' => $case->id,
-                    'path' => $this->copyFixture('gallery-'.$caseData['slug'].'-'.$index.'.jpg', 'content/portfolio/'.$caseData['slug'].'-gallery-'.$index.'.jpg'),
+                    'path' => $this->copyFixture('gallery.jpg', 'content/portfolio/'.$caseData['slug'].'-gallery-'.$index.'.jpg'),
                    'alt_text' => 'Galeria '.$caseData['title'].' '.$index,
                    'caption' => $index === 1 ? 'Detalhe da decoração' : null,
                    'sort_order' => $index,
@@ -197,12 +162,52 @@ class ContentSeeder extends Seeder
        }
    }
    private function seedTestimonials(): void
    {
        $testimonials = [
            [
                'quote' => 'A Amare transformou nosso casamento em uma experiência inesquecível.',
                'author_name' => 'Ana Souza',
                'context' => 'Noiva',
                'sort_order' => 1,
                'is_featured' => true,
            ],
            [
                'quote' => 'Profissionalismo do início ao fim no lançamento da nossa coleção.',
                'author_name' => 'Marcos Lima',
                'context' => 'Diretor de marketing',
                'sort_order' => 2,
                'is_featured' => true,
            ],
            [
                'quote' => 'Cuidaram de cada detalhe com sensibilidade e precisão.',
                'author_name' => 'Marina Costa',
                'context' => 'Anfitriã',
                'sort_order' => 3,
                'is_featured' => false,
            ],
        ];
        foreach ($testimonials as $testimonial) {
            Testimonial::query()->updateOrCreate(
                [
                    'author_name' => $testimonial['author_name'],
                    'quote' => $testimonial['quote'],
                ],
                [
                    ...$testimonial,
                    'photo_path' => $this->copyFixture('testimonial.jpg', 'content/testimonials/'.str($testimonial['author_name'])->slug().'.jpg'),
                    'photo_alt' => 'Foto de '.$testimonial['author_name'],
                    'published_at' => Carbon::parse(self::SEED_TIMESTAMP),
                ],
            );
        }
    }
    private function copyFixture(string $fixtureName, string $destination): string
    {
-        $source = base_path('database/fixtures/images/'.$fixtureName);
+        $source = base_path('tests/fixtures/images/'.$fixtureName);
-        $disk = PublicImageUploadRules::disk();
+        Storage::disk('public')->put($destination, File::get($source));
        Storage::disk($disk)->put($destination, File::get($source), 'public');
        return $destination;
    }
--- a/database/seeders/DatabaseSeeder.php
+++ b/database/seeders/DatabaseSeeder.php
@@ -23,7 +23,6 @@ class DatabaseSeeder extends Seeder
                'password' => Hash::make('password'),
                'role' => UserRole::Admin,
                'is_active' => true,
                'email_verified_at' => now(),
            ],
        );
@@ -34,7 +33,6 @@ class DatabaseSeeder extends Seeder
                'password' => Hash::make('password'),
                'role' => UserRole::Assistant,
                'is_active' => true,
                'email_verified_at' => now(),
            ],
        );
--- a/database/seeders/TestimonialsSeeder.php
+++ b/database/seeders/TestimonialsSeeder.php
@@ -1,70 +0,0 @@
 <?php
 declare(strict_types=1);
 namespace Database\Seeders;
 use App\Models\Testimonial;
 use Illuminate\Database\Seeder;
 use Illuminate\Support\Facades\DB;
 class TestimonialsSeeder extends Seeder
 {
    private const PUBLISHED_AT = '2026-08-05 00:00:00';
    public function run(): void
    {
        $testimonials = [
            [
                'quote' => "Mi, quero agradecer você e a sua equipe por todo empenho, atenção, vocês são abençoadas.\n\nEra nítida sua preocupação em garantir que todos os detalhes planejados desta comemoração, fossem atendidos.\n\nQue você possa transformar o grande dia das noivinhas sempre com essa sua leveza!!!\n\nMuito obrigada!",
                'author_name' => 'Jeniffer e Maick',
                'context' => 'Casamento · 06/12/2025',
                'sort_order' => 1,
                'is_featured' => true,
            ],
            [
                'quote' => "Mi, eu não tenho palavras pra agradecer você e tudo que você fez por mim e por nós na realização desse sonho. Eu tô ainda extasiada com tudo que aconteceu hoje; mas tenho certeza que sem a sua ajuda, muita coisa não aconteceria.\n\nObrigada por tudo !",
                'author_name' => 'Quesia e Jhonata',
                'context' => 'Casamento · 21/12/2025',
                'sort_order' => 2,
                'is_featured' => true,
            ],
            [
                'quote' => 'Que equipe!! Que equipe maravilhosa!! Obrigado pelo empenho de fazer tudo como eu queria!! Obrigado por se esforçar tanto e vir de tão longe pra realizar meu sonho!! Incríveis!!',
                'author_name' => 'Milena e Weslley',
                'context' => 'Casamento · 13/02/2026',
                'sort_order' => 3,
                'is_featured' => false,
            ],
            [
                'quote' => "Gostaríamos de agradecer por todo o acompanhamento e dedicação durante a realização do nosso casamento. Foi um dia muito especial e inesquecível para nós.\n\nDesde o início, conseguimos conduzir tudo aquilo que estávamos planejando, dentro dos horários que estipulamos, o que foi ótimo, e no grande dia sua equipe nos recebeu e tratou com muito carinho, atenção e cuidado, o que fez toda a diferença para vivermos esse momento com mais tranquilidade.\n\nTambém adoramos as sugestões e ideias para as fotos, que deixaram os registros ainda mais bonitos e espontâneos, porque não iríamos lembrar de quais poses fazer na hora.\n\nObrigada por fazer parte de um momento tão importante das nossas vidas. Desejamos muito sucesso e que muitos outros casais possam viver dias especiais através do trabalho da AMARE.",
                'author_name' => 'Raquel e Pedro',
                'context' => 'Casamento · 09/05/2026',
                'sort_order' => 4,
                'is_featured' => false,
            ],
            [
                'quote' => "Miiii, meu amor… você e sua equipe foram impecáveis.\n\nSuperou todas as nossas expectativas. Somos eternamente gratos por fazer nosso dia acontecer muito melhor do que imaginávamos.\n\nSempre muito atenciosa e paciente.\n\nAdoramos te conhecer e estamos muito felizes em termos escolhido você para assessorar nosso dia.",
                'author_name' => 'Victoria e Pedro',
                'context' => 'Casamento · 24/06/2026',
                'sort_order' => 5,
                'is_featured' => false,
            ],
        ];
        DB::transaction(function () use ($testimonials): void {
            foreach ($testimonials as $testimonial) {
                Testimonial::query()->updateOrCreate(
                    ['author_name' => $testimonial['author_name']],
                    [
                        'quote' => $testimonial['quote'],
                        'context' => $testimonial['context'],
                        'sort_order' => $testimonial['sort_order'],
                        'is_featured' => $testimonial['is_featured'],
                        'published_at' => self::PUBLISHED_AT,
                    ],
                );
            }
        });
    }
 }
--- a/database/seeders/VisualContentSeeder.php
+++ b/database/seeders/VisualContentSeeder.php
@@ -11,6 +11,7 @@ use App\Models\SiteSetting;
 use App\Models\Testimonial;
 use Illuminate\Database\Seeder;
 use Illuminate\Support\Carbon;
 use Illuminate\Support\Facades\File;
 use Illuminate\Support\Facades\Storage;
 /**
@@ -36,30 +37,20 @@ class VisualContentSeeder extends Seeder
    {
        SiteSetting::query()->updateOrCreate([], [
            'brand_name' => 'Amare Assessoria',
-            'hero_eyebrow' => 'Assessoria e produção de eventos · São Paulo',
+            'hero_eyebrow' => 'Assessoria de eventos',
            'hero_title' => 'Celebrações com propósito',
-            'hero_subtitle' => 'Planejamento completo para casamentos e eventos corporativos em São Paulo.',
+            'hero_subtitle' => 'Planejamento completo para casamentos e eventos corporativos em Fortaleza.',
-            'hero_cta_label' => 'Solicitar proposta',
+            'hero_cta_label' => 'Solicitar orçamento',
-            'hero_secondary_cta_label' => 'Conheça nosso olhar',
+            'about_summary' => 'Assessoria boutique especializada em experiências memoráveis.',
-            'hero_note' => 'Planejamento cuidadoso, comunicação clara e execução segura — do primeiro encontro ao último detalhe.',
+            'email' => 'contato@amare.local',
-            'about_summary' => 'Assessoria boutique especializada em experiências memoráveis em São Paulo.',
+            'phone' => '(85) 99999-9999',
-            'about_image_path' => $this->writeSolidJpeg('visual/about/about-image.jpg', 1200, 900, [232, 228, 218]),
+            'city' => 'Fortaleza, CE',
            'about_image_alt' => 'Imagem editorial da página Sobre',
            'manifesto_title' => 'Sofisticação que também se traduz em organização.',
            'manifesto_lead' => 'Um evento memorável não nasce apenas de uma boa estética. Ele depende de decisões bem conduzidas, fornecedores alinhados e atenção constante ao que realmente importa.',
            'manifesto_body' => 'A Amare combina sensibilidade e precisão para criar encontros coerentes com cada cliente, marca e ocasião — sem fórmulas prontas, excessos ou ruído.',
            'method_intro' => 'Clareza em cada etapa. Tranquilidade durante todo o processo.',
            'method_steps' => SiteSetting::defaultMethodSteps(),
            'principles' => SiteSetting::defaultPrinciples(),
            'email' => 'amareassessoriaeventos@gmail.com',
            'phone' => '(11) 99999-9999',
            'city' => 'São Paulo - SP',
            'social_links' => [
                'instagram' => 'https://instagram.com/amare',
            ],
            'default_meta_title' => 'Amare Assessoria de Eventos',
-            'default_meta_description' => 'Assessoria premium para casamentos e eventos corporativos em São Paulo.',
+            'default_meta_description' => 'Assessoria premium para casamentos e eventos corporativos.',
-            'default_og_image_path' => $this->writeSolidJpeg('visual/og/og-default.jpg', 1600, 1067, [85, 107, 47]),
+            'default_og_image_path' => $this->copyFixture('og-default.jpg', 'visual/og/og-default.jpg'),
            'default_og_image_alt' => 'Identidade visual da Amare Assessoria de Eventos',
            'analytics_enabled' => false,
            'analytics_script' => null,
@@ -90,7 +81,7 @@ class VisualContentSeeder extends Seeder
                ['slug' => $service['slug']],
                [
                    ...$service,
-                    'cover_image_path' => $this->writeSolidJpeg('visual/services/'.$service['slug'].'.jpg', 1600, 1000, [196, 200, 184]),
+                    'cover_image_path' => $this->copyFixture('service-cover.jpg', 'visual/services/'.$service['slug'].'.jpg'),
                    'cover_image_alt' => 'Capa do serviço '.$service['title'],
                    'published_at' => Carbon::parse(self::SEED_TIMESTAMP),
                ],
@@ -104,9 +95,9 @@ class VisualContentSeeder extends Seeder
            [
                'title' => 'Casamento Ana e Lucas',
                'slug' => 'casamento-ana-lucas',
-                'summary' => 'Cerimônia ao ar livre em São Paulo.',
+                'summary' => 'Cerimônia ao ar livre em Fortaleza.',
                'event_type' => 'Casamento',
-                'city' => 'São Paulo',
+                'city' => 'Fortaleza',
                'venue' => 'Espaço Jardim Atlântico',
                'event_date' => '2025-11-20',
                'challenge' => 'Integrar cerimônia e recepção em áreas distintas.',
@@ -119,7 +110,7 @@ class VisualContentSeeder extends Seeder
                'slug' => 'lancamento-verano',
                'summary' => 'Evento corporativo de lançamento de coleção.',
                'event_type' => 'Corporativo',
-                'city' => 'São Paulo',
+                'city' => 'Fortaleza',
                'venue' => 'Centro de Convenções',
                'event_date' => '2025-09-10',
                'challenge' => 'Ativar marca em ambiente multiestação.',
@@ -134,7 +125,7 @@ class VisualContentSeeder extends Seeder
                ['slug' => $caseData['slug']],
                [
                    ...$caseData,
-                    'cover_image_path' => $this->writeSolidJpeg('visual/portfolio/'.$caseData['slug'].'-cover.jpg', 1600, 1200, [240, 238, 233]),
+                    'cover_image_path' => $this->copyFixture('portfolio-cover.jpg', 'visual/portfolio/'.$caseData['slug'].'-cover.jpg'),
                    'cover_image_alt' => 'Capa do caso '.$caseData['title'],
                    'is_featured' => true,
                    'published_at' => Carbon::parse(self::SEED_TIMESTAMP),
@@ -145,7 +136,7 @@ class VisualContentSeeder extends Seeder
            PortfolioImage::query()->create([
                'portfolio_case_id' => $case->id,
-                'path' => $this->writeSolidJpeg('visual/portfolio/'.$caseData['slug'].'-gallery-1.jpg', 1600, 1200, [228, 226, 221]),
+                'path' => $this->copyFixture('gallery.jpg', 'visual/portfolio/'.$caseData['slug'].'-gallery-1.jpg'),
                'alt_text' => 'Galeria '.$caseData['title'].' 1',
                'caption' => 'Detalhe da decoração',
                'sort_order' => 1,
@@ -155,53 +146,26 @@ class VisualContentSeeder extends Seeder
    private function seedTestimonials(): void
    {
        Testimonial::query()->whereNotIn('author_name', [
            'Jeniffer e Maick',
            'Quesia e Jhonata',
        ])->delete();
        foreach ([
            [
                'quote' => "Mi, quero agradecer você e a sua equipe por todo empenho, atenção, vocês são abençoadas.\n\nEra nítida sua preocupação em garantir que todos os detalhes planejados desta comemoração, fossem atendidos.\n\nQue você possa transformar o grande dia das noivinhas sempre com essa sua leveza!!!\n\nMuito obrigada!",
                'author_name' => 'Jeniffer e Maick',
                'context' => 'Casamento · 06/12/2025',
                'sort_order' => 1,
            ],
            [
                'quote' => "Mi, eu não tenho palavras pra agradecer você e tudo que você fez por mim e por nós na realização desse sonho. Eu tô ainda extasiada com tudo que aconteceu hoje; mas tenho certeza que sem a sua ajuda, muita coisa não aconteceria.\n\nObrigada por tudo !",
                'author_name' => 'Quesia e Jhonata',
                'context' => 'Casamento · 21/12/2025',
                'sort_order' => 2,
            ],
        ] as $testimonial) {
        Testimonial::query()->updateOrCreate(
                ['author_name' => $testimonial['author_name']],
            [
-                    ...$testimonial,
+                'author_name' => 'Ana Souza',
                'quote' => 'A Amare transformou nosso casamento em uma experiência inesquecível.',
            ],
            [
                'context' => 'Noiva',
                'sort_order' => 1,
                'is_featured' => true,
-                    'photo_path' => null,
+                'photo_path' => $this->copyFixture('testimonial.jpg', 'visual/testimonials/ana-souza.jpg'),
-                    'photo_alt' => null,
+                'photo_alt' => 'Foto de Ana Souza',
                'published_at' => Carbon::parse(self::SEED_TIMESTAMP),
            ],
        );
    }
    }
-    /**
+    private function copyFixture(string $fixtureName, string $destination): string
     * @param  array{0: int, 1: int, 2: int}  $rgb
     */
    private function writeSolidJpeg(string $destination, int $width, int $height, array $rgb): string
    {
-        $image = imagecreatetruecolor($width, $height);
+        $source = base_path('tests/fixtures/images/'.$fixtureName);
-        $color = imagecolorallocate($image, $rgb[0], $rgb[1], $rgb[2]);
+        Storage::disk('public')->put($destination, File::get($source));
        imagefilledrectangle($image, 0, 0, $width, $height, $color);
        ob_start();
        imagejpeg($image, null, 90);
        $binary = (string) ob_get_clean();
        imagedestroy($image);
        Storage::disk('public')->put($destination, $binary);
        return $destination;
    }
--- a/depoimentos.md
+++ b/depoimentos.md
@@ -1,39 +0,0 @@
 > **Status deste arquivo:** material bruto histórico, não consumido por
 > nenhum código do site. Os cinco depoimentos abaixo foram transcritos
 > manualmente para dentro de `database/seeders/TestimonialsSeeder.php` e,
 > em produção, o conteúdo real vive no banco de dados, editável apenas
 > pela tela **Depoimentos** do painel administrativo (`/admin`). Editar
 > este arquivo não tem nenhum efeito no site publicado. Mantido apenas como
 > referência histórica de onde o conteúdo original veio. Ver
 > `docs/operations/atualizacao-de-conteudo.md` para o fluxo de edição real.
 Mi, quero agradecer você e a sua equipe por todo empenho, atenção, vocês são abençoadas.
 Era nítida sua preocupação em garantir que todos os detalhes planejados desta comemoração, fossem atendidos. 
 Que você possa transformar o grande dia das noivinhas sempre com essa sua leveza!!! ❤️
 Muito obrigada!
 Jeniffer e Maick
 Casamento - 06/12/2025
 ----
 Mi, eu não tenho palavras pra agradecer você e tudo que você fez por mim e por nós na realização desse sonho. Eu tô ainda extasiada com tudo que aconteceu hoje; mas tenho certeza que sem a sua ajuda, muita coisa não aconteceria.
 Obrigada por tudo !
 Quesia e Jhonata
 casamento - 21/12/2025
 ----
@_amareassessoria
 Que equipe!! Que equipe maravilhosa!! Obrigado pelo empenho de fazer tudo como eu queria!! Obrigado por se esforçar tanto e vir de tão longe pra realizar meu sonho!! Incríveis!! 😍😍
 Milena e Weslley 
 casamento - 13/02/2026
 ---
 Gostaríamos de agradecer por todo o acompanhamento e dedicação durante a realização do nosso casamento. Foi um dia muito especial e inesquecível para nós.
 Desde o início, conseguimos conduzir tudo aquilo que estávamos planejando, dentro dos horários que estipulamos, o que foi ótimo, e no grande dia sua equipe nos recebeu e tratou com muito carinho, atenção e cuidado, o que fez toda a diferença para vivermos esse momento com mais tranquilidade.
 Também adoramos as sugestões e ideias para as fotos, que deixaram os registros ainda mais bonitos e espontâneos, porque não iríamos lembrar de quais poses fazer na hora.
 Obrigada por fazer parte de um momento tão importante das nossas vidas. Desejamos muito sucesso e que muitos outros casais possam viver dias especiais através do trabalho da AMARE.
 Raquel e Pedro 
 casamento - 09/05/2026
 ----
 Miiii, meu amor… você e sua equipe foram impecáveis. 
 Superou todas as nossas expectativas. Somos eternamente gratos por fazer nosso dia acontecer muito melhor do que imaginávamos. 
 Sempre muito atenciosa e paciente.
 Adoramos te conhecer e estamos muito felizes em termos escolhido você para assessorar nosso dia.  ♥️🙏🏻
 Victoria e Pedro 
 casamento -24/06/2026
--- a/docker-compose.deploy.yml
+++ b/docker-compose.deploy.yml
@@ -4,8 +4,6 @@
 #   IMAGE_TAG=staging|production|<git-sha>
 # PostgreSQL is a separate Dokploy database service (not defined here).
 # Traefik/Dokploy domains should target service `web` port 8000.
 # App services join dokploy-network so they can resolve Dokploy-managed
 # Postgres internal hosts (e.g. amare-stg-pez43e).
 services:
  migrate:
@@ -14,15 +12,7 @@ services:
    restart: "no"
    env_file:
      - .env
-    # Exec-array form on a single line, deliberately. A folded block scalar
+    command: ["php", "artisan", "migrate", "--force", "--no-interaction"]
    # (`command: >`) keeps the newline before any line indented deeper than the
    # first, so `sh -c` receives a multi-line string and dies with
    # `sh: 2: Syntax error: "&&" unexpected` before running anything. That broke
    # every staging deploy from 58f24a6 onward, and had already broken them once
    # before 5949fad. Keep this on one line; do not reformat it for width.
    command: ["sh", "-c", "php artisan migrate --force --no-interaction && php artisan db:seed --class=ContentSeeder --force --no-interaction && php artisan media:generate-variants"]
    networks:
      - dokploy-network
  web:
    image: ${APP_IMAGE}:${IMAGE_TAG}
@@ -41,8 +31,6 @@ services:
      timeout: 5s
      start_period: 40s
      retries: 3
    networks:
      - dokploy-network
  queue:
    image: ${APP_IMAGE}:${IMAGE_TAG}
@@ -56,8 +44,6 @@ services:
    command: ["php", "artisan", "queue:work", "--sleep=2", "--tries=3", "--max-time=3600"]
    stop_grace_period: 60s
    stop_signal: SIGTERM
    networks:
      - dokploy-network
  scheduler:
    image: ${APP_IMAGE}:${IMAGE_TAG}
@@ -71,9 +57,3 @@ services:
    command: ["php", "artisan", "schedule:work"]
    stop_grace_period: 30s
    stop_signal: SIGTERM
    networks:
      - dokploy-network
 networks:
  dokploy-network:
    external: true
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -18,34 +18,5 @@ services:
      retries: 10
      start_period: 10s
  # Local parity with the FrankenPHP image used on staging/production.
  # Manual smoke test (not run in CI — the `container` job already builds and
  # health-checks the same Dockerfile-based image):
  #   docker compose up -d
  #   curl localhost:8000/up
  app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: amare-app
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    env_file:
      - .env
    environment:
      # Override host-side .env defaults: DB_HOST=127.0.0.1 only resolves for
      # processes running on the host, not for this container reaching the
      # `postgres` service by its Compose service name. DB_PORT is also
      # forced back to Postgres's internal container port (5432) — .env may
      # have DB_PORT remapped for host-side tooling (e.g. to avoid a local
      # port clash), but that remapping only applies to the published host
      # port, never to container-to-container traffic.
      DB_HOST: postgres
      DB_PORT: "5432"
    ports:
      - "8000:8000"
 volumes:
  amare_postgres_data:
--- a/docker/Caddyfile
+++ b/docker/Caddyfile
@@ -5,20 +5,5 @@
 :8000 {
    root * /app/public
    encode gzip zstd
    # Vite emits content-hashed filenames, so a build asset URL never changes
    # meaning. Same for uploaded media: PublicImageUploadRules stores every
    # upload under a fresh UUID (and ResponsiveImage derives its variants from
    # that name), so replacing an image produces a new URL rather than new bytes
    # at the old one. Both are safe to pin for a year.
    @immutable path /build/* /storage/*
    header @immutable Cache-Control "public, max-age=31536000, immutable"
    # Brand assets ship inside the image under stable filenames, so a rebrand
    # reuses the same URL. One day plus Caddy's ETag revalidation keeps repeat
    # views cheap without pinning an outdated logo in browsers.
    @brand path /brand/*
    header @brand Cache-Control "public, max-age=86400"
    php_server
 }
--- a/docs/agents/domain.md
+++ b/docs/agents/domain.md
@@ -1,51 +0,0 @@
 # Domain Docs
 How the engineering skills should consume this repo's domain documentation when exploring the codebase.
 ## Before exploring, read these
 - **`CONTEXT.md`** at the repo root, or
 - **`CONTEXT-MAP.md`** at the repo root if it exists — it points at one `CONTEXT.md` per context. Read each one relevant to the topic.
 - **`docs/adr/`** — read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
 If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `/domain-modeling` skill (reached via `/grill-with-docs` and `/improve-codebase-architecture`) creates them lazily when terms or decisions actually get resolved.
 ## File structure
 Single-context repo (most repos):
 ```
 /
 ├── CONTEXT.md
 ├── docs/adr/
 │   ├── 0001-event-sourced-orders.md
 │   └── 0002-postgres-for-write-model.md
 └── src/
 ```
 Multi-context repo (presence of `CONTEXT-MAP.md` at the root):
 ```
 /
 ├── CONTEXT-MAP.md
 ├── docs/adr/                          ← system-wide decisions
 └── src/
    ├── ordering/
    │   ├── CONTEXT.md
    │   └── docs/adr/                  ← context-specific decisions
    └── billing/
        ├── CONTEXT.md
        └── docs/adr/
 ```
 ## Use the glossary's vocabulary
 When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
 If the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).
 ## Flag ADR conflicts
 If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
 > _Contradicts ADR-0007 (event-sourced orders) — but worth reopening because…_
--- a/docs/agents/issue-tracker.md
+++ b/docs/agents/issue-tracker.md
@@ -1,26 +0,0 @@
 # Issue tracker: Linear
 Issues and specs for this repo live in Linear. Use the Linear MCP tools for all operations.
 - **Workspace**: maneco-workspace (https://linear.app/maneco-workspace)
 - **Team**: Maneco-workspace
 - **Issue statuses**: Backlog, Todo, In Progress, Done, Canceled, Duplicate
 ## Conventions
 - **Create an issue**: `save_issue` with `title`, `team` (`Maneco-workspace`), and markdown `description`. Assign via `assignee` ("me" for the current user).
 - **Read an issue**: `get_issue` by identifier (e.g. `LIN-123`).
 - **List issues**: `list_issues` filtered by `team`, `assignee`, `state`, or `project`.
 - **Comment on an issue**: `save_comment` with `issueId` and markdown `body`.
 - **Apply / remove labels**: `save_issue` with `labels` (replaces the full set).
 - **Move workflow state**: `save_issue` with `state` (e.g. `Todo`, `In Progress`, `Done`, `Canceled`).
 - **Link work**: `save_issue` with `project`, `cycle`, `parentId`, `blocks` / `blockedBy` (relations are append-only).
 - **Cross-link to a PR**: attach the PR URL via `save_issue` `links`.
 ## When a skill says "publish to the issue tracker"
 Create a Linear issue with `save_issue` on team `Maneco-workspace`.
 ## When a skill says "fetch the relevant ticket"
 Run `get_issue` on the identifier and read the description, state, labels, and assignee.
--- a/docs/agents/triage-labels.md
+++ b/docs/agents/triage-labels.md
@@ -1,15 +0,0 @@
 # Triage Labels
 The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
 | Label in mattpocock/skills | Label in our tracker | Meaning                                  |
 | -------------------------- | -------------------- | ---------------------------------------- |
 | `needs-triage`             | `needs-triage`       | Maintainer needs to evaluate this issue  |
 | `needs-info`               | `needs-info`         | Waiting on reporter for more information |
 | `ready-for-agent`          | `ready-for-agent`    | Fully specified, ready for an AFK agent  |
 | `ready-for-human`          | `ready-for-human`    | Requires human implementation            |
 | `wontfix`                  | `wontfix`            | Will not be actioned                     |
 When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
 Edit the right-hand column to match whatever vocabulary you actually use.
--- a/docs/deployment/dokploy.md
+++ b/docs/deployment/dokploy.md
@@ -50,8 +50,6 @@ IMAGE_TAG=staging   # or production
 Point Dokploy domain(s) at service **`web`**, port **`8000`**. Do not publish PostgreSQL or host ports for app processes.
 Compose services must join the external Docker network `dokploy-network` (declared in `docker-compose.deploy.yml`) so they can resolve the Dokploy-managed Postgres internal host (e.g. `amare-stg-pez43e`). Set `DB_HOST` to that **Internal Host** from the Dokploy database UI — not a public hostname.
 Source can be GitHub (so Dokploy clones the compose file) or Raw paste of `docker-compose.deploy.yml`. Prefer GitHub + fixed compose path so updates stay in sync with `main`.
 ## Required Laravel env (Dokploy only)
@@ -67,10 +65,10 @@ APP_URL=https://staging.example.com
 APP_LOCALE=pt_BR
 APP_FALLBACK_LOCALE=pt_BR
-APP_TIMEZONE=America/Sao_Paulo
+APP_TIMEZONE=America/Fortaleza
 DB_CONNECTION=pgsql
-DB_HOST=<dokploy-postgres-internal-host>  # Internal Host from Dokploy UI (requires dokploy-network)
+DB_HOST=<dokploy-postgres-host>
 DB_PORT=5432
 DB_DATABASE=amare_staging
 DB_USERNAME=...
@@ -100,41 +98,19 @@ LOG_LEVEL=warning
 Trusted proxies are configured in `bootstrap/app.php` so Traefik `X-Forwarded-*` headers work for HTTPS cookies and URLs.
 Livewire temporary uploads default to the **local** disk in `AppServiceProvider` (even when `FILESYSTEM_DISK=r2`), so Filament does not browser-PUT to R2. Final media still lands on R2 via `PublicImageUploadRules`. Optional override: `LIVEWIRE_TEMPORARY_FILE_UPLOAD_DISK` in Dokploy `.env` (`env_file` accepts any key — does not need a compose `environment:` entry).
 ### R2 CORS (public/media reads from JS)
 Upload path does not need R2 CORS with the local temp-disk default. Still useful if the browser fetches R2 URLs cross-origin from JS. Origin must match `APP_URL` exactly; include `AllowedHeaders`:
 ```json
 [
  {
    "AllowedOrigins": ["https://hellomanoel.com"],
    "AllowedMethods": ["GET", "PUT", "POST", "HEAD"],
    "AllowedHeaders": ["*"],
    "ExposeHeaders": ["ETag", "Content-Type"],
    "MaxAgeSeconds": 3600
  }
 ]
 ```
 Also enable public access / custom domain for `R2_URL` so `<img>` URLs work after save.
 ## GitHub Actions secrets
 Repository secrets used by workflows:
 | Secret | Purpose |
 |---|---|
-| `DOKPLOY_URL` | Panel origin **without** `/api` (e.g. `https://panel.example.com`). Do not use the OpenAPI base URL that ends in `/api` — that yields `/api/api/...` and 404s. |
+| `DOKPLOY_URL` | Base URL of the Dokploy panel (no trailing slash) |
 | `DOKPLOY_API_KEY` | API key from Dokploy profile → API/CLI |
-| `DOKPLOY_STAGING_COMPOSE_ID` | Staging **Compose** service id (not an Application id) |
+| `DOKPLOY_STAGING_COMPOSE_ID` | Staging compose id |
-| `DOKPLOY_PRODUCTION_COMPOSE_ID` | Production **Compose** service id (not an Application id) |
+| `DOKPLOY_PRODUCTION_COMPOSE_ID` | Production compose id |
 | `STAGING_URL` | Public origin for staging smoke (e.g. `https://staging.example.com`) |
 | `PRODUCTION_URL` | Public origin for production smoke |
 HTTP 404 from `compose.deploy` usually means the compose id is wrong (Application id instead of Compose) or `DOKPLOY_URL` still includes `/api`.
 `GITHUB_TOKEN` (automatic) publishes to GHCR with `packages:write`. No Laravel/`APP_KEY`/DB/R2/Resend secrets belong in GitHub for this pipeline.
 ## Workflows
@@ -159,71 +135,27 @@ HTTP 404 from `compose.deploy` usually means the compose id is wrong (Applicatio
 Private repos on GitHub Free do not get Environment required reviewers; human approval is the explicit `workflow_dispatch` + confirmation string. GitHub Pro Environment reviewers are optional later.
-## First admin and authorized production seeding
+## First admin (no `db:seed` in production)
 Seed credentials are local-only. For staging/production:
 FrankenPHP sets `XDG_CONFIG_HOME=/config` (Caddy). PsySH/tinker then tries `/config/psysh`, which `appuser` cannot write — you get `Writing to directory /config/psysh is not allowed.` Override that env for the one-shot command:
 ```bash
 # From Dokploy → staging/production → Open terminal on `web` (or one-off run)
-XDG_CONFIG_HOME=/tmp php artisan tinker --execute="
+php artisan tinker --execute="
-\$user = \\App\\Models\\User::query()->updateOrCreate(
+\\App\\Models\\User::query()->updateOrCreate(
  ['email' => 'admin@example.com'],
  [
    'name' => 'Admin',
-    'password' => 'use-a-strong-password',
+    'password' => bcrypt('use-a-strong-password'),
    'role' => 'admin',
    'is_active' => true,
    'email_verified_at' => now(),
  ]
 );
 \$user->forceFill(['email_verified_at' => now()])->save();
 echo \$user->email.PHP_EOL;
 "
 ```
-Plain password is enough: `User` casts `password` to `hashed` (and skips re-hash when value already hashed). `email_verified_at` is not mass-assignable — use `forceFill` as above.
+Adjust field names if the model evolves. Never reuse `admin@amare.local` / `password`.
 Confirm:
 ```bash
 XDG_CONFIG_HOME=/tmp php artisan tinker --execute="echo \\App\\Models\\User::query()->where('email', 'admin@example.com')->exists() ? 'ok' : 'missing';"
 ```
 Never reuse `admin@amare.local` / `password`.
 ### Load authorized testimonials after migrations
 After migrations, manually load the five authorized testimonials in **staging**, then repeat in **production**. From Dokploy, open a terminal on the environment's `web` service (or run an equivalent one-off process):
 ```bash
 php artisan db:seed --class='Database\Seeders\TestimonialsSeeder' --force --no-interaction
 ```
 This seeder is safe to rerun: it overwrites canonical source-owned fields, preserves curated photo fields, and leaves unrelated testimonials unchanged. The five records are published with the approved deterministic timestamp. Upsert keys on `author_name` (no unique DB constraint); keep one row per couple before/after running.
 Optional verification:
 ```bash
 XDG_CONFIG_HOME=/tmp php artisan tinker --execute="
 \$expected = collect(['Jeniffer e Maick', 'Quesia e Jhonata', 'Milena e Weslley', 'Raquel e Pedro', 'Victoria e Pedro']);
 \$rows = \\App\\Models\\Testimonial::query()->whereIn('author_name', \$expected)->get(['author_name', 'published_at'])->groupBy('author_name');
 \$valid = \$expected->every(function (string \$author) use (\$rows): bool {
  \$matches = \$rows->get(\$author, collect());
  return \$matches->count() === 1
    && \$matches->first()->published_at?->format('Y-m-d H:i:s') === '2026-08-05 00:00:00';
 });
 echo (\$valid ? 'ok' : 'invalid').PHP_EOL;
 "
 ```
 Expected output: `ok`.
 The `migrate` service in `docker-compose.deploy.yml` runs `php artisan db:seed --class=ContentSeeder --force --no-interaction` on every deploy, in both stacks. `ContentSeeder::run()` guards itself with an **allow-list** — `App::environment(['local', 'staging', 'testing'])` — and returns immediately (exit code 0, no side effects) unless `APP_ENV` is exactly one of those three values. In **staging** (`APP_ENV=staging`) the guard matches, so `ContentSeeder` still seeds its demo content on every deploy — this is required for visual review and is expected behavior, not a bug. In **production** (`APP_ENV=production`), and for any blank, mistyped, or unexpectedly cased `APP_ENV` value in any stack, the guard does not match, so the step is a deliberate no-op: it never overwrites SiteSetting/Service/PortfolioCase records edited in Filament, never re-uploads fixture images to the production storage disk, and never auto-publishes the fictional portfolio cases. Note the tradeoff this implies: if staging's `APP_ENV` is ever typo'd away from exactly `staging`, demo content silently stops being (re)seeded there too — check the Dokploy environment value first if a staging deploy stops refreshing demo content.
 Do not run bare `DatabaseSeeder` in staging or production: it also creates the `admin@amare.local` / `password` local-dev credentials.
 Publishing the five real testimonials is a separate, deliberate, manually triggered step **only in production** — `ContentSeeder` calls `TestimonialsSeeder` internally, but that call is skipped in production by the same allow-list guard, so the command above is the only path that publishes testimonials there. In **staging**, this is not manual: because the allow-list guard matches `staging`, `ContentSeeder` calls `TestimonialsSeeder` automatically on every deploy, auto-publishing/re-publishing the five canonical testimonials each time (consistent with staging's role as a demo/preview environment).
 ## Backup and restore
--- a/docs/evidence/public-site-motion/about-desktop.png
+++ b/docs/evidence/public-site-motion/about-desktop.png
--- a/docs/evidence/public-site-motion/contact-mobile.png
+++ b/docs/evidence/public-site-motion/contact-mobile.png
--- a/docs/operations/atualizacao-de-conteudo.md
+++ b/docs/operations/atualizacao-de-conteudo.md
@@ -1,417 +0,0 @@
 # Atualização de conteúdo do site
 Guia para quem cuida do conteúdo do site (textos, fotos, casos de portfólio,
 depoimentos, serviços e dados de contato) sem precisar mexer em código.
 O site é editado por um painel interno chamado **"admin"** — é uma tela web,
 parecida com um formulário, onde cada bloco do site (textos da home, casos de
 portfólio, depoimentos, etc.) vira uma "página" que você edita e salva.
 > Antes de qualquer coisa, leia a seção **"A regra mais importante: o que
 > torna algo visível no site"** — ela explica um comportamento que engana
 > quase todo mundo na primeira vez.
 ## Sumário
 - [Como entrar no painel](#como-entrar-no-painel)
 - [A regra mais importante: o que torna algo visível no site](#a-regra-mais-importante-o-que-torna-algo-visível-no-site)
 - [Editar os textos da home e das páginas institucionais](#editar-os-textos-da-home-e-das-páginas-institucionais)
 - [Casos de portfólio: criar, editar, publicar e despublicar](#casos-de-portfólio-criar-editar-publicar-e-despublicar)
 - [Depoimentos: adicionar e publicar](#depoimentos-adicionar-e-publicar)
 - [Serviços: editar](#serviços-editar)
 - [Contato: telefone, e-mail e redes sociais](#contato-telefone-e-mail-e-redes-sociais)
 - [Imagens: formatos aceitos, tamanho e texto alternativo](#imagens-formatos-aceitos-tamanho-e-texto-alternativo)
 - [Usuários: papéis, ativar e desativar contas](#usuários-papéis-ativar-e-desativar-contas)
 - [O que NÃO mexer — e com quem falar](#o-que-não-mexer--e-com-quem-falar)
 - [Seções da home que somem por completo se ficarem vazias](#seções-da-home-que-somem-por-completo-se-ficarem-vazias)
 - [Sobre o arquivo depoimentos.md na raiz do repositório](#sobre-o-arquivo-depoimentosmd-na-raiz-do-repositório)
 ## Como entrar no painel
 1. Acesse `/admin` no domínio do site (ex.: `https://seusite.com.br/admin`).
 2. Se você não estiver logada, o painel mostra uma tela de login pedindo
   e-mail e senha.
 3. Faça login com o e-mail e senha da sua conta.
 **Se você não conseguir entrar:**
 - **Esqueceu a senha:** hoje o painel **não tem** um link de "esqueci minha
  senha" self-service. Só uma pessoa com perfil **Administrador** consegue
  trocar a senha de outra conta (em Usuários → editar a conta → campo
  "Senha"). Se você é a única Administradora e está travada fora do painel,
  vai precisar pedir para quem desenvolve o site trocar a senha diretamente
  no banco de dados.
 - **Mensagem de acesso negado / conta inativa:** sua conta pode estar com o
  campo "Ativo" desligado. Só uma Administradora pode reativar isso em
  Usuários (veja [O que NÃO mexer](#o-que-não-mexer--e-com-quem-falar) sobre
  quem pode mexer em contas de usuário).
 - **Perfil "Assistente" sem acesso a nada:** hoje, contas com o papel
  "Assistente" conseguem fazer login, mas não conseguem ver nem editar
  **nenhum** conteúdo — nem Configurações, nem Portfólio, nem Depoimentos,
  nada. Isso é uma limitação atual do sistema, não um erro seu. Se você
  precisa dar acesso de edição a alguém que não seja Administrador, avise
  quem desenvolve o site — hoje não existe um meio-termo (“pode editar mas
  não pode tudo”), só "Administrador com acesso total" ou "Assistente sem
  acesso a nada".
 ## A regra mais importante: o que torna algo visível no site
 Duas coisas controlam se algo aparece no site. Entender essas duas evita
 99% das dúvidas de "publiquei e não apareceu" ou "não publiquei e apareceu".
 ### 1. O campo "Publicado em" não é um agendamento
 Em Serviços, Portfólio e Depoimentos existe um campo chamado **"Publicado
 em"**. A intuição normal seria pensar "se eu colocar uma data futura, ele só
 aparece nessa data" — **isso está errado**. Assim que você preenche esse
 campo com **qualquer** data/hora (passada, presente ou futura) e salva, o
 item fica visível no site **imediatamente**. Não existe agendamento.
 - **Para publicar:** preencha "Publicado em" com uma data qualquer e salve.
 - **Para despublicar:** apague o conteúdo desse campo (deixe em branco) e
  salve. Colocar uma data no futuro **não** esconde o item — ele continua
  visível.
 ### 2. Home precisa de DOIS interruptores; páginas de listagem só de um
 - Nas páginas de listagem completas — `/servicos` (todos os serviços) e
  `/portfolio` (todos os casos) — basta o item estar **publicado** (campo
  "Publicado em" preenchido) para aparecer.
 - Já nos blocos de **Serviços** e **Portfólio dentro da home** (a página
  inicial), o item só aparece se **as duas coisas** forem verdadeiras ao
  mesmo tempo:
  1. Estiver **publicado** ("Publicado em" preenchido), **e**
  2. Tiver o interruptor **"Destaque"** ligado.
  Publicar sozinho não é suficiente para aparecer na home — só coloca o item
  na listagem completa. Você precisa também ligar "Destaque" se quiser que
  apareça na home.
 - **Depoimentos são a exceção**: o bloco de Depoimentos na home mostra
  **todo** depoimento publicado, independente do interruptor "Destaque". Em
  Depoimentos, "Destaque" só serve para filtrar a tabela dentro do painel —
  não muda nada no que aparece para quem visita o site.
 ## Editar os textos da home e das páginas institucionais
 No menu lateral, vá em **Configurações** (dentro do grupo "Conteúdo do
 site"). É uma página só, dividida em seções. Edite o que quiser e clique em
 salvar no final.
 **Diferente de Portfólio, Depoimentos e Serviços, aqui não existe "Publicado
 em".** Tudo o que você salva em Configurações entra no ar imediatamente —
 não há passo extra de publicação nem como "rascunhar" uma mudança antes de
 ela aparecer no site.
 - **Marca e hero** — nome da marca, logo (+ texto alternativo, obrigatório
  se houver logo), textos do topo da home ("hero"): eyebrow (frase pequena
  acima do título), título, subtítulo, texto dos dois botões de chamada
  (CTA), nota de rodapé do hero, e o **resumo institucional**
  (`about_summary`). **Atenção:** nome da marca, título do hero, subtítulo
  e texto do botão principal são **obrigatórios** — o formulário não deixa
  salvar em branco. Já o eyebrow, o botão secundário e a nota do hero podem
  ficar em branco (o site simplesmente não mostra essa parte se estiver
  vazia).
  - O **resumo institucional** é usado em **dois lugares** e se comporta
    diferente em cada um: na seção "A Amare" da home, se ficar em branco o
    site mostra uma frase padrão fixa no lugar; já na página **Sobre**
    (`/sobre`), esse mesmo texto aparece como o parágrafo principal e, se
    ficar em branco, **fica realmente vazio** ali (sem frase padrão). O
    formulário **deixa salvar em branco sem avisar** — ou seja, não dá erro
    nenhum, o parágrafo só fica vazio silenciosamente na página Sobre até
    alguém notar. Por isso, nunca deixe o resumo institucional em branco;
    depois de editar, confira a página `/sobre` para garantir que o texto
    apareceu.
  - A página **Sobre** também tem uma frase fixa no código
    ("A [nome da marca] atua em [cidade] com foco em planejamento
    completo...") que **não é editável pelo painel** — ela só muda se você
    editar Nome da marca ou Cidade (que entram nessa frase), o resto do
    texto é fixo. Para mudar essa frase, é preciso pedir para quem
    desenvolve o site.
 - **Manifesto editorial** — título, texto de abertura ("lead") e corpo do
  bloco "Manifesto" da home. Diferente de outros textos, se você deixar
  esses campos em branco o site **não** esconde a seção — ele mostra um
  texto padrão fixo no lugar. Ou seja: em branco aqui não é "some", é
  "volta ao texto genérico".
 - **Método** — introdução do bloco "Método" e até 4 passos (título +
  descrição cada), reordenáveis arrastando. Se você apagar todos os passos,
  o site mostra passos padrão pré-definidos em vez de ficar vazio.
 - **Princípios** — lista de princípios (tags) mostrada na seção
  institucional. Se ficar vazia, o site mostra uma lista padrão.
 - **Página Sobre** — imagem da página "Sobre" (+ texto alternativo,
  obrigatório se houver imagem).
 - **SEO padrão** — título e descrição que aparecem quando o site é
  compartilhado ou aparece no Google (título e descrição são obrigatórios),
  e a imagem padrão de compartilhamento (que também é reaproveitada como a
  imagem à direita no hero da home — ao trocar essa imagem, ela muda em
  dois lugares ao mesmo tempo).
 - **Analytics** — **não mexa aqui**, veja [O que NÃO mexer](#o-que-não-mexer--e-com-quem-falar).
 ## Casos de portfólio: criar, editar, publicar e despublicar
 No menu, vá em **Portfólio**.
 ### Criar ou editar um caso
 Clique em "Novo" (ou abra um caso existente) e preencha:
 - **Título** e **Slug** — o slug é o pedacinho do endereço na internet
  (ex.: `casamento-joana-pedro`). Se você deixar o slug em branco ao criar,
  ele é gerado automaticamente a partir do título. **Depois de publicado,
  evite mudar o slug** — isso quebra qualquer link já compartilhado para
  aquele caso (redes sociais, WhatsApp, Google). Se precisar mesmo mudar,
  veja [O que NÃO mexer](#o-que-não-mexer--e-com-quem-falar).
 - **Resumo** — texto curto usado nas listagens.
 - **Tipo de evento**, **Cidade**, **Local**, **Data do evento**.
 - **Desafio**, **Solução**, **Resultado** — o texto do "case" propriamente
  dito (Desafio e Solução são obrigatórios; Resultado é opcional).
 - **Imagem de capa** (+ texto alternativo, obrigatório se houver imagem).
  **Atenção:** diferente de quase toda outra imagem do painel, a capa de um
  caso de portfólio é **sempre obrigatória** por trás dos panos — mas o
  formulário **não bloqueia** o salvamento se você esquecer de anexá-la.
  Se você tentar salvar um caso novo sem imagem de capa, o painel não avisa
  "campo obrigatório": o salvamento simplesmente falha com um erro técnico
  feio (erro de banco de dados), não a mensagem amigável que você vê para
  título, resumo etc. Sempre anexe a imagem de capa antes de salvar um caso
  novo.
 - **Ordem** — número usado para ordenar os casos nas listagens.
 - **Destaque** — liga/desliga a aparição desse caso na home (ver regra das
  [duas chaves](#a-regra-mais-importante-o-que-torna-algo-visível-no-site)).
 - **Publicado em** — data de publicação (ver
  [regra de publicação](#a-regra-mais-importante-o-que-torna-algo-visível-no-site)).
 - **Meta title** / **Meta description** — título e descrição específicos
  desse caso para compartilhamento e Google (opcionais; se em branco, usa
  o padrão configurado em Configurações).
 ### Galeria de fotos do caso
 Depois de salvar o caso, abra-o novamente e procure a aba **"Galeria"**.
 Ali você adiciona quantas fotos quiser, cada uma com:
 - **Imagem** (obrigatória para criar o item da galeria). **Atenção:** assim
  como a capa do caso, o formulário **não bloqueia** o salvamento se você
  esquecer a imagem — ele deixa parecer que deu certo até você clicar em
  salvar, e aí falha com um erro técnico de banco de dados em vez de avisar
  "campo obrigatório". Sempre anexe a imagem antes de salvar um item da
  galeria.
 - **Texto alternativo** — **obrigatório assim que você anexa uma imagem**.
  O sistema não deixa salvar uma foto sem essa descrição.
 - **Legenda** (opcional) — texto que aparece junto da foto.
 - **Ordem** — dá para arrastar as fotos na tabela para reordenar.
 ### Publicar e despublicar um caso
 - **Publicar:** preencha "Publicado em" com qualquer data e salve. Aparece
  imediatamente em `/portfolio` e na página própria do caso. Para também
  aparecer na home, ligue "Destaque".
 - **Despublicar:** apague o conteúdo de "Publicado em" e salve. Colocar
  uma data futura **não** esconde o caso.
 **"Excluir" não é a mesma coisa que despublicar.** Cada linha da tabela de
 Portfólio (e também cada foto dentro da aba "Galeria") tem um botão
 **"Excluir"**, além do botão de editar. Diferente de despublicar, Excluir
 **apaga o caso para sempre**: não existe lixeira, não existe desfazer, e ao
 excluir um caso todas as fotos da galeria dele são apagadas junto
 automaticamente. Selecionar várias linhas na tabela também libera uma ação
 de exclusão em massa, que apaga todas de uma vez com uma única confirmação.
 Para esconder um caso do site, **sempre** use "apagar o Publicado em" — só
 use Excluir quando tiver certeza de que quer destruir o registro
 definitivamente.
 ## Depoimentos: adicionar e publicar
 No menu, vá em **Depoimentos**.
 - **Depoimento** — o texto do casal. Se você separar o texto em parágrafos
  com uma linha em branco entre eles, o site respeita essa quebra e mostra
  cada parágrafo separadamente.
 - **Nome do autor** — ex.: "Jeniffer e Maick".
 - **Contexto** — texto livre mostrado como "— contexto", ex.:
  `Casamento · 06/12/2025`.
 - **Foto** (+ texto alternativo, obrigatório se houver foto) — atenção: a
  foto **existe no formulário mas hoje não aparece** na home; o campo é
  preenchido para o futuro, mas visualmente ainda não é exibido.
 - **Ordem** — ordena os depoimentos no bloco da home.
 - **Destaque** — **não afeta o site público**. Serve só para filtrar a
  tabela de depoimentos dentro do painel.
 - **Publicado em** — este é o único interruptor que importa para
  depoimentos aparecerem na home. Preencha e salve para publicar; apague e
  salve para despublicar. Não existe listagem própria de depoimentos fora
  da home.
 **Atenção ao botão "Excluir"** em cada linha da tabela (e à exclusão em
 massa ao selecionar várias linhas): ele é diferente de despublicar e apaga
 o depoimento para sempre, sem lixeira e sem desfazer. Para tirar um
 depoimento do ar, apague o "Publicado em" — não use Excluir a menos que
 queira apagar o registro definitivamente.
 ## Serviços: editar
 No menu, vá em **Serviços**.
 - **Título** e **Slug** (mesmo comportamento de auto-geração e mesmo
  cuidado ao mudar depois de publicado que o portfólio).
 - **Resumo** e **Descrição**.
 - **Imagem de capa** (+ texto alternativo, obrigatório se houver imagem).
 - **Ordem**, **Destaque** e **Publicado em** funcionam exatamente como em
  portfólio: publicado aparece em `/servicos`; publicado **e** destaque
  aparece também na home.
 **Atenção ao botão "Excluir"** em cada linha da tabela (e à exclusão em
 massa ao selecionar várias linhas): ele é diferente de despublicar e apaga
 o serviço para sempre, sem lixeira e sem desfazer. Para tirar um serviço do
 ar, apague o "Publicado em" — não use Excluir a menos que queira apagar o
 registro definitivamente.
 ## Contato: telefone, e-mail e redes sociais
 Esses campos ficam em **Configurações → seção "Contato"**.
 - **E-mail** e **Telefone** são obrigatórios — o formulário não deixa
  salvá-los em branco. Eles aparecem no rodapé do site e na página
  "Contato" como links clicáveis (e-mail abre o programa de e-mail;
  telefone abre o discador do celular). **Importante:** esse mesmo e-mail
  é também o endereço para onde o site envia toda mensagem enviada pelo
  formulário de contato em `/contato` (o "briefing" que um visitante
  preenche e envia). Ou seja, esse campo não é só um link de exibição —
  ele precisa ser uma caixa de entrada de verdade, monitorada, porque é
  para lá que vão os pedidos de orçamento e contato de clientes em
  potencial. Trocar esse e-mail por um endereço que ninguém acompanha faz
  o site parar de avisar sobre novos contatos, sem nenhum erro aparecer em
  lugar nenhum do painel.
 - **Importante sobre WhatsApp:** hoje existe **um único campo de
  telefone**, e ele vira apenas um link `tel:` (ligação), **não** um botão
  de WhatsApp. Se o número cadastrado for um número de WhatsApp, quem
  clicar vai abrir o discador, não o WhatsApp. Se você precisa de um botão
  específico de WhatsApp no site, isso é um pedido para quem desenvolve o
  site — hoje o campo não faz isso sozinho.
 - **Cidade** — opcional, aparece na página de Contato.
 - **Redes sociais** — lista de "Rede" + "URL" (ex.: `instagram` →
  `https://instagram.com/suaempresa`). Adicione quantas quiser pelo botão
  "Adicionar rede"; para remover uma, apague a linha inteira.
 ## Imagens: formatos aceitos, tamanho e texto alternativo
 Vale para **toda** imagem enviada em qualquer tela do painel (logo, capas,
 galeria de portfólio, fotos de depoimento, imagem da página Sobre, imagem
 de SEO):
 - **Formatos aceitos:** JPG, JPEG, PNG ou WEBP. Qualquer outro formato
  (ex.: HEIC direto do iPhone, PDF, GIF) é recusado com uma mensagem de
  erro — converta a imagem antes de enviar. **HEIC é o caso mais comum**,
  porque é o formato padrão das fotos tiradas no iPhone. Duas formas
  simples de resolver:
  - **Fotos novas:** no iPhone, vá em Ajustes → Câmera → Formatos e
    escolha "Mais Compatível" — a partir daí, novas fotos já são salvas em
    JPEG em vez de HEIC.
  - **Fotos que já estão em HEIC:** envie a foto para você mesma por
    WhatsApp (ex.: em "Mensagens salvas" ou num grupo/conversa qualquer) e
    baixe a versão recebida — o WhatsApp converte a imagem para JPEG
    automaticamente ao enviar.
 - **Tamanho máximo:** 10 MB por arquivo. Acima disso, o envio é recusado.
 - **Texto alternativo é obrigatório sempre que houver imagem.** Isso não é
  burocracia: é o texto que leitores de tela usam para descrever a imagem
  para pessoas com deficiência visual, e também ajuda o Google a entender
  do que se trata a foto. Sem uma imagem, o campo de texto alternativo
  pode ficar em branco; assim que você anexa uma imagem, o sistema passa a
  exigir o texto.
 - **Exceção: a imagem de capa de um caso de portfólio e a imagem de um item
  da galeria não são realmente opcionais**, ao contrário de toda outra
  imagem do painel (logo, imagem da página Sobre, foto de depoimento,
  imagem de SEO). Nesses dois casos específicos, o formulário não impede
  você de salvar sem imagem, mas o salvamento falha de qualquer forma com
  um erro técnico em vez de uma mensagem amigável de "campo obrigatório"
  (ver detalhes nas seções [Casos de
  portfólio](#casos-de-portfólio-criar-editar-publicar-e-despublicar) e
  [Galeria de fotos do caso](#galeria-de-fotos-do-caso)). Sempre anexe uma
  imagem antes de salvar um caso de portfólio ou um item de galeria.
 - Você **não** precisa fazer nada além de enviar a imagem normalmente — o
  sistema gera sozinho as versões menores usadas em celulares e tablets.
  Não existe um botão ou comando manual que você precise rodar depois de
  subir uma foto.
 ## Usuários: papéis, ativar e desativar contas
 No menu, vá em **Usuários**. Esta tela só aparece, e só pode ser editada,
 por contas com perfil **Administrador** — se você consegue ver este menu e
 seguir o resto deste guia, você é Administradora.
 Ao criar ou editar uma conta, os campos são:
 - **Nome** e **E-mail** — identificação da pessoa; o e-mail também é o
  usado para fazer login.
 - **Papel** — **Administrador** ou **Assistente**. Como já visto em [Como
  entrar no painel](#como-entrar-no-painel), hoje não existe meio-termo:
  Administrador tem acesso total, e Assistente consegue fazer login mas
  não vê nem edita **nenhum** conteúdo (nem Portfólio, nem Configurações,
  nada). Trocar o Papel de alguém para Assistente remove todo o acesso
  dela imediatamente.
 - **Ativo** — desligar este interruptor bloqueia o login dessa conta por
  completo, mesmo com e-mail e senha corretos.
 - **Senha** — só é preciso preencher ao criar uma conta nova ou quando
  você realmente quer trocar a senha de alguém; deixando em branco ao
  editar uma conta existente, a senha atual não muda.
 **Cuidado ao editar a sua própria conta.** O painel não impede uma
 Administradora de trocar o próprio Papel para Assistente ou de desligar o
 próprio "Ativo". Se isso acontecer, você perde o acesso imediatamente e,
 como visto em [Como entrar no painel](#como-entrar-no-painel), hoje não
 existe "esqueci minha senha" nem qualquer forma de uma Administradora
 reverter isso sozinha — só sobra pedir para quem desenvolve o site mexer
 diretamente no banco de dados. Ao mexer no seu próprio usuário, confira
 duas vezes o que está mudando antes de salvar.
 ## O que NÃO mexer — e com quem falar
 - **Seção "Analytics" em Configurações** (o interruptor e o campo de
  script). É um campo técnico que injeta código de rastreamento no site.
  Mexer errado aqui pode quebrar o carregamento do site inteiro. Peça para
  quem desenvolve o site fazer essa alteração.
 - **Slug de serviços e casos de portfólio**, depois de publicados. Mudar
  quebra links já compartilhados (redes sociais, WhatsApp, resultados de
  busca do Google). Se for realmente necessário mudar, avise quem
  desenvolve o site para avaliar redirecionamento.
 - **Usuários e permissões** (menu "Usuários") — só para quem **não** é
  Administradora: essa tela só existe para contas com perfil
  **Administrador**, então se você não consegue nem ver o menu "Usuários",
  precisa de uma conta nova, de desativar alguém, ou de trocar uma senha,
  peça a uma Administradora — ou, na ausência de uma, a quem desenvolve o
  site. Se você **é** Administradora, essa tela é sua e está descrita em
  [Usuários: papéis, ativar e desativar
  contas](#usuários-papéis-ativar-e-desativar-contas).
 - **Qualquer coisa fora do painel `/admin`** — arquivos de código, banco
  de dados, comandos de terminal. Nada disso deve ser mexido para uma
  atualização de conteúdo do dia a dia; se alguém pedir para você rodar um
  comando técnico para "gerar imagens" ou algo do tipo, isso é tarefa de
  engenharia, não de edição de conteúdo — fale com quem desenvolve o site.
 ## Seções da home que somem por completo se ficarem vazias
 Estas três seções da home **desaparecem inteiramente** (sem nenhum aviso ou
 espaço reservado) se não houver nenhum item que atenda aos critérios
 abaixo:
 | Seção da home | Desaparece quando... |
 |---|---|
 | **Serviços** | zero serviços estiverem, ao mesmo tempo, publicados **e** com "Destaque" ligado |
 | **Portfólio** | zero casos estiverem, ao mesmo tempo, publicados **e** com "Destaque" ligado |
 | **Depoimentos** | zero depoimentos estiverem publicados (o "Destaque" não importa aqui) |
 Se você despublicar o último item de uma dessas categorias — ou esquecer de
 ligar "Destaque" em qualquer serviço/caso — a home simplesmente fica sem
 aquele bloco, sem mensagem de erro em lugar nenhum. Se um bloco "sumiu" da
 home, o primeiro lugar para checar é exatamente essa combinação de
 publicado + destaque.
 ## Sobre o arquivo `depoimentos.md` na raiz do repositório
 Existe um arquivo chamado `depoimentos.md` na raiz do projeto com os cinco
 depoimentos reais originais, copiados manualmente de onde vieram
 (WhatsApp/redes sociais). Ele foi o material bruto usado, uma única vez,
 para digitar os depoimentos dentro do sistema (e é citado em documentos
 técnicos antigos como a origem desse conteúdo) — mas **hoje nenhum código
 do site lê esse arquivo**. Editar, corrigir ou apagar `depoimentos.md` **não
 muda nada** no site: o texto que aparece de verdade para quem visita o site
 vive no banco de dados, e é editado exclusivamente pela tela **Depoimentos**
 descrita [acima](#depoimentos-adicionar-e-publicar). Trate esse arquivo como
 material histórico de referência, não como fonte de conteúdo.
--- a/docs/screenshots/home-editorial-cadence-desktop.webp
+++ b/docs/screenshots/home-editorial-cadence-desktop.webp
--- a/docs/screenshots/home-editorial-cadence-mobile.webp
+++ b/docs/screenshots/home-editorial-cadence-mobile.webp
--- a/frontend-audit.md
+++ b/frontend-audit.md
@@ -1,262 +0,0 @@
 Audite e melhore integralmente este projeto do site da **Amare**, incluindo todas as rotas públicas, componentes compartilhados, formulários, navegação, conteúdo, metadados e comportamento responsivo.
 Você está autorizado a executar o projeto, inspecionar o repositório e modificar diretamente o código. Não entregue somente recomendações: implemente as correções necessárias e valide o resultado.
 ## Objetivo
 Deixar o site tecnicamente sólido, visualmente refinado e pronto para apresentação à cliente e posterior lançamento, corrigindo problemas de:
 * UI e UX;
 * responsividade;
 * posicionamento e conteúdo;
 * acessibilidade;
 * conversão;
 * SEO;
 * performance;
 * robustez;
 * qualidade e manutenção do código.
 ## Contexto do produto
 A Amare é uma empresa de assessoria, produção e organização de eventos em São Paulo.
 Ela atende:
 * casamentos;
 * eventos sociais e celebrações particulares;
 * eventos corporativos.
 O site não deve transmitir que a empresa trabalha exclusivamente com casamentos.
 A experiência precisa equilibrar:
 * emoção, proximidade, sensibilidade e sofisticação para eventos sociais;
 * organização, segurança, método, clareza e credibilidade para eventos corporativos.
 O resultado deve ser editorial, contemporâneo, humano, elegante e profissional, sem parecer excessivamente romântico nem corporativo demais.
 Preview de referência:
 `https://amare.preview.hellomanoel.com/`
 Considere os documentos existentes no repositório, especialmente `AGENTS.md`, `README.md`, `SPEC.md`, `DESIGN.md` e equivalentes, como contexto autoritativo do projeto.
 ## Direção visual
 Preserve a identidade visual existente quando ela funcionar corretamente:
 * fundos off-white ou bege claro;
 * verde oliva;
 * composição editorial;
 * fotografias em destaque;
 * espaços em branco generosos;
 * EB Garamond em títulos e destaques;
 * elementos minimalistas;
 * animações discretas;
 * aparência refinada e atemporal.
 Não preserve decisões que prejudiquem usabilidade, contraste, legibilidade, acessibilidade, responsividade ou performance.
 Avalie especialmente:
 * uso excessivo de Garamond em textos pequenos, menus, botões e formulários;
 * verdes claros com contraste insuficiente;
 * CTAs discretos demais;
 * espaços vazios excessivos no celular;
 * imagens que reforcem somente o posicionamento de casamento;
 * falta de equilíbrio entre conteúdo social e corporativo;
 * inconsistência tipográfica ou de espaçamento;
 * aparência de template genérico de casamento.
 ## Escopo da auditoria
 Analise todas as rotas encontradas no código e corrija problemas relacionados a:
 ### Produto e conteúdo
 * clareza da proposta de valor;
 * equilíbrio entre eventos sociais e corporativos;
 * hierarquia das informações;
 * conteúdo genérico, redundante ou sem função;
 * coerência entre títulos, textos, imagens e CTAs;
 * clareza dos serviços;
 * confiança e credibilidade;
 * caminho até contato ou solicitação de proposta.
 Não invente história, números, clientes, prêmios, depoimentos, equipe, serviços, telefone, e-mail ou qualquer informação não confirmada.
 ### UI e experiência
 * navegação;
 * header e footer;
 * menu mobile;
 * hierarquia visual;
 * tipografia;
 * espaçamento;
 * grids;
 * CTAs;
 * formulários;
 * estados interativos;
 * consistência entre páginas;
 * experiência mobile-first;
 * ausência de overflow, cortes, sobreposições ou distorções;
 * adaptação real do layout ao celular, e não apenas redução da versão desktop.
 ### Acessibilidade
 Use WCAG 2.2 AA como referência prática.
 Corrija problemas de:
 * HTML semântico;
 * hierarquia de headings;
 * navegação por teclado;
 * foco visível;
 * contraste;
 * nomes acessíveis;
 * labels;
 * mensagens de erro;
 * áreas de toque;
 * textos alternativos;
 * menu mobile;
 * overlays;
 * preferência por redução de movimento;
 * uso correto de links e botões.
 Prefira HTML semântico a ARIA desnecessária.
 ### Formulários e conversão
 Garanta, quando aplicável:
 * campos e obrigatoriedade claros;
 * validação adequada;
 * mensagens de erro específicas;
 * estado de envio;
 * prevenção de envio duplicado;
 * estados de sucesso e falha;
 * tratamento de erro de rede;
 * preservação dos dados após erros recuperáveis;
 * proteção antispam simples;
 * privacidade e LGPD;
 * links e mensagens de WhatsApp corretos;
 * ausência de segredos expostos no cliente.
 Quando algum dado real não estiver disponível, use configuração ou variável de ambiente e documente a pendência.
 ### SEO
 Corrija, quando aplicável:
 * títulos exclusivos por rota;
 * meta descriptions;
 * canonical;
 * Open Graph;
 * Twitter cards;
 * sitemap;
 * robots;
 * favicon;
 * idioma;
 * headings;
 * URLs;
 * links internos;
 * página 404;
 * metadados sociais;
 * indexação distinta entre preview e produção.
 Não crie dados estruturados com informações não confirmadas.
 ### Performance
 Corrija problemas relevantes relacionados a:
 * imagens;
 * tamanhos responsivos;
 * formatos modernos;
 * lazy loading;
 * LCP;
 * CLS;
 * INP;
 * fontes;
 * scripts desnecessários;
 * hidratação excessiva;
 * JavaScript evitável;
 * componentes client-side sem necessidade;
 * animações custosas;
 * dependências pesadas;
 * carregamento de conteúdo abaixo da dobra.
 Preserve a qualidade visual das fotografias.
 ### Qualidade técnica
 Corrija:
 * erros de TypeScript;
 * erros de lint;
 * erros de build;
 * warnings de hidratação;
 * erros de console;
 * requisições quebradas;
 * links inválidos;
 * rotas órfãs;
 * componentes duplicados quando a consolidação simplificar o projeto;
 * tratamento de erros ausente;
 * tipagem insegura;
 * complexidade desnecessária diretamente relacionada ao escopo.
 ## Prioridades
 Considere:
 * **P0:** bloqueia funcionamento, segurança, uso ou lançamento;
 * **P1:** prejudica significativamente experiência, conversão, acessibilidade, SEO, performance ou credibilidade;
 * **P2:** refinamento não essencial para o lançamento.
 Implemente todos os itens P0 e P1 que possam ser resolvidos com as informações existentes.
 Itens dependentes de dados reais da cliente devem permanecer como pendências explícitas, sem conteúdo fictício.
 ## Restrições
 * Preserve a stack e a arquitetura existentes quando forem adequadas.
 * Prefira mudanças simples, localizadas e fáceis de manter.
 * Não reescreva o projeto sem necessidade concreta.
 * Não adicione bibliotecas quando a solução atual for suficiente.
 * Não implemente pagamentos, CRM, área do cliente, chat, contratos avançados ou funcionalidades fora do MVP.
 * Não altere arquivos não relacionados sem justificativa.
 * Preserve alterações locais preexistentes.
 * Não silencie problemas com `any`, `eslint-disable`, casts inseguros ou desativação de validações.
 * Não reduza acessibilidade para preservar estética.
 * Não deixe mocks ou soluções temporárias como implementação final.
 ## Critérios de conclusão
 A tarefa estará concluída quando:
 * todas as rotas públicas existentes tiverem sido auditadas;
 * todos os problemas P0 e P1 solucionáveis tiverem sido corrigidos;
 * o site funcionar corretamente em mobile e desktop;
 * não houver overflow horizontal, sobreposição ou componentes quebrados;
 * menu, navegação, links, CTAs e formulários funcionarem;
 * o posicionamento social e corporativo estiver claro;
 * a acessibilidade essencial estiver atendida;
 * os metadados e fundamentos de SEO estiverem corretos;
 * os principais problemas de performance tiverem sido tratados;
 * erros causados ou revelados pelas alterações tiverem sido resolvidos;
 * lint, TypeScript, testes e build disponíveis tiverem sido executados com sucesso.
 Não declare uma validação como aprovada sem executá-la.
 ## Entrega final
 Ao concluir, apresente:
 1. rotas auditadas;
 2. problemas principais encontrados;
 3. alterações implementadas;
 4. arquivos modificados;
 5. comandos executados e seus resultados;
 6. decisões e trade-offs relevantes;
 7. informações que dependem da cliente;
 8. itens P2 mantidos fora do escopo.
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/.openspec.yaml
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/.openspec.yaml
@@ -1,2 +0,0 @@
 schema: spec-driven
 created: 2026-08-02
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/NOTES.md
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/NOTES.md
@@ -1,12 +0,0 @@
 # Notes — recreate-public-frontend
 ## Remaining unresolved (do not invent)
 - **Official contacts:** production e-mail is `amareassessoriaeventos@gmail.com`; WhatsApp and Instagram handles still placeholder until the owner confirms.
 - **Testimonial authorization:** five real couples from `depoimentos.md` are seeded for local/demo/visual; production publish still requires explicit couple authorization before `published_at` goes live.
 - **Authorized photography:** public images remain fixture/demo with editorial disclosure notes until Amare supplies an authorized portfolio archive.
 - **WEB-05 briefing form:** `/contato` stays presentation-only (channels + CTA); lead capture is a future change.
 ## Adaptation note
 Mockup `amare-home-editorial.html` was single-page with anchors. Implementation keeps Laravel multipage routes; home carries the editorial narrative, internal pages are chapters with the same Heritage Editorial grammar.
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/design.md
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/design.md
@@ -1,158 +0,0 @@
 ## Context
 O site público da Fase 1 já entrega rotas, CMS, SEO, mídia responsiva, regressão visual e acessibilidade. A identidade visual, porém, ainda é o placeholder da fundação: Instrument Sans, acento ouro, raios arredondados e cartões com sombra. `DESIGN.md` (“Heritage Editorial”), o mockup `amare-home-editorial.html`, o logo fornecido (coração facetado) e `depoimentos.md` (cinco casais reais) definem a marca a materializar.
 Restrições que condicionam o desenho:
 - Arquitetura multipágina Laravel/Blade/CMS já aprovada; o mockup HTML é single-page com âncoras — adaptar, não portar literalmente.
 - Contato permanece placeholder (WEB-05 fora de escopo); CTAs levam a `/contato` sem criar leads.
 - Fontes self-hosted via Vite (determinismo visual); sem Google Fonts CDN.
 - Imagens públicas via disco configurado + variantes; Unsplash do mockup não entra no app.
 - `PRODUCT.md`: São Paulo capital; seeders atuais ainda usam Fortaleza e depoimentos fictícios.
 - Change paralela `complete-foundation-parity` não bloqueia nem é bloqueada por esta.
 ## Goals / Non-Goals
 **Goals:**
 - Materializar Heritage Editorial em todas as rotas públicas (home, serviços, portfólio, caso, sobre, contato, privacidade, 404, 500).
 - Home como capa do “Dossiê Editorial do Evento”: hero, manifesto, serviços, portfólio, método (4 passos), depoimentos reais, perfil Amare, CTA final.
 - Tokens centralizados alinhados a `DESIGN.md`; EB Garamond única família; radius 0; elevação por campos tonais.
 - Logo oficial otimizado (selo + lockup) em fundos claros/escuros, geometria preservada.
 - Cinco depoimentos de `depoimentos.md` no CMS/seed, multipárrafo, com nota de autorização.
 - Manter publicação dinâmica, paginação, eager loading, SEO, axe, teclado, contraste AA e baselines determinísticas.
 **Non-Goals:**
 - Briefing funcional / lead (WEB-05), WhatsApp automatizado, inventar provas corporativas.
 - Redesign do Filament, page builder, single-page navigation como modelo primário.
 - Fotografia proprietária real (permanece ilustrativa e marcada até acervo autorizado).
 - Staging/deploy/auth parity (`complete-foundation-parity`).
 ## Decisions
 ### D1 — Multipágina editorial, não single-page literal
 Preservar rotas do SPEC §5.1. Home concentra a narrativa do mockup; páginas internas herdam a mesma gramática (eyebrow, títulos, linhas 1px, spreads assimétricos no desktop, sequência linear no mobile). Header usa links de rota (não `#âncoras` como navegação primária), com CTA “Solicitar proposta” → `contact`.
 *Alternativas:* home quase idêntica com âncoras (rejeitada: conflita com SEO/CMS/rotas já testadas); portar HTML estático (rejeitada: perde CMS e determinismo).
 ### D2 — Tokens Heritage Editorial como única fonte visual
 Reescrever `resources/css/tokens.css` e o mapeamento `@theme` em `app.css`:
 | Papel | Token | Valor |
 |-------|-------|-------|
 | Fundo | `--amare-color-bg` | `#FBF9F4` (Papel Marfim) |
 | Fundo profundo | `--amare-color-bg-deep` | `#F0EEE9` |
 | Arquivo | `--amare-color-bg-archive` | `#E4E2DD` |
 | Oliva | `--amare-color-accent` | `#556B2F` |
 | Oliva profunda | `--amare-color-accent-deep` | `#3E5219` |
 | Sálvia | `--amare-color-sage` | `#8B9D77` |
 | Tinta | `--amare-color-text` | `#1B1C19` |
 | Tinta suave | `--amare-color-muted` | `#5D6155` |
 | Linha | `--amare-color-border` | `#C5C8B8` |
 | Radius | `--amare-radius-*` | `0` |
 | Container | `--amare-container-max` | `1120px` |
 | Sombra | removida / não usada em conteúdo | — |
 Tipografia: EB Garamond (400/500/600) self-hosted via Vite; escala display/headline/title/body/label conforme `DESIGN.md`. Componentes públicos deixam de usar `rounded-*` e shadows de cartão.
 *Alternativa:* CSS inline do mockup (rejeitada: foge de `design-tokens` e quebra Tailwind/`@theme`).
 ### D3 — Composição da home e omissão de seções vazias
 Ordem canônica:
 1. Hero (settings + imagem OG/hero se houver)
 2. Manifesto (copy de settings)
 3. Serviços em destaque (lista editorial, não grid de cartões)
 4. Portfólio em destaque (bloco escuro oliva; funde proof+cases atuais)
 5. Método (4 passos: Escuta, Direção, Produção, Execução)
 6. Depoimentos publicados
 7. Perfil / posicionamento Amare (about + princípios)
 8. CTA final → `/contato`
 Seções alimentadas por collections (serviços, casos, depoimentos) **omitidas** quando vazias. Manifesto, método, perfil e CTA final permanecem (copy de settings / defaults editoriais). Um único `h1` no hero; demais seções usam `h2`/`h3`.
 ### D4 — Contato continua presentation-only
 `/contato` e o CTA da home mostram canais de `site_settings` (e-mail, telefone, cidade, sociais). Nenhum `<form>` funcional, nenhum lead. O mockup de formulário serve só como referência visual futura para WEB-05; nesta change o bloco de contato da home é CTA editorial + link para a página de contato, não formulário embutido.
 ### D5 — Extensão mínima tipada de `site_settings`
 Novos campos tipados (não key/value genérico):
 - `logo_path` / `logo_alt` (opcional; fallback para lockup estático em `public/`)
 - `hero_secondary_cta_label` (opcional)
 - `hero_note` (texto curto sob CTAs)
 - `manifesto_title`, `manifesto_lead`, `manifesto_body`
 - `method_intro` (opcional; passos estruturados em JSON tipado ou colunas `method_step_{1..4}_{title,body}` — preferir JSONB `method_steps` validado no Filament)
 - `principles` (JSONB lista de até 4 strings) **ou** quatro colunas `principle_1..4`
 - Manter `about_summary`, hero atual, contato, SEO, analytics
 Filament `ManageSiteSettings` ganha seções editoriais em pt-BR. Defaults no seeder alinhados ao mockup + São Paulo.
 *Alternativa:* hardcode de manifesto/método nas Blade (rejeitada parcialmente: método/princípios podem ter default no view, mas copy institucional deve ser editável como o hero).
 ### D6 — Logo: ativo estático + campo CMS opcional
 1. Converter/otimizar o PNG fornecido para WebP/SVG derivados em `public/brand/` (selo coração + lockup completo), com versões para fundo claro (oliva) e fundo escuro (papel/branco).
 2. Componente `<x-brand.logo>` escolhe variante por contexto (`on-dark` / `on-light`) e expõe `alt` acessível.
 3. Se `logo_path` em settings estiver preenchido, usa o upload; senão, o estático versionado.
 Não redesenhar o coração facetado; não inventar polígonos decorativos genéricos.
 ### D7 — Depoimentos reais multipárrafo
 - Seedar os 5 casais de `depoimentos.md` em `quote` (texto completo com quebras `\n\n`), `author_name`, `context` (ex.: `Casamento · 06/12/2025`), `sort_order`, `is_featured`, `published_at` conforme ambiente.
 - Blade renderiza parágrafos a partir de quebras de linha; tipografia editorial (aspas, offset).
 - Nota discreta no markup/admin: autorização final dos casais antes de publicação em produção.
 - Remover depoimentos fictícios dos seeders de demo/visual ou substituí-los pelos reais (visual seeder usa subset determinístico, tipicamente 2 featured).
 ### D8 — Navegação responsiva com JS mínimo
 `resources/js/app.js` ganha toggle de menu mobile (aria-expanded, `menu-open`, fechar ao navegar), espelhando o mockup. Sem framework novo. `prefers-reduced-motion` continua a anular transições não essenciais. Hover de imagem (scale leve) só quando motion permitido.
 ### D9 — Páginas internas como capítulos
 | Rota | Tratamento |
 |------|------------|
 | `/servicos` | Lista editorial (número + nome + resumo), não cartões |
 | `/portfolio` | Grade assimétrica / stack com captions; fundo pode usar papel profundo |
 | `/portfolio/{slug}` | Caderno de caso: metadados, desafio/solução/resultado, galeria |
 | `/sobre` | Perfil editorial + princípios |
 | `/contato` | Canais + CTA textual (sem form) |
 | `/privacidade` | Tipografia editorial sobre papel |
 | 404/500 | Mesma linguagem; 500 sem internals |
 ### D10 — Testes e baselines
 - Atualizar feature tests de home (ordem de seções, omissão, CTA → contact, `data-testid="home-primary-cta"`).
 - Browser: axe nas rotas cobertas; Tab até CTA; console limpo.
 - `composer visual:update` após aprovação visual local; timezone permanece `America/Fortaleza` (SPEC); copy de cidade pública passa a São Paulo.
 - Fotos fixture locais continuam; filtro CSS de saturação contida via classe utilitária, não via URL externa.
 ## Risks / Trade-offs
 - **Regeneração de 8+ snapshots** → risco de ruído no PR; mitigar com seeder visual estável e revisão humana do diff.
 - **EB Garamond em forms/UI** → legibilidade de labels uppercase; mitigar com letter-spacing e peso 600 conforme DESIGN.md; validar contraste AA.
 - **Depoimentos longos** → layout quebra em mobile; mitigar com tipografia responsiva e subset featured na home.
 - **Autorização de depoimentos** → risco legal/reputacional; mitigar com nota explícita e `published_at` null até autorização.
 - **Campos novos em site_settings** → migração + Filament; mitigar com defaults e nullable.
 - **Paridade com mockup single-page** → expectativa visual vs rotas; documentar adaptação multipágina na proposta e no surface brief.
 ## Migration Plan
 1. Migrar tokens/fontes/logo estático (sem breaking de rotas).
 2. Migrar `site_settings` (colunas novas nullable + backfill de defaults).
 3. Atualizar seeders (SP + depoimentos reais).
 4. Trocar layout e páginas; manter contratos de testes passando incrementalmente.
 5. Regenerar baselines com `composer visual:update`.
 6. Rollback: reverter deploy/commit; migração down remove colunas novas; assets estáticos são aditivos.
 ## Open Questions
 - Formato exato de `method_steps` / `principles` (JSONB vs colunas) — default recomendado: JSONB validado no Filament.
 - WhatsApp/e-mail/Instagram oficiais ainda ausentes — settings continuam placeholder até o dono informar.
 - Subconjunto de depoimentos na home (2 vs 5) — default: featured first, até 2 na home estilo mockup; listagem completa só se houver página dedicada (não há); home mostra todos published featured ou os N primeiros por `sort_order` (cap 2–3 para ritmo editorial).
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/proposal.md
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/proposal.md
@@ -1,49 +0,0 @@
 ## Why
 O site público já existe com rotas, CMS e gates de qualidade, mas a identidade visual ainda é o placeholder da Fase 0 (Instrument Sans, ouro, cantos arredondados, cartões genéricos). `DESIGN.md` e o mockup editorial já definem o sistema Heritage Editorial; `depoimentos.md` e o logo fornecido finalmente permitem prova e marca reais. Sem recriar o frontend agora, o critério de saída da Fase 1 (“site público aprovado visualmente”) permanece ligado a uma UI que não representa a marca, e a Fase 2 (WEB-05) herdaria um shell genérico.
 ## What Changes
 - Substituir tokens, tipografia e composição do site público pelo sistema **Heritage Editorial** de `DESIGN.md` (EB Garamond, oliva/papel, cantos retos, campos tonais, sem sombras de cartão SaaS).
 - Adaptar o mockup `amare-home-editorial.html` à arquitetura **multipágina** Laravel/CMS existente: home como capa editorial; serviços, portfólio, caso, sobre, contato, privacidade e erros como capítulos coerentes.
 - Incorporar o logo fornecido (coração facetado + lockup) como ativo otimizado com variantes para fundos claros/escuros, sem redesenhar a geometria.
 - Seedar e renderizar os **cinco depoimentos reais** de `depoimentos.md` (texto, casal, data/contexto), com autorização final como requisito de publicação.
 - Reestruturar a home na narrativa editorial: hero → manifesto → serviços → portfólio → método → depoimentos → perfil Amare → CTA final (WEB-01).
 - Atualizar layout público (header/footer, navegação responsiva, selo), componentes Blade e páginas internas para a mesma linguagem visual.
 - Estender `site_settings` o mínimo necessário para copy editorial (manifesto, nota do hero, CTA secundário, passos do método, princípios) mantendo singleton tipado (WEB-06).
 - Regenerar baselines visuais desktop/mobile e manter axe, teclado, landmarks, SEO e publicação dinâmica (SPEC §6.5, §13.5, §13.8).
 - Atualizar seeders/conteúdo demonstrativo para São Paulo e marcar fotografias ilustrativas até existir acervo autorizado.
 ## Non-Goals
 Conforme [SPEC.md §4.2](../../SPEC.md) e decisões desta proposta:
 - Formulário funcional de briefing / criação de lead (WEB-05) — permanece placeholder em `/contato`; change futura `build-lead-capture`.
 - Integração WhatsApp, portal do cliente, page builder, i18n, PWA.
 - Inventar cases corporativos, credenciais, números, imprensa ou provas não autorizadas.
 - Redesign do painel Filament / área interna.
 - Deploy staging / paridade de fundação — change paralela `complete-foundation-parity`, independente desta.
 ## Capabilities
 ### New Capabilities
 <!-- Nenhuma capability nova: a recriação altera requisitos de capabilities já existentes. -->
 ### Modified Capabilities
 - `design-tokens`: substituir tokens placeholder (Instrument Sans, ouro, raios, sombras) pelos tokens Heritage Editorial (EB Garamond, oliva/papel, radius 0, elevação tonal).
 - `public-site-pages`: reestruturar home editorial e páginas públicas para a composição “Dossiê Editorial do Evento”, preservando rotas e publicação.
 - `site-settings`: campos tipados adicionais para copy editorial da home (manifesto, CTAs, método, princípios, logo).
 - `testimonials`: suporte a depoimentos multipárrafo reais com contexto/data e regra de autorização antes da publicação.
 - `content-media`: logo da marca e tratamento editorial de imagens demonstrativas (marcação, filtros contidos) sem inventar acervo.
 - `visual-regression`: baselines regeneradas sob a nova identidade; determinismo e cobertura de telas mantidos.
 - `web-accessibility`: preservação/reforço de landmarks, foco, teclado, contraste AA e movimento reduzido após a troca tipográfica/cromática.
 ## Impact
 - **Altera**: `resources/css/tokens.css`, `resources/css/app.css`, `vite.config.js`, `resources/views/layouts/public.blade.php`, `resources/views/pages/**`, `resources/views/components/home/**`, `resources/js/app.js`, seeders (`ContentSeeder`, `VisualContentSeeder`), possivelmente migração + model/Filament de `site_settings`, testes Feature/Browser e snapshots em `tests/.pest/snapshots/`.
 - **Cria**: ativo de logo em `public/` (ou storage CMS), componentes Blade de marca/manifesto/positioning, campos tipados novos em `site_settings` se necessário.
 - **Depende de**: specs atuais `design-tokens`, `public-site-pages`, `site-settings`, `testimonials`, `content-media`, `visual-regression`, `web-accessibility`, `public-seo`, `service-catalog`, `portfolio-cases`.
 - **Independente de**: `complete-foundation-parity` (auth/staging/coverage).
 - **Risco**: regeneração ampla de snapshots; mitigado por seed determinístico, fontes self-hosted e `composer visual:update` com revisão humana. Depoimentos reais exigem confirmação de autorização antes de publicar em produção.
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/content-media/spec.md
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/content-media/spec.md
@@ -1,31 +0,0 @@
 ## ADDED Requirements
 ### Requirement: Brand logo assets are available to the public layout
 The system SHALL provide optimized Amare brand logo assets derived from the official faceted-heart lockup for use in the public header, footer and institutional pages. Assets MUST preserve the original geometry, include an accessible text alternative, and provide variants suitable for light and dark tonal fields. When `site_settings.logo_path` is present, the uploaded logo MUST be used; otherwise the versioned static brand asset MUST be used.
 #### Scenario: Header renders brand mark with alt text
 - **WHEN** any public page is rendered
 - **THEN** the brand mark image or equivalent MUST expose accessible alternative text identifying Amare Assessoria
 #### Scenario: Dark portfolio field uses a legible logo variant
 - **WHEN** the brand mark is rendered on an olive-deep or otherwise dark public surface
 - **THEN** the chosen logo variant MUST remain legible against that background
 #### Scenario: Uploaded logo overrides static fallback
 - **GIVEN** an admin has saved `logo_path` and `logo_alt` in site settings
 - **WHEN** the public layout renders the brand mark
 - **THEN** the uploaded logo MUST be used instead of the static fallback
 ### Requirement: Editorial image treatment remains self-hosted and deterministic
 Public photography SHALL continue to use validated self-hosted uploads and responsive variants. Decorative saturation/contrast treatment for editorial mood MUST be applied via CSS on self-hosted images and MUST NOT introduce external image CDN dependencies that break deterministic visual tests.
 #### Scenario: Public pages do not depend on external stock hosts
 - **WHEN** the visual or browser suite loads covered public routes
 - **THEN** content images MUST resolve from the application media disk or static fixtures
 - **AND** MUST NOT require network access to third-party stock hosts
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/design-tokens/spec.md
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/design-tokens/spec.md
@@ -1,53 +0,0 @@
 ## MODIFIED Requirements
 ### Requirement: Design tokens are centralized for the public site
 The system SHALL define design tokens in a single source consumed by the public site layout and components. Tokens MUST implement the Heritage Editorial system from `DESIGN.md`: typography family EB Garamond (self-hosted), font scale (display/headline/title/body/label), spacing on an 8px rhythm, border radius `0` for interactive and content surfaces, container max width `1120px`, paper/olive/sage/ink color roles, transition duration/easing, and MUST NOT rely on card shadows as a hierarchy mechanism for regular content.
 #### Scenario: Public layout uses shared Heritage Editorial tokens
 - **WHEN** a public page is rendered
 - **THEN** visual properties MUST be derived from the centralized token definitions rather than arbitrary inline values
 - **AND** the primary typeface MUST be EB Garamond (or the declared serif fallback stack)
 - **AND** public content surfaces MUST use `0` border radius from tokens
 #### Scenario: Palette commits paper and olive regions
 - **WHEN** the public site is rendered
 - **THEN** background regions MUST use paper ivory / paper deep / olive deep tokens rather than pure white card stacks on a white page
 - **AND** primary interactive emphasis MUST use olive heritage (`#556B2F`) / olive deep (`#3E5219`) tokens
 ### Requirement: Public site respects reduced motion preference
 The system SHALL honor `prefers-reduced-motion` by disabling or minimizing non-essential animations and transitions on the public site, including image hover scales and menu transitions.
 #### Scenario: User prefers reduced motion
 - **WHEN** a visitor has `prefers-reduced-motion: reduce` enabled
 - **THEN** the public site MUST NOT play non-essential motion effects
 ### Requirement: Public site meets baseline accessibility contrast
 The system SHALL use Heritage Editorial color combinations that meet WCAG AA contrast requirements for text and interactive elements. Long-form text MUST use ink on paper; sage MUST NOT replace reading color when contrast would fall below AA.
 #### Scenario: Primary text is readable
 - **WHEN** primary body text is rendered on its background color
 - **THEN** the contrast ratio MUST meet WCAG AA minimums
 #### Scenario: Olive on paper interactive text is readable
 - **WHEN** primary buttons or links use olive tokens on paper backgrounds (or paper text on olive)
 - **THEN** the contrast ratio MUST meet WCAG AA minimums
 ## ADDED Requirements
 ### Requirement: Elevation comes from tonal fields not card shadows
 The public site SHALL express hierarchy through tonal paper fields, 1px botanical rules, and editorial overlap. Regular content components MUST NOT use short grey SaaS card shadows.
 #### Scenario: Content cards omit drop shadows
 - **WHEN** home services, testimonials, or portfolio items are rendered
 - **THEN** they MUST NOT depend on `--amare-shadow-*` card elevation for hierarchy
 - **AND** separation MUST come from borders, tonal backgrounds, or whitespace
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/public-site-pages/spec.md
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/public-site-pages/spec.md
@@ -1,107 +0,0 @@
 ## MODIFIED Requirements
 ### Requirement: Home renders the editorial structure from CMS content
 The home page SHALL render, in order: header/navigation, hero, manifesto, featured services summary, featured portfolio selection, working method (four steps), testimonials, Amare positioning/profile, final contact CTA, and footer with contact, social links and legal links (WEB-01). Hero copy, brand name, manifesto, method and principles MUST come from `site_settings` (with editorial defaults when optional fields are empty); services, cases and testimonials MUST come from published records. The home MUST follow the Heritage Editorial composition (asymmetric spreads on desktop, linear sequence on mobile) rather than rounded card grids.
 #### Scenario: Published content is displayed in configured order
 - **GIVEN** published services, cases and testimonials exist
 - **WHEN** a visitor loads the home
 - **THEN** the published content MUST be displayed following the `sort_order` and featured flags
 - **AND** the hero MUST show the values stored in `site_settings`
 - **AND** the manifesto, method and positioning sections MUST be present
 #### Scenario: CTA leads to the contact placeholder page
 - **WHEN** a visitor activates the primary or final CTA on the home
 - **THEN** the visitor MUST be taken to the `contact` route
 - **AND** no lead record MUST be created
 #### Scenario: Empty catalog sections are omitted
 - **GIVEN** no published services, cases or testimonials
 - **WHEN** a visitor loads the home
 - **THEN** the response MUST be 200
 - **AND** the services, portfolio and testimonials sections MUST be omitted instead of rendering empty containers
 - **AND** hero, manifesto, method, positioning and final CTA MUST still render
 #### Scenario: Home has no console errors
 - **WHEN** the home is loaded in a real browser at desktop and mobile viewports
 - **THEN** the browser console MUST contain no JavaScript errors
 ### Requirement: Listing and detail pages exist for catalog content
 The system SHALL render a services listing (WEB-02) and a portfolio listing plus case detail (WEB-03) using the Heritage Editorial visual language. The case detail MUST present summary, event type, optional city/venue/date, challenge, solution, optional result, cover image and the ordered gallery.
 #### Scenario: Services listing shows published services
 - **WHEN** a visitor loads `/servicos`
 - **THEN** every published service MUST be listed with title and summary in `sort_order`
 - **AND** the listing MUST use the public editorial layout (not an unrelated visual system)
 #### Scenario: Gallery respects stored order
 - **GIVEN** a published case with multiple gallery images
 - **WHEN** a visitor loads the case detail
 - **THEN** the images MUST be rendered ordered by `sort_order`
 #### Scenario: Listings paginate open-ended growth
 - **WHEN** the number of published cases exceeds the page size
 - **THEN** `/portfolio` MUST paginate instead of rendering all records
 ### Requirement: Institutional and error pages have brand identity
 The system SHALL provide the Sobre and Política de privacidade pages and branded error pages (WEB-07) using the Heritage Editorial public layout, including the brand mark when available. The 404 page MUST use the public layout, and the 500 page MUST NOT expose stack traces or internal details when `APP_DEBUG` is false.
 #### Scenario: Unknown URL renders branded 404
 - **WHEN** a visitor requests a non-existent public URL
 - **THEN** the response status MUST be 404
 - **AND** the page MUST use the public layout and offer navigation back to the home
 #### Scenario: Server error hides internals in production
 - **GIVEN** `APP_DEBUG` is false
 - **WHEN** an unhandled exception occurs on a public route
 - **THEN** the response MUST be a generic branded error page
 - **AND** MUST NOT contain a stack trace, file path, or environment variable
 ### Requirement: Contact page presents contact data as briefing placeholder
 The `contact` route SHALL render the contact page using `site_settings` (e-mail, phone, city, social links) so the home CTA has a valid destination before the briefing form exists. The page MUST NOT create leads and MUST NOT submit a functional briefing form in this change.
 #### Scenario: Contact page shows configured contact data
 - **WHEN** a visitor loads `/contato`
 - **THEN** the e-mail and phone stored in `site_settings` MUST be displayed
 - **AND** no lead record MUST be created
 ## ADDED Requirements
 ### Requirement: Public header exposes brand mark and responsive navigation
 The public layout SHALL render the Amare brand mark (faceted-heart logo lockup or configured logo), primary route navigation, and a contact CTA. On narrow viewports the navigation MUST be operable via a disclosure control with accessible name and `aria-expanded` state.
 #### Scenario: Desktop header shows navigation and CTA
 - **WHEN** a visitor loads any public page at a desktop viewport
 - **THEN** the header MUST include brand mark, links to home/services/portfolio/about/contact, and a contact CTA
 #### Scenario: Mobile menu toggles accessibly
 - **WHEN** a visitor activates the menu button on a narrow viewport
 - **THEN** the primary navigation MUST become available
 - **AND** the control MUST expose an updated `aria-expanded` value
 - **AND** activating a navigation link MUST close the menu
 ### Requirement: Demonstrative photography is labeled until authorized assets exist
 When public pages render illustrative/demo photography that is not an authorized Amare asset, the system SHALL mark that imagery as demonstrative in visible copy or accessible labeling so visitors are not misled.
 #### Scenario: Portfolio demo imagery is disclosed
 - **WHEN** the home or portfolio renders placeholder photography
 - **THEN** a visible note or equivalent disclosure MUST indicate the imagery is illustrative pending authorized assets
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/site-settings/spec.md
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/site-settings/spec.md
@@ -1,53 +0,0 @@
 ## MODIFIED Requirements
 ### Requirement: Site settings singleton is manageable by admin only
 The system SHALL persist site-wide settings in a `site_settings` table as a typed singleton (SPEC WEB-06, §8.2). Fields MUST include brand name, optional logo path and logo alt text, hero copy (eyebrow, title, subtitle, primary CTA label, optional secondary CTA label, optional hero note), manifesto copy (title, lead, body), method steps (structured typed data for four editorial steps), principles (structured typed list), about summary, contact email/phone/city, social links (jsonb), default meta title/description, default OG image path and alt text, and optional analytics fields disabled by default.
 #### Scenario: Admin updates site settings
 - **WHEN** an admin saves the site settings form in Filament
 - **THEN** the singleton record is updated
 - **AND** labels and validation messages are in pt-BR
 #### Scenario: Assistant cannot access site settings
 - **WHEN** an assistant navigates to site settings in Filament
 - **THEN** access MUST be denied with HTTP 403
 #### Scenario: Default OG image requires alt text
 - **WHEN** an admin uploads a default OG image without alt text
 - **THEN** validation MUST fail with a pt-BR error message
 - **AND** alt text MUST remain optional when no default OG image is present
 #### Scenario: Logo upload requires alt text
 - **WHEN** an admin uploads a brand logo without alt text
 - **THEN** validation MUST fail with a pt-BR error message
 - **AND** alt text MUST remain optional when no logo is uploaded
 #### Scenario: Singleton avoids generic key-value store
 - **WHEN** site settings are stored
 - **THEN** the system MUST use typed columns on `site_settings`
 - **AND** MUST NOT introduce a generic key/value configuration table
 #### Scenario: Editorial defaults remain available when optional fields are empty
 - **GIVEN** manifesto, method steps or principles fields are empty
 - **WHEN** the home is rendered
 - **THEN** the page MUST still render those sections using safe editorial defaults
 - **AND** MUST NOT error
 ## ADDED Requirements
 ### Requirement: Public geography defaults to São Paulo
 Demo and visual seed content for site settings SHALL present the Amare operating city as São Paulo (capital), matching `PRODUCT.md`, instead of unrelated cities.
 #### Scenario: Seeded settings use São Paulo
 - **WHEN** content seeders populate `site_settings`
 - **THEN** the city field MUST be São Paulo (or equivalent capital wording)
 - **AND** MUST NOT present Fortaleza as the operating city
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/testimonials/spec.md
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/testimonials/spec.md
@@ -1,47 +0,0 @@
 ## MODIFIED Requirements
 ### Requirement: Testimonials are managed with publication control
 The system SHALL allow admins to manage testimonials (SPEC WEB-04) with quote text (including multi-paragraph content), author name, optional context (event type and/or date), optional photo with alt text, sort order, featured flag, and `published_at`. Public rendering MUST preserve paragraph breaks from the stored quote. Testimonials sourced from real clients MUST NOT be published to production without authorization; development seeds MAY include the authorized-pending real quotes marked for review.
 #### Scenario: Unpublished testimonial is excluded
 - **WHEN** a testimonial has `published_at` null
 - **THEN** the `published()` scope MUST exclude it
 #### Scenario: Published testimonial is queryable
 - **WHEN** an admin sets `published_at` with required quote and author name
 - **THEN** the testimonial MUST be included in the `published()` scope
 #### Scenario: Assistant cannot manage testimonials
 - **WHEN** an assistant attempts to access the testimonials Resource
 - **THEN** access MUST be denied with HTTP 403
 #### Scenario: Featured testimonials are filterable
 - **WHEN** content is queried with featured filter
 - **THEN** records with `is_featured` true MUST be retrievable independently of sort order
 #### Scenario: Multi-paragraph quotes render as paragraphs
 - **GIVEN** a published testimonial whose quote contains blank-line separated paragraphs
 - **WHEN** the home testimonials section is rendered
 - **THEN** each paragraph MUST appear as distinct block text rather than a single collapsed line
 ## ADDED Requirements
 ### Requirement: Real wedding testimonials are seeded from authorized source copy
 Content and visual seeders SHALL replace fictional testimonials with the five real wedding testimonials from `depoimentos.md`, preserving author couple names, quote wording, and date/context. Until final publication authorization is confirmed, production deployments MUST keep those records unpublished or gated by explicit admin publish action.
 #### Scenario: Seed loads the five real couples
 - **WHEN** the content seeder runs
 - **THEN** testimonials for Jeniffer e Maick, Quesia e Jhonata, Milena e Weslley, Raquel e Pedro, and Victoria e Pedro MUST exist with their source quotes and marriage context/dates
 #### Scenario: Fictional demo quotes are removed
 - **WHEN** the content seeder completes
 - **THEN** previously invented placeholder testimonial authors MUST NOT remain as the published demo set
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/visual-regression/spec.md
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/visual-regression/spec.md
@@ -1,56 +0,0 @@
 ## MODIFIED Requirements
 ### Requirement: Public screens have desktop and mobile visual baselines
 The system SHALL keep versioned screenshot baselines for the public screens available in this phase (SPEC §13.5): Home, Serviços, Portfólio and Detalhe do portfólio, at 1440×1000 desktop and 390×844 mobile, under the Heritage Editorial identity. A rendering change that alters those screens MUST fail the browser suite until the diff is reviewed and baselines are explicitly updated.
 #### Scenario: Unintended visual change fails the suite
 - **GIVEN** approved baselines exist
 - **WHEN** a code change alters the rendering of a covered screen
 - **THEN** the visual assertion MUST fail and report the diff
 #### Scenario: Both viewports are covered
 - **WHEN** the visual suite runs
 - **THEN** each covered screen MUST be asserted at 1440×1000 and 390×844
 #### Scenario: Heritage Editorial identity is captured
 - **WHEN** approved baselines for the home are reviewed after this change
 - **THEN** they MUST reflect EB Garamond typography, olive/paper palette and sharp-edged editorial layout rather than the previous gold/rounded placeholder look
 ### Requirement: Visual runs are deterministic
 Visual runs SHALL be deterministic per SPEC §13.5: fixed Chromium and Linux image, fixed viewport, timezone `America/Fortaleza`, locale `pt-BR`, self-hosted fonts installed/bundled for the suite, frozen clock, deterministic seed (including real testimonial subset and São Paulo settings), animations and transitions disabled, and no dependency on external network.
 #### Scenario: Repeated run without code change produces no diff
 - **WHEN** the visual suite runs twice against the same commit and seed
 - **THEN** both runs MUST pass with no pixel diff
 #### Scenario: Time-dependent content does not cause drift
 - **GIVEN** the clock is frozen and the seed is deterministic
 - **WHEN** the suite runs on a different calendar day
 - **THEN** rendered dates MUST remain identical to the baseline
 #### Scenario: Motion is disabled during capture
 - **WHEN** a screenshot is captured
 - **THEN** CSS animations and transitions MUST be disabled
 ### Requirement: Baseline updates are explicit and reviewed
 Baselines SHALL only be updated through the explicit `composer visual:update` command, and the resulting diff MUST be reviewed by a human before merge. Baselines MUST NOT be regenerated automatically to make CI pass.
 #### Scenario: CI does not regenerate baselines
 - **WHEN** the `browser` CI job runs
 - **THEN** it MUST run in assertion mode
 - **AND** MUST NOT write new baselines
 #### Scenario: Developer updates baselines intentionally
 - **WHEN** a developer runs `composer visual:update`
 - **THEN** the updated baseline files MUST be written to the versioned baseline directory for review
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/web-accessibility/spec.md
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/specs/web-accessibility/spec.md
@@ -1,79 +0,0 @@
 ## MODIFIED Requirements
 ### Requirement: Public routes have no critical or serious accessibility issues
 The system SHALL run automated accessibility checks on the public routes covered by the browser suite (SPEC §6.5, §13.8) after the Heritage Editorial redesign. A critical or serious issue MUST fail the suite.
 #### Scenario: Critical issue blocks the suite
 - **WHEN** the automated accessibility check reports a critical or serious issue on a covered route
 - **THEN** the browser suite MUST fail and report the offending rule and selector
 #### Scenario: Covered routes are checked
 - **WHEN** the accessibility suite runs
 - **THEN** the home, services listing, portfolio listing and case detail MUST each be checked
 ### Requirement: Public pages use accessible semantic structure
 Public pages SHALL provide semantic landmarks, exactly one `h1` per page, a coherent heading order, alt text on every content image and brand mark, and visible focus on interactive elements (SPEC §6.5).
 #### Scenario: Single h1 per page
 - **WHEN** any public page is rendered
 - **THEN** exactly one `h1` element MUST be present
 #### Scenario: Landmarks are present
 - **WHEN** any public page is rendered
 - **THEN** `header`, `main`, `nav` and `footer` landmarks MUST be present
 #### Scenario: Content images expose alt text
 - **WHEN** a page renders a cover or gallery image
 - **THEN** the `alt` attribute MUST contain the stored alt text
 #### Scenario: Brand mark exposes accessible name
 - **WHEN** the public header brand mark is rendered
 - **THEN** it MUST expose an accessible name identifying Amare Assessoria
 ### Requirement: Public pages are fully keyboard operable
 Visitors SHALL be able to reach and activate every interactive element with the keyboard, including the mobile navigation disclosure when visible, with a visible focus indicator and a skip link to the main content.
 #### Scenario: Keyboard reaches the primary CTA
 - **WHEN** a visitor navigates the home with the Tab key
 - **THEN** the primary CTA MUST receive focus with a visible indicator
 - **AND** activating it with the keyboard MUST navigate to the contact route
 #### Scenario: Skip link bypasses navigation
 - **WHEN** a visitor focuses the first element of a public page
 - **THEN** a skip link to the main content MUST be available
 #### Scenario: Mobile menu is keyboard operable
 - **WHEN** the mobile menu button is focused and activated with the keyboard
 - **THEN** the navigation links MUST become reachable by subsequent Tab stops
 - **AND** the button MUST expose the correct `aria-expanded` state
 ### Requirement: Reduced motion preference is honored
 The system SHALL suppress non-essential animation and transition when the user agent reports `prefers-reduced-motion: reduce`, including editorial hover scales and menu transitions introduced by the redesign.
 #### Scenario: Reduced motion disables transitions
 - **GIVEN** the browser reports `prefers-reduced-motion: reduce`
 - **WHEN** a public page is loaded
 - **THEN** decorative transitions and animations MUST NOT run
 ### Requirement: Public pages emit no console errors
 Covered public routes SHALL load without JavaScript console errors in a real browser (SPEC §13.8, §19), including pages that load the mobile navigation script.
 #### Scenario: Console stays clean on covered routes
 - **WHEN** a covered public route is loaded in the browser suite
 - **THEN** the console MUST contain no error-level messages
--- a/openspec/changes/archive/2026-08-01-recreate-public-frontend/tasks.md
+++ b/openspec/changes/archive/2026-08-01-recreate-public-frontend/tasks.md
@@ -1,57 +0,0 @@
 ## 1. Tokens, fonts and brand assets
 - [x] 1.1 Write failing feature/CSS contract tests (or extend existing token/layout assertions) for Heritage Editorial palette, EB Garamond family, radius 0 and container `1120px`
 - [x] 1.2 Rewrite `resources/css/tokens.css` + `@theme` mapping in `app.css` to Heritage Editorial; remove card-shadow hierarchy for public content
 - [x] 1.3 Swap Vite font from Instrument Sans to self-hosted EB Garamond (400/500/600) and update `components/fonts.blade.php` consumption
 - [x] 1.4 Add optimized logo assets under `public/brand/` (light/dark variants) from the provided lockup without redrawing geometry; add `<x-brand.logo>` with accessible alt
 - [x] 1.5 Run focused feature/static checks covering tokens/fonts and `npm run build`
 ## 2. Site settings and CMS editorial fields
 - [x] 2.1 Add failing feature tests for new typed `site_settings` fields (logo, hero secondary CTA/note, manifesto, method steps, principles) and São Paulo seed city
 - [x] 2.2 Create migration + model fillable/casts for the new typed columns (JSONB for method steps/principles preferred)
 - [x] 2.3 Update Filament `ManageSiteSettings` with pt-BR editorial sections and logo alt validation
 - [x] 2.4 Update `ContentSeeder` / factory defaults with editorial copy and São Paulo; keep optional fields nullable with safe view defaults
 - [x] 2.5 Run `composer test:feature` for site-settings coverage
 ## 3. Real testimonials
 - [x] 3.1 Add failing tests for multi-paragraph quote rendering and seeder expectations for the five couples from `depoimentos.md`
 - [x] 3.2 Replace fictional testimonials in content/visual seeders with the real quotes, author names and context/dates
 - [x] 3.3 Update testimonials Blade to render paragraph breaks; keep unpublished-by-default path documented for production authorization
 - [x] 3.4 Run testimonials feature tests
 ## 4. Public layout and navigation
 - [x] 4.1 Add/extend failing tests for brand mark in header, landmarks, skip link, and mobile menu `aria-expanded` behavior
 - [x] 4.2 Redesign `layouts/public.blade.php` header/footer for Heritage Editorial (logo, route nav, contact CTA, footer groups)
 - [x] 4.3 Implement minimal mobile menu toggle in `resources/js/app.js` with reduced-motion safety
 - [x] 4.4 Run layout/accessibility structure feature tests
 ## 5. Home editorial reconstruction
 - [x] 5.1 Update failing `HomePageContentTest` (and related) for new section order: hero → manifesto → services → portfolio → method → testimonials → positioning → final CTA; empty catalog sections omitted; CTA → contact; preserve `data-testid="home-primary-cta"`
 - [x] 5.2 Rebuild home components/pages to match editorial composition (merge proof+cases into one portfolio block; add manifesto + positioning; four method steps)
 - [x] 5.3 Wire settings-driven copy and demo-image disclosure note; keep single `h1`
 - [x] 5.4 Run home feature tests
 ## 6. Internal public pages as chapters
 - [x] 6.1 Extend/adjust public page feature tests for services, portfolio index/show, about, contact (presentation-only), privacy and branded errors under the new layout
 - [x] 6.2 Restyle `pages/services`, `pages/portfolio/*`, `pages/about`, `pages/contact`, `pages/privacy`, `errors/404`, `errors/500` to Heritage Editorial without changing route contracts or inventing proof
 - [x] 6.3 Confirm contact page shows settings channels and creates no leads
 - [x] 6.4 Run `PublicPagesTest` and related SEO/N+1 tests
 ## 7. Accessibility, browser and visual gates
 - [x] 7.1 Update browser accessibility tests for brand mark name, keyboard path to primary CTA, mobile menu operability, axe on covered routes, reduced motion and clean console
 - [x] 7.2 Update `VisualContentSeeder` for deterministic Heritage Editorial content (SP + real testimonial subset + fixtures)
 - [x] 7.3 Run browser a11y/smoke suites; fix regressions
 - [x] 7.4 Run `composer visual:update` and review desktop `1440×1000` / mobile `390×844` diffs for home, services, portfolio, portfolio detail before committing baselines
 ## 8. Quality closeout
 - [x] 8.1 Run `composer pint` and `composer phpstan` on touched PHP
 - [x] 8.2 Run `composer test:feature` and `composer test:browser`
 - [x] 8.3 Run `composer quality` (or equivalent full gate) and fix remaining failures
 - [x] 8.4 Update surface brief / note remaining unresolved items (official contacts, final testimonial authorization, authorized photography) without inventing facts
--- a/openspec/changes/complete-foundation-parity/tasks.md
+++ b/openspec/changes/complete-foundation-parity/tasks.md
@@ -1,23 +1,23 @@
 ## 1. Auth and strict types parity
- [x] 1.1 Add `MustVerifyEmail` to `User` and require verified + active in `canAccessPanel`; update seed so admin/assistant are verified; feature tests for unverified denial and verified access
+- [ ] 1.1 Add `MustVerifyEmail` to `User` and require verified + active in `canAccessPanel`; update seed so admin/assistant are verified; feature tests for unverified denial and verified access
- [x] 1.2 Confirm Filament/Laravel password reset is enabled; add feature tests for registered vs unknown email without account enumeration — required a custom `App\Filament\Pages\Auth\RequestPasswordReset` overriding Filament's stock page, which discloses account existence via a distinguishable danger notification on `Password::INVALID_USER`
+- [ ] 1.2 Confirm Filament/Laravel password reset is enabled; add feature tests for registered vs unknown email without account enumeration
- [x] 1.3 Add `declare(strict_types=1);` to project-owned PHP files missing it (e.g. `AdminPanelProvider`); architecture/unit regression as needed — 15 files total: `AdminPanelProvider`, `Controller`, and 13 Filament Resource Pages classes
+- [ ] 1.3 Add `declare(strict_types=1);` to project-owned PHP files missing it (e.g. `AdminPanelProvider`); architecture/unit regression as needed
- [x] 1.4 Run `composer pint`, `composer phpstan`, and `composer test:feature` for auth changes — all green
+- [ ] 1.4 Run `composer pint`, `composer phpstan`, and `composer test:feature` for auth changes
 ## 2. Local runtime and PHP 8.4 alignment
- [x] 2.1 Extend `docker-compose.yml` with FrankenPHP `app` service (build Dockerfile, depend on healthy postgres, publish 8000); document in README
+- [ ] 2.1 Extend `docker-compose.yml` with FrankenPHP `app` service (build Dockerfile, depend on healthy postgres, publish 8000); document in README
- [x] 2.2 Align README/docs to PHP 8.4 canonical (keep Composer `^8.3`); verify Dockerfile/CI already on 8.4
+- [ ] 2.2 Align README/docs to PHP 8.4 canonical (keep Composer `^8.3`); verify Dockerfile/CI already on 8.4
- [x] 2.3 Smoke local compose: `docker compose up -d` → `GET /up` returns 200 — run as an isolated `-p fase0smoke` project (separate container names/ports via a `!override` compose overlay, kept outside the repo) so it didn't collide with the `amare-postgres` container already running for a concurrent sibling worktree session. `depends_on: condition: service_healthy` correctly gated `app` on Postgres's healthcheck, `curl localhost:18000/up` returned `200`, and `docker exec ... php artisan migrate --force` succeeded — proving `DB_HOST: postgres` resolves the `app` container to the `postgres` service by Compose's service-name DNS, not just that the image boots. Torn down afterwards (`down -v` + image removal); the shared sibling `amare-postgres` container was untouched throughout.
+- [ ] 2.3 Smoke local compose: `docker compose up -d` → `GET /up` returns 200
- [x] 2.4 Run `composer quality` after compose/docs changes — pint/phpstan/test:feature all green locally (browser suite is CI-only, per AGENTS.md)
+- [ ] 2.4 Run `composer quality` after compose/docs changes
 ## 3. Quality gates: npm audit and coverage
- [x] 3.1 Add npm audit step to `composer quality` and CI `static` (policy: production deps; document any allowlist) — `npm audit --omit=dev --audit-level=high`, rationale documented inline in `ci.yml`; currently a vacuous forward guard since `package.json` has no runtime `dependencies`
+- [ ] 3.1 Add npm audit step to `composer quality` and CI `static` (policy: production deps; document any allowlist)
- [x] 3.2 Enable Domain/Application coverage in CI `unit` with 80% fail threshold; exclude views/migrations/framework — scoped via a dedicated `phpunit.coverage.xml` (not the project-wide `phpunit.xml`), run as `Unit,Architecture,Feature` because the `Application/Queries/Marketing` classes are only exercised via Feature/HTTP tests; measured locally with `pcov` at 98.1%, well above the 80% gate
+- [ ] 3.2 Enable Domain/Application coverage in CI `unit` with 80% fail threshold; exclude views/migrations/framework
- [x] 3.3 Add/adjust unit tests if current Domain/Application coverage is below threshold — no-op: measured coverage (98.1%) already clears 80% with existing Feature-suite coverage of the Marketing queries plus existing `PageMeta`/`HomeContent` unit tests
+- [ ] 3.3 Add/adjust unit tests if current Domain/Application coverage is below threshold
- [ ] 3.4 Verify CI `static` and `unit` fail appropriately on intentional audit/coverage breakage in a branch experiment or equivalent proof — blocked: no push/PR in this task's scope, so no real CI run exists to break intentionally; defer to a follow-up once a PR is open
+- [ ] 3.4 Verify CI `static` and `unit` fail appropriately on intentional audit/coverage breakage in a branch experiment or equivalent proof
 ## 4. Staging/production Compose and Dokploy prep
@@ -38,6 +38,6 @@
 - [ ] 6.1 Perform first successful staging deploy of a `main` SHA and capture evidence (workflow URL, smoke output)
 - [ ] 6.2 Verify rollback to previous SHA works once on staging
- [x] 6.3 Update `SPEC.md` §18 Fase 0 checkboxes only for items with evidence; note remaining deferred items if any — flipped L2338 (FrankenPHP/Compose) and the auth/npm-audit/coverage bullets to `[x]`; left the staging hello-world bullet and the phase exit-criterion line unchecked (Dokploy deploy still failing, out of scope here)
+- [ ] 6.3 Update `SPEC.md` §18 Fase 0 checkboxes only for items with evidence; note remaining deferred items if any
 - [ ] 6.4 Run full `composer quality` and confirm all five CI jobs + staging deploy path green
 - [ ] 6.5 Report in SPEC §24 format; archive this change only after remaining parity tasks (1–3) also complete
--- a/openspec/changes/enhance-public-motion/.openspec.yaml
+++ b/openspec/changes/enhance-public-motion/.openspec.yaml
@@ -1,2 +0,0 @@
 schema: spec-driven
 created: 2026-08-06
--- a/openspec/changes/enhance-public-motion/design.md
+++ b/openspec/changes/enhance-public-motion/design.md
@@ -1,51 +0,0 @@
 ## Context
 O site público usa Blade/Tailwind e já contém um runtime pequeno em `resources/js/motion.js`: abertura focal da home, `page-open`, reveals com `IntersectionObserver` e progresso do índice. A cobertura e a marcação são parciais, os reveals não têm grupos/direções explícitas e a matriz browser se concentra nas quatro páginas visuais originais. A mudança cruza templates, CSS, JavaScript e testes, mas não envolve estado de aplicação, dados ou dependências.
 ## Goals / Non-Goals
 **Goals:**
 - Tornar a coreografia Heritage Editorial consistente em toda página pública visual.
 - Manter texto legível durante toda entrada, animando somente `transform` e recorte de mídia.
 - Garantir enhancement progressivo: estado final imediato sem JavaScript, observer ou com movimento reduzido.
 - Preservar interação, foco, validação e ausência de overflow em desktop/mobile.
 - Cobrir marcação, comportamento real, acessibilidade, console e capturas determinísticas.
 **Non-Goals:**
 - Não criar transições de rota, parallax, animação contínua ou repetição ao voltar no scroll.
 - Não mudar copy, dados de clientes, estrutura de layout, CMS, controllers, banco, APIs ou Filament.
 - Não adicionar biblioteca de animação nem itens de SPEC.md §4.2.
 ## Decisions
 1. **Contrato declarativo em atributos `data-*`.** Templates usarão `data-motion="page-open"`, `data-motion-beat`, `data-reveal-group`, `data-reveal` e `data-reveal-from="up|left|right"`. CSS define o estado visual e JS apenas ativa classes. Alternativa rejeitada: acoplar seletores a classes de layout, por tornar a coreografia frágil a ajustes visuais.
 2. **Enhancement opt-in pelo elemento raiz.** O HTML inicial permanece no estado final; o runtime adiciona `html[data-motion="enhance"]` somente quando movimento é permitido e os recursos necessários existem. Sem JS, sem `IntersectionObserver`, ou em `reduce`, o atributo não é aplicado/removido e todo conteúdo fica final. Alternativa rejeitada: estado inicial oculto no HTML/CSS, pois pode prender conteúdo fora da tela.
 3. **Transformação sem fade de texto.** Entradas duram cerca de 500 ms com `cubic-bezier(0.16, 1, 0.3, 1)`, deslocamento vertical de 12 px e lateral de 24 px no desktop/16 px no mobile. Grupos recebem stagger de 90 ms limitado a 270 ms. Mídia pode combinar transform com `clip-path`; texto não usa opacidade. Alternativa rejeitada: fade geral, que reduz contraste durante axe e legibilidade percebida.
 4. **Observer de execução única.** Cada reveal intersectado recebe o estado final e é removido do observer. Grupos calculam índice limitado para o delay; depoimentos definem explicitamente `left`/`right` pela coluna, preservando alternância no mobile. Alternativa rejeitada: reanimar em toda rolagem, por criar fadiga e instabilidade.
 5. **Feedback separado das entradas.** CTAs, links, navegação e controles recebem transições curtas (100–200 ms) em cor/transform/borda. `:focus-visible` continua prioritário; alertas e mensagens de erro não entram no contrato de motion. Alternativa rejeitada: feedback via JS, desnecessário para estados CSS.
 6. **Progresso com coalescência por frame.** Eventos de scroll apenas agendam uma atualização por `requestAnimationFrame`; o cálculo existente é preservado. Alternativa rejeitada: calcular em todo evento, que multiplica leituras/escritas durante scroll.
 7. **Testes em camadas.** Feature tests comprovam contratos Blade/CSS/JS e renderização de erros; browser tests comprovam entrada, stagger, direções, reduced motion, fallback, interação, overflow e console. Axe/snapshots passam a incluir sobre, contato, privacidade e 404; demais erros ficam em renderização feature.
 ## Risks / Trade-offs
 - [Conteúdo pisca entre estado final e início do enhancement] → inicializar no primeiro módulo Vite, limitar transformações a distâncias pequenas e nunca ocultar texto.
 - [Transforms laterais causam overflow horizontal] → limitar distância por breakpoint, manter recorte no contêiner público e testar `scrollWidth` em ambos viewports.
 - [Snapshots ficam instáveis] → continuar capturando com `reducedMotion: reduce` e transições desabilitadas.
 - [Muitos observers/estilos inline] → usar um único observer, custom property de índice limitada e `unobserve` imediato.
 - [Páginas de erro não carregam o runtime em todos os contextos] → o estado final é o baseline seguro; feature tests cobrem os cinco templates.
 ## Migration Plan
 Publicar CSS, JS e templates no mesmo bundle/commit; não há migração de dados. Rollback consiste em reverter esses assets e atributos, sem compatibilidade de schema ou limpeza operacional.
 ## Open Questions
 Nenhuma; direção, alternância mobile, execução única e limites de escopo foram aprovados no plano.
--- a/openspec/changes/enhance-public-motion/proposal.md
+++ b/openspec/changes/enhance-public-motion/proposal.md
@@ -1,31 +0,0 @@
 ## Why
 O site público já possui uma abertura focal na home, mas o restante da experiência ainda muda de estado de forma desigual entre páginas e seções. WEB-01, WEB-07 e os requisitos transversais de acessibilidade pedem uma coreografia editorial consistente, progressiva e dispensável, sem ocultar conteúdo nem comprometer interação, performance ou movimento reduzido.
 ## What Changes
 - Evoluir o contrato de motion do site público com abertura de página, sequência editorial inicial e reveals direcionais executados uma única vez.
 - Aplicar a coreografia à home, serviços, portfólio, detalhe, sobre, contato, privacidade e páginas de erro 404/419/429/500/503.
 - Alternar depoimentos entre esquerda e direita, filtrando citações vazias antes de renderizar a sequência.
 - Adicionar feedback curto e não bloqueante a links, CTAs, navegação e controles de formulário, preservando foco e mensagens de validação.
 - Garantir estado final imediato sem JavaScript, sem `IntersectionObserver` e com `prefers-reduced-motion: reduce`.
 - Limitar o progresso/índice da home a uma atualização por frame e ampliar testes de marcação, browser, acessibilidade, console e regressão visual.
 - Não objetivos: não criar transições entre rotas, alterar conteúdo ou layout estrutural, adicionar biblioteca de animação, modificar CMS/API/banco/Filament, nem introduzir itens fora do MVP listados em SPEC.md §4.2.
 ## Capabilities
 ### New Capabilities
 - `public-site-motion`: Coreografia progressiva, direções, timings, execução única, microfeedback, performance e fallbacks do motion público.
 ### Modified Capabilities
 - `design-tokens`: Especificar tokens compartilhados de duração, stagger, distância e easing para motion editorial.
 - `public-site-pages`: Cobrir todas as páginas públicas visuais e templates de erro com o contrato compartilhado de abertura e reveal.
 - `testimonials`: Filtrar citações vazias e alternar explicitamente a direção de entrada dos depoimentos renderizados.
 - `visual-regression`: Ampliar a matriz visual para sobre, contato, privacidade e 404, mantendo capturas determinísticas sem animação.
 - `web-accessibility`: Ampliar axe/console e validar conteúdo imediatamente utilizável com movimento reduzido ou enhancement indisponível.
 ## Impact
 Afeta somente templates Blade públicos, `resources/js/motion.js`, tokens/regras CSS e testes Pest/Pest Browser. Não altera APIs, banco, controllers, CMS, dependências, endpoints técnicos (`sitemap.xml`, `robots.txt`) ou Filament.
--- a/openspec/changes/enhance-public-motion/specs/design-tokens/spec.md
+++ b/openspec/changes/enhance-public-motion/specs/design-tokens/spec.md
@@ -1,9 +0,0 @@
 ## ADDED Requirements
 ### Requirement: Editorial motion tokens are centralized
 The system SHALL define shared public motion tokens for an approximately 500 ms entrance, short interaction feedback, exponential ease-out, 90 ms stagger capped at 270 ms, 12 px vertical distance, and 24 px desktop / 16 px mobile lateral distance. Public motion CSS MUST consume these tokens instead of duplicating arbitrary values.
 #### Scenario: Motion runtime uses shared values
 - **WHEN** page openings, reveals, or interaction feedback are styled
 - **THEN** duration, easing, stagger, and distance MUST be derived from centralized tokens
--- a/openspec/changes/enhance-public-motion/specs/public-site-motion/spec.md
+++ b/openspec/changes/enhance-public-motion/specs/public-site-motion/spec.md
@@ -1,74 +0,0 @@
 ## ADDED Requirements
 ### Requirement: Public pages use shared progressive motion choreography
 The public site SHALL expose a declarative motion contract using `data-motion="page-open"`, `data-motion-beat`, `data-reveal-group`, `data-reveal`, and `data-reveal-from="up|left|right"`. Home, services, portfolio index/detail, about, contact, privacy, and branded 404/419/429/500/503 pages MUST use the contract without introducing route transitions.
 #### Scenario: Visual public route exposes motion hooks
 - **WHEN** a visitor loads any visual public route or branded error page
 - **THEN** the rendered page MUST expose a page opening hook and appropriate reveal hooks
 #### Scenario: Technical endpoints remain outside motion
 - **WHEN** a visitor requests `sitemap.xml` or `robots.txt`
 - **THEN** the response MUST NOT depend on the public motion runtime
 ### Requirement: Editorial entrance timing and direction are consistent
 Entrances SHALL use shared tokens for an approximately 500 ms duration, 90 ms stagger capped at 270 ms, 12 px vertical distance, and 24 px desktop / 16 px mobile lateral distance. Text MUST remain fully visible; motion MUST use transforms and MAY use media clipping without opacity fades for text.
 #### Scenario: Reveal group computes capped stagger
 - **WHEN** more than four reveal items are rendered in one group
 - **THEN** the applied delay MUST NOT exceed 270 ms
 #### Scenario: Text enters without opacity fade
 - **WHEN** page opening or scroll reveal motion runs
 - **THEN** text MUST remain visible throughout the transition
 ### Requirement: Reveals execute once without blocking interaction
 Each scroll reveal SHALL activate once, reach its final state, and be removed from observation. Visitors MUST be able to activate links and form controls while entrance motion is running.
 #### Scenario: Revealed content leaves observer
 - **WHEN** a reveal target intersects the configured viewport threshold
 - **THEN** it MUST receive the final state and be unobserved
 - **AND** scrolling away and back MUST NOT replay the reveal
 #### Scenario: CTA remains interactive during entrance
 - **WHEN** a visitor activates a CTA while its entrance is in progress
 - **THEN** navigation MUST proceed without waiting for animation completion
 ### Requirement: Motion enhancement has immediate safe fallbacks
 Without JavaScript, without `IntersectionObserver`, or when `prefers-reduced-motion: reduce` is active, the site SHALL render every motion target immediately in its final usable state. Non-essential animation and transition MUST NOT run under reduced motion.
 #### Scenario: JavaScript is unavailable
 - **WHEN** a public page renders without executing JavaScript
 - **THEN** all content MUST be visible and usable in its final state
 #### Scenario: IntersectionObserver is unavailable
 - **WHEN** JavaScript runs but `IntersectionObserver` is not supported
 - **THEN** all reveal targets MUST remain in their final state
 #### Scenario: Reduced motion is preferred
 - **WHEN** the browser reports `prefers-reduced-motion: reduce`
 - **THEN** page openings, reveals, media clips, and non-essential feedback transitions MUST NOT run
 ### Requirement: Public interaction feedback is short and accessible
 CTAs, links, navigation, and form controls SHALL provide short feedback using shared tokens while preserving visible `:focus-visible` indication. Alerts and validation messages MUST NOT be animated by this contract.
 #### Scenario: Keyboard focus remains visible
 - **WHEN** a visitor focuses an interactive element with the keyboard
 - **THEN** its focus indicator MUST remain visible and MUST NOT be displaced by motion feedback
 #### Scenario: Validation message appears without motion
 - **WHEN** server validation renders an error message
 - **THEN** the message MUST appear in its final position without entrance animation
 ### Requirement: Home progress updates at most once per animation frame
 Scroll-driven chapter index and progress updates on the home SHALL be coalesced through `requestAnimationFrame`, with at most one pending update per frame.
 #### Scenario: Multiple scroll events occur in one frame
 - **WHEN** multiple scroll events fire before the next animation frame
 - **THEN** the home progress calculation MUST execute only once for that frame
--- a/Show More
+++ b/Show More
		`@@ -1,3 +0,0 @@`
			`#!/usr/bin/env sh`

			`composer pint:check && composer phpstan`