Audit your project
FC-AUDIT is a reference of audit rules to assess the quality of a Front-Commerce project, and an AI prompt that runs the audit for you.
Front-Commerce projects share recurring quality pitfalls: disabled native caches, over-extended theme overrides, missing error boundaries, unoptimized assets, or unguarded routes. FC-AUDIT turns years of audits performed by the Front-Commerce team into a public, actionable rule set that you can run on your own project — before going to production, after a major release, or as a periodic health check.
Run an audit with an AI agent
Copy the prompt below and paste it into your coding agent of choice (Claude Code, Cursor, etc.) opened at the root of your project. The agent identifies your project setup, checks every applicable rule, and produces an interactive HTML report with findings linked to your code.
The static rules only need your repository. For runtime rules (Lighthouse, CSP, cache headers…), the agent will either start your project locally or ask you for a deployed URL (staging is fine, HTTP Basic Auth is supported).
The rule set
Rules are grouped by theme. Each rule has a stable code you can reference in reviews and reports:
- Performance (
AUDIT-PERF-*) — server-side caching, DataLoaders, client assets - Security (
AUDIT-SEC-*) — permissions, rate limiting, CSP, information leaks - Theme customization (
AUDIT-THEME-*) — override surface, error boundaries, design system usage - Code quality (
AUDIT-CODE-*) — dependencies, GraphQL conventions, error handling, upgrade path - SEO & analytics (
AUDIT-SEO-*) — meta tags, sitemap, structured data, tracking reliability - Deployment & observability (
AUDIT-INFRA-*) — health checks, metrics, environment hygiene - Resilience (
AUDIT-RES-*) — graceful degradation, timeouts, error swallowing - Accessibility (
AUDIT-A11Y-*) — landmarks, labels, keyboard navigation - Migration from 2.x (
AUDIT-MIG-*) — only for projects carrying 2.x compatibility code
How rules are qualified
Every rule declares two attributes:
Severity — how urgent a violation is:
| Severity | Meaning |
|---|---|
critical | Security exposure, production outage or major degradation, data leak. Fix immediately. |
important | Significant performance, SEO, or maintainability impact; blocks smooth version upgrades. |
minor | Hygiene and polish. Fix opportunistically. |
Detection — what is needed to check the rule:
| Detection | Meaning |
|---|---|
static | Verifiable by analyzing the repository alone. |
runtime | Requires the application running (locally or a deployed URL). |
manual | Requires human judgment; an AI agent can prepare the evidence. |
Scope and philosophy
These rules target integrator projects built on the Front-Commerce skeleton
(a front-commerce.config.ts file, an app/ directory, custom extensions).
They complement — not replace — your own team standards. A rule violation is a
conversation starter backed by a rationale, not a build failure: the Why of
each rule explains the risk so your team can arbitrate with full knowledge.
For the manual, visual checks to run right before a go-live (Offline page, Maintenance page, and similar), see Before going to production.