Manoel Freitas
2e43fdeb04
A cidade de atuação é São Paulo, garantida por teste em quatro lugares e exigida por openspec/specs/site-settings/spec.md. O identificador de timezone, porém, era America/Fortaleza. O identificador passa a acompanhar o negócio. A mudança não altera comportamento. America/Sao_Paulo e America/Fortaleza são UTC-3 o ano inteiro desde que o horário de verão brasileiro foi extinto — verificado para janeiro, março e dezembro de 2026, idênticos ao segundo. Nada renderizado muda, o relógio congelado dos testes visuais usa offset absoluto (-03:00) e os baselines seguem válidos. O motivo de mexer é outro: a divergência entre o timezone e a cidade custou tempo real. Uma sessão anterior a interpretou como drift e "corrigiu" a SPEC no sentido errado, mudando o documento normativo para Fortaleza em vez de olhar o que o negócio é. Com os dois valores dizendo São Paulo, não há mais o que interpretar. Escopo: config/app.php, .env.example, os dois pontos do ci.yml, SPEC.md (§0, §13.5, §15.4), README.md, docs/deployment/dokploy.md, CLAUDE.md, openspec/config.yaml, openspec/specs/visual-regression/spec.md e o withTimezone do VisualRegressionTest. Intocados de propósito: as asserções que garantem que Fortaleza não aparece como cidade de operação, em PublicPagesTest, SiteSettingsTest, ContentSeederProductionGatingTest e openspec/specs/site-settings. Essas tratam de cidade, não de fuso, e continuam corretas. Co-Authored-By: Claude noreply@anthropic.com AI-Assisted: yes AI-Tool: claude-code Co-authored-by: manoel.neto <manoel.neto@creditas.com>
23 lines
1.4 KiB
YAML
23 lines
1.4 KiB
YAML
schema: spec-driven
|
|
|
|
context: |
|
|
Fonte de verdade: SPEC.md na raiz. Precedência: instrução do dono do produto > SPEC.md > ADRs > testes > convenções.
|
|
Produto: plataforma de assessoria de eventos, single-tenant, MVP. UI em pt-BR, timezone America/Sao_Paulo, atuação em São Paulo (capital), BRL.
|
|
Stack: Laravel 13, Filament 5 (/admin), Blade + Tailwind + JS vanilla progressivo (site público; sem framework reativo — Livewire 4 é dependência do Filament, ver SPEC ADR-015),
|
|
PostgreSQL, FrankenPHP regular mode (sem worker mode), Vite, Pest 4 + Pest Browser, database queue.
|
|
Arquitetura: monólito modular. Interface -> Application (Actions/Queries) -> Domain (Enums/VOs) -> Infrastructure.
|
|
Domain não depende de Filament/Livewire. strict_types em todo PHP próprio.
|
|
Princípio: YAGNI. Nada da seção 4.2 "Fora do MVP". Sem repositórios genéricos, sem BaseService/BaseAction.
|
|
Dinheiro sempre em centavos BIGINT, nunca float. Status derivável não é persistido.
|
|
|
|
rules:
|
|
proposal:
|
|
- Referenciar os IDs de requisito do SPEC.md (WEB-xx, CRM-xx, ADM-xx, etc.)
|
|
- Incluir seção de não objetivos apontando para SPEC.md 4.2
|
|
specs:
|
|
- Cenários em WHEN/THEN derivados dos blocos gherkin do SPEC.md quando existirem
|
|
- Requisitos normativos em SHALL/MUST
|
|
tasks:
|
|
- Cada task é fatia vertical verificável (migration + regra + UI + teste quando aplicável)
|
|
- Nenhuma task marcada concluída sem gate de qualidade correspondente
|