Repository navigation
FR Equipe Commentaires
English · Type : procédure · Public : auteur · Contexte : Studio hébergé · Statut : prête · S'applique depuis : 4.2.3
Le Studio Server (Studio d'équipe hébergé) · contrat : expérimental · vérifié par la CI (matrice de support de la 4.4.0, 2026-10-23) : Postgres, S3 et Keycloak en CI ; Chromium et Firefox (job studio-hosted) ; WebKit sous macOS, à la main seulement · vérifications automatiques : jobs
studio-hosted,studio-install-smoke; plan de CIstudioHosted; 3 fichiers de tests · passes humaines :studio-hostedpas faite (#149),studio-collabpas faite (#150),studio-previewpas faite (#166),studio-assets-hostedpas faite (#167),studio-mcp-remotepas faite (#196),studio-oidc-genericpas faite (#197) · limites connues :comments-limits
Sur un Studio d'équipe, les membres commentent ce que le jeu nomme (une salle, une porte, un objet, une règle, une case du storyboard) ou le jeu lui-même, en fils de discussion. Les commentaires sont gardés par le Studio, jamais dans un fichier du jeu : un reviewer peut donc commenter aussi.
Un fil ancré sur un identifiant stable du jeu, avec la révision où il a été écrit, auquel l'équipe répond, qu'elle
résout et rouvre ; et les anciennes notes de notes.json reprises en commentaires.
Un Studio hébergé (le Studio Server), depuis la 4.2.3. Le Studio local a des notes (notes.json), pas de commentaires.
Le code est studio-server/src/server/comments.ts.
- N'importe quel rôle : un
reviewercommente, répond et résout ses propres fils ; undevou unownerrésout n'importe quel fil ; faire entrer les notes revient à un owner (voir Rôles et actions).
Dans le Studio, l'onglet Notes, panneau Comments. Ou par l'API avec le jeton d'un membre.
-
Écrire un commentaire. Dans le champ about, tapez ce dont il parle : l'identifiant d'une salle (
hall), une entité (hall.door), un objet (item:key), un personnage (char:lou), l'identifiant d'une règle, un objectif (objective:<id>), un point de passage (checkpoint:<id>), ou l'identifiant d'une planche ou d'une case du storyboard. Laissez-le vide pour le jeu lui-même. Tapez le texte (1 à 4 000 caractères), puis Comment.
- Répondre. Sous un fil, tapez dans Reply. Un fil n'a qu'un niveau : la réponse à une réponse rejoint le même fil, sur son ancre.
- Résoudre, ou rouvrir. Resolve ferme tout le fil ; Open again le rouvre.
-
Faire entrer les notes (owner). Bring the notes in transforme chaque note de
notes.jsonen commentaire, une seule fois : sonaboutdevient l'ancre quand c'est un identifiant, sinon la note rejoint le fil du jeu, sonabouten tête du texte. Le relancer ne fait entrer que les nouvelles notes. La réponse est{imported, already}.
Par l'API :
# n'importe où, avec le jeton d'un membre
curl -H "Authorization: Bearer $TOKEN" "https://studio.example.fr/api/comments?anchor=hall.door"
curl -X POST -H "Authorization: Bearer $TOKEN" -H "content-type: application/json" \
-d '{"anchor": "hall.door", "text": "The door should creak."}' https://studio.example.fr/api/comments
curl -X PUT -H "Authorization: Bearer $TOKEN" -H "content-type: application/json" \
-d '{"resolved": true}' https://studio.example.fr/api/comments/<id>| Route | Fait |
|---|---|
GET /api/comments[?anchor=<id>] |
tous les commentaires (ou ceux d'une ancre), du plus ancien au plus récent, les 2 000 derniers au plus |
POST /api/comments {anchor?, text, parent?}
|
un commentaire, ou une réponse avec parent (201) |
PUT /api/comments/<id> {text?, resolved?}
|
son texte changé (par son auteur seulement), son fil résolu ou rouvert |
POST /api/comments/import-notes |
les notes de notes.json, chacune une fois (owner) |
Chaque commentaire a id, anchor ('' pour le jeu), rev (la révision où il a été écrit), parent, author,
text, resolved, at, edited, et orphan.
- Un commentaire garde sa révision. Il dit de quelle version du jeu il parlait.
- Orphelin, jamais déplacé. Un commentaire dont l'ancre n'est plus nommée par le jeu (une salle supprimée, un identifiant renommé) s'affiche « orphan: the game no longer names it » ; il n'est jamais rattaché ailleurs. Les ancres sont les salles, règles, scripts, entités, objectifs et points de passage du jeu, et les planches et cases du storyboard. L'identifiant d'une ligne n'est pas une ancre. Tant que le jeu ne se charge pas, aucun commentaire n'est dit orphelin.
-
Seul son auteur change son texte. Le panneau du Studio n'a pas de bouton de modification : le texte se change
par
PUT /api/comments/<id>avectext. - Un reviewer résout ses propres fils ; un dev ou un owner, n'importe lequel.
- Gardés par le Studio : dans sa base et dans ses sauvegardes, jamais dans un fichier du jeu ; aucun fichier du jeu n'est écrit, donc un commentaire ne demande aucun pan et n'est jamais refusé par une 423.
Garantie ·
comment-author-edits· référencée · portée vérifiée par son auteur (IA), pas relue Seul son auteur change le texte d'un commentaire ; un fil se résout d'un bloc ; un reviewer ne résout que ses propres fils.
Limite ·
comments-limitsUn commentaire ne peut pas être supprimé (aucune route). Un membre garde 2 000 commentaires ouverts au plus (429 au-delà : résolvez-en d'abord). La liste donne les 2 000 plus récents. Les commentaires ne sont ni dans le dépôt Git du jeu ni dans un export : ils vivent dans la base du Studio.
Le fil apparaît dans le panneau Comments de chacun, sous son ancre, avec sa révision.
GET /api/comments?anchor=<id> le liste.
| Symptôme | Cause | Correction |
|---|---|---|
a comment is a text of 1 to 4000 characters (400) |
Vide ou trop long | Raccourcissez, ou coupez-le en deux |
an anchor is a stable id of the game (letters, digits, . : @ - _) (400) |
Des espaces ou d'autres caractères dans about | Mettez l'identifiant, pas une phrase |
only its author changes a comment's text (403) |
Le commentaire de quelqu'un d'autre | Répondez plutôt |
a reviewer resolves their own threads (403) |
Un reviewer sur le fil d'un autre | Demandez à un dev |
comments are a shared Studio's (404) |
Un Studio Server sans OIDC (mode local) | Les commentaires demandent un Studio d'équipe |
Des lignes de la table studio_comments. Aucun fichier du jeu, aucune révision.
Un fil résolu par erreur se rouvre. Un texte se corrige par son auteur. Rien d'autre ne s'annule.
Generated publication · publication générée — current documentation · documentation courante: quest'n'click 4.4.0 r1, documentation revision · révision de la documentation 8dc717c69acb62c4742b69c54a7e7dfb620f75d8.
Earlier versions and permalinks · versions précédentes et liens permanents: https://wanoo.github.io/quest-n-click/docs/
An edit made in this wiki is overwritten at the next publication · une modification faite dans ce wiki est écrasée à la publication suivante.
Edit the source · Modifier la source · Report an error · Signaler une erreur
Index (6)
Démarrer (6)
Jouer (9)
Installer (17)
- Prérequis
- Installer depuis l'archive de la release
- Installer depuis npm, une fois publié
- Installer depuis le dépôt pour travailler sur le moteur
- doctor : vérifier sa machine
- Outils pour les images
- Outils audio : ffmpeg, fluidsynth, Furnace, uv
- Mettre à jour
- Notes de mise à jour : 4.4
- Notes de mise à jour : 4.3
- Notes de mise à jour : 4.2
- Notes de mise à jour : 4.1
- Notes de mise à jour : v3
- Notes de mise à jour : v2 vers v3
- Venir de web-scumm
- Référence du paquet
- Dépannage de l'installation
Créer un jeu (55)
- Votre premier jeu
- Organisation d'un projet créé et du dépôt du moteur
- La boucle de travail
- Principes du contenu et contrat d'identité
- Salles
- Géométrie : placement, zones de marche, masques, calques, caméra
- Un objet est visible mais inaccessible
- Réactions
- Commandes du jeu
- Conditions
- Drapeaux, variables et événements : lequel choisir
- Code sur mesure
- Personnages
- Objets et inventaire
- Carte du monde
- Dialogues
- Scripts et événements
- Faire bouger les personnages : patrouilles et marches
- Sorties
- Chapitres et objectifs
- État et sauvegardes : persistant ou temporaire, renommer un id, migrations
- Mise en scène : salles larges et animations
- La scène : lumières, particules, sols
- Habillage et polices
- Titre et générique
- Héros : plusieurs personnages et choix du héros
- Mini-jeux intégrés
- Un mini-jeu sur mesure
- Traductions
- Musique en stems
- Bruitages
- Voix : par langue et par héros
- Images : prompts, découpe des planches, transparence, échelle
- Provenance des assets
- Le storyboard, source de vérité
- Concevoir des énigmes
- Mécaniques classiques
- Pages de relecture
- Référence du DSL
- Vérifier son jeu
- Ce que prouve le solveur
- Options du solveur
- Playtests
- Remix
- Speedrun pour les auteurs
- La fin scellée
- Modèle de production
- Jeux d'exemple
- Travailler avec une IA
- Construire et publier un jeu
- Publier sur GitHub Pages
- Le jeu statique sur Clever Cloud
- Autres hébergeurs statiques
- Sous-chemin, cache et service worker, déploiement incomplet, retour arrière
- Tester sur un téléphone en réseau local
Studio local (24)
- Le Studio local : présentation et lancement
- Modifier une salle
- Placement et scène
- Aperçu, application, annulation
- Storyboard
- Assets et découpe
- Vérifier : validateur, solveur, chemin critique, chaleur, santé, couverture
- Captures avant et après
- Diff sémantique
- Jouer et rejouer une session
- Explication des règles
- Langue et objectifs
- Voix et matrice héros × langues
- Carte
- Notes
- Remix dans le Studio
- Musique
- L'Assistant : votre propre clé
- Mode démo et studio-apply
- Sécurité en local et en réseau local
- API du Studio
- MCP local : configurer chaque client
- Outils MCP
- Dépannage du Studio
Studio d'équipe (21)
- Ce qui tourne où
- Concepts : révision, transaction, pan, bail, aperçu, build
- Débuter comme dev invité
- Travailler ensemble au quotidien
- Rôles et actions : la matrice complète
- Invitations
- Gérer les membres
- Écriture refusée sur le Studio hébergé : révision de base périmée (409)
- Écriture refusée sur le Studio hébergé : pan verrouillé (423)
- Reprendre après un bail perdu, une déconnexion ou un aperçu périmé
- Commentaires
- Carte et diff sémantique
- Publier des builds
- MCP distant
- Le jeu dans Git
- Mettre à jour le moteur d'un jeu hébergé
- Assets hébergés
- La ligne de commande du serveur
- Routes de santé et de métriques
- L'essayer en local avec compose.yml
- Limites connues
Clever Cloud (23)
- Clever Cloud : vue d'ensemble, coût et prérequis
- Applications et add-ons
- Domaines et TLS
- Keycloak
- OIDC générique et GitLab
- Configuration
- Premier déploiement
- Sauvegardes
- RPO et RTO
- Exercice de restauration sur une installation vierge
- Redéploiements
- Mettre à jour le serveur et vérifier l'état après une migration
- Limites du retour arrière
- Supervision
- Sécurité
- Renouveler les clés
- Récupérer l'accès administrateur
- Changer de domaine ou de fournisseur OIDC
- Worker, PostgreSQL ou Cellar en panne
- Exporter le jeu et quitter l'installation
- Rétention
- Dépannage sur Clever Cloud
- Coûts et démontage
Reality Bridge et connecteurs (16)
- Le Reality Bridge : ce que c'est
- Démarrage rapide
- Garanties
- Installer et lancer le Bridge
- Sauvegarde et restauration
- Plusieurs tenants
- Signaux et manifeste
- La ligne de commande du Bridge
- Vue d'ensemble des connecteurs
- Connecteur email
- Connecteur Telnet
- Connecteur SSH
- Connecteur Open Badges
- Le SDK des connecteurs
- Sécurité : Biscuit et signatures
- Dépannage du Bridge et des connecteurs
Contribuer (25)
- Bienvenue
- Préparer son poste de développement
- La boucle de développement
- Avant une pull request
- Conventions
- Écrire la documentation
- Architecture
- Visite du code
- Frontières d'import
- Quels tests tournent quand
- Tests de mutation
- Le cliquet de couverture
- La référence de qualité
- La CI expliquée
- Passes de terrain
- Mesures de performance
- Publier une release
- Paquets npm
- Décisions et ADR
- Gouvernance
- Pull requests des bots
- Contribuer avec des agents IA
- Politique de sécurité
- Code de conduite
- Licences et crédits