# AGENTS.md

## Stack and runtime
- Astro 5 SSR with `@astrojs/node` in `standalone` mode.
- Production entrypoint is `node ./dist/server/entry.mjs`.
- Runtime target is Node 20 (`Dockerfile` and `nixpacks.toml` both pin Node 20).
- TypeScript extends `astro/tsconfigs/strict`.

## Verified commands
- Install deps: `npm install` or `npm ci`
- Dev server: `npm run dev`
- Type/content check: `npm run check`
- Build: `npm run build`
- Local preview: `npm run preview`
- Production start: `npm run start`

Recommended verification after UI/content changes:
1. `npm run check`
2. `npm run build`

There are currently no repo scripts for linting, formatting, or tests, and no CI workflows to rely on.

## Real app structure
- File-based routes live in `src/pages/`.
- Main public routes: `index.astro`, `nosotros.astro`, `bodas-reales.astro`, `corporativo-business.astro`, `reuniones-familiares.astro`, `contacto.astro`.
- Legal routes are part of the real surface area: `cookies.astro` and `privacidad.astro`.
- Shared shell is `src/layouts/MainLayout.astro`.
- Shared UI lives in `src/components/`.
- Global styling is split across `src/styles/tokens.css`, `base.css`, `layout.css`, `components.css`, `utilities.css`, and `animations.css`.

## Important implementation facts
- `MainLayout.astro` is the real wiring point: it imports all global CSS and mounts `SiteHeader`, `SiteFooter`, `WhatsAppButton`, and `CookieBanner` on every page.
- `MainLayout.astro` also owns global client behavior: reveal-on-scroll, scroll progress bar, reduced-motion handling, and internal-link fade transitions.
- This is a marketing site optimized for WhatsApp lead capture. Keep WhatsApp as the primary CTA and treat the contact form as secondary.
- The contact form in `src/pages/contacto.astro` is presentational only (`method="dialog"`); do not describe or treat it as a working backend submission flow.
- The WhatsApp destination is hardcoded in multiple places (`+34 678 17 15 13` / `34678171513`). If lead routing changes, search for all occurrences instead of updating a single component and assuming coverage.

## Content and design constraints
- Keep the mobile-first approach in base styles and layout decisions.
- Use CSS variables/tokens instead of introducing utility CSS frameworks.
- Keep service pages structurally consistent, but do not clone copy blindly: adapt CTA, gallery, and messaging per service.
- Galleries belong inside each service page, not as a separate gallery page.
- Preserve the premium editorial tone from `DESIGN.md`; gold is an accent, not a dominant fill color.

## Deployment notes
- Docker and Nixpacks both expect a built SSR app and start with `node ./dist/server/entry.mjs`.
- Runtime env defaults used by deploy config: `HOST=0.0.0.0`, `PORT=4321`, `NODE_ENV=production`.

## Repo-specific gotchas
- Ignore generated/build output: `.astro/` and `dist/`.
- `.gitignore` also excludes `.opencode/`, `.worktrees/`, and local planning artifacts under `docs/plans/`.
- Read `DESIGN.md` before making visual changes; it contains the project’s visual system and tone constraints.