Projects vs Platform

This is the single most important mental model in the WDG AI Development Environment. Almost every decision about where code goes, which language to use, which AI configs apply, and which collection to search comes back to this boundary.

There are two distinct contexts:

	PLATFORM	PROJECT
What it is	The infrastructure that runs everything	An individual WordPress site
Languages	Python, JavaScript/React, Bash	PHP / WordPress
Lives in	Repository root (mcp-server/, indexer/, cli/, dashboard/, services/)	projects/{name}/repositories/{repo}/
Examples	MCP server, code indexer, the wdg CLI, Docker orchestration	A client's theme, custom post types, blocks, plugins
Vector collection	platform (and wdg_framework for Wikit)	project_{name}
AI configs	Root CLAUDE.md, .claude/skills/, .claude/agents/	Per-repo .claude/ inside the project

Why the boundary matters

The platform is shared infrastructure used across every client site. A project is one client's WordPress installation. Mixing them causes real problems:

• Editing platform code while "working on a project" can break every project at once.
• Editing the Wikit framework to fix one site breaks the extend-never-modify contract and makes the fix impossible to carry forward.
• Searching the wrong collection returns code from the wrong context — platform Python when you wanted project PHP, or one client's code when you meant another's.

The platform CLAUDE.md states it directly: PLATFORM is infrastructure (MCP server, CLI, Docker, indexing) in Python/JavaScript/Bash; PROJECT is the individual WordPress sites in projects/{name}/repositories/, written in PHP/WordPress, each with separate AI configs.

Where each lives on disk

wdg-ai-development-environment/        ← PLATFORM root
├── mcp-server/                        ← Platform: FastMCP server (Python)
├── indexer/                           ← Platform: code indexing (Python)
├── cli/                               ← Platform: wdg CLI (Bash)
│   └── templates/                     ← Templates distributed INTO projects
│       ├── project-skills/            ← Skill templates → projects
│       └── project-agents/            ← Agent templates → projects
├── dashboard/                         ← Platform: web dashboard (React + Flask)
├── services/                          ← Platform: Docker service configs
├── repositories/                      ← Wikit framework (core, theme, facets, app)
├── .claude/
│   ├── skills/                        ← PLATFORM skills
│   └── agents/                        ← PLATFORM agents
└── projects/
    └── {name}/
        └── repositories/
            └── {repo}/                ← PROJECT code (PHP/WordPress)
                └── .claude/
                    ├── skills/        ← PROJECT skills (synced from templates)
                    └── agents/        ← PROJECT agents (synced from templates)

The platform's .claude/ directory configures the AI instance that builds and maintains the platform itself. Each project's .claude/ directory configures the AI instance that builds that one WordPress site.

💡 TIP

The cli/templates/project-skills/ and cli/templates/project-agents/ directories are not themselves project configs — they are the source templates the platform distributes into projects. See Skills and Agents.

How AI configs are scoped

Four kinds of AI configuration are scoped differently depending on context:

CLAUDE.md

• Platform: the root CLAUDE.md defines the operating protocols, platform identity, and decision framework for platform work.
• Project: each project repository gets its own CLAUDE.md, synced from platform templates via wdg ai-config sync, oriented toward WordPress/Wikit development.

Skills

• Platform skills (.claude/skills/) are available to the platform Claude instance immediately — they cover infrastructure and cross-project tooling.
• Project skills are distributed from cli/templates/project-skills/ into each project via wdg create (or wdg <project> skills sync), landing in projects/{name}/repositories/{repo}/.claude/skills/.

Agents

• Platform agents (.claude/agents/) specialize in platform infrastructure and WDG-wide concerns.
• Project agents are distributed from cli/templates/project-agents/ into each project's .claude/agents/ via wdg ai-config sync.

MCP collections

The vector database is partitioned so each context searches only what it should:

Collection	Contents	Used by
platform	MCP server, CLI, indexer, Docker configs	Platform work
wdg_framework	Wikit framework (blocks, core classes, theme utilities, facets)	Both — framework is shared
project_{name}	One project's custom code (CPTs, theme customizations)	That project only

Projects cannot search each other's code; the framework collection is available to all. Scope searches with the project parameter — "platform" for CLI/MCP/indexer, "wdg_framework" for Wikit, or "project_{name}" for a specific site.

Quick decision guide

Ask these questions when you start work:

1. Am I changing infrastructure or a WordPress site? Infrastructure → platform. A site → project.
2. What language is the change in? Python/JS/Bash → platform. PHP/WordPress → project.
3. Which directory does the file live in? Root subdirs → platform. projects/{name}/repositories/{repo}/ → project.
4. Which collection should I search? platform for infra, project_{name} for site code, wdg_framework for Wikit.

If a change would affect every client site at once, you are in platform territory and should treat it accordingly.

See also

• Core Concepts — projects, repositories, collections, and isolation
• Skills — platform skills vs project skill templates
• Agents — platform agents vs project agent templates
• MCP Server — semantic search across collections