Guidelines for AI Agents

Project

This repository is the 120.dev website. It uses VitePress, Vue single-file components, UnoCSS, and Playwright visual tests. Use pnpm; do not introduce another package manager.

Key locations:

• Root Markdown files define top-level routes.
• docs/ and blog/ contain documentation and historical posts.
• .vitepress/config.mts owns navigation and site configuration.
• .vitepress/theme/index.ts registers global Vue components.
• .vitepress/theme/components/ contains page sections and product components.
• public/ contains static assets served from the site root.
• tests/ contains one Playwright spec and snapshot directory per tested page.
• vercel.json owns production redirects and deployment settings.

Do not edit generated files in .vitepress/cache, .vitepress/dist, test-results, or playwright-report.

Development

On Windows, use PowerShell.

Use the existing Vue and UnoCSS patterns. Follow the indentation of the file being edited. Keep light and dark image variants behaviorally equivalent. Prefer a component-scoped CSS rule when a layout contract must not depend on utility generation or cascade order.

When adding, removing, or renaming a public route, check all of the following:

• Root Markdown pages
• VitePress navigation
• Theme component imports and registrations
• Home-page product links
• Documentation and current-product copy
• Vercel redirects
• Playwright specs and snapshots

Verification

Run the production build after site or component changes:

pnpm build

Run visual tests after user-facing changes:

pnpm test:e2e

Each page should have a separate Playwright spec. When an intentional visual change affects a page, update only the relevant baseline first, then run the complete suite without update mode:

pnpm exec playwright test tests/<page>.spec.ts --update-snapshots
pnpm test:e2e

Use tests/screenshot.css for deterministic screenshot-only overrides. Golden snapshots under tests/*.spec.ts-snapshots/ are source artifacts and must be committed with their specs.

Refactoring

When renaming or removing something, update related variables, functions, files, routes, imports, registrations, tests, snapshots, and documentation. Keep names consistent with existing project conventions. Warn the user when a partial rename could leave broken routes or confusing public copy.

Commits

When asked Commit push, commit only the changes that are already staged. Do not stage additional files. If nothing is staged, do nothing and report that there are no staged changes.

Base the commit message only on the staged diff. Use present tense, start with a capital letter, and follow this format:

[<area>] <description>

Use the narrowest relevant area, such as site, docs, test, or dev.