From 5b014b589cd7d5ff293a0c32ec5f20e4c4859608 Mon Sep 17 00:00:00 2001 From: Kevin Bataille Date: Sun, 13 Sep 2026 13:59:23 +0200 Subject: [PATCH] docs: remove third-party plugin name from design doc Specification-first wording: features are specified from user behavior, not benchmarked against a named product. --- docs/plans/2026-09-13-wprecache-design.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/plans/2026-09-13-wprecache-design.md b/docs/plans/2026-09-13-wprecache-design.md index 462550c..7e0898b 100644 --- a/docs/plans/2026-09-13-wprecache-design.md +++ b/docs/plans/2026-09-13-wprecache-design.md @@ -2,20 +2,20 @@ ## Overview -Create a commercial-grade WordPress performance plugin with feature parity to WP Rocket, implemented via clean-room methodology. The plugin will be open source (GPL-2.0+) and provide page caching, file optimization, and image optimization. +Create a commercial-grade, open source (GPL-2.0+) WordPress performance plugin providing page caching, file optimization, and image optimization. Features are written from specification, never derived from any existing plugin's source code. -## Clean-Room Methodology +## Specification-First Methodology ### Rules -1. **No code reuse.** Never copy, paste, or adapt any PHP/JS/CSS from WP Rocket. -2. **Feature specs only.** Document what WP Rocket does from a *user perspective* (UI behavior, options, output), not how it's implemented. +1. **No code reuse.** Never copy, paste, or adapt PHP/JS/CSS from any existing performance plugin. +2. **Feature specs only.** Features are specified from a *user perspective* (UI behavior, options, output), not from anyone's implementation. 3. **Independent implementation.** All code written from scratch using WordPress APIs and standard libraries. 4. **Documentation trail.** Keep records of the specification process to prove independent development. ### What We Study (User Perspective) -- WP Rocket admin UI: what settings exist, what they control +- Admin UIs of established performance plugins: what settings exist, what they control - Frontend output: what HTML/JS/CSS changes appear after activation - Behavior: when cache clears, what gets optimized, what's excluded by default - Performance: what metrics improve @@ -204,8 +204,8 @@ wp-recache/ ## Legal Considerations 1. **Document everything.** Keep records of the specification process. -2. **Never access WP Rocket source** while implementing. -3. **Use different naming.** Don't use "rocket" prefixes or similar naming. +2. **Never access third-party plugin source code** while implementing. +3. **Use different naming.** Don't reuse prefixes or naming from existing plugins. 4. **Independent architecture.** Design your own class structure. 5. **Different defaults.** Choose different default settings where possible. @@ -219,8 +219,8 @@ wp-recache/ ## Success Criteria -1. Feature parity with WP Rocket for page cache, file optimization, image optimization -2. No code overlap (verified by code review) -3. Performance benchmarks comparable to or better than WP Rocket +1. Feature set competitive with established commercial performance plugins: page cache, file optimization, image optimization +2. No code overlap with any existing plugin (verified by code review) +3. Performance benchmarks comparable to or better than established commercial solutions 4. Clean, maintainable code following WordPress standards 5. Active open source community