Repository navigation
EN Contribute Bot Pull Requests
Français · Type: how-to · Audience: contributor · Context: engine repository · Status: ready · Applies from: 4.4.0
How the maintainer, or an assistant working for them, handles the pull requests Dependabot opens: when, how to judge each one, and what to do with a red one.
No bot pull request left open without a reason: each one merged on green, fixed and taken, or closed with its reason written, and the dependency it moves checked across the places that copy it (package locks, the worker's Python lock, action pins).
The engine repository on GitHub, wanoo/quest-n-click. .github/dependabot.yml as of 4.4.0: npm every week (minor
and patch updates grouped as minor-and-patch), GitHub Actions every week, pip (requirements.txt) every month.
@types/node majors are ignored: the types follow the oldest Node the project supports (22.12, engines), and Node
26's types reject code that is right on 22 (#101, 4.1.19); they are raised by hand when engines moves.
- Write access to the repository and the GitHub CLI (
gh), logged in. - A prepared clone: Developer setup.
- No release in progress (next step).
gh commands anywhere; checks in the engine repository, on a branch made for the bot updates.
-
Wait for the release to be out. Bot pull requests are handled after each release, never in the middle of one.
release.ymlrunsmain's copy of its workflow while it releases a tag, and a bot update of an action it uses would change the release run under way; the 4.1.19 release waited this way for #95–#102 (LOG #169).
-
List them, with their checks.
# anywhere, with gh logged in gh pr list -R wanoo/quest-n-click --author app/dependabot gh pr checks <number> -R wanoo/quest-n-click
- Merge a green one whose change you have read (the release notes of the dependency, the lockfile diff). Several at once may go through one branch instead of one CI cycle each: merge their commits into it, run CI once, then close each bot pull request with a pointer to the branch (LOG #169 did seven this way).
-
A red one is fixed or closed, never left. Reproduce the failure locally first. When the update is right and a
test or our code must follow, fix it on the branch (Playwright 1.64 made WebKit print a test's deliberate 500, and
the PWA test learned to excuse exactly that response). When the update is wrong for the project, close it with the
reason written on the pull request: Vite 8 (its bundler broke a CommonJS default import, the game did not start),
TypeScript 7 (no
baseUrl, no non-relativepaths), raised pip minimums that broke a shared Python (NumPy 2.5),@types/node26.
-
Follow the copies of the version. Some dependencies are pinned elsewhere too:
- the packages' own locks under
scripts/locks/(the Bridge, the connectors, the Studio Server, the Bridge image): runnpm run lockswhen a dependency of those packages changes, review the diff, commit it;npm run locks -- --checksays whether each lock still fits; - the Studio worker's Python lock, which follows
requirements.txtwith its hashes (Pillow 13.0.0, #213:tests/worker-python-lock.test.ts); - an action's pin: check the new SHA against the official tag (
gh api repos/<owner>/<action>/git/ref/tags/<tag>).
- the packages' own locks under
-
An update of an action used by
release.ymlorcandidate.ymlis only proved by the next candidate and release run: label the branchfull-ci(it also runs the candidate workflow, as information) and say in the pull request what remains to be seen.
Limit ·
no-auto-mergeNothing merges a bot pull request by itself: no auto-merge is configured. A pull request that waits is a decision not taken, not a decision.
gh pr list -R wanoo/quest-n-click --author app/dependabot lists nothing, or only pull requests opened since the last
release. main is green after the merges.
| Symptom | Cause | Fix |
|---|---|---|
A bot PR red only on pwa-firefox or a WebKit row |
A known flake (CI explained) | Re-run the job; reproduce before blaming the update |
tests/pack-locks.test.ts fails after a merge |
A package's lock under scripts/locks/ no longer fits |
npm run locks, review, commit |
Type errors after a @types/node major |
Types newer than the supported Node | Close it; dependabot.yml already ignores those majors |
package.json, package-lock.json, requirements.txt, .github/workflows/*.yml (action pins), scripts/locks/*.json,
the worker's Python lock. A code change that follows an update carries its changes/ fragment
(Conventions).
A merged update is reverted by a pull request that reverts its commit (git revert), with the reason; Dependabot then
proposes it again unless it is ignored in .github/dependabot.yml.
-
.github/dependabot.yml,docs/dev/LOG.md(#169, the pull requests of 11 October 2026). - CI explained, Releasing, npm packages.
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)
Start (6)
Play (9)
Install (17)
- Requirements
- Install from the release archive
- Install from npm, once published
- Install from the repository to work on the engine
- doctor: checking your machine
- Image toolchain
- Audio toolchain: ffmpeg, fluidsynth, Furnace, uv
- Upgrade
- Upgrade notes: 4.4
- Upgrade notes: 4.3
- Upgrade notes: 4.2
- Upgrade notes: 4.1
- Upgrade notes: v3
- Upgrade notes: v2 to v3
- Coming from web-scumm
- Package reference
- Install troubleshooting
Create a game (55)
- Your first game
- Layout of a created project and of the engine repository
- The working loop
- Content principles and the identity contract
- Rooms
- Geometry: placement, walk zones, masks, layers, camera
- Something is visible but unreachable
- Reactions
- Game commands
- Conditions
- Flags, variables and events: which to use
- Custom code
- Characters
- Items and inventory
- World map
- Dialogues
- Scripts and events
- Moving characters: patrols and walks
- Exits
- Chapters and objectives
- State and saves: persistent or temporary, renaming an id, migrations
- Staging: wide rooms and animations
- The stage: lights, particles, floors
- Skin and fonts
- Title and credits
- Heroes: several characters and hero choice
- Built-in minigames
- A custom minigame
- Translations
- Music in stems
- Sound effects
- Voices: per language and per hero
- Images: prompts, cutting sheets, transparency, scale
- Asset provenance
- The storyboard, source of truth
- Puzzle design
- Classic mechanics
- Review pages
- DSL reference
- Checking your game
- What the solver proves
- Solver options
- Playtests
- Remix
- Speedrun for authors
- The sealed ending
- Production template
- Example games
- Working with an AI
- Build and release a game
- Publish on GitHub Pages
- The static game on Clever Cloud
- Other static hosts
- Sub-path, cache and service worker, incomplete deploys, going back
- Testing on a phone over the LAN
Local Studio (24)
- The local Studio: overview and launch
- Edit a room
- Placement and stage
- Preview, apply, undo
- Storyboard
- Assets and cutting
- Check: validator, solver, critical path, heat, health, coverage
- Before and after captures
- Semantic diff
- Play and replay a session
- Rule explainer
- Language and objectives
- Voices and the heroes × languages matrix
- Map
- Notes
- Remix in the Studio
- Music
- The Assistant: bring your own key
- Demo mode and studio-apply
- Local and LAN security
- Studio API
- Local MCP: setting up each client
- MCP tools
- Studio troubleshooting
Team Studio (21)
- What runs where
- Concepts: revision, transaction, span, lease, preview, build
- Starting as an invited dev
- Working together day to day
- Roles and actions: the full matrix
- Invitations
- Managing members
- Write refused on the hosted Studio: stale base revision (409)
- Write refused on the hosted Studio: span locked (423)
- Recovering after a lost lease, a disconnection or a stale preview
- Comments
- Map and semantic diff
- Publishing builds
- Remote MCP
- The game in Git
- Upgrading the engine of a hosted game
- Hosted assets
- The server's command line
- Health and metrics routes
- Trying it locally with compose.yml
- Known limits
Clever Cloud (23)
- Clever Cloud: overview, cost and prerequisites
- Apps and add-ons
- Domains and TLS
- Keycloak
- Generic OIDC and GitLab
- Configuration
- First deployment
- Backups
- RPO and RTO
- Restore the Studio on a fresh installation
- Redeploys
- Upgrading the server and checking state after a migration
- Limits of going back
- Monitoring
- Security
- Rotating keys
- Recovering admin access
- Changing domain or OIDC provider
- Worker, PostgreSQL or Cellar down
- Exporting the game and leaving the installation
- Retention
- Clever Cloud troubleshooting
- Costs and teardown
Reality Bridge and connectors (16)
- The Reality Bridge: what it is
- Quick start
- Guarantees
- Install and run the Bridge
- Backup and restore
- Several tenants
- Signals and the manifest
- The Bridge's command line
- Connectors overview
- Email connector
- Telnet connector
- SSH connector
- Open Badges connector
- The connector SDK
- Security: Biscuit and signatures
- Bridge and connector troubleshooting
Contribute (25)
- Welcome
- Developer setup
- The dev loop
- Before a pull request
- Conventions
- Writing documentation
- Architecture
- Code tour
- Import boundaries
- Which tests run when
- Mutation testing
- The coverage ratchet
- The quality baseline
- CI explained
- Field passes
- Benchmarks
- Releasing
- npm packages
- Decisions and ADRs
- Governance
- Bot pull requests
- Contributing with AI agents
- Security policy
- Code of conduct
- Licences and credits