# Site1 — WordPress Project
## Agent
Primary agent:
- @site1
This agent manages the WordPress project architecture, development workflow, frontend changes, SEO safety, and deployment preparation.
---
# Project Context
Project type:
- Custom WordPress website.
Architecture:
- WordPress core.
- Custom theme:
  `wp-content/themes/dekart/`
Theme contains:
- Templates
- Custom frontend styles
- Carbon Fields integration
- Schema.org JSON-LD logic
- Custom business data logic
Repository:
- Git is the source of truth.
- Theme changes are deployed through Git.
- Production and development environments are separated.
Important:
Before any changes, inspect existing architecture.
Do not assume standard WordPress structure.
---
# Critical Rules
## Forbidden without explicit confirmation
NEVER modify:
- wp-config.php
- database structure
- production environment files
- uploads directory
- user data
- existing production configuration
Before executing:
- rm
- delete
- overwrite
- database write
- git push
Ask for confirmation.
---
# WordPress Architecture Rules
## Theme
Location:
wp-content/themes/dekart/
Rules:
Preserve:
- existing PHP templates
- template hierarchy
- hooks
- filters
- Carbon Fields compatibility
- schema.org output
- SEO logic
Do not:
- rebuild templates
- replace theme architecture
- move functionality into plugins without approval
- introduce page builders
---
# Carbon Fields
Carbon Fields is intentionally located inside the theme.
Rules:
Do not:
- move Carbon Fields into a plugin
- rename fields
- change option keys
- modify stored data structure
Any changes must preserve backward compatibility.
---
# Frontend / Redesign Rules
Goal:
Improve visual design without changing markup.
Allowed:
- CSS
- SCSS
- CSS variables
- typography
- colors
- spacing
- borders
- shadows
- animations
- responsive improvements
Forbidden:
- changing HTML structure
- changing block layout
- changing forms
- replacing components
- adding Elementor
- adding visual builders
Priority:
1. Preserve functionality
2. Preserve SEO
3. Preserve accessibility
4. Improve UI consistency
---
# Modern Web Development
Use Google Chrome Modern Web Guidance principles.
Priorities:
- Accessibility
- Performance
- Responsive design
- Maintainable CSS
- Browser compatibility
Prefer:
- CSS variables
- reusable design tokens
- semantic CSS naming
- modern CSS compatible with Baseline
Avoid:
- unnecessary JavaScript
- duplicated CSS
- layout shifts
- heavy dependencies
Consider:
- Core Web Vitals
- CLS
- LCP
- accessibility contrast
- responsive behavior
---
# Frontend Workflow
Before changing styles:
1. Audit existing CSS.
2. Identify:
- colors
- typography
- spacing
- components
- duplicated rules
- inconsistent UI patterns
Create design tokens when possible:
Example:
```css
:root {
    --color-primary:
    --color-secondary:
    --color-text:
    --color-background:
    --border-radius:
    --shadow:
}
Do not make blind global replacements.
SEO Safety
Never break:
title/meta logic
schema.org JSON-LD
breadcrumbs
canonical URLs
indexing behavior
structured data
Frontend changes must not affect SEO output.
Performance
Keep:
Core Web Vitals
minimal CSS overhead
optimized assets
no unnecessary scripts
Avoid:
additional libraries without approval
duplicate dependencies
blocking resources
Redis Object Cache
Current architecture:
Redis Object Cache plugin
mu-plugin bootstrap
WordPress object cache API
Rules:
Do not create another caching layer.
Do not create custom Redis clients.
Do not create custom object-cache.php.
Use:
wp_cache_get()
wp_cache_set()
Runtime files:
Never commit:
wp-content/object-cache.php
Development Standards
PHP
Use:
PSR-12
type declarations where appropriate
WordPress coding standards
JavaScript
Use:
TypeScript strict
ESM
async/await
Avoid unnecessary frameworks.
Git Rules
Commit format:
feat:
fix:
refactor:
style:
chore:
docs:
Before commit:
Run:
git status
git diff
Never commit:
.env
uploads/
logs/
wp-content/object-cache.php
cache files
temporary files
Testing
PHP:
vendor/bin/phpunit
vendor/bin/phpstan analyse
JavaScript:
npm run build
npm test
npm run lint
Run only relevant checks for changed area.
Deployment Rules
Before deployment verify:
changed files
dependencies
environment requirements
database impact
cache impact
Never assume production environment matches development.
Required Work Process
For complex tasks:
Analyze current implementation.
Explain planned changes.
Wait for confirmation if architecture changes are required.
Implement minimal changes.
Verify result.
Provide report.
Final Response Format
After completing tasks always provide:
Summary
What was changed.
Files Changed
List files.
Technical Details
Explain implementation.
Validation
Tests and checks performed.
Risks
Possible issues.
Deployment Notes
Required production actions.