WordPress en tant que cible de déploiement pour Claude Code, Cursor et Codex.

Comment y penser

WordPress en tant que runtime, comme Chrome exécute les extensions ou Figma exécute les plugins.

DesignSetGo Apps est une extension WordPress. Les applications que vous déployez via celle-ci ne sont pas des extensions. Ce sont des bundles statiques bac-à-sablés (HTML, JS, CSS, WASM) plus un manifeste dsgo-app.json. Le runtime les charge, les met en bac à sable, et leur fournit des données WordPress via un pont typé. L'application ne voit jamais un jeton REST.

Le changement en une ligne : tout ce que vous distribuiez autrefois comme plugin WordPress avec une confiance totale (une calculatrice, un portail, un tableau de bord, un outil AI) devient un bundle en sandbox avec des permissions déclarées. La catégorie survit. Le modèle de sécurité se retourne.

La boucle

De l'initialisation à la mise en ligne en trois commandes.

La CLI génère par défaut un démarrage minimal, ou un démarrage Astro avec --astro pour les applications multi-pages. N'importe quel bundle statique fonctionne. Elle s'authentifie avec un mot de passe d'application WordPress et pousse le bundle ; chaque déploiement suivant est une mise à jour atomique au même id d'application.

Le client du pont

Pas de plomberie REST. Pas de boilerplate d'authentification.

Le package @designsetgo/app-client vous donne un accès typé à votre site WordPress. Même surface en mode inline (même fenêtre) et mode iframe (cross-frame) ; le transport est sélectionné automatiquement.

// Read posts, pages, the current user, and per-app storage.
// The bridge handles auth + REST behind the scenes.

import { dsgo } from "@designsetgo/app-client";
await dsgo.ready;

// Site context
const site = await dsgo.site.info();

// Real posts, filtered by what the current user can see
const { posts } = await dsgo.posts.list({
    type: "recipe",
    orderby: "date",
    order: "desc",
    per_page: 10,
});

// Logged-in user, and what they're allowed to do
const me = await dsgo.user.current();
if (await dsgo.user.can("edit_posts")) {
    // show the editor-only UI
}

// Per-app, per-user persistent storage; survives reloads
await dsgo.storage.user.set("favourites", [42, 88]);

Ce que votre agent IA voit

Un AGENTS.md et un CLAUDE.md dans chaque démarrage.

Le starter inclut un manuel d'extension complet à la racine du projet. AGENTS.md est le fichier canonique indépendant de tout fournisseur ; Codex, Cursor, Aider et tout outil respectant la convention agents.md la lisent directement. CLAUDE.md @-importe AGENTS.md en une ligne afin que Claude Code récupère le même contenu sans duplication ni dérive.

Pack de skills pour agents

Enseigner le bridge à l'agent avant le projet existe.

AGENTS.md répond à l'agent une fois qu'il se trouve à l'intérieur d'un projet DSGo. Le pack de skills DSGo le guide en amont : installé au niveau utilisateur, l'agent connaît déjà le schéma manifest, chaque méthode dsgo.*, et la boucle CLI avant que apps init s'exécute.

npx skills add DesignSetGo/skills

• building-dsgo-apps Mise en place, le choix entre inline et iframe, structure du projet.
• dsgo-manifest Chaque champ de dsgo-app.json : routes, permissions, secrets, tâches planifiées, webhooks.
• dsgo-bridge-api Chaque méthode dsgo.*, son contrôle d'autorisation, la structure de ses codes d'erreur.
• deploying-dsgo-apps La boucle @designsetgo/cli, les déploiements en prévisualisation, intégration continue avec authentification par variables d'environnement.
• dsgo-abilities Publication des capacités vers le site, consommation des capacités, appel d'outils dsgo.ai.prompt.

Modes d'isolation

Inline pour les pages indexables. Iframe pour les artefacts clés en main.

Même format de bundle, même bridge, rendu différent. Les apps déclarent celui souhaité dans le manifest. Consultez Comment ça fonctionne pour les détails des compromis.