1. Engineering Principles

• Prefer modular plugins and documented APIs over theme-dependent business logic.
• Keep authoritative data separate from presentation.
• Use WordPress coding, security, accessibility, and internationalization practices.
• Design every write operation for validation, authorization, logging, and safe failure.

2. Naming and Structure

Use consistent NAPPSA or NKN prefixes for custom namespaces, options, metadata, scheduled events, REST routes, and database objects. Names must communicate purpose and avoid collisions.

3. Security Requirements

Validate and sanitize inputs, escape outputs, verify nonces and capabilities, use prepared database operations, protect secrets, restrict file operations, and never rely on obscurity for access control.

4. API Requirements

APIs must have versioned routes, documented schemas, explicit permissions, meaningful error responses, rate and abuse controls where needed, and idempotent behavior for retried operations.

5. Testing

Changes require tests appropriate to risk: unit, integration, authorization, accessibility, mobile rendering, synchronization, rollback, and regression checks. Production deployment requires recorded acceptance criteria.

6. Documentation

Every production capability must document purpose, dependencies, configuration, data flow, permissions, failure modes, support owner, deployment steps, rollback, and maintenance cadence.

7. Deployment

Use source control, reviewed changes, reproducible packages, backups, staged validation, release notes, post-deployment checks, and clear rollback points. Direct production edits are reserved for controlled emergencies.

8. Deprecation

Deprecated routes, shortcodes, fields, and integrations require a transition period, replacement guidance, usage review, and removal plan.

9. Definition of Done

A capability is complete only when it is secure, accessible, tested, documented, monitored, owned, recoverable, and verified in production.