État des plugins
La version de production actuelle n'expose pas de capacités de plugins. Le Worker rejette /api/plugins/*, le panneau n'a aucune entrée de téléversement de plugins, et GET /api/v1 n'annonce aucun runtime de plugins.
Alternatives fonctionnelles
- Ajuster uniquement le visuel de la page d'état d'origine : développez un thème CSS.
- Réécrire entièrement la mise en page de la page publique : développez un thème Canvas.
- Fournir un panneau supplémentaire sur un domaine séparé : construisez un frontend alternatif contre l'API publique v1 et faites configurer une liste d'autorisation
DEVELOPER_API_ORIGINSexacte par le déployeur.
Ne construisez ni ne distribuez de ZIP type: "plugin", et ne vous fiez pas à /api/plugins/upload, aux manifests de plugins ni aux protocoles de messages de plugins des anciens tutoriels ; ces interfaces n'ont jamais fait partie des capacités de production actuelles.
Un ancien schéma nstatus-extension-v1 dans un manifest de thème ou l'en-tête hérité x-extension-sha256 n'impliquent pas non plus un support de plugins. Le Worker exige toujours type: "theme", et les thèmes Canvas ne peuvent déclarer que status:read.
Les frontends alternatifs ne lisent que l'API publique sans identifiants. Ne demandez pas de sessions admin, mots de passe, TOTP, Token maître Agent ni jetons scoped de nœud, et n'acceptez pas de téléversements de scripts exécutables.