MNQ-Catering-y-Evento/AGENTS.md

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.