WDG Playground - Parity Strategy

Platform Synchronization PlanVersion: 1.0 Last Updated: October 2025

Overview

This document defines how WDG Playground maintains feature parity with the WDG AI Development Environment platform while serving different user audiences. The goal is to keep core capabilities synchronized while appropriately simplifying or abstracting features for non-technical users.

Parity Philosophy

Two Products, One Foundation

%%{init:{'theme':'neutral'}}%%
graph TB
   subgraph "WDG AI Development Environment (Platform)"
       PlatformFeatures[Full Feature Set]
       PlatformCLI[CLI Tools]
       PlatformDocker[Docker Services]
       PlatformDashboard[Technical Dashboard]
   end

   subgraph "Shared Components"
       WikitFramework[Wikit Framework]
       MCPTools[MCP Tools]
       VectorDB[Vector Database]
       Documentation[Wikit Documentation]
   end

   subgraph "WDG Playground (Desktop App)"
       SimplifiedUI[Simplified UI]
       EmbeddedServices[Embedded Services]
       VisualWorkflows[Visual Workflows]
       GuidedAI[Guided AI Features]
   end

   PlatformFeatures --> WikitFramework
   PlatformCLI --> MCPTools
   PlatformDocker --> VectorDB

   WikitFramework --> SimplifiedUI
   MCPTools --> VisualWorkflows
   VectorDB --> GuidedAI
   Documentation --> SimplifiedUI

Key Principle: Platform innovations flow to Playground; Playground UX innovations flow back to Platform

Feature Mapping

Complete Parity (Must Match)

Features that must remain identical between Platform and Playground:

Feature	Platform Implementation	Playground Implementation	Sync Strategy
Wikit Framework Version	Git submodule/clone	Bundled in app resources	Monthly sync with platform repos
Wikit Blocks	All 50+ blocks	All 50+ blocks	Same codebase, same functionality
MCP Search Tools	Python FastMCP server	Rust embedded server	Feature parity, same APIs
Vector Database Schema	Qdrant collections	Qdrant collections	Identical schema, compatible exports
WordPress Core	Latest stable	Latest stable	Synchronized updates
Code Indexing	Embedder.py logic	Same embedding model	Identical vector generation

Synchronization Method:

Automated tests verify feature parity
Shared test suites for MCP tools
Weekly comparison reports
Quarterly full audits

Adapted Features (Simplified UX)

Features with same functionality, different interface:

Feature	Platform (Technical)	Playground (Visual)	Adaptation Strategy
Project Creation	CLI: `wdg create {name}`	Wizard with templates	Same backend logic, visual wrapper
Git Operations	CLI git commands	Visual commit/push UI	git2-rs library, same operations
WP-CLI	Direct terminal access	Predefined actions (buttons)	Same WP-CLI, curated commands
Service Management	docker-compose up/down	Auto-start/visual status	Different tech, same result
Code Search	MCP tools in terminal	Block explorer + AI chat	Same MCP tools, visual presentation
Database Ops	CLI mysqldump	Visual backup/restore buttons	Same operations, simpler UI
Plugin Install	WP-CLI or composer	Plugin browser (planned)	Same installation, visual search

Synchronization Method:

Share backend logic libraries
Visual layer independent
Test same outcomes
Documentation cross-references

Platform-Exclusive (Not in Playground)

Features that remain Platform-only:

Feature	Why Platform-Only	Alternative in Playground
Multi-Project Management	Complexity, resource usage	Single active project (switchable)
Full Docker Access	Technical requirement	Embedded services (transparent)
Terminal Integration	Power-user feature	Visual alternatives for all ops
Custom MCP Servers	Advanced configuration	Built-in MCP server
Advanced Git (rebase, cherry-pick)	Complex workflows	Basic git operations only
PHPStan / Code Quality	Developer tools	Not needed for target users
Custom PHP Versions	Development requirement	Fixed PHP 8.2
Nginx Config Editing	Low-level control	Auto-generated configs

Philosophy: If target users (designers, PMs) wouldn't use it, don't include it

Playground-Exclusive (Not in Platform)

Features unique to Playground:

Feature	Why Playground-Only	Potential Platform Integration
Onboarding Wizard	First-time user focus	Could add to platform dashboard
Visual Block Gallery	Non-technical discoverability	Could enhance platform dashboard
Template Marketplace	Curated for non-devs	Platform could offer dev templates
Guided AI Workflows	Hand-holding for new users	Platform AI is more freeform
Auto-Update	Desktop app standard	Platform updates via git pull
Portable Execution	Desktop app benefit	N/A for Docker-based platform

Philosophy: Innovations here may inspire platform enhancements

Shared Repositories

wdg-ecosystem/
wikit-core/              # Shared: Wikit PHP framework
wikit-theme/             # Shared: Base theme
wikit-facets/            # Shared: Component library
wikit-app/               # Shared: Application framework
wikit-docs/              # Shared: Documentation
wdg-ai-dev-environment/  # Platform (main repo)
   mcp-server/          # MCP implementation (Python)
   indexer/             # Code indexing logic
   dashboard/           # Technical dashboard
   cli/                 # CLI tools
wdg-playground/          # Playground (desktop app)
    src-tauri/           # Rust backend
       mcp/             # MCP implementation (Rust)
    src/                 # React frontend (adapted)
    resources/           # Embedded binaries

Shared Components

1. Wikit Framework (Git Submodules)

bash

# Platform
cd repositories/
git submodule add https://github.com/wdgdc/wikit-core

# Playground
cd src-tauri/resources/wikit/
git submodule add https://github.com/wdgdc/wikit-core

Sync Strategy:

Both reference same Wikit repositories
Platform pulls latest weekly
Playground bundles stable monthly release
Security patches synced immediately

2. React Components (Selective Import)

typescript

// Playground can import from Platform dashboard
import { MarkdownMessage } from '@wdg-platform/dashboard-components';
import { CodeBlock } from '@wdg-platform/dashboard-components';

// But adapts for simpler UI
export function SimplifiedChat() {
 return (
   <div className="simplified-wrapper">
     <MarkdownMessage content={message} />
   </div>
 );
}

Sync Strategy:

Publish platform components as npm package
Playground imports selectively
Playground maintains own UI layer
Share core rendering logic only

3. MCP Tool Definitions (API Parity)

yaml

# Shared MCP tool specification (JSON schema)

search_codebase:
 name: "search_codebase"
 description: "Search codebase using semantic search"
 parameters:
   query: {type: string, required: true}
   file_types: {type: array}
   limit: {type: number}

# Platform implements in Python
# Playground implements in Rust
# Both match this spec exactly

Sync Strategy:

Shared OpenAPI/JSON schema definitions
Automated tests verify both implementations
Cross-platform compatibility tests
Version MCP API (v1, v2, etc.)

4. Test Suites (Shared Behavior Tests)

javascript

// Shared test: MCP tools return same results

describe('MCP search_codebase', () => {
 it('returns Hero blocks when searching "hero"', async () => {
   const results = await mcp.search_codebase({
     query: "hero",
     component_type: "block"
   });

   expect(results).toContainEqual(
     expect.objectContaining({
       component_name: "Hero",
       component_type: "block"
     })
   );
 });
});

Sync Strategy:

Shared test repository
Run against both Platform and Playground
CI fails if behavior diverges
Tests define the contract

Update Flow

Platform → Playground Updates

%%{init:{'theme':'neutral'}}%%
graph LR
   A[Platform Update] --> B{Update Type}

   B -->|Wikit Framework| C[Update Submodule]
   C --> D[Test in Playground]
   D --> E[Bundle in Next Release]

   B -->|MCP Tool| F[Update Rust Implementation]
   F --> G[Match API]
   G --> H[Test Parity]

   B -->|Bug Fix| I[Apply to Playground]
   I --> J[Test]

   B -->|New Feature| K{Applicable to Playground?}
   K -->|Yes| L[Adapt for Visual UI]
   K -->|No| M[Document as Platform-Only]

   L --> N[Implement]
   N --> O[Test]

Update Schedule:

Update Type	Frequency	Process
Wikit Framework	Monthly	Pull latest stable, test, bundle
Security Patches	Immediate	Apply ASAP, emergency release
MCP Tool Updates	Bi-weekly	Sync API changes, maintain parity
Bug Fixes	Weekly	Cherry-pick applicable fixes
New Features	Quarterly	Evaluate, adapt if relevant

Playground → Platform Feedback

%%{init:{'theme':'neutral'}}%%
graph LR
   A[Playground Innovation] --> B{Valuable for Platform?}

   B -->|Yes| C[Propose to Platform Team]
   C --> D[Design Platform Version]
   D --> E[Implement in Platform]

   B -->|No| F[Keep Playground-Exclusive]

   E --> G[Both Products Enhanced]

Examples:

Visual Block Gallery → Inspired platform dashboard enhancement
Onboarding Wizard → Platform adds optional setup guide
Template System → Platform adds dev-focused templates

Dependency Management

Version Alignment

yaml

# Playground bundles specific versions

WikitFramework:
 core: v2.5.0
 theme: v1.8.2
 facets: v3.1.1
 app: v1.2.0

WordPress:
 core: 6.4.2

PHP:
 version: 8.2.15

# Platform uses latest or user-specified

WikitFramework:
 core: latest (auto-update)
 theme: latest
 facets: latest
 app: latest

WordPress:
 core: latest

PHP:
 version: 8.0 / 8.1 / 8.2 / 8.3 (user choice)

Compatibility Strategy:

Playground uses proven-stable versions
Platform can use bleeding-edge
Playground updates lag by ~1 month
Critical security updates synchronized

Breaking Changes

When Platform Introduces Breaking Change:

Document Impact

What breaks in Playground?
Migration path for users

Parallel Support (if possible)

Platform supports old + new
Gives Playground time to adapt

Coordinated Release

Platform releases breaking change
Playground releases adaptation
Joint announcement

Deprecation Period

Minimum 3 months notice
Clear migration guides
Automated migration tools

Example:

Platform: Wikit 3.0 with new block API
Timeline:
 Month 0: Platform announces Wikit 3.0 (beta)
 Month 1: Playground team tests compatibility
 Month 2: Playground adapts MCP tools for 3.0
 Month 3: Platform releases Wikit 3.0 stable
 Month 3: Playground bundles Wikit 3.0
 Month 4: Old API deprecated

Testing Strategy

Cross-Compatibility Tests

javascript

// Test: Platform project exports work in Playground

describe('Project Export/Import', () => {
 it('exports from Platform and imports to Playground', async () => {
   // Export from Platform
   const platformProject = createPlatformProject();
   const exportData = platformProject.export();

   // Import to Playground
   const playgroundProject = new PlaygroundProject();
   await playgroundProject.import(exportData);

   // Verify compatibility
   expect(playgroundProject.blocks).toEqual(platformProject.blocks);
   expect(playgroundProject.posts).toEqual(platformProject.posts);
 });
});

MCP Tool Parity Tests

bash

# Automated test suite

npm run test:mcp-parity

# Tests both implementations return same results
# Platform (Python) vs Playground (Rust)

 search_codebase("hero") returns same blocks
 search_functions("register_block") finds same functions
 search_wikit_blocks() returns same count
 Vector similarity scores match within 5%

Integration Tests

bash

# Full workflow test

npm run test:integration

# Tests complete user workflows work identically
# Create project → Add blocks → Export

 Project creation creates valid WordPress
 Wikit blocks render identically
 AI assistant uses same MCP tools
 Exported projects compatible

Documentation Sync

Shared Documentation

What's Shared:

Wikit framework documentation
Block usage guides
WordPress/Wikit best practices
Code examples
Tutorial content

Location: docs/wikit/ (linked from both products)

Sync Method:

Single source of truth
Both products link to same docs
Updates apply to both

Product-Specific Documentation

Platform Docs: docs/ (platform root)

CLI reference
Docker setup
Advanced git workflows
Developer guides

Playground Docs: docs/wdg-playground/

User guide (non-technical)
Visual tutorials
Simplified workflows
FAQ for designers/PMs

Cross-References:

Platform docs link to Playground for "easier alternative"
Playground docs link to Platform for "advanced features"

Communication & Coordination

Regular Syncs

Meeting	Frequency	Attendees	Purpose
Platform-Playground Sync	Weekly	Both tech leads	Coordinate updates, discuss changes
Wikit Framework Review	Bi-weekly	All developers	Review Wikit updates, plan integration
Feature Planning	Monthly	Product + Tech leads	Align roadmaps, plan features
Parity Audit	Quarterly	QA + Tech leads	Verify parity, identify drift

Communication Channels

yaml

SlackChannels:
 - #wdg-platform: Platform development
 - #wdg-playground: Playground development
 - #platform-playground-sync: Cross-team coordination
 - #wikit-framework: Wikit discussions

GitHub:
 - Cross-repo issue linking
 - Shared project boards
 - Joint release planning

Documentation:
 - Shared Notion workspace
 - Architecture decision records (ADRs)
 - API specifications

Migration Path

For Users

Platform → Playground:

bash

# Export project from Platform
wdg export my-site --output=project.zip

# Import to Playground
# Open Playground → File → Import Project → Select project.zip
# Playground automatically converts to embedded services

Playground → Platform:

bash

# Export from Playground
# File → Export Project → Save my-site.zip

# Import to Platform
wdg import my-site.zip --create-project
# Platform converts to Docker-based project

Bi-Directional Compatibility:

Project structure identical
Database dumps compatible
wp-content portable
Git history preserved

For Developers

Working on Both:

bash

# Developer working on Wikit
cd ~/wikit-core/
git checkout -b feature/new-block

# Test in Platform
cd ~/wdg-ai-dev-environment/
wdg repo sync wikit-core

# Test in Playground
cd ~/wdg-playground/
npm run update-wikit

# Both see same changes

Success Metrics

Parity Health

Metric	Target	Measurement
MCP Tool Parity	100%	Automated tests pass
Wikit Version Lag	< 1 month	Version comparison
Shared Test Coverage	> 80%	Coverage report
Breaking Change Lead Time	> 3 months	Release notes review
Cross-Import Success	> 95%	User reports

User Satisfaction

Metric	Target	Measurement
Platform Users Aware of Playground	> 60%	Surveys
Playground Users Who Upgrade to Platform	> 10%	Telemetry
Feature Request Overlap	< 30%	Issue tracker analysis
Documentation Cross-References	100%	Doc audit

Conclusion

WDG Playground and WDG AI Development Environment are complementary products serving different audiences with shared core technology. By maintaining disciplined parity on core features (Wikit, MCP tools) while allowing each product to innovate in its domain (visual UX vs power tools), we create a stronger ecosystem where users can choose the right tool for their needs and seamlessly move between them.

Key Takeaways:

Share Wikit framework and MCP tools exactly
Adapt UX for different audiences
Test compatibility continuously
Sync updates on defined schedule
Allow product-specific innovation

Document Status: Complete Parity Strategy Review Schedule: Quarterly Related Docs: Technical Architecture, Implementation Roadmap

WDG Playground - Parity Strategy ​

Overview ​

Parity Philosophy ​

Two Products, One Foundation ​

Feature Mapping ​

Complete Parity (Must Match) ​

Adapted Features (Simplified UX) ​

Platform-Exclusive (Not in Playground) ​

Playground-Exclusive (Not in Platform) ​

Code Sharing Strategy ​

Shared Repositories ​

Shared Components ​

Update Flow ​

Platform → Playground Updates ​

Playground → Platform Feedback ​

Dependency Management ​

Version Alignment ​

Breaking Changes ​

Testing Strategy ​

Cross-Compatibility Tests ​

MCP Tool Parity Tests ​

Integration Tests ​

Documentation Sync ​

Shared Documentation ​

Product-Specific Documentation ​

Communication & Coordination ​

Regular Syncs ​

Communication Channels ​

Migration Path ​

For Users ​

For Developers ​

Success Metrics ​

Parity Health ​

User Satisfaction ​

Conclusion ​

WDG Playground - Parity Strategy

Overview

Parity Philosophy

Two Products, One Foundation

Feature Mapping

Complete Parity (Must Match)

Adapted Features (Simplified UX)

Platform-Exclusive (Not in Playground)

Playground-Exclusive (Not in Platform)

Code Sharing Strategy

Shared Repositories

Shared Components

Update Flow

Platform → Playground Updates

Playground → Platform Feedback

Dependency Management

Version Alignment

Breaking Changes

Testing Strategy

Cross-Compatibility Tests

MCP Tool Parity Tests

Integration Tests

Documentation Sync

Shared Documentation

Product-Specific Documentation

Communication & Coordination

Regular Syncs

Communication Channels

Migration Path

For Users

For Developers

Success Metrics

Parity Health

User Satisfaction

Conclusion