Repository navigation
FR Bridge CLI
English · Type : référence · Public : administrateur · Contexte : Reality Bridge · Statut : prête · S'applique depuis : 4.3.0
Le Reality Bridge, profil
local(SQLite) · contrat : stable · vérifié par la CI (matrice de support de la 4.4.0, 2026-10-23) : Node 22.13+ avec node:sqlite, sous Ubuntu ; Chromium et WebKit de bout en bout · vérifications automatiques : jobsreality,reality-xcheck; plan de CIreality; 2 fichiers de tests · passes humaines : aucune · limites connues :bridge-init-store-urlLe Reality Bridge, profil
distributed(Postgres) · contrat : expérimental · vérifié par la CI (matrice de support de la 4.4.0, 2026-10-23) : Postgres 16 en CI ; Le profil de qualification : HTTPS, trois instances (ops/qualify/) · vérifications automatiques : jobsbridge-postgres,deployment-smoke; plan de CIreality; 1 fichier de tests · passes humaines :bridge-postgres-httpspas faite (#77) · limites connues :bridge-init-store-url
Chaque sous-commande du Reality Bridge de référence, avec ses options, ses valeurs par défaut, sa sortie et ses codes
de sortie, lus dans bridge/src/cli.ts et bridge/src/cli-store.ts. Comment les enchaîner :
Installer et lancer le Bridge.
fonction apparue en 4.1.1
| Où | Commande |
|---|---|
| Le dépôt du moteur |
npm run bridge -- <sous-commande> [options] (le jeu courant, ou GAME=<id>) |
| Un projet créé |
npx quest-n-click bridge <sous-commande> [options] (il faut quest-n-click-bridge installé à côté du moteur) |
| Le paquet autonome | npx quest-n-click-bridge <sous-commande> [options] |
Une option s’écrit --nom=valeur ou --nom valeur. Chaque sous-commande prend --dir=<dossier>, le dossier du
Bridge qui contient config.json, .cache/bridge par défaut (relatif au dossier courant).
Sous-commandes : init, serve, grant, rotate, revoke, doctor, compact, migrate, tenant, backup,
restore. Le stockage sur lequel travaille une commande est, le premier trouvé : --store=, la variable
BRIDGE_STORE, le fichier nommé par BRIDGE_STORE_FILE, le store de config.json, sinon le journal (jsonl). Un
stockage s’écrit jsonl, sqlite (le fichier bridge.sqlite à côté de config.json), sqlite:<fichier> (relatif au
dossier du Bridge) ou postgres://….
Une autre sous-commande affiche usage: quest-n-click-bridge <init|serve|grant|rotate|revoke|doctor|compact|migrate|tenant|backup|restore>
et sort avec le code 2. Hors du dépôt du moteur, sans le paquet : ✖ the Reality Bridge is a separate package: npm install quest-n-click-bridge, code 1.
# dans le dépôt du moteur
GAME=signals npm run bridge -- doctorUne option qu’aucune sous-commande ne lit est ignorée.
4.1.1 (init, serve, grant, rotate, revoke) ; doctor et compact en 4.1.2 ; migrate, tenant,
backup, restore en 4.1.10 ; les deux modes de restauration en 4.1.20 ; le nom quest-n-click-bridge en 4.2.5.
fonction apparue en 4.1.1
init [--dir=.cache/bridge] [--manifest=<fichier>] [--audience=bridge.local] [--origin=<url>,…] [--no-demo-webhooks] [--demo-days=30] [--store=sqlite|sqlite:<fichier>] [--tenant=<id>] [--environment=prod|staging|dev] [--hosts=<hôte>,…] [--signal-version=2] [--force]
Crée les clés et la configuration d’un tenant, sous --dir, en mode 600 : config.json, root.key (la moitié privée
de la racine Biscuit, pour grant seulement), admin-token (le jeton de l’opérateur, seule copie en clair).
-
--manifest: le manifeste construit du jeu (dist/reality-manifest.json) ; sans lui, le contenu du jeu courant. -
--audience: qui est le Bridge dans les jetons de ses connecteurs (bridge.local). -
--origin: les sites du jeu, pour CORS (http://127.0.0.1:5173,http://localhost:5173). - Un webhook de démonstration par source des signaux du jeu, sauf avec
--no-demo-webhooks, chacun avec son secret et un jeton qui peut envoyer n’importe quel signal de cette source pour n’importe quel joueur et confirmer des appairages, pendant--demo-daysjours. -
--store:sqliteécritsqlite:bridge.sqlite; absent, le journal (journal.jsonl). -
--tenant,--environment(prodsi absent),--hosts: pour plusieurs tenants.--signal-version=2: un tenant seul signe desWorldSignalV2.
Affiche les chemins écrits et les routes des webhooks, jamais un secret. Code 0.
-
✖ the game declares no reality.signals: nothing to bridge, code 1. -
✖ <dir>/config.json exists (--force replaces it, and every key and token with it), code 1.
Limite ·
bridge-init-store-url--storeest écrit dansconfig.jsontel quel. Ne passez jamais àinitune URL Postgres avec son mot de passe : donnez-la àserveet aux autres commandes parBRIDGE_STOREouBRIDGE_STORE_FILE, qui ne sont jamais écrits.
# dans le dépôt du moteur
npm run bridge -- init --store=sqlite --no-demo-webhooks --origin=https://game.example.orgIgnoré.
4.1.1 ; --store, --tenant, --environment, --hosts, --signal-version en 4.1.10.
fonction apparue en 4.1.1
serve [--dir=…] [--tenants=<dossier>,<dossier>] [--store=…] [--port=8787] [--host=127.0.0.1] [--trust-proxy[=<proxy>,…]] [--tenant-header]
Sert le Bridge en HTTP jusqu’à SIGINT ou SIGTERM, puis termine les flux, ferme le serveur, libère le stockage et ses
verrous (cinq secondes au plus) et sort avec le code 0. Il journalise des lignes JSON sur la sortie standard, la
première {"event":"bridge.listening","url":…,"game":…,"tenants":…,"store":…,"pid":…}.
-
--tenants: un dossier par tenant, tous sur un stockage SQL. -
--trust-proxyseul fait confiance à la boucle locale ; avec une liste, à ces adresses ou réseaux IPv4. -
--tenant-header: une requête peut nommer son tenant dansX-Web-Scumm-Tenant. - Les variables
BRIDGE_STORE,BRIDGE_STORE_FILEetOTEL_EXPORTER_OTLP_ENDPOINT.
Code 1, dit sur la sortie d’erreur, quand : deux dossiers configurent un même tenant ; plusieurs tenants sur le
journal ; une section runs ou daily sur le journal ; un fichier de jeton de modération absent, ouvert aux autres
ou de moins de 32 caractères ; un bail de maintenance refuse le stockage (✖ … : not serving). Il refuse de démarrer
sur un autre manifeste que celui configuré, sur une limite qui n’en est pas une (limits), et sur un
journal qu’un autre processus vivant tient.
# dans le dépôt du moteur
npm run bridge -- serve --port=8787 --host=127.0.0.1 --trust-proxyIgnoré.
4.1.1 ; --tenants, --tenant-header, --trust-proxy=<liste> en 4.1.10 ; le bail serving en 4.1.20.
fonction apparue en 4.1.1
grant --connector=<id> --source=<source> --signals=<a>,<b> [--players=any|p-…,p-…] [--pair] [--days=30] [--dir=…]
Fabrique le jeton Biscuit d’un connecteur à partir de root.key et l’affiche sur la sortie standard, sur une ligne :
redirigez-la vers un fichier. Le jeton nomme le jeu, la source, les signaux, les joueurs (any, n’importe quel joueur
du jeu, par défaut), l’audience du Bridge, le tenant du dossier, et une expiration dans --days jours (à la seconde ;
refusé à partir de cette seconde). --pair lui permet de confirmer des codes d’appairage. Code 0.
root.key doit être dans le dossier (ou le champ de la configuration de la 4.1.1) : <dir>/root.key is missing: the root key signs connector tokens, and nothing else can. Ne donnez à chaque connecteur que les signaux qu’il propose.
Un connecteur peut atténuer son propre jeton (moins de joueurs, une expiration plus proche) avant de le transmettre ;
il ne peut jamais l’élargir.
# dans le dépôt du moteur
npm run bridge -- grant --connector=shed-telnet --source=terminal --signals=terminal.lamp --pair > telnet.tokenIgnoré.
4.1.1 ; lié à son tenant depuis la 4.1.10.
fonction apparue en 4.1.1
rotate [--keep-days=30] [--dir=…]
Crée une nouvelle clé de signature des événements, garde l’actuelle dans previousKeys pendant --keep-days jours,
réécrit config.json et affiche ✔ new event key k-…; the previous one trusted until <date> (restart the Bridge).
Code 0. Elle prend effet au redémarrage du Bridge. Pourquoi et quand : Sécurité.
Aucune au-delà d’un config.json lisible.
# dans le dépôt du moteur
npm run bridge -- rotate --keep-days=30Ignoré.
4.1.1 ; ce qui attend un joueur est re-signé sous la nouvelle clé depuis la 4.1.2.
fonction apparue en 4.1.1
revoke [--url=http://127.0.0.1:8787/] (--player=<p-…> | --token=<id de révocation>) [--dir=…]
Demande au Bridge en marche de révoquer le lien d’un joueur, ou le jeton d’un connecteur par n’importe lequel de ses
identifiants de révocation (hexadécimaux), avec le jeton de l’opérateur lu dans <dir>/admin-token
(POST /v1/admin/revoke). Affiche ✔ revoked, code 0 ; sinon ✖ <statut> <réponse>, code 1.
Le Bridge doit tourner et être joignable à --url. Avec plusieurs tenants, le nom d’hôte de l’URL choisit le tenant.
# dans le dépôt du moteur
npm run bridge -- revoke --url=https://bridge.example.org/ --player=p-0123456789abcdefIgnoré.
4.1.1.
fonction apparue en 4.1.2
doctor [--dir=…] [--store=…]
Lit le stockage sans le modifier. Sur le journal : une ligne {"event":"journal","lines":…,"players":…,"signals":…, "torn":…}, puis ✔ journal readable, ou ⚠ quand la dernière ligne a été coupée par un plantage (serve la retire
et le dit). Sur un stockage SQL : {"event":"store","kind":…,"schema":…,"tenants":[{tenant, players, signals, gaps, quarantined}]}, une ligne ⚠ quarantined: … par ligne en quarantaine, puis ✔ sqlite store readable (schema 5).
Code 1 quand le journal contient une ligne corrompue (✖ <quoi>: the Bridge will not start on it), ou quand la
séquence d’un joueur a un trou (✖ a player has a gap in its sequence).
# dans le dépôt du moteur
npm run bridge -- doctorIgnoré.
4.1.2 ; chaque champ d’une ligne du journal vérifié en 4.1.8 ; les stockages SQL en 4.1.10.
fonction apparue en 4.1.2
compact [--retention-days=90] [--dir=…], le Bridge arrêté.
Réécrit le journal sans les appairages échus, les versions antérieures de la ligne d’un joueur, et les signaux
acquittés plus vieux que la rétention. Le dernier signal d’un joueur et tout ce qui n’est pas encore acquitté restent.
Affiche ✔ journal compacted: <avant> → <après> lines (…).
Elle prend le verrou du journal, donc refuse tant qu’un Bridge tourne. Sur un stockage SQL : ✖ compact rewrites the JSON-lines journal; a SQL store keeps every signal in 4.1.10 (no retention yet), code 1.
# dans le dépôt du moteur, le Bridge arrêté
npm run bridge -- compact --retention-days=90Ignoré.
4.1.2 ; sous le verrou du journal en 4.1.8.
fonction apparue en 4.1.10
migrate --from=jsonl --to=sqlite[:<fichier>]|postgres://… [--tenant=<id>] [--no-config], ou
migrate [--schema=N] [--lock-timeout=30000].
- Depuis le journal, le Bridge arrêté : le lit sous son verrou, écrit chaque joueur, signal, accusé de réception et
révocation dans la cible comme un seul tenant (
default, ou--tenant), les relit, puis nomme le nouveau stockage dansconfig.json(pas pour une URL, ni avec--no-config). Le journal est gardé tel quel. Affiche✔ <n> players and <m> signals moved to <stockage> as tenant <id>; the journal is kept as it was. - Le schéma SQL : jusqu’au plus récent (
✔ schema 5 (nothing to do)), ou jusqu’à--schema=N, vers le haut ou vers le bas (--schema=0défait tout). Vers le bas, elle prend le bail de maintenance exclusif ; vers le haut, un bailserving.
-
✖ the target already holds the tenant <id>: nothing written, code 1. -
✖ the target does not hold what was written: the configuration is left on the journal, code 1. -
✖ the JSON-lines journal has no schema: migrate --from=jsonl --to=sqlite moves it, code 1. - Un bail refusé :
✖ <qui le tient>; nothing migrated, code 1. Un mauvais--lock-timeoutou un mauvais usage : code 2. - Une base plus récente que le Bridge est refusée. En dessous du schéma 5 il n’y a pas de table des baux : arrêtez tout écrivain.
# dans le dépôt du moteur, le Bridge arrêté
npm run bridge -- migrate --from=jsonl --to=sqliteIgnoré.
4.1.10 ; les baux en 4.1.20.
fonction apparue en 4.1.10
tenant export --tenant=<id> [--out=<fichier>] · tenant delete --tenant=<id> --yes
export écrit toutes les lignes d’un tenant, dans chaque table, en JSON : dans --out (mode 600) ou sur la sortie
standard. delete les supprime. --tenant vaut par défaut le tenant du dossier (default).
delete sans --yes : ✖ deleting the tenant <id> removes every row it has: add --yes, code 1. Une autre
sous-sous-commande : l’usage, code 2.
# dans le dépôt du moteur
npm run bridge -- tenant export --tenant=a --out=tenant-a.jsonIgnoré.
4.1.10.
fonction apparue en 4.1.10
backup --out=<fichier> [--max-bytes=268435456] [--max-rows=2000000]
Écrit le stockage entier en un seul instantané, schéma 4, dans --out (mode 600, un fichier temporaire renommé).
Affiche les comptes, le schéma et le début du SHA-256. Code 0. La procédure, le contenu du fichier et la mémoire qu’il
faut : Sauvegarde et restauration.
Sans --out : l’usage, code 2. Une borne qui n’est pas un entier positif : code 2. Un stockage au-delà de
--max-rows, ou un fichier au-delà de --max-bytes : ✖ … : no file written, code 1.
# dans le dépôt du moteur
npm run bridge -- backup --out=bridge.jsonIgnoré.
4.1.10 ; un seul instantané (schéma 3) en 4.1.19 ; le schéma 4 en 4.1.20.
fonction apparue en 4.1.10
restore --from=<fichier> --mode=merge [--force] [--max-bytes=<n>] [--lock-timeout=<ms>]
restore --from=<fichier> --mode=replace-store --yes-replace-store --safety-out=<nouveau fichier> [--max-bytes=<n>] [--max-rows=<n>] [--lock-timeout=<ms>]
Tout ou rien, dans le mode que vous nommez : merge garde ce dont le fichier ne parle pas ; replace-store fait du
stockage le fichier, après une sauvegarde de sécurité. Le fichier est vérifié en entier avant l’ouverture du stockage,
écrit dans une transaction, comparé avant la validation et audité après. --lock-timeout : combien de temps le verrou
consultatif Postgres est essayé (30 000 ms).
| Code | Quand |
|---|---|
| 0 | Restauré et vérifié |
| 1 | Refusé ou échoué, nothing restored (un conflit, un fichier refusé, le journal, un bail tenu, une sauvegarde de sécurité impossible à écrire) |
| 2 | Usage : pas de --mode, --force avec replace-store, --safety-out ou --yes-replace-store avec merge, une confirmation ou un chemin de sécurité manquant, une mauvaise borne |
| 3 | Une différence trouvée après la validation (P0), ou la réponse de la validation perdue |
# dans le dépôt du moteur, chaque Bridge sur ce stockage arrêté
npm run bridge -- restore --from=bridge.json --mode=mergeIgnoré. Un fichier avec un champ inconnu est refusé (schémas stricts).
4.1.10 ; tout ou rien en 4.1.19 ; les modes en 4.1.20.
S'applique depuis la 4.3.0 · fonction apparue en 4.1.1
Un objet d’entiers dans le config.json d’un tenant, "limits": { "perMinutePerConnector": 240 }. Chaque nom absent
garde sa valeur par défaut.
| Limite | Défaut | Minimum |
|---|---|---|
bodyBytes : le corps d’une requête, en octets |
8 192 | 1 |
perMinutePerConnector : signaux qu’un connecteur peut proposer par minute, par instance |
120 | 0 |
pendingPerPlayer : signaux en attente de l’accusé de réception d’un joueur |
1 000 | 0 |
pairingMs : combien de temps attend un code d’appairage |
600 000 (10 min) | 0 |
capabilityMs : la vie d’une capacité sans accusé de réception |
2 592 000 000 (30 jours) | 0 |
capabilityMaxMs : la vie la plus longue d’une capacité, renouvellements compris |
15 552 000 000 (180 jours) | 0 |
streamsPerPlayer : flux d’événements ouverts par joueur |
4 | 0 |
streamsPerInstance : flux d’événements ouverts sur une instance |
10 000 | 0 |
streamBufferBytes : octets qu’un flux peut garder non envoyés |
65 536 | 1 |
pendingPairings : codes en attente de confirmation, tous joueurs confondus |
1 000 | 0 |
resignedCache : signaux re-signés après une rotation, gardés en mémoire |
10 000 | 0 |
streamPage : signaux qu’un flux lit d’un coup dans le stockage |
100 | 1 |
Depuis la 4.3.0, le Bridge les vérifie avant de démarrer : limits.<nom> must be an integer of at least <n>, not <valeur>, ou limits.<nom> is no limit of the Bridge (<les noms>). Sur un Bridge partagé, la mauvaise limite d’un
tenant arrête tous les tenants : lisez les Notes de mise à jour 4.3 avant de mettre à
jour.
"limits": { "perMinutePerConnector": 240, "pendingPerPlayer": 2000 }Refusé (depuis la 4.3.0).
4.1.1 ; vérifiées depuis la 4.3.0.
fonction apparue en 4.1.9
Cinq endroits, dans cet ordre :
- Sur le Bridge :
DELETE /v1/admin/players/<id>avec le jeton de l’opérateur (le lien, les signaux, les accusés de réception).GETsur la même route les exporte d’abord. - Dans une boîte IMAP : supprimer les messages signalés du joueur, s’il y en a (ceux acceptés sont déjà partis avec
keepDays: 0). - Dans la configuration du connecteur SSH : retirer la clé déclarée du joueur, s’il y en a une, et redémarrer le connecteur.
- En mémoire (expéditeurs d’e-mail liés par un code d’appairage, mots de reprise Telnet et SSH) : redémarrer les connecteurs les oublie tous.
- Sur l’appareil : le joueur efface la sauvegarde ou les données du site.
DELETE répond 204 ; un joueur inconnu, 404.
Le jeton de l’opérateur (admin-token). Les fichiers de sauvegarde déjà écrits contiennent encore le joueur : c’est à
vous de les faire expirer.
# sur la machine du Bridge, dans le dépôt du moteur
curl -s -X DELETE -H "Authorization: Bearer $(cat .cache/bridge/admin-token)" https://bridge.example.org/v1/admin/players/p-0123456789abcdefLa route prend un p- et 16 chiffres hexadécimaux ; tout le reste est une 404.
La route du Bridge en 4.1.1 ; la partie des connecteurs en 4.1.9. Ce que garde chaque endroit : Vie privée.
-
npm run connector(quest-n-click-connector) : Vue d’ensemble des connecteurs. -
npm run bridge:load(troisservesur un stockage, sous charge ;docs/dev/BENCH-BRIDGE.md) : Bancs d’essai. -
npm run ops:qualify: Le déploiement de référence. - Les autres CLI du projet : CLI.
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