Selzler Construtora
Selzler Arquitetura e Engenharia: public, industrial and residential construction, Toledo/PR. 40 years.
the_problem
The existing site is static WordPress. Every completed project, every new client in the portfolio, required calling a developer. The partners had no way to publish their own work.
what_it_does
- Public frontend reproducing the existing information architecture: home, about, completed works split by public/industrial/residential, works in progress, clients, contact and privacy policy.
- Admin panel behind a partner login with no public signup. Users are created by seed. Full CRUD over works and clients, with image upload.
- Client logo carousel as a continuous JetBrains-style marquee, with real logos.
- Cookie consent card gating analytics, for LGPD.
- Google Places integration for reviews, synchronised in the background by a hosted service.
- Container warm-up on the contact page, a serverless cold-start detail resolved before the visitor can feel it.
stack
frontend
Next.js (App Router) · React 19 · TypeScript · Tailwind CSS v4 · shadcn/ui on Base UI · Vitest
backend
C# / .NET 10 · ASP.NET Core · EF Core 10 + Npgsql · PostgreSQL 16 · Docker
infra
Terraform · Cloudflare R2
measured
- Commits in ten days
- 119git history, 2026-07-14 to 2026-07-24
- Audit findings closed
- 12docs/audit/2026-07, four separate sweeps
how_it_was_built
This is the repository where the methodology is most explicit. The stack was locked by a dated decision ("locked on 14/07/2026, do not change without explicit discussion") and the structure, authentication and testing patterns were deliberately inherited from Telas Paraná. Reuse between the same author’s projects, not reinvention. The modular monolith is likewise justified rather than copied: no process split until there is a concrete reason.
The agent configuration carries a team of specialised sub-operators (architect, backend, frontend, DBA, devops, cybersecurity, DPO, QA, content and vault), each with persistent per-agent memory holding concrete lessons from the project. Those memories are behavioural corrections that outlived the session that produced them.
Work is organised as numbered PRDs (client carousel, JWT auth, frontend login, an OpenAPI vulnerability, admin hardening) plus a formal audit with four separate sweeps across backend, database, frontend and security, whose twelve findings were closed in a commit of their own.
Unusual for a project this size: a legal folder analysing software law, civil code, LGPD and the Brazilian internet framework, a map of data sub-processors, a signed DPA versioned as a PDF, and a claims audit of the site’s public statements so that no published number is invented.
known_limitations
- Not deployed. Everything through v0.4 is complete and working locally, but v1.0, production deployment on its own domain, is still open, so this is presented as functional rather than in production.
- The frontend test suite covers structural invariants, not appearance. Layout and accessibility still require direct measurement in a real browser.
- A designed next sprint exists on paper only: a local vector RAG over the documentation, exposed to the agents through an MCP server.
roadmap
- v0.1 health check ✓
- v0.2 CRUD ✓
- v0.3 public frontend ✓
- v0.4 admin auth ✓
- v1.0 production deployment on its own domain: pending
tracked coding time
19 hrs 17 mins Source: WakaTime · tracked 2026-03-17 to current